給老闆解釋為什麼要用SpringCloud alibaba作為微服務開發框架？

什麼是微服務

提到微服務不得不提Martin Fowler在2014年3月25日發表的文章 Microservices，裡面給出了微服務的定義。後續國內所有關於微服務的介紹都是基於這篇文章的翻譯，或加上自己的理解而成。其中最重要的一段如下：

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

翻譯過來就是：微服務這種架構風格就是把一組小服務演化成為一個單一的應用的一種方法。每個應用都運行在自己的程序中，並通過輕量級的機制保持通訊，就像HTTP這樣的API。這些服務要基於業務場景，並使用自動化部署工具進行獨立的釋出。可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的資料儲存。

如何實現微服務

相對於單體式架構的簡單粗暴，微服務架構將應用打散，形成多個微服務進行獨立開發、測試、部署與運維。雖然從管理與邏輯上更符合業務需要，但微服務架構也帶來了諸多急需解決的核心問題：

1. 如何發現新服務節點以及檢查服務節點的狀態？

2. 如何發現服務及負載均衡如何實現？

3. 服務間如何進行訊息通訊？

4. 如何對使用者暴露服務 API？

5. 如何集中管理眾多服務節點的配置檔案？

6. 如何收集服務節點的日誌並統一管理？

7. 如何實現服務間呼叫鏈路追蹤？

8. 如何對系統進行鏈路保護，避免微服務雪崩？

可以發現，上述這些問題並不是針對某種語言或某種技術的，任何軟體廠商要構建微服務架構就必須面對這些問題，要麼獨立開發要麼將已有多種技術整合形成整體解決方案。好在經過多年沉澱，業內已經有了標準答案，下圖清晰的說明微服務架構需要的標準組件。

API閘道器： 封裝了系統內部架構，為每個客戶端提供一個定製的 API。在微服務架構中，服務閘道器的核心要點是，所有的客戶端和消費端都通過統一的閘道器接入微服務，在閘道器層處理所有的非業務功能。

註冊中心： 微服務架構體系中最核心的技術元件，它起到新服務節點的註冊與狀態維護的作用。諸如 Dubbo、Spring Cloud 等主流的微服務框架都基於 Zookeeper、Eureka 等分散式系統協調工具構建了服務註冊中心。

服務路由： 通過註冊中心構建了一個多服務的叢集化環境中，當客戶端請求到達叢集，如何確定由哪一臺伺服器進行請求響應呢？這就是服務路由問題。

服務通訊： 在微服務定義中闡述服務間通訊採用輕量級協議，通常是 HTTP RESTful 風格。但因 RESTful 風格過於靈活，必須加以約束，通常在應用時對其進行上層封裝，例如在 Spring Cloud 中就提供了 Feign 和 RestTemplate 兩種技術遮蔽底層實現 RESTful 通訊細節。

服務保護： 對於分散式環境中的服務而言，服務在自身失敗引發生錯誤的同時，還會因為依賴其他服務而導致失敗。除了比較容易想到和實現的超時、重試和非同步解耦等手段之外，我們需要考慮針對各種場景的容錯機制。

鏈路跟蹤：一個複雜的業務流程可能需要連續呼叫多個微服務，我們需要記錄一個完整業務邏輯涉及的每一個微服務的運行狀態，再通過視覺化鏈路圖展現，幫助軟體工程師在系統出錯時分析解決問題，常見的解決方案有Zipkin，SkyWalking。

統一日誌管理： 微服務架構預設將應用日誌分散儲存在每一個微服務節點上，當系統進行使用者行為分析、資料統計時必須收集所有節點日誌資料，非常不方便。這時候我們需要一個獨立的日誌平臺，收集所有節點的日誌資料並可方便對其進行彙總分析，常見的解決方案有ELK，EFK。

配置中心： 在微服務架構中，考慮到服務數量和配置資訊的分散性，一般都需要引入配置中心的設計思想和相關工具。通過部署配置中心伺服器，將原本分散的配置檔案從應用中剝離，集中轉存到配置中心。一般配置中心會提供 UI 介面，可以方便快捷的實現大規模叢集的配置調整。

為什麼選擇SpringCloud

首先，Spring Cloud 具備一個天生的優勢，因為它是 Spring 家庭的一員，而 Spring 在 Java EE 開發領域的強大地位，給 Spring Cloud 起到很好的推動作用。同時，Spring Cloud 所基於的 Spring Boot，已經成為 Java EE 領域中最流行的開發框架，用來簡化 Spring 應用程式的框架搭建和開發過程。

其次，技術元件的完備性是我們選擇 Spring Cloud 的主要原因。Spring Cloud 中包含了開發一個完整的微服務系統所需的幾乎所有技術元件，包括服務註冊和發現、API 閘道器、配置中心、訊息處理、負載均衡、熔斷器、資料監控等常見技術元件都可以基於 Spring Boot 快速整合到業務系統中。

以下為SpringCloud 中常用的技術元件

為什麼選擇SpringCloud alibaba

首先， SpringCloud中的技術元件是集眾家之長，如註冊中心 Eureka，Zuul等都是依賴於Netflix的，這也導致它受制於第三方廠商。如Zuul宣佈停止維護，Spring機構便不得不尋找替代品或自研；Eureka2.x 閉源不允許使用；

其次，Springcloud作為國外產品引入到國內後出現了水土不服，如SpringCloud Config預設將檔案存在Github上，且沒有維護介面，國內軟體公司很少會同意這麼做。比如我們部門就是使用了Apollo配置中心替代了原生的SpringCloud Config。

Spring Cloud Alibaba是國產的微服務開發一站式解決方案，與原有 Spring Cloud 相容的同時對微服務生態進行擴展，通過新增少量的配置註解，便可實現更符合國情的微服務架構，當前Spring Cloud Alibaba已經是直接隸屬於 Spring Cloud 的子項目。官網是：https://spring.io/projects/spring-cloud-alibaba#overview

Spring Cloud Alibaba 對服務註冊、配置中心與負載均衡功能都整合進 Nacos，有圖形化介面，簡化了微服務架構的複雜度，出問題的概率也會降低。原有的服務保護元件也調整為 Sentinel，相較Hystrix功能更強大，使用也更加友好。同時還支援了對Dubbo的呼叫，而且還有Seata用於支援分散式事務。

想了解更多精彩內容，快來關注計算機java程式設計