[[402711]]

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

什么是微服務(wù)

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

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.

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

如何實(shí)現(xiàn)微服務(wù)

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

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

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

服務(wù)間如何進(jìn)行消息通信?

如何對(duì)使用者暴露服務(wù) API?

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

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

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

如何對(duì)系統(tǒng)進(jìn)行鏈路保護(hù)，避免微服務(wù)雪崩?

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

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

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

服務(wù)路由： 通過(guò)注冊(cè)中心構(gòu)建了一個(gè)多服務(wù)的集群化環(huán)境中，當(dāng)客戶端請(qǐng)求到達(dá)集群，如何確定由哪一臺(tái)服務(wù)器進(jìn)行請(qǐng)求響應(yīng)呢?這就是服務(wù)路由問(wèn)題。

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

服務(wù)保護(hù)： 對(duì)于分布式環(huán)境中的服務(wù)而言，服務(wù)在自身失敗引發(fā)生錯(cuò)誤的同時(shí)，還會(huì)因?yàn)橐蕾嚻渌?wù)而導(dǎo)致失敗。除了比較容易想到和實(shí)現(xiàn)的超時(shí)、重試和異步解耦等手段之外，我們需要考慮針對(duì)各種場(chǎng)景的容錯(cuò)機(jī)制。

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

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

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

為什么選擇SpringCloud

首先，Spring Cloud 具備一個(gè)天生的優(yōu)勢(shì)，因?yàn)樗?Spring 家庭的一員，而 Spring 在 Java EE 開(kāi)發(fā)領(lǐng)域的強(qiáng)大地位，給 Spring Cloud 起到很好的推動(dòng)作用。同時(shí)，Spring Cloud 所基于的 Spring Boot，已經(jīng)成為 Java EE 領(lǐng)域中最流行的開(kāi)發(fā)框架，用來(lái)簡(jiǎn)化 Spring 應(yīng)用程序的框架搭建和開(kāi)發(fā)過(guò)程。

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

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

為什么選擇SpringCloud alibaba

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

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

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

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