為什么大公司一定要使用微服務？

關(guān)注我們,設為星標,每天7:30不見不散,架構(gòu)路上與您共享 
回復"架構(gòu)師"獲取資源

而比較有趣的這其中以小公司出來的人為絕大多數(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)設計模式

• 服務拆分

• 微服務框架

• 架構(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)境驗證的，其他的則建議慎重選擇。

• small

• automated

• lightweight

• 單一職責

• 關(guān)注分離：控制與邏輯相分離

• 模塊化和分而治之

• 用服務進行組件化

• 圍繞業(yè)務能力進行組織

• 是產(chǎn)品而非項目

• 端點智能化和啞管道: 控制邏輯都在端點，管道僅僅是傳輸

• 全自動化部署

• 語言和數(shù)據(jù)的去中心化控制

• 面向失敗設計

• 漸進式設計

• 優(yōu)點：模塊的強邊界；獨立部署；技術(shù)選型的多樣性。

• 缺點：分布式帶來編程復雜度，遠程調(diào)用的消耗；舍棄強一致性，實現(xiàn)最終一致性；操作復雜性要求有一個成熟的運維團隊或者運維基礎(chǔ)設施。

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

• 多人開發(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)度。

• 快速的環(huán)境提供能力：依賴于云計算、容器技術(shù)，快速交付環(huán)境。

• 基本的監(jiān)控能力：包括基礎(chǔ)的技術(shù)監(jiān)控和業(yè)務監(jiān)控。

• 快速的應用部署能力：需要部署管道提供快速的部署能力。

• Devops 文化：需要具有良好的持續(xù)交付能力，包括全鏈路追蹤、快速環(huán)境提供和部署等，還需要快速的反應能力（對問題、故障的快速響應），開發(fā)和運維的協(xié)同工作。

• 一個微服務由一個團隊維護，團隊成員以三人為宜。

• 單個團隊的任務和發(fā)展是獨立的，不受其他因素影響。

• 團隊是功能齊全、全棧、自治的，扁平、自我管理。

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

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

③提升測試和運維效率

④進一步提升運維效率

如下圖所示：

• 后臺采用微服務架構(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)勢。

• 基于業(yè)務邏輯拆分

• 基于可擴展拆分

• 基于可靠性拆分

• 基于性能拆分

• 先少后多、先粗后細（粒度）

• 服務縱向拆分最多三層，兩次調(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 應用的初始搭建以及開發(fā)過程的。其雖然不是微服務框架，但其設計的初衷本質(zhì)就是微應用的底層框架，因此非常適合用于微服務基礎(chǔ)設施的開發(fā)以及微服務的應用開發(fā)。

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

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

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

• 服務發(fā)現(xiàn)：服務發(fā)布、訂閱、通知。

• 高可用策略：失敗重試（Failover）、快速失?。‵ailfast）、資源隔離 - 負載均衡 ：最少活躍連接、一致性 Hash、隨機請求、輪詢等。

• 擴展性 ：支持 SPI 擴展（service provider interface）。

• 其他 ：調(diào)用統(tǒng)計、訪問日志等。

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 則是下一代微服務架構(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 則相對簡單、功能聚焦。

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

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

綜上，目前公司技術(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)解析

文章來源：https://www.rowkey.me/blog/2019/05/30/msa/

到此文章就結(jié)束了。如果今天的文章對你在進階架構(gòu)師的路上有新的啟發(fā)和進步，歡迎轉(zhuǎn)發(fā)給更多人。歡迎加入架構(gòu)師社區(qū)技術(shù)交流群，眾多大咖帶你進階架構(gòu)師，在后臺回復“加群”即可入群。

這些年小編給你分享過的干貨

1.SpringBoot物流管理項目，拿去學習吧（附源碼）

2.ERP系統(tǒng)，自帶進銷存+財務+生產(chǎn)功能，拿來即用（附源碼）

3.帶工作流的SpringBoot后臺管理項目快速開發(fā)（附源碼）
4.最好的OA系統(tǒng)，拿來即用，非常方便（附源碼）

5.SpringBoot+Vue完整的外賣系統(tǒng)，手機端和后臺管理，附源碼！

6.SpringBoot+Vue 可視化拖拽編輯的大屏項目（附源碼）

轉(zhuǎn)發(fā)在看就是最大的支持??