在移動及雲時代，儘管大部分可擴充套件的問題可以通過雲平台解決，但是服務本身的擴充套件性挑戰仍然存在。比如乙個新的專案，用php或jsp實現了基本功能，部署在apache或tomcat等容器上，在業界這種部署在乙個容器內的功能模組通常可以稱為乙個service。服務容器很容易通過ec2或者docker等方式來擴充套件部署更多的例項。但service本身的管理的以下幾個方面的問題仍然需要架構師去設計及解決。
1、服務的遠端呼叫（rpc）
隨著系統的使用者訪問規模增大，以及系統功能的增多，眾多的功能模組(service)很難用單個service來承載，這些不同功能的service可能由不同的開發團隊開發，甚至使用不同的開發語言，最終部署在不同的伺服器容器內。service之間的呼叫需要一種協議及遠端呼叫的實現，需要具備靈活的data type支援，對呼叫雙方透明（理想情況它就像在執行本地呼叫），並且具有良好的效能。比較典型的rpc實現有
2、服務的分布式呼叫鏈及服務狀態跟蹤統計
隨著系統內部的服務增多，乙個功能的呼叫可能會通過系統內部多個服務相互呼叫來完成，並且這些服務可能由不同的團隊開發，並且分布在不同的伺服器容器，甚至可能在多個地域不同的機房內。因此分布式系統需要有一種方式來清晰的了解系統的呼叫及執行狀況，測量系統的執行效能，方便準確的指導系統的優化及改進。
3、服務的配置管理。包括服務發現、負載均衡及服務依賴管理。
比較常用的服務發現是網域名稱方式，呼叫方通過網域名稱來定位目標服務。網域名稱定址方式可通過配置多ip（或vip）來實現負載均衡。網域名稱方式存在一些弊端，常用的dns伺服器通常是上個世紀的產物，管理繁瑣，更新網域名稱記錄後由於協議設計上存在的ttl快取機制，修改不能立即生效，也無法做變更的push操作。更高階的特性如控制流量、灰度發布等也無法實現。
目前，成熟的分布式服務較多使用基於zookeepr的配置服務，zookeeper由於與client保持長連，因此具有push能力，可以迅速的調整配置及生效。但由於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，因此將要做的功能肯定是透明及可插拔的。
由於這件事情並沒有嚴格的可參考目標，因此對於最終實現的是哪個子集還存在一些不確定因素，這個專案如果具有通用性，也考慮以開源的方式來開發。
【體驗 coding 極速**庫，抽取機械鍵盤 】極速**庫是 coding 基於 git 搭建，速度和效能極佳的 git **託管服務。詳情: www.coding.net 。
分布式服務框架的4項特性
在移動及雲時代，儘管大部分可擴充套件的問題可以通過雲平台解決，但是服務本身的擴充套件性挑戰仍然存在。比如乙個新的專案，用php或jsp實現了基本功能，部署在apache或tomcat等容器上，在業界這種部署在乙個容器內的功能模組通常可以稱為乙個service。服務容器很容易通過ec2或者docker...
分布式服務框架 Zookeeper
createmode persistent 建立後只要不刪就永久存在 ephemeral 會話結束年結點自動被刪除，ephemeral結點不允許有子節點 sequential 節點名末尾會自動追加乙個10位數的單調遞增的序號，同乙個節點的所有子節點序號是單調遞增的 persistent sequen...
大型分布式服務框架
1 首先遠端服務呼叫有三種模式 同步 非同步 future 非同步 callback 三種呼叫模型,正常的都是同步呼叫，呼叫的時候阻塞當前執行緒，非同步一般只會在特殊的情景下有用。2 全域性配置 所有服務的配置應該是需要在乙個全域性配置中心配置 zookeeper集群 的，而不是寫死在 裡面，避免出...