分布式服務框架的4項特性

在移動及云時代，盡管大部分可擴展的問題可以通過云平臺解決，但是服務本身的擴展性挑戰仍然存在。比如一個新的項目，用PHP或JSP實現了基本功 能，部署在Apache或Tomcat等容器上，在業界這種部署在一個容器內的功能模塊通常可以稱為一個service。服務容器很容易通過EC2或者 docker等方式來擴展部署更多的實例。但service本身的管理的以下幾個方面的問題仍然需要架構師去設計及解決。

1、服務的遠程調用（RPC）。

隨著系統的用戶訪問規模增大，以及系統功能的增多，眾多的功能模塊(service)很難用單個service來承載，這些不同功能的 service可能由不同的開發團隊開發，甚至使用不同的開發語言，最終部署在不同的服務器容器內。Service之間的調用需要一種協議及遠程調用的實 現，需要具備靈活的data type支持，對調用雙方透明（理想情況它就像在執行本地調用），并且具有良好的性能。比較典型的RPC實現有
Google: Protocol Buffers RPC
非死book: Thrift
推ter: Finagle

2、服務的分布式調用鏈及服務狀態跟蹤統計

隨著系統內部的服務增多，一個功能的調用可能會通過系統內部多個服務相互調用來完成，并且這些服務可能由不同的團隊開發，并且分布在不同的服務器容 器，甚至可能在多個地域不同的機房內。因此分布式系統需要有一種方式來清晰的了解系統的調用及運行狀況，測量系統的運行性能，方便準確的指導系統的優化及 改進。

由于trace的主要功能都是依賴日志輸出來完成，因此通常也需要建設相關的分布式日志系統及數據實時分析展示系統等，分布式日志收集及數據實時分析也是一個非常大的話題，本文不展開詳談。比較典型的trace系統有
Google: Dapper
推ter: 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，因此將要做的功能肯定是透明及可插拔的。

來自：http://timyang.net/distributed/service-architecture/