基于SpringCloud的微服務(wù)架構(gòu)演變史？

前言

一段時(shí)期以來 “微服務(wù)架構(gòu) ”一直是一個(gè)熱門詞匯，各種技術(shù)類公眾號(hào)或架構(gòu)分享會(huì)議上，關(guān)于微服務(wù)架構(gòu)的討論和主題也都非常多。對(duì)于大部分初創(chuàng)互聯(lián)網(wǎng)公司來說，早期的單體應(yīng)用結(jié)構(gòu)才是最合適的選擇，只有當(dāng)業(yè)務(wù)進(jìn)入快速發(fā)展期，在系統(tǒng)壓力、業(yè)務(wù)復(fù)雜度以及人員擴(kuò)展速度都快速上升的情況下，如何快速、穩(wěn)妥有序的將整個(gè)互聯(lián)網(wǎng)軟件系統(tǒng)升級(jí)成微服務(wù)架構(gòu)，以滿足業(yè)務(wù)發(fā)展需要及技術(shù)組織的重新塑造，才是進(jìn)行微服務(wù)架構(gòu)的最主要的動(dòng)力，否則空談微服務(wù)架構(gòu)是沒有意義的。

創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供上蔡網(wǎng)站建設(shè)、上蔡做網(wǎng)站、上蔡網(wǎng)站設(shè)計(jì)、上蔡網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、上蔡企業(yè)網(wǎng)站模板建站服務(wù)，10余年上蔡做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。

而一旦決定將整個(gè)應(yīng)用體系按照微服務(wù)架構(gòu)體系進(jìn)行升級(jí)，就需要有組織有計(jì)劃的進(jìn)行業(yè)務(wù)系統(tǒng)、基礎(chǔ)架構(gòu)、運(yùn)維體系等多個(gè)方面的升級(jí)配套。而另一個(gè)比較尷尬的現(xiàn)實(shí)是，一般業(yè)務(wù)發(fā)展進(jìn)入到需要進(jìn)行微服務(wù)架構(gòu)層面的時(shí)候，業(yè)務(wù)發(fā)展往往又都是非常迅猛的，這種業(yè)務(wù)快速發(fā)展和增長的壓力往往又會(huì)給整個(gè)技術(shù)團(tuán)隊(duì)帶來非常大的挑戰(zhàn)，因?yàn)榇藭r(shí)你需要取舍，是簡單方案快速支撐呢？還是選擇適當(dāng)長遠(yuǎn)一點(diǎn)的方案？當(dāng)然這種情況大部分是技術(shù)細(xì)節(jié)方面的問題，掌控的“度”大部分情況是掌握在具體的工程師手中。

而如何整體上確保應(yīng)用體系及組織結(jié)構(gòu)向微服務(wù)時(shí)代快速、有序的跨越，是一件十分考驗(yàn)團(tuán)隊(duì)能力以及架構(gòu)管理水平的事。能做到80分已然算優(yōu)秀了，因?yàn)檫@是有其客觀規(guī)律的！

作者自身親歷了一個(gè)快速發(fā)展的互聯(lián)網(wǎng)公司從單體應(yīng)用～以SpringCloud為技術(shù)棧的微服務(wù)架構(gòu)體系的全過程。本文將主要從技術(shù)角度與大家探討如何利用SpringCloud進(jìn)行微服務(wù)架構(gòu)拆分，以及在這個(gè)過程中一點(diǎn)自己的思考。水平有限，不足之處還請(qǐng)包涵！

系統(tǒng)架構(gòu)演變概述

在公司業(yè)務(wù)初創(chuàng)時(shí)期，面對(duì)的主要問題是如何將一個(gè)想法變成實(shí)際的軟件實(shí)現(xiàn)，在這個(gè)時(shí)候整個(gè)軟件系統(tǒng)的架構(gòu)并沒有搞得那么復(fù)雜，為了快速迭代，整個(gè)軟件系統(tǒng)就是由“App+后臺(tái)服務(wù)”組成，而后臺(tái)服務(wù)也只是從工程角度將應(yīng)用進(jìn)行Jar包的拆分。此時(shí)軟件系統(tǒng)架構(gòu)如下：

基于SpringCloud的微服務(wù)架構(gòu)演變史？

而此時(shí)整個(gè)軟件系統(tǒng)的功能也比較簡單，只有基本的用戶、訂單、支付等功能，并且由于業(yè)務(wù)流程沒有那么復(fù)雜，這些功能基本耦合在一起。而隨著App的受歡迎程度（作者所在的公司正好處于互聯(lián)網(wǎng)熱點(diǎn)），所以App下載量在2017年迅猛增長，在線注冊(cè)人數(shù)此時(shí)也是蹭蹭往上漲。

隨著流量的迅猛增長，此時(shí)整個(gè)后臺(tái)服務(wù)的壓力變得非常大，為了抗住壓力只能不斷的加機(jī)器，平行擴(kuò)展后臺(tái)服務(wù)節(jié)點(diǎn)。此時(shí)的部署架構(gòu)如下：

基于SpringCloud的微服務(wù)架構(gòu)演變史？

通過這種方式，整個(gè)軟件系統(tǒng)抗住了一波壓力，然而系統(tǒng)往往還是會(huì)偶爾出點(diǎn)事故，特別是因?yàn)閍pi中的某個(gè)接口性能問題導(dǎo)致整個(gè)服務(wù)不可用，因?yàn)檫@些接口都在一個(gè)JVM進(jìn)程中，雖然此時(shí)部署了多個(gè)節(jié)點(diǎn)，但因?yàn)榈讓訑?shù)據(jù)庫、緩存系統(tǒng)都是一套，所以還是會(huì)出現(xiàn)一掛全掛的情況。

另一方面，隨著業(yè)務(wù)的快速發(fā)展，以往相對(duì)簡單的功能變得復(fù)雜起來，這些功能除了有用戶看得見的、也會(huì)包括很多用戶看不見的，就好像百度搜索，用戶能看見的可能只是一個(gè)搜索框，但是實(shí)際上后臺(tái)對(duì)應(yīng)的服務(wù)可能是成百上千，如有些增長策略相關(guān)的功能：紅包、分享拉新等。還有些如廣告推薦相關(guān)的變現(xiàn)功能等。

此外，流量/業(yè)務(wù)的增長也意味著團(tuán)隊(duì)人數(shù)的迅速增長，如果此時(shí)大家開發(fā)各自的業(yè)務(wù)功能還是用一套服務(wù)代碼，很難想象百十來號(hào)人，在同一個(gè)工程在疊加功能會(huì)是一個(gè)什么樣的場景。所以如何劃分業(yè)務(wù)邊界、合理的進(jìn)行團(tuán)隊(duì)配置也是一件十分迫切的事情了！

為了解決上述問題，適應(yīng)業(yè)務(wù)、團(tuán)隊(duì)發(fā)展，架構(gòu)團(tuán)隊(duì)決定進(jìn)行微服務(wù)拆分。而要實(shí)施微服務(wù)架構(gòu)，除了需要合理的劃分業(yè)務(wù)模塊邊界外，也需要一整套完整的技術(shù)解決方案。

在技術(shù)方案的選擇上，服務(wù)拆分治理的框架也是有很多，早期的有如WebService，近期的則有各種Rpc框架（如Dubbo、Thirft、Grpc）。而Spring Cloud則是基于Springboot提供的一整套微服務(wù)解決方案，因?yàn)榧夹g(shù)棧比較新，并且各類組件的支撐也非常全面，所以Spring Cloud就成為了首選。

經(jīng)過一系列的重構(gòu)+擴(kuò)展，整個(gè)系統(tǒng)架構(gòu)最終形成了以app為中心的一套微服務(wù)軟件系統(tǒng)，結(jié)構(gòu)如下：

基于SpringCloud的微服務(wù)架構(gòu)演變史？

到這里，整個(gè)軟件系統(tǒng)就基于SpringCloud初步完成了微服務(wù)體系的拆分。支付、訂單、用戶、廣告等核心功能抽離成獨(dú)立的微服務(wù)，與此同時(shí)各自微服務(wù)對(duì)應(yīng)的數(shù)據(jù)庫也按照服務(wù)邊界進(jìn)行了拆分。

在完成服務(wù)的拆分以后，原來功能邏輯之間的代碼調(diào)用關(guān)系，轉(zhuǎn)換成了服務(wù)間網(wǎng)絡(luò)的調(diào)用關(guān)系，而各個(gè)微服務(wù)需要根據(jù)各自所承載的功能提供相應(yīng)的服務(wù)，此時(shí)服務(wù)如何被其他服務(wù)發(fā)現(xiàn)并調(diào)用，就成了整個(gè)微服務(wù)體系中比較關(guān)鍵的部分，使用過Dubbo框架的同學(xué)知道，在Dubbo中服務(wù)的注冊(cè)&發(fā)現(xiàn)是依賴于Zookeeper實(shí)現(xiàn)的，而在SpringCloud中我們是通過Consul來實(shí)現(xiàn)。另外在基于SpringCloud的架構(gòu)體系中，提供了配置中心（ConfigServer）來幫助各個(gè)微服務(wù)管理配置文件，而原本的api服務(wù)，隨著各個(gè)功能的抽離，逐步演變成前置網(wǎng)關(guān)服務(wù)了。

聊到這里，基于SpringCloud我們進(jìn)行了微服務(wù)拆分，而在這個(gè)體系結(jié)構(gòu)中，分別提到了Consul、ConfigServer、網(wǎng)關(guān)服務(wù)這幾個(gè)關(guān)鍵組件，那么這幾個(gè)關(guān)鍵組件具體是如何支撐這個(gè)龐大的服務(wù)體系的呢？

SpringCloud關(guān)鍵組件

Consul

Consul是一個(gè)開源的，使用go語言開發(fā)的注冊(cè)中心服務(wù)。它里面內(nèi)置了服務(wù)發(fā)現(xiàn)與注冊(cè)框架、分布一致性協(xié)議實(shí)現(xiàn)、健康檢查、Key/Value存儲(chǔ)、多數(shù)據(jù)中心等多個(gè)方案。在SpringCloud框架中還可以選擇Eurke作為注冊(cè)中心，這里之所以選擇Consul主要原因在于Consul對(duì)異構(gòu)的服務(wù)的支持,如：grpc服務(wù)。

事實(shí)上，在后續(xù)的系統(tǒng)架構(gòu)演進(jìn)中，在某些服務(wù)模塊進(jìn)一步向子系統(tǒng)化拆分的過程中，就采用了grpc作為子系統(tǒng)服務(wù)間的調(diào)用方式。例如，支付模塊的繼續(xù)擴(kuò)張，對(duì)支付服務(wù)本身又進(jìn)行了微服務(wù)架構(gòu)的拆分，此時(shí)支付微服務(wù)內(nèi)部就采用了grpc的方式進(jìn)行調(diào)用，而服務(wù)注冊(cè)與發(fā)現(xiàn)本身則還是依賴于同一套Consul集群。

此時(shí)的系統(tǒng)架構(gòu)演進(jìn)如下：

基于SpringCloud的微服務(wù)架構(gòu)演變史？

原有微服務(wù)架構(gòu)中的模塊服務(wù)在規(guī)模達(dá)到一定程度或復(fù)雜性達(dá)到一定程度后，都會(huì)朝著獨(dú)立的體系發(fā)展，從而將整個(gè)微服務(wù)的調(diào)用鏈路變的非常長，而從Consul的角度看，所有的服務(wù)又都是扁平的。

隨著微服務(wù)規(guī)模的越來越大，Consul作為整個(gè)體系的核心服務(wù)組件，在整個(gè)體系中處于關(guān)鍵的位置，一旦Consul掛掉，所有的服務(wù)都將停止服務(wù)。那么Consul到底是什么樣服務(wù)？其容災(zāi)機(jī)制又該如何設(shè)計(jì)呢？

要保證Consul服務(wù)的高可用，在生產(chǎn)環(huán)境Consul應(yīng)該是一個(gè)集群（關(guān)于Consul集群的安裝與配置可以參考網(wǎng)絡(luò)資料），這是毫無疑問的。而在Consul集群中，存在兩種角色：Server、Client，這兩種角色與Consul集群上運(yùn)行的應(yīng)用服務(wù)并沒有什么關(guān)系，只是基于Consul層面的一種角色劃分。實(shí)際上，維持整個(gè)Consul集群狀態(tài)信息的還是Server節(jié)點(diǎn)，與Dubbo中使用Zookeeper實(shí)現(xiàn)注冊(cè)中心一樣，Consul集群中的各個(gè)Server節(jié)點(diǎn)也需要通過選舉的方式（使用GOSSIP協(xié)議、Raft一致性算法，這里不做詳細(xì)展開，在后面的文章中可以和大家單獨(dú)討論）來選舉整個(gè)集群中的Leader節(jié)點(diǎn)來負(fù)責(zé)處理所有查詢和事務(wù)，并向其他節(jié)點(diǎn)同步狀態(tài)信息。

而Client角色則是相對(duì)無狀態(tài)的，只是簡單的代理轉(zhuǎn)發(fā)RPC請(qǐng)求到Server節(jié)點(diǎn)，之所以存在Client節(jié)點(diǎn)主要是分擔(dān)Server節(jié)點(diǎn)的壓力，作一層緩沖而已，這主要是因?yàn)镾erver節(jié)點(diǎn)的數(shù)量不宜過多，因?yàn)镾erver節(jié)點(diǎn)越多也就意味著達(dá)成共識(shí)的過程越慢，節(jié)點(diǎn)間同步的代價(jià)也就越高。對(duì)于Server節(jié)點(diǎn)，一般建議3-5臺(tái)，而Client節(jié)點(diǎn)則沒有數(shù)量的限制，可以根據(jù)實(shí)際情況部署數(shù)千或數(shù)萬臺(tái)。事實(shí)上，這也只是一種策略，在現(xiàn)實(shí)的生產(chǎn)環(huán)境中，大部分應(yīng)用只需要設(shè)置3～5臺(tái)Server節(jié)點(diǎn)就夠了，作者所在的公司一套生產(chǎn)集群中的Consul集群的節(jié)點(diǎn)配置就是5個(gè)Server節(jié)點(diǎn)，并沒有額外再設(shè)置Client節(jié)點(diǎn)。

另外，在Consul集群中還有一個(gè)概念是Agent，事實(shí)上每個(gè)Server或Client都是一個(gè)consul agent，它是運(yùn)行在Consul集群中每個(gè)成員上的一個(gè)守護(hù)進(jìn)程，主要的作用是運(yùn)行DNS或HTTP接口，并負(fù)責(zé)運(yùn)行時(shí)檢查和保持服務(wù)信息同步。我們?cè)趩?dòng)Consul集群的節(jié)點(diǎn)（Server或Client）時(shí)，都是通過consul agent的方式啟動(dòng)的。例如：

consul agent -server -bootstrap -syslog \
    -ui \
    -data-dir=/opt/consul/data \
    -dns-port=53
    -recursor=10.211.55.3
    -config-dir=/opt/consul/conf \
    -pid-file=/opt/consul/run/consul.pid \
    -client=10.211.55.4 \
    -bind=10.211.55.4 \
    -node=consul-server01 \
    -disable-host-node-id &

以實(shí)際的生產(chǎn)環(huán)境為例，Consul集群的部署結(jié)構(gòu)示意圖如下：

基于SpringCloud的微服務(wù)架構(gòu)演變史？

實(shí)際生產(chǎn)案例中并沒有設(shè)置Client節(jié)點(diǎn)，而是通過5個(gè)Consul Server節(jié)點(diǎn)組成的集群，來服務(wù)整套生產(chǎn)集群的應(yīng)用注冊(cè)&發(fā)現(xiàn)。這里有細(xì)節(jié)需要了解下，實(shí)際上5個(gè)Consul Server節(jié)點(diǎn)的IP地址是不一樣的，具體的服務(wù)在連接Consul集群進(jìn)行服務(wù)注冊(cè)與查詢時(shí)應(yīng)該連接Leader節(jié)點(diǎn)的IP，而問題是，如果Leader節(jié)點(diǎn)掛掉了，相應(yīng)的應(yīng)用服務(wù)節(jié)點(diǎn)，此時(shí)如何連接通過Raft選舉產(chǎn)生的新Leader節(jié)點(diǎn)呢？難道手工切換IP不成？

顯然手工切換IP的方式并不靠譜，而在生產(chǎn)實(shí)踐中，Consul集群的各個(gè)節(jié)點(diǎn)實(shí)際上是在Consul Agent上運(yùn)行DNS（如啟動(dòng)參數(shù)中紅色字體部分），應(yīng)用服務(wù)在連接Consul集群時(shí)的IP地址為DNS的IP，DNS會(huì)將地址解析映射到Leader節(jié)點(diǎn)對(duì)應(yīng)的IP上，如果Leader節(jié)點(diǎn)掛掉，選舉產(chǎn)生的新Leader節(jié)點(diǎn)會(huì)將自己的IP通知DNS服務(wù)，DNS更新映射關(guān)系，這一過程對(duì)各應(yīng)用服務(wù)則是透明的。

通過以上分析，Consul是通過集群設(shè)計(jì)、Raft選舉算法，Gossip協(xié)議等機(jī)制來確保Consul服務(wù)的穩(wěn)定與高可用的。如果需要更高的容災(zāi)級(jí)別，也可以通過設(shè)計(jì)雙數(shù)據(jù)中心的方式，來異地搭建兩個(gè)Consul數(shù)據(jù)中心，組成一個(gè)異地災(zāi)備Consul服務(wù)集群，只是這樣成本會(huì)更高，這就看具體是否真的需要了。

ConfigServer(配置中心)

配置中心是對(duì)微服務(wù)應(yīng)用配置進(jìn)行管理的服務(wù)，例如數(shù)據(jù)庫的配置、某些外部接口地址的配置等等。在SpringCloud中ConfigServer是獨(dú)立的服務(wù)組件，它與Consul一樣也是整個(gè)微服務(wù)體系中比較關(guān)鍵的一個(gè)組件，所有的微服務(wù)應(yīng)用都需要通過調(diào)用其服務(wù)，從而獲取應(yīng)用所需的配置信息。

隨著微服務(wù)應(yīng)用規(guī)模的擴(kuò)大，整個(gè)ConfigServer節(jié)點(diǎn)的訪問壓力也會(huì)逐步增加，與此同時(shí)，各個(gè)微服務(wù)的各類配置也會(huì)越來越多，如何管理好這些配置文件以及它們的更新策略（確保不因生產(chǎn)配置隨意改動(dòng)而造成線上故障風(fēng)險(xiǎn)），以及搭建高可用的ConfigServer集群，也是確保微服務(wù)體系穩(wěn)定很重要的一個(gè)方面。

在生產(chǎn)實(shí)踐中，因?yàn)橄馛onsul、ConfigServer這樣的關(guān)鍵組件，需要搭建獨(dú)立的集群，并且部署在物理機(jī)而不是容器里。在上一節(jié)介紹Consul的時(shí)候，我們是獨(dú)立搭建了5個(gè)Consul Server節(jié)點(diǎn)。而ConfigServer因?yàn)橹饕莌ttp配置文件訪問服務(wù)，不涉及節(jié)點(diǎn)選舉、一致性同步這樣的操作，所以還是按照傳統(tǒng)的方式搭建高可用配置中心。具體結(jié)構(gòu)示意圖如下：

基于SpringCloud的微服務(wù)架構(gòu)演變史？

我們可以單獨(dú)通過git來管理應(yīng)用配置文件，正常來說由ConfigSeever直接通過網(wǎng)絡(luò)拉取git倉庫的配置供服務(wù)獲取就可以了，這樣只要git倉庫配置更新，配置中心就能立刻感知到。但是這樣做的不穩(wěn)定之處，就在于git本身是內(nèi)網(wǎng)開發(fā)用的代碼管理工具，如果讓線上實(shí)時(shí)服務(wù)直接讀取，很容易將git倉庫拉掛了，所以，我們?cè)趯?shí)際的運(yùn)維過程中，是通過git進(jìn)行配置文件的版本控制，區(qū)分線上分支/master與功能開發(fā)分支/feature，并且在完成mr后還需要手工（通過發(fā)布平臺(tái)觸發(fā)）同步一遍配置，過程是將新的master分支的配置同步一份到各個(gè)configserver節(jié)點(diǎn)所在主機(jī)的本地路徑，這樣configserver服務(wù)節(jié)點(diǎn)就可以通過其本地目錄獲取配置文件，而不用多次調(diào)用網(wǎng)絡(luò)獲取配置文件了。

而另一方面，隨著微服務(wù)越來越多，git倉庫中的配置文件數(shù)量也會(huì)越來越多。為了便于配置的管理，我們需要按照一定的組織方式來組織不同應(yīng)用類型的配置。在早期所有的應(yīng)用因?yàn)闆]有分類，所以導(dǎo)致上百個(gè)微服務(wù)的配置文件放在一個(gè)倉庫目錄，這樣一來導(dǎo)致配置文件管理成本增加，另外一方面也會(huì)影響ConfigServer的性能，因?yàn)槟硞€(gè)微服務(wù)用不到的配置也會(huì)被ConfigServer加載。

所以后期的實(shí)踐是，按照配置的層次關(guān)系進(jìn)行組織，將公司全局的項(xiàng)目配置抽象到頂層，由ConfigServer默認(rèn)加載，而其他所有的微服務(wù)則按照應(yīng)用類型進(jìn)行分組（通過git項(xiàng)目空間的方式分組），相同的應(yīng)用放在一個(gè)組，然后這個(gè)組下單獨(dú)設(shè)立一個(gè)名為config的git倉庫來存放這個(gè)組下相關(guān)微服務(wù)的配置文件。層次結(jié)構(gòu)如下：

基于SpringCloud的微服務(wù)架構(gòu)演變史？

這樣應(yīng)用加載配置的優(yōu)先級(jí)就是“本地配置->common配置->組公共配置->項(xiàng)目配置”這樣的順序。例如某服務(wù)A，在項(xiàng)目工程的默認(rèn)配置文件（“bootstrap.yml/application.yml”）中配置了參數(shù)A，同時(shí)也在本地項(xiàng)目配置“application-production.yml”配置了參數(shù)B，而與此同時(shí)，ConfigServer中的common倉庫下的配置文件“application.yml／application-production.yml”又分別存在參數(shù)C、參數(shù)D，同時(shí)有個(gè)組叫“pay”，其下的默認(rèn)配置文件“application.yml／application-production.yml”存在參數(shù)E、參數(shù)F，具體項(xiàng)目pay-api又存在配置文件“pay-api-production.yml”其覆蓋了common倉庫中參數(shù)C、參數(shù)D的值。那么此時(shí)如果該應(yīng)用以“spring.profiles.active=production”的方式啟動(dòng)，那么其能獲取到的配置參數(shù)（通過鏈接訪問：http://{spring.cloud.config.uri}/pay-api-production.yml）就是A、B、C、D、E、F，其中C、D的參數(shù)值為pay-api-production.yml中最后覆蓋的值。

而對(duì)于ConfigServer服務(wù)本身來說，需要按照這樣的組織方式進(jìn)行配置類型匹配，例如上述的例子中，假設(shè)還存在finance的配置倉庫，而pay組下的服務(wù)訪問配置中心的時(shí)候，是不需要finance空間下的配置文件的，所以ConfigServer可以不用加載。這里就需要在ConfigServer服務(wù)配置中進(jìn)行一些配置。具體如下：

spring:
  application:
    name: @project.artifactId@
    version: @project.version@
    build: @buildNumber@
    branch: @scmBranch@
  cloud:
    inetutils:
      ignoredInterfaces:
        - docker0
    config:
      server:
        health.enabled: false
        git:
          uri: /opt/repos/config
          searchPaths: 'common,{application}'
          cloneOnStart: true
          repos:
            pay:
                pattern: pay-*
                cloneOnStart: true
                uri: /opt/repos/example/config
                searchPaths: 'common,{application}'
            finance:
                pattern: finance-*
                cloneOnStart: true
                uri: /opt/repos/finance/config
                searchPaths: 'common,{application}'

通過在ConfigServer服務(wù)本身的application.yml本地配置中，設(shè)置其配置搜索方式，來實(shí)現(xiàn)這樣的目的。