微服務架構到底應該如何選擇？
什麼是微服務？
微服務的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出，他們定義了微服務是由單一應用程式構成的小服務，擁有自己的程序與輕量化處理，服務依業務功能設計，以全自動的方式部署，與其他服務使用 HTTP API 通訊。同時，服務會使用最小規模的集中管理 （例如 Docker）技術，服務可以用不同的程式語言與資料庫等。
微服務是SOA架構下的最終產物，該架構的設計目標是為了肢解業務，使得服務能夠獨立執行。
主要有一下幾個特點
服務拆分粒度更細微服務可以說是更細維度的服務化，小到一個子模組，只要該模組依賴的資源與其他模組都沒有關係，那麼就可以拆分為一個微服務。
服務獨立部署
每個微服務都嚴格遵循獨立打包部署的準則，互不影響。比如一臺物理機上可以部署多個 Docker 例項，每個 Docker 例項可以部署一個微服務的程式碼。
服務獨立維護
每個微服務都可以交由一個小團隊甚至個人來開發、測試、釋出和運維，並對整個生命週期負責。
服務治理能力要求高
因為拆分為微服務之後，服務的數量變多，因此需要有統一的服務治理平臺，來對各個服務進行管理。
微服務架構下，服務呼叫主要依賴下面幾個基本元件： 服務描述 註冊中心 服務框架 服務監控 服務追蹤 服務治理
開源RPC框架介紹
Dubbo
國內最早開源的 RPC 框架，由阿里巴巴公司開發並於 2011 年末對外開源，僅支援 Java 語言。中間一度沒人維護坑了不少人，17年重啟維護煥發新春。架構圖如下
官網： http://dubbo.io/
通訊框架方面，Dubbo 預設採用了 Netty 作為通訊框架。
通訊協議方面，Dubbo 除了支援私有的 Dubbo 協議外，還支援 RMI 協議、Hession 協議、HTTP 協議、Thrift 協議等。
序列化格式方面，Dubbo 支援多種序列化格式，比如 Dubbo、Hession、JSON、Kryo、FST 等。
Tars
Tars是基於名字服務使用Tars協議的高效能RPC開發框架，同時配套一體化的服務治理平臺，幫助個人或者企業快速的以微服務的方式構建自己穩定可靠的分散式應用。
Tars是將騰訊內部使用的微服務架構TAF（Total Application Framework）多年的實踐成果總結而成的開源專案。
官網： https://github.com/TarsCloud/...
架構圖如下
開源協議為：BSD-3-Clause
支援多語言 C++，Java，Nodejs，PHP，Go
效能： https://github.com/TarsCloud/...
gRPC
一開始由 google 開發，是一款語言中立、平臺中立、開源的遠端過程呼叫(RPC)系統。
官網： https://grpc.io
基於HTTP/2HTTP/2 提供了連線多路複用、雙向流、伺服器推送、請求優先順序、首部壓縮等機制。可以節省頻寬、降低TCP連結次數、節省CPU，幫助移動裝置延長電池壽命等。gRPC 的協議設計上使用了HTTP2 現有的語義，請求和響應的資料使用HTTP Body 傳送，其他的控制資訊則用Header 表示。
IDL使用ProtoBufgRPC使用ProtoBuf來定義服務，ProtoBuf是由Google開發的一種資料序列化協議（類似於XML、JSON、hessian）。ProtoBuf能夠將資料進行序列化，並廣泛應用在資料儲存、通訊協議等方面。壓縮和傳輸效率高，語法簡單，表達力強。
多語言支援（C, C++, Python, PHP, Nodejs, C#, Objective-C、Golang、Java）
gRPC支援多種語言，並能夠基於語言自動生成客戶端和服務端功能庫。目前已提供了C版本grpc、Java版本grpc-java 和 Go版本grpc-go，其它語言的版本正在積極開發中，其中，grpc支援C、C++、Node.js、Python、Ruby、Objective-C、PHP和C#等語言，grpc-java已經支援Android開發。
Motan
Motan 是國內另外一個比較有名的開源的 RPC 框架，同樣也只支援 Java 語言實現，它的架構可以用下面這張圖描述。
Motan 與 Dubbo 的架構類似，都需要在 Client 端（服務消費者）和 Server 端（服務提供者）引入 SDK，其中 Motan 框架主要包含下面幾個功能模組。
register：用來和註冊中心互動，包括註冊服務、訂閱服務、服務變更通知、服務心跳傳送等功能。Server 端會在系統初始化時通過 register 模組註冊服務，Client 端會在系統初始化時通過 register 模組訂閱到具體提供服務的 Server 列表，當 Server 列表發生變更時也由 register 模組通知 Client。
protocol：用來進行 RPC 服務的描述和 RPC 服務的配置管理，這一層還可以新增不同功能的 filter 用來完成統計、併發限制等功能。
serialize：將 RPC 請求中的引數、結果等物件進行序列化與反序列化，即進行物件與位元組流的互相轉換，預設使用對 Java 更友好的 Hessian 2 進行序列化。
transport：用來進行遠端通訊，預設使用 Netty NIO 的 TCP 長連結方式。
cluster：Client 端使用的模組，cluster 是一組可用的 Server 在邏輯上的封裝，包含若干可以提供 RPC 服務的 Server，實際請求時會根據不同的高可用與負載均衡策略選擇一個可用的 Server 發起遠端呼叫。
Spring Cloud
Spring Cloud 是為了解決微服務架構中服務治理而提供的一系列功能的開發框架，它是完全基於 Spring Boot 進行開發的，Spring Cloud 利用 Spring Boot 特性整合了開源行業中優秀的元件，整體對外提供了一套在微服務架構中服務治理的解決方案。它的架構圖可以用下面這張圖來描述。
以下為Spring Cloud的核心功能：
- 分散式/版本化配置
- 服務註冊和發現
- 路由
- 服務和服務之間的呼叫
- 負載均衡
- 斷路器
- 分散式訊息傳遞
Spring Cloud對於中小型網際網路公司來說是一種福音，因為這類公司往往沒有實力或者沒有足夠的資金投入去開發自己的分散式系統基礎設施，使用Spring Cloud一站式解決方案能在從容應對業務發展的同時大大減少開發成本。
下圖是RPC框架詳細的比較
如何選擇？
一家A輪融資的公司 原來架構是net，想換java架構。
公司沒有強大的研發實力，公司主要是to B業務，對併發要求不高，那可以試試Spring Cloud 架構，
Spring Cloud 不僅提供了基本的 RPC 框架功能，還提供了服務註冊元件、配置中心元件、負載均衡元件、斷路器元件、分散式訊息追蹤元件等一系列元件，被技術圈的人稱之為“Spring Cloud 全家桶”，而 Dubbo、Motan 基本上只提供了最基礎的 RPC 框架的功能，其他微服務元件都需要自己去實現,對於這類研發能力弱的團隊，SpringCloud 無疑是最合適的，減少了研發成本，社群熱度高，相關的教程文件很多，減少了入門成本；
再比如這家公司不準備切換Java框架還是繼續使用net架構， 有一定的研發能力，對併發要求很高， 那gRPC無疑是最適合的，跨語言支援，高效能；
沒有完美的解決方案，只有最合適的
推薦閱讀
學習Java進階技術乾貨、實踐分享，職位內推，一起聊聊理想。志同道合的朋友，歡迎你的加入。
