爲何大公司必定要使用微服務？

做者：颯然Hang
https://www.rowkey.me/blog/20...

這幾年在 Java 工程師招聘時，會看到不少人的簡歷都寫着使用了 Spring Cloud 作微服務實現，使用 Docker 作自動化部署，而且也會把這些作爲本身的亮點。

而比較有趣的這其中以小公司出來的人爲絕大多數，大的公司出來的人簡歷上卻是不多提這些東西。

對於我本身來講，從 2015 年就開始關注這一塊，看過馬丁·福勒最開始的關於微服務的論文、也看過很多對微服務的論證的英文文章和書，也研究過 Spring Cloud、Sofa 等開源實現以及 Service Mesh。

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

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

而隨着最近公司業務的逐步提高，研發人員愈來愈多，藉着在梳理公司的微服務落地計劃時，也梳理了一下微服務的相關知識點，也是本文的主要內容。

主要從如下幾個方面跟你們分享：

• 微服務是什麼
• 爲何要採用微服務
• 微服務架構
• 架構設計模式
• 服務拆分
• 微服務框架

開篇以前先聲明我對微服務的幾點態度：

• 架構模式有不少，微服務不是惟一的選擇也不是什麼銀彈。國內絕大多數中小公司引入微服務都是在盲目追新，也能看出作此種技術選型的工程師基礎架構素質的不足。
• 「你必須長的足夠高才能使用微服務」。微服務基礎設施，尤爲是容器技術、自動化部署、自動化測試這些不完備，微服務形同虛設，不會帶來什麼質的提高。
• 微服務架構的關鍵不在於具體的實現，而在於如何合理地劃分服務邊界以及組織架構是否相匹配。不考慮研發團隊的規模和組成就盲目上微服務是不良的技術選型。
• Spring Boot 是 Spring 全家桶的上層封裝，並非什麼嶄新的技術，也不是什麼值得成爲本身殺手鐗的技術。
• Spring Cloud 中 Spring Cloud Netflix 的組件是通過生產環境驗證的，其餘的則建議慎重選擇。

微服務是什麼

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

2014 年，由 Martin Fowler 與 James Lewis 共同提出了微服務的概念，定義了微服務架構風格是一種經過一套小型服務來開發單個應用的方法，每一個服務運行在本身的進程中，並經過輕量級的機制進行通信（HTTP API）。

關鍵的三點是：

• small
• automated
• lightweight

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

其共同的架構原理：

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

特色：

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

綜合來看，其優缺點以下：

• 優勢： 模塊的強邊界；獨立部署；技術選型的多樣性。
• 缺點： 分佈式帶來編程複雜度，遠程調用的消耗；捨棄強一致性，實現最終一致性；操做複雜性要求有一個成熟的運維團隊或者運維基礎設施。

爲何要採用微服務

是否選擇微服務取決於你要設計的系統的複雜度。微服務是用來把控複雜系統的，可是隨之而來的就是引入了微服務自己的複雜度。

須要解決包括自動化部署、監控、容錯處理、最終一致性等其餘分佈式系統面臨的問題。即便已經有一些廣泛使用的解決方案，可是仍然是有不小的成本的。

生產力和複雜度的關係如圖所示，可見系統越複雜，微服務帶來的收益越大。此外，不管是單體應用仍是微服務，團隊的技能都須要可以把控住。

馬丁·福勒的一個觀點是： 除非管理單體應用的成本已經太複雜了（太大致使很難修改和部署），不然都不要考慮微服務。

大部分應用都應該選擇單體架構，作好單體應用的模塊化而不是拆分紅服務。

所以，系統一開始採用單體架構，作好模塊化，以後隨着系統變得愈來愈複雜、模塊/服務間的邊界愈來愈清晰，再重構爲微服務架構是一個合理的架構演化路徑。

四個能夠考慮上微服務的狀況：

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

微服務的三個階段：

• 微服務 1.0： 僅使用註冊發現，基於 Spring Cloud 或者 Dubbo 進行開發。
• 微服務 2.0： 使用了熔斷、限流、降級等服務治理策略，並配備完整服務工具和平臺。
• 微服務 3.0： Service Mesh 將服務治理做爲通用組件，下沉到平臺層實現，應用層僅僅關注業務邏輯，平臺層能夠根據業務監控自動調度和參數調整，實現 AIOps 和智能調度。

  

微服務架構

先決條件

微服務的先決條件以下：

• 快速的環境提供能力： 依賴於雲計算、容器技術，快速交付環境。
• 基本的監控能力： 包括基礎的技術監控和業務監控。
• 快速的應用部署能力： 須要部署管道提供快速的部署能力。
• Devops 文化： 須要具備良好的持續交付能力，包括全鏈路追蹤、快速環境提供和部署等，還須要快速的反應能力（對問題、故障的快速響應），開發和運維的協同工做。

此外，根據康威定律和逆康威定律（技術架構倒逼組織架構改進），組織架構也是一個很關鍵的因素。

對應於微服務架構，組織架構須要遵循如下原則：

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

基礎設施

微服務的推行須要依賴於不少底層基礎設施，包括提供微服務的編譯、集成、打包、部署、配置等工做，採用 PaaS 平臺解決微服務從開發到運行的全生命週期管理，同時提供異構環境管理、容器資源隔離與互通、服務伸縮漂移、服務升級與回退、服務熔斷與降級、服務註冊與發現。

①最基本的基礎設施

進程間通信機制： 微服務是獨立進程的，須要肯定之間的通信方式。

服務發現+服務路由： 提供服務註冊中心，服務提供者和消費者經過服務發現獲取服務的信息從而調用服務，實現服務的負載均衡等。

服務容錯： 微服務架構中，因爲服務很是多，每每是一個服務掛了，整個請求鏈路的服務都受到影響。

所以須要服務容錯，在服務調用失敗的時候可以處理錯誤或者快速失敗，包括熔斷、Fallback、重試、流控和服務隔離等。

分佈式事務支持： 隨着業務拆分爲服務，那麼有時候不開避免的就是跨服務的事務，即分佈式事務的問題。

原則是儘可能避免分佈式事務，若是沒法避免那麼可使用消息系統或者 CQRS 和 Event Sourcing 方案來實現最終一致性。

若是須要強一致性，則有兩階段提交、三階段提交、TCC 等分佈式事務解決方案。

②提高外部服務對接效率和內部開發效率

API 網關： 負責外部系統的訪問，跨橫切面的公共層面的工做，包括安全、日誌、權限控制、傳輸加密、請求轉發、流量控制等。

典型的網關功能即對外暴露一個域名 xx.com，根據第一級目錄作反向路由 xx.com/user，xx.com/trade。

每一級目錄，如 user、trade 對應一個服務的域名。此外，API 網關也能夠有服務編排的功能（不推薦）。

接口框架： 規範服務之間通信使用的數據格式、解析包、自解釋文檔，便於服務使用方快速上手等。

③提高測試和運維效率

配置中心: 運行時配置管理可以解決動態修改配置並批量生效的問題。包括配置版本管理、配置項管理、節點管理、配置同步等。

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

持續集成： 這一部分並不是是微服務特定的，對於以前的單體應用，此部分通常來講也是必要的。

主要是指經過自動化手段，持續地對代碼進程編譯構建、自動化測試，以獲得快速有效的質量反饋，從而保證代碼的順利交付。

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

自動化部署： 微服務架構，節點數動輒上百上千，自動化部署可以提升部署速度和部署頻率，從而保證持續交付。

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

④進一步提高運維效率

服務監控： 微服務架構下節點數目衆多，須要監控的機器、網絡、進程、接口等的數量大大增長，須要一個強大的監控系統，可以提供實時蒐集信息進行分析以及實時分析之上的預警。

包括監控服務的請求次數、響應時間分佈、最大/最小響應值、錯誤碼分佈等。

服務跟蹤： 跟蹤一個請求的完整路徑，包括請求發起時間、響應時間、響應碼、請求參數、返回結果等信息，也叫作全鏈路跟蹤。

一般的服務能夠和服務監控作在一塊兒，宏觀信息由服務跟蹤呈現，微觀單個服務/節點的信息由服務監控呈現。服務跟蹤目前的實現理論基本都是 Google 的 Dapper 論文。

服務安全： 內網之間的微服務調用原則上講應該是均可以互相訪問寫，通常並不須要權限控制，但有時候限於業務要求，會對接口、數據等方面有安全控制的要求。

此部分能夠以配置的方式存在於服務註冊中心中，和服務綁定，在請求時由作爲服務提供者的服務節點進行安全策略控制。配置則能夠存儲在配置中心以方便動態修改。

在微服務數量不多的狀況下，以上基礎設施的優先級自上而降低低。不然，僅僅依賴人工操做，則投入產出比會很低。

還須要提到的是 Docker 容器技術。雖然這個對於微服務並非必須的，可是容器技術輕量級、靈活、與應用依存、屏蔽環境差別的特性對於持續交付的實現是相當重要的，即便對於傳統的單體應用也可以給其帶來交付效率的大幅提高。

 

架構設計模式

在引入微服務以後，傳統的單體應用變爲了一個一個服務，以前一個應用直接提供接口給客戶端訪問的架構再也不適用。

微服務架構下，針對不一樣設備的接口作爲 BFF 層（Backend For Frontend），也叫作用戶體驗適配層，負責聚合、編排微服務的數據轉換成前端須要的數據。

服務之間的調用則在容許的狀況下（容許延遲）儘量使用異步消息傳遞方式，如此造成面向用戶體驗的微服務架構設計模式。

以下圖所示：

Client→API Gateway→BFF（Backend For Frontend）→Downstream Microservices：

• 後臺採用微服務架構，微服務能夠採用不一樣的編程語言和不一樣的存儲機制。
• 前臺採用 BFF 模式對不一樣的用戶體驗（如桌面瀏覽器，Native App，平板響應式 Web）進行適配。
• BFF、API Orchestration Layer，Edge Service Layer，Device Wrapper Layer 是相同的概念。
• BFF 不能過多，過多會形成代碼邏輯重複冗餘。
• 能夠將網關承擔的功能，如 Geoip、限流、安全認證等跨橫切面功能和 BFF 作在同一層，雖然增長了 BFF 層的複雜性，但可以獲得性能優點。

服務拆分

微服務架構最核心的環節，主要是對服務的橫向拆分。服務拆分就是將一個完整的業務系統解耦爲服務，服務須要職責單一，之間沒有耦合關係，可以獨立開發和維護。

服務拆分不是一蹴而就的，須要在開發過程當中不斷地理清邊界。在徹底理清服務以前，儘可能推遲對服務的拆分，尤爲是對數據庫的拆分。

拆分方法以下：

• 基於業務邏輯拆分
• 基於可擴展拆分
• 基於可靠性拆分
• 基於性能拆分

其中，對於沒法修改的遺留系統，採用絞殺者模式：在遺留系統外面增長新的功能作成微服務方式，而不是直接修改原有系統，逐步的實現對老系統替換。

拆分過程須要遵照的規範以下：

• 先少後多、先粗後細（粒度）
• 服務縱向拆分最多三層，兩次調用：Controller、組合服務、基礎服務
• 僅僅單向調用，禁止循環調用
• 串行調用改成並行調用或者異步化
• 接口應該冪等
• 接口數據定義嚴禁內嵌，透傳
• 規範化工程名
• 先拆分服務，等服務粒度肯定後再拆分數據庫。

微服務框架

上面講述了微服務架構的衆多基礎設施，若是每個基礎設施都須要本身開發的話是很是巨大的開發工做。目前市面上已經有很多開源的微服務框架能夠選擇。

Spring Boot

Spring Boot 是用來簡化新 Spring 應用的初始搭建以及開發過程的。其雖然不是微服務框架，但其設計的初衷本質就是微應用的底層框架，所以很是適合用於微服務基礎設施的開發以及微服務的應用開發。

尤爲對於 Spring 技術棧的團隊來講，基於 Spring Boot 開發微服務框架和應用是天然而然的一個選擇。關注微信公衆號：Java技術棧，在後臺回覆：boot，能夠獲取我整理的 N 篇最新 Spring Boot 教程，都是乾貨。

Dubbo&Motan

Dubbo 是阿里開源的服務治理框架。其出如今微服務理念興起以前，能夠看作是 SOA 框架的集大成之做。

但其僅僅包含了微服務基礎設施的部分功能，諸如熔斷、服務跟蹤、網關等都沒有實現：

• 服務發現： 服務發佈、訂閱、通知。
• 高可用策略： 失敗重試（Failover）、快速失敗（Failfast）、資源隔離 - 負載均衡 ：最少活躍鏈接、一致性 Hash、隨機請求、輪詢等。
• 擴展性 ： 支持 SPI 擴展（service provider interface）。
• 其餘 ： 調用統計、訪問日誌等。

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

Spring Cloud

Spring Cloud 是基於 Spring Boot 實現的微服務框架，也能夠看作一套微服務實現規範。關注微信公衆號：Java技術棧，在後臺回覆：cloud，能夠獲取我整理的 N 篇最新 Spring Cloud 教程，都是乾貨。

基本涵蓋了微服務基礎設施的方方面面，包括配置管理、服務發現、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分佈式會話和集羣狀態管理等。

其基於 Spring 生態，社區支持很是好。但其不少組件都沒有通過生產環境驗證，須要慎重選擇。

Spring Cloud Netflix 是 Spring Cloud 的一個子項目，是 Spring 對 Netflix OSS 的集成實現。

基於 Netflix 的大規模使用，其中的已經被普遍使用的組件包括：

• Eureka： 服務註冊和服務發現
• Ribbon： 彈性而智能的進程間和服務通信機制，客戶端負載均衡
• Hystrix： 熔斷器，在運行時提供延遲和容錯的隔離
• Zuul： 服務網關

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

Service Mesh

上述的微服務框架都是侵入式的，服務化的過程都須要進行代碼改造。Service Mesh 則是下一代微服務架構，最明顯的特徵就是無入侵。採用 Sidecar 模式來解決系統架構微服務化後的服務間通訊和治理問題。

以下圖所示：

目前主流的開源實現包括：

• Linkerd 和 Envoy： 以 Sidecar 爲核心，關注如何作好 Proxy，並完成一些通用控制平面的功能。缺少對這些 Sidecar 的管理和控制。
• Istio 和 Conduit： 目前最爲流行的 Service Mesh 實現方案，集中在更增強大的控制平面(Sidecar 被稱爲數據平面)功能。

  前者由 Google 和 IBM 合做，並使用了 Envoy 做爲 Sidecar 部分的實現；後者則是 Linkerd 做者的做品。

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

限於 Service Mesh 帶來的性能延遲的開銷以及 Sidecar 對分佈複雜性的增長，其對大規模部署(微服務數目多)、異構複雜(交互協議/開發語言類型多)的微服務架構帶來的收益會更大。

Sofastack

螞蟻金服開源的構建金融級分佈式架構的一套中間件。包括微服務開發框架、RPC 框架、服務註冊中心、全鏈路追蹤、服務監控、Service Mesh 等一整套分佈式應用開發工具。

特別值得一提的是 SOFAMesh。其實對下一代微服務架構 Service Mesh 的大規模落地方案實踐，基於 Istio 改進和擴展而來，應該是國內最爲成熟的開源 Service Mesh 方案。

此外，須要提到 Kubernetes（K8s），其自己提供了部分的微服務特性支持（經過域名作服務發現），對代碼無侵入。但服務調用、熔斷這些都須要本身實現。

綜上，目前公司技術團隊技術棧是 Spring，而且已有服務的實現都是基於 Dubbo。

所以選擇 Spring Cloud Netflix 作爲基礎的微服務框架，對其中不成熟或者缺少的組件，選擇業界更爲成熟的組件替代便可：

• API 網關： Zuul。
• 服務註冊中心： Dubbo。
• 配置中心： Disconf。
• 服務監控&全鏈路追蹤： CAT。
• 服務開發框架： Spring Boot。
• 日誌監控、告警： ELK+Elasalert。
• 流量控制： Sentinel。
• 消息隊列： Kafka。

推薦去個人博客閱讀更多：

1.Java JVM、集合、多線程、新特性系列教程

2.Spring MVC、Spring Boot、Spring Cloud 系列教程

3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程

4.Java、後端、架構、阿里巴巴等大廠最新面試題

生活很美好，明天見～