在移動及雲時代，盡管大部分可擴充的問題可以通過雲平台解決，但是服務本身的擴充性挑戰仍然存在。比如一個新的項目，用PHP或JSP實作了基本功能，部署在Apache或Tomcat等容器上，在業界這種部署在一個容器内的功能子產品通常可以稱為一個service。服務容器很容易通過EC2或者docker等方式來擴充部署更多的執行個體。但service本身的管理的以下幾個方面的問題仍然需要架構師去設計及解決。
1、服務的遠端調用（RPC）。
随着系統的使用者通路規模增大，以及系統功能的增多，衆多的功能子產品(service)很難用單個service來承載，這些不同功能的service可能由不同的開發團隊開發，甚至使用不同的開發語言，最終部署在不同的伺服器容器内。Service之間的調用需要一種協定及遠端調用的實作，需要具備靈活的data type支援，對調用雙方透明（理想情況它就像在執行本地調用），并且具有良好的性能。比較典型的RPC實作有
Google: Protocol Buffers RPC
Facebook: Thrift
Twitter: Finagle
2、服務的分布式調用鍊及服務狀态跟蹤統計
随着系統内部的服務增多，一個功能的調用可能會通過系統内部多個服務互相調用來完成，并且這些服務可能由不同的團隊開發，并且分布在不同的伺服器容器，甚至可能在多個地域不同的機房内。是以分布式系統需要有一種方式來清晰的了解系統的調用及運作狀況，測量系統的運作性能，友善準确的指導系統的優化及改進。
由于trace的主要功能都是依賴日志輸出來完成，是以通常也需要建設相關的分布式日志系統及資料實時分析展示系統等，分布式日志收集及資料實時分析也是一個非常大的話題，本文不展開詳談。比較典型的trace系統有
Google: Dapper
Twitter: zipkin
3、服務的配置管理。包括服務發現、負載均衡及服務依賴管理。
比較常用的服務發現是域名方式，調用方通過域名來定位目标服務。域名尋址方式可通過配置多IP（或VIP）來實作負載均衡。域名方式存在一些弊端，常用的DNS伺服器通常是上個世紀的産物，管理繁瑣，更新域名記錄後由于協定設計上存在的TTL緩存機制，修改不能立即生效，也無法做變更的push操作。更進階的特性如控制流量、灰階釋出等也無法實作。
目前，成熟的分布式服務較多使用基于ZooKeepr的配置服務，ZooKeeper由于與client保持長連，是以具有push能力，可以迅速的調整配置及生效。但由于ZooKeeper本身隻是一個通用工具，分布式服務具體場景各種進階特性還需要自行在此基礎上實作。
基于DNS的服務發現在負載均衡方面具有明顯缺點，由于多IP或VIP使用類似round robin的政策，在實踐中，同一服務的多個IP之間負載通常并不均衡。而服務提供方并沒有有效手段對runtime期間不均衡進行調整。基于ZooKeeper的配置服務可以支援各種複雜的特性，但需要做一些定制化開發，但服務發現作為系統中最核心的一個環節，這些定制化開發需要較多的經驗的積累及沉澱，之前線上上就碰到過配置服務将一個服務池中疑似不穩定的節點移除過多，進而導緻出現雪崩的情況。
除了ZooKeeper之外，業界還有一些類似工具，如serfdom及consui。
4、服務之間的排程及生命周期管理
目前大部分服務的部署都是按照事先的規劃安裝在機房不同的伺服器上，配置服務通常隻是起服務節點的failover作用，業務中真正按彈性排程來運作的系統還不普遍。但原理上所有的service可以看做是MapReduce中的task，它的排程及生命周期可以很高效的由分布式容器來管理，并且根據service的屬性來靈活的配置設定資源，比如控制CPU的核及記憶體大小。
業界比較成熟的有Apache旗下的Mesos及YARN。它們的特性有點類似，但是由不同的組織開發。Mesos主要功能是由C++來實作，可以支援docker container來進行排程，是以它的實作更偏底層一些。Yarn是Hadoop 2的一部分，可以更靈活的來排程MapReduce jobs，它是一種JVM内部的實作，可以很好的支援JVM級别的任務配置設定及排程。
上面介紹了這麼多，主要是最近考慮團隊在上述1-4之間做一些事情。一方面目前業界在這幾點之間還有一些缺失或者欠優化之處，另外1-4點之間也可以适當做一些實作的整合。整合并不是要産出一個大而龐雜的軟體，我個人是極力反對大而全，也不喜歡沉重的架構，業務的service實作方不應該import太多工具或者SDK，是以将要做的功能肯定是透明及可插拔的。
由于這件事情并沒有嚴格的可參考目标，是以對于最終實作的是哪個子集還存在一些不确定因素，這個項目如果具有通用性，也考慮以開源的方式來開發。