前言

Spring Cloud是一個基于Spring Boot實現(xiàn)的云應(yīng)用開發(fā)工具寺董，它為基于JVM的云應(yīng)用開發(fā)中的配置管理菊值、服務(wù)注冊外驱，服務(wù)發(fā)現(xiàn)、斷路器俊性、智能路由略步、微代理、控制總線定页、全局鎖趟薄、決策競選、分布式會話和集群狀態(tài)管理等操作提供了一種簡單的開發(fā)方式典徊。

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

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

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

隨著流量的迅猛增長讨越，此時整個后臺服務(wù)的壓力變得非常大两残，為了抗住壓力只能不斷的加機器，平行擴展后臺服務(wù)節(jié)點把跨。此時的部署架構(gòu)如下：

通過這種方式人弓，整個軟件系統(tǒng)抗住了一波壓力，然而系統(tǒng)往往還是會偶爾出點事故节猿，特別是因為api中的某個接口性能問題導(dǎo)致整個服務(wù)不可用票从，因為這些接口都在一個JVM進(jìn)程中，雖然此時部署了多個節(jié)點滨嘱，但因為底層數(shù)據(jù)庫峰鄙、緩存系統(tǒng)都是一套，所以還是會出現(xiàn)一掛全掛的情況太雨。

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

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

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

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

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

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

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

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

SpringCloud關(guān)鍵組件

Consul

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

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

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

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

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

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

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

另外，在Consul集群中還有一個概念是Agent顶考，事實上每個Server或Client都是一個consul agent赁还，它是運行在Consul集群中每個成員上的一個守護進(jìn)程，主要的作用是運行DNS或HTTP接口驹沿，并負(fù)責(zé)運行時檢查和保持服務(wù)信息同步艘策。我們在啟動Consul集群的節(jié)點（Server或Client）時，都是通過consul agent的方式啟動的甚负。例如：

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 &

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

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

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

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

ConfigServer(配置中心)

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

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

在生產(chǎn)實踐中，因為像Consul缩幸、ConfigServer這樣的關(guān)鍵組件壹置，需要搭建獨立的集群，并且部署在物理機而不是容器里表谊。在上一節(jié)介紹Consul的時候钞护，我們是獨立搭建了5個Consul Server節(jié)點。而ConfigServer因為主要是http配置文件訪問服務(wù)爆办，不涉及節(jié)點選舉难咕、一致性同步這樣的操作，所以還是按照傳統(tǒng)的方式搭建高可用配置中心距辆。具體結(jié)構(gòu)示意圖如下：

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

而另一方面丛晦，隨著微服務(wù)越來越多奕纫，git倉庫中的配置文件數(shù)量也會越來越多。為了便于配置的管理烫沙，我們需要按照一定的組織方式來組織不同應(yīng)用類型的配置匹层。在早期所有的應(yīng)用因為沒有分類，所以導(dǎo)致上百個微服務(wù)的配置文件放在一個倉庫目錄锌蓄，這樣一來導(dǎo)致配置文件管理成本增加升筏，另外一方面也會影響ConfigServer的性能撑柔，因為某個微服務(wù)用不到的配置也會被ConfigServer加載。

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

這樣應(yīng)用加載配置的優(yōu)先級就是“本地配置->common配置->組公共配置->項目配置”這樣的順序肢扯。例如某服務(wù)A，在項目工程的默認(rèn)配置文件（“bootstrap.yml/application.yml”）中配置了參數(shù)A担锤，同時也在本地項目配置“application-production.yml”配置了參數(shù)B蔚晨，而與此同時，ConfigServer中的common倉庫下的配置文件“application.yml／application-production.yml”又分別存在參數(shù)C肛循、參數(shù)D铭腕，同時有個組叫“pay”，其下的默認(rèn)配置文件“application.yml／application-production.yml”存在參數(shù)E多糠、參數(shù)F累舷，具體項目pay-api又存在配置文件“pay-api-production.yml”其覆蓋了common倉庫中參數(shù)C、參數(shù)D的值夹孔。那么此時如果該應(yīng)用以“spring.profiles.active=production”的方式啟動被盈，那么其能獲取到的配置參數(shù)（通過鏈接訪問：http://{spring.cloud.config.uri}/pay-api-production.yml）就是A、B搭伤、C只怎、D、E怜俐、F身堡，其中C、D的參數(shù)值為pay-api-production.yml中最后覆蓋的值拍鲤。

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

spring:application:name:@project.artifactId@version:@project.version@build:@buildNumber@branch:@scmBranch@cloud:inetutils:ignoredInterfaces: - docker0config:server: health.enabled: falsegit:uri: /opt/repos/configsearchPaths:'common,{application}'cloneOnStart: truerepos:pay:pattern: pay-*cloneOnStart: trueuri: /opt/repos/example/configsearchPaths:'common,{application}'finance:pattern: finance-*cloneOnStart: trueuri: /opt/repos/finance/configsearchPaths:'common,{application}'

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

網(wǎng)關(guān)服務(wù)&服務(wù)熔斷&監(jiān)控

通過上面兩小節(jié)的內(nèi)容，我們相對詳細(xì)地介紹了基于SpringCloud體系中比較關(guān)鍵的兩個服務(wù)組件逐哈。然而在微服務(wù)架構(gòu)體系中芬迄，還有很多關(guān)鍵的問題需要解決，例如昂秃，應(yīng)用服務(wù)在Consul中部署了多個節(jié)點禀梳，那么調(diào)用方如何實現(xiàn)負(fù)載均衡？

關(guān)于這個問題肠骆，在傳統(tǒng)的架構(gòu)方案中是通過Nginx實現(xiàn)的算途，但是在前面介紹Consul的時候只提到了Consul的服務(wù)注冊&發(fā)現(xiàn)、選舉等機制蚀腿，并沒有提到Consul如何在實現(xiàn)服務(wù)調(diào)用的負(fù)載均衡嘴瓤。難道基于SpringCloud的微服務(wù)體系中的應(yīng)用服務(wù)都是單節(jié)點在提供服務(wù)，哪怕即使部署了多個服務(wù)節(jié)點莉钙？事實上廓脆，我們在服務(wù)消費方通過@EnableFeignClients注解開啟調(diào)用，通過@FeignClient("user")注解進(jìn)行服務(wù)調(diào)用時磁玉，就已經(jīng)實現(xiàn)了負(fù)載均衡停忿，為什么呢？因為蚊伞，這個注解默認(rèn)是會默認(rèn)開啟Robbin代理的席赂，而Robbin是實現(xiàn)客戶端負(fù)載均衡的一個組件，通過從Consul拉取服務(wù)節(jié)點信息厚柳，從而以輪詢的方式轉(zhuǎn)發(fā)客戶端調(diào)用請求至不同的服務(wù)端節(jié)點來實現(xiàn)負(fù)載均衡。而這一切都是在消費端的進(jìn)程內(nèi)部通過代碼的方式實現(xiàn)的沐兵。這種負(fù)載方式寄宿于消費端應(yīng)用服務(wù)上别垮，對消費端存在一定的代碼侵入性，這是為什么后面會出現(xiàn)Service Mesh（服務(wù)網(wǎng)格）概念的原因之一扎谎，這里就不展開了碳想，后面有機會再和大家交流。

另一需要解決的關(guān)鍵問題是服務(wù)熔斷毁靶、限流等機制的實現(xiàn)胧奔，SpringCloud通過集成Netflix的Hystrix框架來提供這種機制的支持，與負(fù)載均衡機制一樣也是在消費端實現(xiàn)预吆。由于篇幅的關(guān)系龙填，這里也不展開了，在后面的文章中有機會再和大家交流。

此外還有Zuul組件來實現(xiàn)API網(wǎng)關(guān)服務(wù)岩遗，提供路由分發(fā)與過濾相關(guān)的功能扇商。而其他輔助組件還有諸如Sleuth來實現(xiàn)分布式鏈路追蹤、Bus實現(xiàn)消息總線宿礁、Dashboard實現(xiàn)監(jiān)控儀表盤等案铺。由于SpringCloud的開源社區(qū)比較活躍，還有很多新的組件在不斷的被集成進(jìn)來梆靖，感興趣的朋友可以持續(xù)關(guān)注下控汉！

微服務(wù)之運維形態(tài)

在微服務(wù)體系結(jié)構(gòu)下，隨著服務(wù)數(shù)量大量的增長返吻，線上的部署&維護的工作量會變得非常大姑子，而如果還采用原有的運維模式的話，就能難滿足需要了思喊。此時運維團隊需要實施Devops策略壁酬，開發(fā)自動化運維發(fā)布平臺，打通產(chǎn)品恨课、開發(fā)舆乔、測試、運維流程剂公，關(guān)注研發(fā)效能希俩。

另外一方面也需要推進(jìn)容器化（Docker/Docker Swarm/k8s）策略，這樣才能快速對服務(wù)節(jié)點進(jìn)行伸縮纲辽，這也是微服務(wù)體系下的必然要求颜武。

微服務(wù)泛濫問題

這里還需要注意一個問題，就是實施微服務(wù)架構(gòu)后拖吼，如何在工程上管控微服務(wù)的問題鳞上。盲目的進(jìn)行微服務(wù)的拆分也不是一件很合理的事情，因為這會導(dǎo)致整個服務(wù)調(diào)用鏈路變得深不可測吊档，對問題排查造成難度篙议，也浪費線上資源。

重構(gòu)問題

在早期單體架構(gòu)方式向微服務(wù)架構(gòu)的轉(zhuǎn)變過程中怠硼，重構(gòu)是一個非常好的方式鬼贱，也是確保服務(wù)規(guī)范化，業(yè)務(wù)系統(tǒng)應(yīng)用架構(gòu)合理化的很重要的手段香璃。但是这难，一般來說，在快速發(fā)展階段也就意味著團隊規(guī)模的迅速增長葡秒，短時間內(nèi)如何讓新的團隊有事可做也是一件非骋雠遥考驗管理水平的事情嵌溢，因為如果招了很多人，并且他們之間呈現(xiàn)一種過渡的競爭狀態(tài)的話糖权，就會出現(xiàn)讓重構(gòu)這件事變得有些功利的情況堵腹，從而導(dǎo)致重構(gòu)不徹底、避重就輕星澳，導(dǎo)致表象上看是很高大上的微服務(wù)架構(gòu)疚顷，而業(yè)務(wù)系統(tǒng)實際上比較爛的情況。

另外禁偎，重構(gòu)是在一定階段后作出的重要決策腿堤，不僅僅是重新拆分，也是對業(yè)務(wù)系統(tǒng)的重新塑造如暖，所以一定要考慮好應(yīng)用軟件的系統(tǒng)結(jié)構(gòu)以及實施它們所需要付出的成本笆檀，切不可盲目！

總結(jié)

基于SpringCloud的微服務(wù)架構(gòu)體系盒至，通過集成各種開源組件來為整個體系服務(wù)支持酗洒，但是在負(fù)載均衡、熔斷枷遂、流量控制的方面需要對服務(wù)消費端的業(yè)務(wù)進(jìn)程進(jìn)行侵入樱衷。所以很多人會認(rèn)為這不是一件很好的事情，于是出現(xiàn)了Service Mesh（服務(wù)網(wǎng)格）的概念酒唉，Service Mesh的基本思路就是通過主機獨立Proxy進(jìn)行的部署來解耦業(yè)務(wù)系統(tǒng)進(jìn)程矩桂，這個Proxy除了負(fù)責(zé)服務(wù)發(fā)現(xiàn)和負(fù)載均衡（不在需要單獨的注冊組件，如Consul）外痪伦，還負(fù)責(zé)動態(tài)路由侄榴、容錯限流、監(jiān)控度量和安全日志等功能网沾。

而在具體的服務(wù)組件上目前主要是 Google/IBM 等大廠支持和推進(jìn)的一個叫做Istio的ServiceMesh 標(biāo)準(zhǔn)化工作組癞蚕。具體關(guān)于Service Mesh的知識，在后面的內(nèi)容中再和大家交流辉哥。以上就是本文的全部內(nèi)容桦山，由于作者水平有限，還請多多包涵证薇！