[[402711]]

本文轉(zhuǎn)載自微信公眾號「JAVA日知錄」，作者飄渺Jam。轉(zhuǎn)載本文請聯(lián)系JAVA日知錄公眾號。

什么是微服務

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

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.

翻譯過來就是：微服務這種架構(gòu)風格就是把一組小服務演化成為一個單一的應用的一種方法。每個應用都運行在自己的進程中，并通過輕量級的機制保持通信，就像HTTP這樣的API。這些服務要基于業(yè)務場景，并使用自動化布署工具進行獨立的發(fā)布。可以有一個非常輕量級的集中式管理來協(xié)調(diào)這些服務，可以使用不同的語言來編寫服務，也可以使用不同的數(shù)據(jù)存儲。

如何實現(xiàn)微服務

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

如何發(fā)現(xiàn)新服務節(jié)點以及檢查服務節(jié)點的狀態(tài)?

如何發(fā)現(xiàn)服務及負載均衡如何實現(xiàn)?

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

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

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

如何收集服務節(jié)點的日志并統(tǒng)一管理?

如何實現(xiàn)服務間調(diào)用鏈路追蹤?

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

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

API網(wǎng)關(guān)： 封裝了系統(tǒng)內(nèi)部架構(gòu)，為每個客戶端提供一個定制的 API。在微服務架構(gòu)中，服務網(wǎng)關(guān)的核心要點是，所有的客戶端和消費端都通過統(tǒng)一的網(wǎng)關(guān)接入微服務，在網(wǎng)關(guān)層處理所有的非業(yè)務功能。

注冊中心： 微服務架構(gòu)體系中最核心的技術(shù)組件，它起到新服務節(jié)點的注冊與狀態(tài)維護的作用。諸如 Dubbo、Spring Cloud 等主流的微服務框架都基于 Zookeeper、Eureka 等分布式系統(tǒng)協(xié)調(diào)工具構(gòu)建了服務注冊中心。

服務路由： 通過注冊中心構(gòu)建了一個多服務的集群化環(huán)境中，當客戶端請求到達集群，如何確定由哪一臺服務器進行請求響應呢?這就是服務路由問題。

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

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

鏈路跟蹤：一個復雜的業(yè)務流程可能需要連續(xù)調(diào)用多個微服務，我們需要記錄一個完整業(yè)務邏輯涉及的每一個微服務的運行狀態(tài)，再通過可視化鏈路圖展現(xiàn)，幫助軟件工程師在系統(tǒng)出錯時分析解決問題，常見的解決方案有Zipkin，SkyWalking。

統(tǒng)一日志管理： 微服務架構(gòu)默認將應用日志分散保存在每一個微服務節(jié)點上，當系統(tǒng)進行用戶行為分析、數(shù)據(jù)統(tǒng)計時必須收集所有節(jié)點日志數(shù)據(jù)，非常不方便。這時候我們需要一個獨立的日志平臺，收集所有節(jié)點的日志數(shù)據(jù)并可方便對其進行匯總分析，常見的解決方案有ELK，EFK。

配置中心： 在微服務架構(gòu)中，考慮到服務數(shù)量和配置信息的分散性，一般都需要引入配置中心的設(shè)計思想和相關(guān)工具。通過部署配置中心服務器，將原本分散的配置文件從應用中剝離，集中轉(zhuǎn)存到配置中心。一般配置中心會提供 UI 界面，可以方便快捷的實現(xiàn)大規(guī)模集群的配置調(diào)整。

為什么選擇SpringCloud

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

其次，技術(shù)組件的完備性是我們選擇 Spring Cloud 的主要原因。Spring Cloud 中包含了開發(fā)一個完整的微服務系統(tǒng)所需的幾乎所有技術(shù)組件，包括服務注冊和發(fā)現(xiàn)、API 網(wǎng)關(guān)、配置中心、消息處理、負載均衡、熔斷器、數(shù)據(jù)監(jiān)控等常見技術(shù)組件都可以基于 Spring Boot 快速集成到業(yè)務系統(tǒng)中。

以下為SpringCloud 中常用的技術(shù)組件

為什么選擇SpringCloud alibaba

首先， SpringCloud中的技術(shù)組件是集眾家之長，如注冊中心 Eureka，Zuul等都是依賴于Netflix的，這也導致它受制于第三方廠商。如Zuul宣布停止維護，Spring機構(gòu)便不得不尋找替代品或自研;Eureka2.x 閉源不允許使用;

其次，Springcloud作為國外產(chǎn)品引入到國內(nèi)后出現(xiàn)了水土不服，如SpringCloud Config默認將文件存在Github上，且沒有維護界面，國內(nèi)軟件公司很少會同意這么做。比如我們部門就是使用了Apollo配置中心替代了原生的SpringCloud Config。

Spring Cloud Alibaba是國產(chǎn)的微服務開發(fā)一站式解決方案，與原有 Spring Cloud 兼容的同時對微服務生態(tài)進行擴展，通過添加少量的配置注解，便可實現(xiàn)更符合國情的微服務架構(gòu)，當前Spring Cloud Alibaba已經(jīng)是直接隸屬于 Spring Cloud 的子項目。官網(wǎng)是：https://spring.io/projects/spring-cloud-alibaba#overview

Spring Cloud Alibaba 對服務注冊、配置中心與負載均衡功能都整合進 Nacos，有圖形化界面，簡化了微服務架構(gòu)的復雜度，出問題的概率也會降低。原有的服務保護組件也調(diào)整為 Sentinel，相較Hystrix功能更強大，使用也更加友好。同時還支持了對Dubbo的調(diào)用，而且還有Seata用于支持分布式事務。