什么是微服務

提到微服務不得不提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。這些服務要基于業務場景，并使用自動化布署工具進行獨立的發布。可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的數據存儲。

如何實現微服務

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

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

如何發現服務及負載均衡如何實現?

服務間如何進行消息通信?

如何對使用者暴露服務 API?

如何集中管理眾多服務節點的配置文件?

如何收集服務節點的日志并統一管理?

如何實現服務間調用鏈路追蹤?

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

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

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用于支持分布式事務。

原文鏈接：https://mp.weixin.qq.com/s/AYCSL5BhfOcH-HpE1VP-mg