微服務不同於單一架構應用, 是典型的分布式場景, 各服務之間通過IPC進行通信. 實現微服務的過程中, 我們需要解決以下問題:
- 服務注冊和服務發現.
- 根據應用選擇合適的通信協議和數據協議. 例如可以選用thrift, protocol buffer或REST.
- 服務負載均衡. 一個服務一般會部署多個實例. 如果使壓力均勻分布是需要考慮的問題.
- 服務路由與限流.
- 容錯處理. 相對於單機應用, 分布式環境下錯誤發生的概率會大大提高, 服務宕機, 網絡不可用的情況時常發生.
- 服務監控. 各服務實例的性能指標, 例如請求響應時間, 請求並發數量, 以及服務實例的部署數量等.
- 事務一致性. 一般來說這個問題需要我們結合業務自己處理, 框架不會給我們太多幫助.
好的微服務框架應該能幫助我們解決上面的全部或者大部分問題.目前常見的微服務相關框架：
- Dubbo、DubboX
- Spring Cloud(Netflix OSS)
- Finagle
- Motan
- Thrift、gRPC
一、Dubbo優缺點：
Dubbo幾乎是唯一能被稱作全棧微服務框架的“框架”，它包含了微服務所需的幾乎所有內容，而DubboX作為它的增強，增加了REST支持。
優點很多，例如：
- 全棧，服務治理的所有問題幾乎都有現成答案
- 可靠，經過阿里實踐檢驗的產品
- 實踐多，社區有許多成功應用Dubbo的經驗
不過遺憾的是：
- 已經停止維護
- 不利於裁剪使用
- “過於Java”，與其他語言相容性一般
二、Motan優缺點：
Motan是微博平台微服務框架，承載了微博平台千億次調用業務。優點是：
- 性能好，源自於微博對高並發和實時性的要求
- 模塊化，結構簡單，易於使用
- 與其他語言相容性好
不過：
- 為“短平快”業務而生，即業務簡單，追求高性能高並發。
三、Apache Thrift、gRPC優缺點：
Apache Thrift、gRPC等雖然優秀，並不能算作微服務框架，自身並不包括服務發現等必要特性。如果說微服務少不了Java，那么一定少不了Spring，如果說少不了Spring，那么微服務“官配”Spring Cloud當然是值得斟酌的選擇。優點：
- “不做生產者，只做搬運工”
- 簡單方便，幾乎零配置
- 模塊化，松散耦合，按需取用
- 社區背靠Spring大樹
不足：
- 輕量並非全棧
- 沒解決RPC的問題
- 實踐案例少
根據我們的目標，我們最終選擇了Spring Cloud作為我們的微服務框架，原因有4點：
- 雖然Dubbo基礎設施更加完善，但結構復雜，我們很難吃得下，容易出坑
- 基於Apache Thrift、gRPC自研，投入產出比很差
- 不想過早引入RPC以防濫用，Restful風格本身就是一種約束。
四、Finagle
關於Finagle的使用請參見:http://skaka.me/blog/2016/03/19/finagle1/
五、Spring Cloud
Spring Cloud是一個集成框架，將開源社區中的框架集成到Spring體系下，幾個重要的家族項目：
- Spring-boot:一改Java應用程序運行難、部署難，甚至無需Web容器，只依賴JRE即可
- Spring-cloud-netflix:集成Netflix優秀的組件Eureka、Hystrix、Ribbon、Zuul，提供服務發現、限流、客戶端負載均衡和API網關等特性支持;
- Spring-cloud-config:微服務配置管理
- Spring-cloud-consul:集成Consul支持
關於Spring-cloud的使用請參見:http://blog.xujin.org/sc/sc-fx1/