微服務架構的特點、優勢和常見技術

微服務的四個特點和六個能力

現在讓我們分析一下上一節裡的各個技術大牛們闡述的技術觀點，從設計開發、系統部署、測試運維和服務治理四個主要方面來考慮微服務架構的特點，那麼這四個方面就可以總結為下圖：

微服務架構首先是一個分散式的架構，其次我們要暴露和提供業務服務能力，然後我們需要考慮圍繞這些業務能力的各種非功能性的能力。這些分散在各處的服務本身需要被管理起來，並且對服務的呼叫方透明，這樣就有了服務的註冊發現的功能需求。

同樣地，每個服務可能部署了多臺機器多個例項，所以，我們需要有路由和定址的能力，做負載均衡，提升系統的擴充套件能力。有了這麼多對外提供的不同服務介面，我們一樣需要有一種機制對他們進行統一的接入控制，並把一些非業務的策略做到這個接入層，比如許可權相關的，這就是服務閘道器。同時我們發現隨著業務的發展和一些特定的運營活動，比如秒殺大促，流量會出現十倍以上的激增，這時候我們就需要考慮系統容量，服務間的強弱依賴關係，做服務降級、熔斷，系統過載保護等措施。

以上這些由於微服務帶來的複雜性，導致了應用配置、業務配置，都被散落到各處，所以分散式配置中心的需求也出現了。最後，系統分散部署以後，所有的呼叫都跨了程序，我們還需要有能在線上做鏈路跟蹤，效能監控的一套技術，來協助我們時刻了解系統內部的狀態和指標，讓我們能夠隨時對系統進行分析和干預。這六種能力總結如下圖：

微服務的優勢

為什麼我們要從單體系統走向微服務架構呢？我們先來看一個圖。

這個圖 x 軸是系統複雜度，y 軸是開發的生產力，我們可以看到：

在系統複雜度很低的時候，單體的生產力要高一點，這是因為拆分微服務，管理這些服務的成本增加了

當複雜度開始增加，單體的生產力快速的降低，而微服務則不太受影響，這是因為複雜度大了，單體牽一髮而動全身，各種耦合和相互影響太多

隨著複雜度越來越高，微服務的低耦合開始減低了生產力的衰變，而單體架構的生產力則會降到一個非常低的水平

也就是說微服務應用在複雜度低的情況下，生產力反而比單體系統低。在複雜度高的地方，情況恰恰相反。

隨著複雜度升高，單體架構的生產力快速下降，而微服務相對平穩，所以，複雜度越高的業務系統，越適合使用微服務架構。

搞清楚了微服務架構與單體架構的生產力的區別以後，我們再來看看微服務有哪些優勢，我總結了一下有以下幾點：

服務簡單：因為微小，所以簡單，從一個大泥球，變成了很多個小而美的顆粒，每個小顆粒職責單一，邊界明確，可以透過簡單組裝完成大的功能，自然就比之前的大泥球好處理得多。

靈活擴充套件：單體的情況下，只能透過增加機器，再部署多套單體系統做成叢集，前面加負載均衡來擴充套件；微服務以後，我們會發現使用者服務壓力不大不用擴充套件，訂單服務壓力大的時候多部署兩臺就可以了，這樣我們就把擴充套件的方式從全部最佳化到區域性。

便於維護：如果一個系統有 100 個業務功能，依賴關係相互耦合到一起，那麼這就是維護的惡夢，這樣的系統沒有任何免疫力，修改任何一個功能，都可能會導致整個系統崩潰。微服務就簡單得多了，每個服務自己出現問題，其他服務不會直接受到影響。同時維護具體某個服務的人員，也不需要一上來就學習全部的業務知識，比如使用者服務模組的維護人員，只需要先學習使用者服務的業務就可以上手工作了。

獨立演進：變成微服務以後，各個獨立系統的內部設計和實現細節都被隔離開，相互之間不受影響，只要服務間的介面不變，大家就可以各自獨立的發展自己的系統，完成升級、重構、功能增強等等。

混合開發：各服務獨立開發的另外一個好處就是，各個獨立系統可以使用自己的技術棧和研發模式，包括開發語言和工具、資料庫儲存和中介軟體等技術，這樣有助於試驗和引入更先進和創新的技術，從一些個邊緣服務開始嘗試，技術、工具、中介軟體、研發模式，孵化成熟以後，可以大範圍推廣，實現技術和研發能力的持續更新換代，讓研發組織保持長期的優勢和活力，充分獲得技術發展的紅利。

持續交付：微服務比單體系統簡單明確，這樣就便於我們利用自動化測試和自動化部署來加速功能的迭代，配合 CI/CD 等基礎設施，實現業務功能的持續交付，保障研發能夠緊跟業務發展變化的節奏。

常見的微服務技術框架

具體怎麼做微服務呢？我們先看看大家最常簡單見到的微服務的圖：

在網際網路出行業務中，使用者透過 API 閘道器訪問系統的乘客、司機、出行三個 REST 服務，這三個服務再透過 REST 訪問計費、支付和通知三個服務。看起來很簡單，也好理解，但是實際的業務系統裡，設計和實現一般會是這樣：

服務框架：我們可以選擇用 Spring Cloud 或者 Apache Dubbo，包括新興的 Spring Cloud Alibaba，還有華為貢獻的 Apache ServiceComb，螞蟻金服的 SOFAStack ，Oracle 的 Helidon，Redhat 的 Quarkus，基於 Scala 語言和 Akka 的 Lagom，基於 Grails 語言的 Micronaut，基於 Python 語言的 Nameko，基於 Golang 語言的 go-micro，支援多語言混編的響應式微服務框架 Vert。X，騰訊開源的 Tars，百度開源的 Apache BRPC（孵化中），微博的簡化版 Dubbo 框架 Motan 等等。

配置中心：Apollo，Nacos，disconf，Spring Cloud Config，或者 Etcd、ZK、Redis 自己封裝

服務註冊發現：Eureka，Consul，或者 Etcd、ZK、Redis 自己封裝

服務閘道器：Zuul/Zuul2，Spring Cloud Gateway，nginx 系列的 Open Resty 和 Kong，基於 Golang 的 fagongzi Gateway 等

容錯限流：Hystrix，Sentinel，Resilience4j，或者直接用 Kong 自帶的外掛

訊息處理：Kafka、RabbitMQ、RocketMQ，以及 Pulsar，可以使用 Sping Messaging 或者 Spring Cloud Stream 來簡化處理

鏈路監控與日誌：開源的鏈路技術有 CAT、Pinpoint、Skywalking、Zipkin、Jaeger 等，也可以考慮用商業的 APM（比如聽雲 APM、OneAPM、App Dynamic 等），日誌可以用 ELK

認證與授權：比如要支援 OAuth2、LDAP，傳統的自定義 BRAC 等，可以選擇 Spring Security 或者 Apache Shiro 等

Sping Cloud 與 Apache Dubbo、Spring Cloud Alibaba

Spring Cloud 是一個較為成熟的微服務框架，定位為開發人員提供工具，以快速構建分散式系統中的某些常見模式（例如，配置管理，服務發現，斷路器，智慧路由，微代理，控制匯流排，一次性令牌，全域性鎖，Leader 選舉，分散式會話，群集狀態）。其技術棧大致如下：

可以看到很多元件都是由 Netflix 貢獻的。

而 Apache Dubbo 定位是一款高效能、輕量級的開源 Java RPC 框架，它提供了三大核心能力：面向介面的遠端方法呼叫，智慧容錯和負載均衡，以及服務自動註冊和發現。所以，我們可以看到 Dubbo 提供的能力只是 Spring Cloud 的一部分子集。

同時 Dubbo 專案重新維護以後，捐獻給了 Apache，專案的導師就是 Spring Cloud 的核心人員。自這時候起 Dubbo 專案就開始在適合 Spring Cloud 體系，結果就是 Alibaba 也基於自己的一系列開源元件和技術，實現了 Spring Cloud Alibaba，並順利從 Spring Cloud 孵化器畢業。詳見：

Spring Cloud Alibaba 致力於提供微服務開發的一站式解決方案。此專案包含開發分散式應用微服務的必需元件，方便開發者透過 Spring Cloud 程式設計模型輕鬆使用這些元件來開發分散式應用服務。主要功能和開源技術棧：

服務限流降級（Sentinel）：預設支援 WebServlet、WebFlux， OpenFeign、RestTemplate、Spring Cloud Gateway， Zuul， Dubbo 和 RocketMQ 限流降級功能的接入，可以在執行時透過控制檯實時修改限流降級規則，還支援檢視限流降級 Metrics 監控。

服務註冊與發現（Nacos）：適配 Spring Cloud 服務註冊與發現標準，預設集成了 Ribbon 的支援。

分散式配置管理（Nacos）：支援分散式系統中的外部化配置，配置更改時自動重新整理。

訊息驅動能力（Apache RocketMQ）：基於 Spring Cloud Stream 為微服務應用構建訊息驅動能力。

分散式事務（Seata）：使用 @GlobalTransactional 註解， 高效並且對業務零侵入地解決分散式事務問題。

可以看到，基本上功能都比較完備了。