這幾年在 Java 工程師招聘時，會看到很多人的簡歷都寫著使用了 Spring Cloud 做微服務實現(xiàn)，使用 Docker 做自動化部署，并且也會把這些做為自己的亮點。 

[[287298]]

圖片來自 Pexels

而比較有趣的這其中以小公司出來的人為絕大多數(shù)，大的公司出來的人簡歷上倒是很少提這些東西。

對于我自己來說，從 2015 年就開始關(guān)注這一塊，看過馬丁·福勒最開始的關(guān)于微服務的論文、也看過不少對微服務的論證的英文文章和書，也研究過 Spring Cloud、Sofa 等開源實現(xiàn)以及 Service Mesh。

考慮到我們公司研發(fā)團隊人力不足、基礎(chǔ)設施不完善，當初是沒有推行微服務的。

但隨著看到上述的那種簡歷越來越多，有時候我也會疑問：難道真的不用微服務就落后了嗎?公司的同事如果不掌握這些就真的沒有競爭力了嗎。

而隨著最近公司業(yè)務的逐步提升，研發(fā)人員越來越多，借著在梳理公司的微服務落地計劃時，也梳理了一下微服務的相關(guān)知識點，也是本文的主要內(nèi)容。

主要從以下幾個方面跟大家分享：

• 微服務是什么
• 為什么要采用微服務
• 微服務架構(gòu)
• 架構(gòu)設計模式
• 服務拆分
• 微服務框架

開篇之前先聲明我對微服務的幾點態(tài)度：

• 架構(gòu)模式有很多，微服務不是唯一的選擇也不是什么銀彈。國內(nèi)絕大多數(shù)中小公司引入微服務都是在盲目追新，也能看出做此種技術(shù)選型的工程師基礎(chǔ)架構(gòu)素質(zhì)的不足。
• “你必須長的足夠高才能使用微服務”。微服務基礎(chǔ)設施，尤其是容器技術(shù)、自動化部署、自動化測試這些不完備，微服務形同虛設，不會帶來什么質(zhì)的提升。
• 微服務架構(gòu)的關(guān)鍵不在于具體的實現(xiàn)，而在于如何合理地劃分服務邊界以及組織架構(gòu)是否相匹配。不考慮研發(fā)團隊的規(guī)模和組成就盲目上微服務是不良的技術(shù)選型。
• Spring Boot 是 Spring 全家桶的上層封裝，并不是什么嶄新的技術(shù)，也不是什么值得成為自己殺手锏的技術(shù)。
• Spring Cloud 中 Spring Cloud Netflix 的組件是經(jīng)過生產(chǎn)環(huán)境驗證的，其他的則建議慎重選擇。

微服務是什么

微服務起源于 2005 年 Peter Rodgers 博士在云端運算博覽會提出的微 Web 服務(Micro-Web-Service)，根本思想類似于 Unix 的管道設計理念。

2014 年，由 Martin Fowler 與 James Lewis 共同提出了微服務的概念，定義了微服務架構(gòu)風格是一種通過一套小型服務來開發(fā)單個應用的方法，每個服務運行在自己的進程中，并通過輕量級的機制進行通訊(HTTP API)。

關(guān)鍵的三點是：

• small
• automated
• lightweight

對比 SOA，微服務可以看做是 SOA 的子集，是輕量級的 SOA，粒度更細的服務，獨立進程、數(shù)據(jù)分離，更注重敏捷、持續(xù)交付、DevOps 以及去中心化實踐。

其共同的架構(gòu)原理：

• 單一職責
• 關(guān)注分離：控制與邏輯相分離
• 模塊化和分而治之

特點：

• 用服務進行組件化
• 圍繞業(yè)務能力進行組織
• 是產(chǎn)品而非項目
• 端點智能化和啞管道: 控制邏輯都在端點，管道僅僅是傳輸
• 全自動化部署
• 語言和數(shù)據(jù)的去中心化控制
• 面向失敗設計
• 漸進式設計

綜合來看，其優(yōu)缺點如下：

• 優(yōu)點：模塊的強邊界;獨立部署;技術(shù)選型的多樣性。
• 缺點：分布式帶來編程復雜度，遠程調(diào)用的消耗;舍棄強一致性，實現(xiàn)最終一致性;操作復雜性要求有一個成熟的運維團隊或者運維基礎(chǔ)設施。

為什么要采用微服務

是否選擇微服務取決于你要設計的系統(tǒng)的復雜度。微服務是用來把控復雜系統(tǒng)的，但是隨之而來的就是引入了微服務本身的復雜度。

需要解決包括自動化部署、監(jiān)控、容錯處理、最終一致性等其他分布式系統(tǒng)面臨的問題。即使已經(jīng)有一些普遍使用的解決方案，但是仍然是有不小的成本的。

生產(chǎn)力和復雜度的關(guān)系如圖所示，可見系統(tǒng)越復雜，微服務帶來的收益越大。此外，無論是單體應用還是微服務，團隊的技能都需要能夠把控住。 

馬丁·福勒的一個觀點是：除非管理單體應用的成本已經(jīng)太復雜了(太大導致很難修改和部署)，否則都不要考慮微服務。

大部分應用都應該選擇單體架構(gòu)，做好單體應用的模塊化而不是拆分成服務。

因此，系統(tǒng)一開始采用單體架構(gòu)，做好模塊化，之后隨著系統(tǒng)變得越來越復雜、模塊/服務間的邊界越來越清晰，再重構(gòu)為微服務架構(gòu)是一個合理的架構(gòu)演化路徑。

四個可以考慮上微服務的情況：

• 多人開發(fā)一個模塊/項目，提交代碼頻繁出現(xiàn)大量沖突。
• 模塊間嚴重耦合，互相依賴，每次變動需要牽扯多個團隊，單次上線需求太多，風險大。
• 主要業(yè)務和次要業(yè)務耦合，橫向擴展流程復雜。
• 熔斷降級全靠 if-else。

微服務的三個階段：

• 微服務 1.0：僅使用注冊發(fā)現(xiàn)，基于 Spring Cloud 或者 Dubbo 進行開發(fā)。
• 微服務 2.0：使用了熔斷、限流、降級等服務治理策略，并配備完整服務工具和平臺。
• 微服務 3.0：Service Mesh 將服務治理作為通用組件，下沉到平臺層實現(xiàn)，應用層僅僅關(guān)注業(yè)務邏輯，平臺層可以根據(jù)業(yè)務監(jiān)控自動調(diào)度和參數(shù)調(diào)整，實現(xiàn) AIOps 和智能調(diào)度。

微服務架構(gòu)

先決條件

微服務的先決條件如下：

• 快速的環(huán)境提供能力：依賴于云計算、容器技術(shù)，快速交付環(huán)境。
• 基本的監(jiān)控能力：包括基礎(chǔ)的技術(shù)監(jiān)控和業(yè)務監(jiān)控。
• 快速的應用部署能力：需要部署管道提供快速的部署能力。
• Devops 文化：需要具有良好的持續(xù)交付能力，包括全鏈路追蹤、快速環(huán)境提供和部署等，還需要快速的反應能力(對問題、故障的快速響應)，開發(fā)和運維的協(xié)同工作。

此外，根據(jù)康威定律和逆康威定律(技術(shù)架構(gòu)倒逼組織架構(gòu)改進)，組織架構(gòu)也是一個很關(guān)鍵的因素。

對應于微服務架構(gòu)，組織架構(gòu)需要遵循以下原則：

• 一個微服務由一個團隊維護，團隊成員以三人為宜。
• 單個團隊的任務和發(fā)展是獨立的，不受其他因素影響。
• 團隊是功能齊全、全棧、自治的，扁平、自我管理。

基礎(chǔ)設施

微服務的推行需要依賴于很多底層基礎(chǔ)設施，包括提供微服務的編譯、集成、打包、部署、配置等工作，采用 PaaS 平臺解決微服務從開發(fā)到運行的全生命周期管理，同時提供異構(gòu)環(huán)境管理、容器資源隔離與互通、服務伸縮漂移、服務升級與回退、服務熔斷與降級、服務注冊與發(fā)現(xiàn)。

①最基本的基礎(chǔ)設施

進程間通訊機制：微服務是獨立進程的，需要確定之間的通訊方式。

服務發(fā)現(xiàn)+服務路由：提供服務注冊中心，服務提供者和消費者通過服務發(fā)現(xiàn)獲取服務的信息從而調(diào)用服務，實現(xiàn)服務的負載均衡等。

服務容錯：微服務架構(gòu)中，由于服務非常多，往往是一個服務掛了，整個請求鏈路的服務都受到影響。

因此需要服務容錯，在服務調(diào)用失敗的時候能夠處理錯誤或者快速失敗，包括熔斷、Fallback、重試、流控和服務隔離等。

分布式事務支持：隨著業(yè)務拆分為服務，那么有時候不開避免的就是跨服務的事務，即分布式事務的問題。

原則是盡量避免分布式事務，如果無法避免那么可以使用消息系統(tǒng)或者 CQRS 和 Event Sourcing 方案來實現(xiàn)最終一致性。

如果需要強一致性，則有兩階段提交、三階段提交、TCC 等分布式事務解決方案。

②提升外部服務對接效率和內(nèi)部開發(fā)效率

API 網(wǎng)關(guān)：負責外部系統(tǒng)的訪問，跨橫切面的公共層面的工作，包括安全、日志、權(quán)限控制、傳輸加密、請求轉(zhuǎn)發(fā)、流量控制等。

典型的網(wǎng)關(guān)功能即對外暴露一個域名 xx.com，根據(jù)第一級目錄做反向路由 xx.com/user，xx.com/trade。

每一級目錄，如 user、trade 對應一個服務的域名。此外，API 網(wǎng)關(guān)也可以有服務編排的功能(不推薦)。

接口框架：規(guī)范服務之間通訊使用的數(shù)據(jù)格式、解析包、自解釋文檔，便于服務使用方快速上手等。

③提升測試和運維效率

配置中心: 運行時配置管理能夠解決動態(tài)修改配置并批量生效的問題。包括配置版本管理、配置項管理、節(jié)點管理、配置同步等。

持續(xù)交付：包括持續(xù)集成、自動化部署等流程。目的就是小步迭代，快速交付。

持續(xù)集成：這一部分并非是微服務特定的，對于之前的單體應用，此部分一般來說也是必要的。

主要是指通過自動化手段，持續(xù)地對代碼進程編譯構(gòu)建、自動化測試，以得到快速有效的質(zhì)量反饋，從而保證代碼的順利交付。

自動化測試包括代碼級別的單元測試、單個系統(tǒng)的集成測試、系統(tǒng)間的接口測試。

自動化部署：微服務架構(gòu)，節(jié)點數(shù)動輒上百上千，自動化部署能夠提高部署速度和部署頻率，從而保證持續(xù)交付。

包括版本管理、資源管理、部署操作、回滾操作等功能。而對于微服務的部署方式，包括藍綠部署、滾動部署以及金絲雀部署。

④進一步提升運維效率

服務監(jiān)控：微服務架構(gòu)下節(jié)點數(shù)目眾多，需要監(jiān)控的機器、網(wǎng)絡、進程、接口等的數(shù)量大大增加，需要一個強大的監(jiān)控系統(tǒng)，能夠提供實時搜集信息進行分析以及實時分析之上的預警。

包括監(jiān)控服務的請求次數(shù)、響應時間分布、最大/最小響應值、錯誤碼分布等。

服務跟蹤：跟蹤一個請求的完整路徑，包括請求發(fā)起時間、響應時間、響應碼、請求參數(shù)、返回結(jié)果等信息，也叫做全鏈路跟蹤。

通常的服務可以和服務監(jiān)控做在一起，宏觀信息由服務跟蹤呈現(xiàn)，微觀單個服務/節(jié)點的信息由服務監(jiān)控呈現(xiàn)。服務跟蹤目前的實現(xiàn)理論基本都是 Google 的 Dapper 論文。

服務安全：內(nèi)網(wǎng)之間的微服務調(diào)用原則上講應該是都可以互相訪問寫，一般并不需要權(quán)限控制，但有時候限于業(yè)務要求，會對接口、數(shù)據(jù)等方面有安全控制的要求。

此部分可以以配置的方式存在于服務注冊中心中，和服務綁定，在請求時由做為服務提供者的服務節(jié)點進行安全策略控制。配置則可以存儲在配置中心以方便動態(tài)修改。

在微服務數(shù)量很少的情況下，以上基礎(chǔ)設施的優(yōu)先級自上而下降低。否則，僅僅依賴人工操作，則投入產(chǎn)出比會很低。

還需要提到的是 Docker 容器技術(shù)。雖然這個對于微服務并不是必須的，但是容器技術(shù)輕量級、靈活、與應用依存、屏蔽環(huán)境差異的特性對于持續(xù)交付的實現(xiàn)是至關(guān)重要的，即使對于傳統(tǒng)的單體應用也能夠給其帶來交付效率的大幅提升。

架構(gòu)設計模式

在引入微服務之后，傳統(tǒng)的單體應用變?yōu)榱艘粋€一個服務，之前一個應用直接提供接口給客戶端訪問的架構(gòu)不再適用。

微服務架構(gòu)下，針對不同設備的接口做為 BFF 層(Backend For Frontend)，也叫做用戶體驗適配層，負責聚合、編排微服務的數(shù)據(jù)轉(zhuǎn)換成前端需要的數(shù)據(jù)。

服務之間的調(diào)用則在允許的情況下(允許延遲)盡可能使用異步消息傳遞方式，如此形成面向用戶體驗的微服務架構(gòu)設計模式。

如下圖所示：

 

Client→API Gateway→BFF(Backend For Frontend)→Downstream Microservices：

• 后臺采用微服務架構(gòu)，微服務可以采用不同的編程語言和不同的存儲機制。
• 前臺采用 BFF 模式對不同的用戶體驗(如桌面瀏覽器，Native App，平板響應式 Web)進行適配。
• BFF、API Orchestration Layer，Edge Service Layer，Device Wrapper Layer 是相同的概念。
• BFF 不能過多，過多會造成代碼邏輯重復冗余。
• 可以將網(wǎng)關(guān)承擔的功能，如 Geoip、限流、安全認證等跨橫切面功能和 BFF 做在同一層，雖然增加了 BFF 層的復雜性，但能夠得到性能優(yōu)勢。

服務拆分

微服務架構(gòu)最核心的環(huán)節(jié)，主要是對服務的橫向拆分。服務拆分就是將一個完整的業(yè)務系統(tǒng)解耦為服務，服務需要職責單一，之間沒有耦合關(guān)系，能夠獨立開發(fā)和維護。

服務拆分不是一蹴而就的，需要在開發(fā)過程中不斷地理清邊界。在完全理清服務之前，盡量推遲對服務的拆分，尤其是對數(shù)據(jù)庫的拆分。

拆分方法如下：

• 基于業(yè)務邏輯拆分
• 基于可擴展拆分
• 基于可靠性拆分
• 基于性能拆分

其中，對于無法修改的遺留系統(tǒng)，采用絞殺者模式：在遺留系統(tǒng)外面增加新的功能做成微服務方式，而不是直接修改原有系統(tǒng)，逐步的實現(xiàn)對老系統(tǒng)替換。

拆分過程需要遵守的規(guī)范如下：

• 先少后多、先粗后細(粒度)
• 服務縱向拆分最多三層，兩次調(diào)用：Controller、組合服務、基礎(chǔ)服務
• 僅僅單向調(diào)用，禁止循環(huán)調(diào)用
• 串行調(diào)用改為并行調(diào)用或者異步化
• 接口應該冪等
• 接口數(shù)據(jù)定義嚴禁內(nèi)嵌，透傳
• 規(guī)范化工程名
• 先拆分服務，等服務粒度確定后再拆分數(shù)據(jù)庫。

微服務框架

上面講述了微服務架構(gòu)的眾多基礎(chǔ)設施，如果每一個基礎(chǔ)設施都需要自己開發(fā)的話是非常巨大的開發(fā)工作。目前市面上已經(jīng)有不少開源的微服務框架可以選擇。

Spring Boot

Spring Boot 是用來簡化新 Spring 應用的初始搭建以及開發(fā)過程的。其雖然不是微服務框架，但其設計的初衷本質(zhì)就是微應用的底層框架，因此非常適合用于微服務基礎(chǔ)設施的開發(fā)以及微服務的應用開發(fā)。

尤其對于 Spring 技術(shù)棧的團隊來說，基于 Spring Boot 開發(fā)微服務框架和應用是自然而然的一個選擇。

Dubbo&Motan

Dubbo 是阿里開源的服務治理框架。其出現(xiàn)在微服務理念興起之前，可以看做是 SOA 框架的集大成之作。

但其僅僅包含了微服務基礎(chǔ)設施的部分功能，諸如熔斷、服務跟蹤、網(wǎng)關(guān)等都沒有實現(xiàn)：

• 服務發(fā)現(xiàn)：服務發(fā)布、訂閱、通知。
• 高可用策略：失敗重試(Failover)、快速失敗(Failfast)、資源隔離 - 負載均衡 ：最少活躍連接、一致性 Hash、隨機請求、輪詢等。
• 擴展性 ：支持 SPI 擴展(service provider interface)。
• 其他 ：調(diào)用統(tǒng)計、訪問日志等。

Motan 則是微博開源的類似 Dubbo 的 RPC 框架，與 Dubbo 相比更輕量級。

Spring Cloud

Spring Cloud 是基于 Spring Boot 實現(xiàn)的微服務框架，也可以看做一套微服務實現(xiàn)規(guī)范。

基本涵蓋了微服務基礎(chǔ)設施的方方面面，包括配置管理、服務發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分布式會話和集群狀態(tài)管理等。

其基于 Spring 生態(tài)，社區(qū)支持非常好。但其很多組件都沒有經(jīng)過生產(chǎn)環(huán)境驗證，需要慎重選擇。

Spring Cloud Netflix 是 Spring Cloud 的一個子項目，是 Spring 對 Netflix OSS 的集成實現(xiàn)。

基于 Netflix 的大規(guī)模使用，其中的已經(jīng)被廣泛使用的組件包括：

• Eureka：服務注冊和服務發(fā)現(xiàn)
• Ribbon：彈性而智能的進程間和服務通訊機制，客戶端負載均衡
• Hystrix：熔斷器，在運行時提供延遲和容錯的隔離
• Zuul：服務網(wǎng)關(guān)

此外，另一個子項目 Spring Cloud Alibaba 則是 Alibaba 開源的基于 Spring Boot 的微服務框架，主要是對阿里云服務的支持。

Service Mesh

上述的微服務框架都是侵入式的，服務化的過程都需要進行代碼改造。Service Mesh 則是下一代微服務架構(gòu)，最明顯的特征就是無入侵。采用 Sidecar 模式來解決系統(tǒng)架構(gòu)微服務化后的服務間通信和治理問題。

如下圖所示：

 

目前主流的開源實現(xiàn)包括：

• Linkerd 和 Envoy：以 Sidecar 為核心，關(guān)注如何做好 Proxy，并完成一些通用控制平面的功能。缺乏對這些 Sidecar 的管理和控制。
• Istio 和 Conduit：目前最為流行的 Service Mesh 實現(xiàn)方案，集中在更加強大的控制平面(Sidecar 被稱為數(shù)據(jù)平面)功能。

前者由 Google 和 IBM 合作，并使用了 Envoy 作為 Sidecar 部分的實現(xiàn);后者則是 Linkerd 作者的作品。

相比起來，Istio 有巨頭背景，功能強大，但可用性和易用性一直不高，Conduit 則相對簡單、功能聚焦。

限于 Service Mesh 帶來的性能延遲的開銷以及 Sidecar 對分布復雜性的增加，其對大規(guī)模部署(微服務數(shù)目多)、異構(gòu)復雜(交互協(xié)議/開發(fā)語言類型多)的微服務架構(gòu)帶來的收益會更大。

Sofastack

螞蟻金服開源的構(gòu)建金融級分布式架構(gòu)的一套中間件。包括微服務開發(fā)框架、RPC 框架、服務注冊中心、全鏈路追蹤、服務監(jiān)控、Service Mesh 等一整套分布式應用開發(fā)工具。

特別值得一提的是 SOFAMesh。其實對下一代微服務架構(gòu) Service Mesh 的大規(guī)模落地方案實踐，基于 Istio 改進和擴展而來，應該是國內(nèi)最為成熟的開源 Service Mesh 方案。

此外，需要提到 Kubernetes(K8s)，其本身提供了部分的微服務特性支持(通過域名做服務發(fā)現(xiàn))，對代碼無侵入。但服務調(diào)用、熔斷這些都需要自己實現(xiàn)。

 

綜上，目前公司技術(shù)團隊技術(shù)棧是 Spring，并且已有服務的實現(xiàn)都是基于 Dubbo。

因此選擇 Spring Cloud Netflix 做為基礎(chǔ)的微服務框架，對其中不成熟或者缺乏的組件，選擇業(yè)界更為成熟的組件替代即可：

• API 網(wǎng)關(guān)：Zuul。
• 服務注冊中心：Dubbo。
• 配置中心：Disconf。
• 服務監(jiān)控&全鏈路追蹤：CAT。
• 服務開發(fā)框架：Spring Boot。
• 日志監(jiān)控、告警：ELK+Elasalert。
• 流量控制：Sentinel。
• 消息隊列：Kafka。

參考資料：

• What’s so bad about monoliths anyway…?!
• Microservice
• MicroservicePremium
• Microservice Trade-Offs
• MicroservicePrerequisites
• MonolithFirst
• 服務怎么拆?
• BFF@SoundCloud
• Service Mesh 及其主流開源實現(xiàn)解析

作者：颯然Hang

簡介：《Java 工程師修煉之道》作者。重度 Java 使用者，專注于 JavaEE、三高系統(tǒng)架構(gòu)、分布式等后端技術(shù)。