微服務架構到底應該如何選擇？

什麼是微服務？

微服務的概念最先是在 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 等。

性能：
http://dubbo.apache.org/zh-cn...

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/2
HTTP/2 提供了鏈接多路複用、雙向流、服務器推送、請求優先級、首部壓縮等機制。能夠節省帶寬、下降TCP連接次數、節省CPU，幫助移動設備延長電池壽命等。gRPC 的協議設計上使用了HTTP2 現有的語義，請求和響應的數據使用HTTP Body 發送，其餘的控制信息則用Header 表示。

IDL使用ProtoBuf
gRPC使用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無疑是最適合的，跨語言支持，高性能；

沒有完美的解決方案，只有最合適的

推薦閱讀

互聯網公司面試必問的Redis題目

互聯網公司面試必問的mysql題目(下)

學習Java進階技術乾貨、實踐分享，職位內推，一塊兒聊聊理想。志同道合的朋友，歡迎你的加入。