轉(zhuǎn)眼已經(jīng) 2020，距離微服務(wù)這個(gè)詞落地已經(jīng)過(guò)去好多年！（我記得 2017 年就聽(tīng)過(guò)這個(gè)詞）林说。然而今天我想想什么是微服務(wù)，其實(shí)并沒(méi)有一個(gè)很好的定義屡谐。

為什么這樣說(shuō)述么？按照微服務(wù)的定義：

微服務(wù)架構(gòu)就是將一個(gè)龐大的業(yè)務(wù)系統(tǒng)按照業(yè)務(wù)模塊拆分成若干個(gè)獨(dú)立的子系統(tǒng)蝌数，每個(gè)子系統(tǒng)都是一個(gè)獨(dú)立的應(yīng)用愕掏，它是一種將應(yīng)用構(gòu)建成一系列按業(yè)務(wù)領(lǐng)域劃分模塊的，小的自治服務(wù)的軟件架構(gòu)方式顶伞，倡導(dǎo)將復(fù)雜的單體應(yīng)用拆分成若干個(gè)功能單一饵撑、松偶合的服務(wù)，這樣可以降低開(kāi)發(fā)難度唆貌、增強(qiáng)擴(kuò)展性滑潘、便于敏捷開(kāi)發(fā)，及持續(xù)集成與交付活動(dòng)锨咙。

根據(jù)這個(gè)定義语卤，不難看出其實(shí)就是對(duì)復(fù)雜的業(yè)務(wù)系統(tǒng)統(tǒng)一做邏輯拆分，保持邏輯上的獨(dú)立。

那么邏輯上獨(dú)立粹舵，一個(gè)服務(wù)這樣做真的就好嗎钮孵，如何界定：小、獨(dú)眼滤，還有要做一個(gè)事情巴席，完成單一的業(yè)務(wù)，單一的功能要拆分出來(lái)诅需，為了獨(dú)立而獨(dú)立會(huì)不會(huì)導(dǎo)致拆的過(guò)細(xì)漾唉？

不同人有不同的見(jiàn)解，我們今天一起探討微服務(wù)的過(guò)去和未來(lái)堰塌。

微服務(wù)緣起

在沒(méi)有微服務(wù)之前赵刑，我們最早的架構(gòu)模式就是 MVC 模式，把業(yè)務(wù)邏輯分為：

表示層業(yè)務(wù)邏輯層數(shù)據(jù)訪問(wèn)層

MVC 模式隨著大前端的發(fā)展场刑，從一開(kāi)始的前后端不分離料睛，到現(xiàn)在的前后端分離逐漸演進(jìn)。

這種演進(jìn)好的一點(diǎn)是剝離了不同開(kāi)發(fā)語(yǔ)言的開(kāi)發(fā)環(huán)境和部署環(huán)境摇邦，使得開(kāi)發(fā)較為便利恤煞，部署更直接。

然而問(wèn)題是：這種模式仍然是單體應(yīng)用模式施籍，如果有一個(gè)改動(dòng)需要上線居扒，你不得不因?yàn)檫@個(gè)改動(dòng)去考慮更多，因?yàn)槟銦o(wú)法估量在這么大體量的代碼中你的一個(gè)改動(dòng)會(huì)不會(huì)引發(fā)蝴蝶效應(yīng)丑慎。

另外很重要的一點(diǎn)就是移動(dòng)互聯(lián)網(wǎng)時(shí)代的到來(lái)喜喂，引發(fā)了用戶數(shù)幾何倍數(shù)暴增，傳統(tǒng)的單體應(yīng)用模式已經(jīng)無(wú)法支撐用戶量暴漲的流量沖擊竿裂，互聯(lián)網(wǎng)人不得不做出加機(jī)器的無(wú)奈之舉玉吁。

然而發(fā)現(xiàn)有的時(shí)候加機(jī)器都無(wú)法搞定問(wèn)題，因?yàn)檫壿嬚{(diào)用過(guò)于耦合導(dǎo)致調(diào)用鏈復(fù)雜腻异。

繼而出現(xiàn)精簡(jiǎn)調(diào)用流程进副，梳理調(diào)用路徑的舉措，于是演變出微服務(wù)這個(gè)概念悔常。

其實(shí)在沒(méi)有微服務(wù)這個(gè)詞出現(xiàn)之前影斑， 我們也是這樣干的，只是干的不徹底而已机打。

比如說(shuō)有一個(gè)信貸系統(tǒng)矫户，分為貸前，貸中残邀，貸后三步：

在微服務(wù)未出現(xiàn)之前皆辽，我們大多是單體應(yīng)用柑蛇，基本上一個(gè)工程包含所有，無(wú)所不能驱闷，所以很臃腫唯蝶。上述這些模塊應(yīng)該都是在一個(gè)工程中，但是按照業(yè)務(wù)做了代碼上的拆分遗嗽。

另外就是 RPC 框架橫空出世粘我，如果有服務(wù)上的拆分，比如不同部門(mén)之間調(diào)用對(duì)方提供的服務(wù)痹换，那么八九不離十肯定定義的是 HTTP 接口征字，因?yàn)橥ㄓ谩５悄承r(shí)候大家又怕 HTTP 接口性能差娇豫，關(guān)鍵服務(wù)不敢用匙姜。

微服務(wù)出現(xiàn)之后，大家覺(jué)得按照模塊分別部署好像是這么回事冯痢，同時(shí)默默在心里嘀咕氮昧，以前我只用發(fā)布一個(gè)工程，現(xiàn)在倒好浦楣，可能有個(gè)改動(dòng)涉及 3 個(gè)服務(wù)袖肥，我一個(gè)小小的改動(dòng)就要發(fā)布 3 次，是不是增加了工作量振劳。

另外我以前都不用調(diào)接口的椎组，現(xiàn)在依賴了一堆別的系統(tǒng)，系統(tǒng)調(diào)用這么復(fù)雜历恐，萬(wàn)一別的系統(tǒng)有問(wèn)題寸癌，我豈不是就被耽擱了！

在這種質(zhì)疑中大家雖有抱怨但是也沒(méi)有放棄趕時(shí)髦弱贼，微服務(wù)開(kāi)展的如火如荼蒸苇，用戶中心獨(dú)立部署，風(fēng)控系統(tǒng)單獨(dú)成型吮旅，支付中心全公司統(tǒng)一獨(dú)立溪烤，財(cái)務(wù)系統(tǒng)不再各個(gè)業(yè)務(wù)各自為戰(zhàn)而是統(tǒng)籌公司各個(gè)業(yè)務(wù)線統(tǒng)一規(guī)劃。

按照業(yè)務(wù)抽象獨(dú)立之后鸟辅，大家發(fā)現(xiàn)好像是這么回事氛什，用起來(lái)真香。雖然每次需要?jiǎng)e的模塊的時(shí)候就需要找對(duì)應(yīng)模塊進(jìn)行接入匪凉，但是業(yè)務(wù)邏輯上清晰了呀，如果出了問(wèn)題捺檬，不是自己的再层，那就是別人的，甩鍋很方便的（笑）。

如何做微服務(wù)

因?yàn)槲⒎?wù)是功能粒度上的拆分聂受，必然導(dǎo)致拆分之后的模塊變多蒿秦。

針對(duì)模塊與模塊之間的通信與維護(hù)，又演變出如下問(wèn)題：

模塊與模塊之間如何通信每個(gè)被拆分的微服務(wù)如何做負(fù)載均衡服務(wù)如何做注冊(cè)蛋济，如何做發(fā)現(xiàn)服務(wù)之間調(diào)用如何做限流棍鳖，服務(wù)調(diào)用失敗如何做降級(jí)，流量異常如何做熔斷服務(wù)調(diào)用是否可以做統(tǒng)一的訪問(wèn)控制

針對(duì)這些問(wèn)題碗旅，業(yè)界也在發(fā)展中慢慢演進(jìn)出幾套通用的框架渡处。

理想中微服務(wù)框架應(yīng)該具備這樣的能力：

基于上述微服務(wù)框架應(yīng)該具備的能力，我們來(lái)分析目前可以落地的微服務(wù)框架的具體實(shí)現(xiàn)祟辟。

目前國(guó)內(nèi)用的最多的無(wú)外乎是兩套框架：

DubboSpring Cloud

Dubbo 大家都很熟悉医瘫，從開(kāi)源到無(wú)人維護(hù)再到重新沖擊 Apache 頂級(jí)項(xiàng)目。

但是 Dubbo 更加準(zhǔn)確來(lái)說(shuō)是一個(gè)分布式服務(wù)框架旧困，致力于提供高效的 RPC 遠(yuǎn)程服務(wù)調(diào)用方案以及 SOA 服務(wù)治理方案醇份。說(shuō)白了就是個(gè)分布式遠(yuǎn)程服務(wù)調(diào)用框架。

Dubbo

從 Dubbo 官網(wǎng)給的圖來(lái)看 Dubbo 的整體架構(gòu)：

模塊注解：

Provider：暴露服務(wù)的服務(wù)提供方吼具。Consumer：調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方僚纷。Registry：服務(wù)注冊(cè)與發(fā)現(xiàn)的注冊(cè)中心。Monitor：統(tǒng)計(jì)服務(wù)的調(diào)用次數(shù)和調(diào)用時(shí)間的監(jiān)控中心拗盒。Container：服務(wù)運(yùn)行容器畔濒。

從上圖中不難看出 Dubbo 功能還是很明確的：服務(wù)注冊(cè)于發(fā)現(xiàn)，服務(wù)監(jiān)控锣咒。

另外 Dubbo 也提供服務(wù)治理功能：

Dubbo 提供了集群容錯(cuò)的能力侵状，在管理后臺(tái)可以快速的摘除失敗的服務(wù)。

從我們上面提到的一整套微服務(wù)應(yīng)該提供的功能看毅整，Dubbo 只是提供了服務(wù)注冊(cè)與服務(wù)發(fā)現(xiàn)的功能趣兄。不可否認(rèn)在這一項(xiàng)功能中，Dubbo 做的是非常優(yōu)秀的悼嫉。

Spring Cloud

Spring Cloud 基于 Spring Boot艇潭，為微服務(wù)體系開(kāi)發(fā)中的架構(gòu)問(wèn)題，提供了一整套的解決方案：服務(wù)注冊(cè)與發(fā)現(xiàn)戏蔑，服務(wù)消費(fèi)蹋凝，服務(wù)保護(hù)與熔斷，網(wǎng)關(guān)总棵，分布式調(diào)用追蹤鳍寂，分布式配置管理等。

①服務(wù)注冊(cè)與發(fā)現(xiàn)

目前 Spring Cloud 支持的服務(wù)注冊(cè)組件有：

ConsulEureka

Consul 不是 Spring 官方的項(xiàng)目情龄，需要單獨(dú)部署迄汛，Eureka 被 Spring 官方收錄捍壤，本身屬于 Spring Cloud 體系中。

下面列出可以被用作注冊(cè)中心的組件鞍爱，他們的特性對(duì)比：

Consul 官網(wǎng)中介紹了 Consul 的以下幾個(gè)核心功能：

服務(wù)發(fā)現(xiàn)(Service Discovery)：提供 HTTP 與DNS 兩種方式鹃觉。健康檢查(Health Checking)：提供多種健康檢查方式，比如 HTTP 狀態(tài)碼睹逃、內(nèi)存使用情況盗扇、硬盤(pán)等等。鍵值存儲(chǔ)(KV Store)：可以作為服務(wù)配置中心使用沉填，類似 Spring Cloud Config疗隶。加密服務(wù)通信(Secure Service Communication)。多數(shù)據(jù)中心(Multi Datacenter)：Consul 通過(guò) WAN 的 Gossip 協(xié)議拜轨，完成跨數(shù)據(jù)中心的同步抽减。

Consul 需要單獨(dú)部署，而不是與 Spring 集成的組件橄碾。

Eureka 是 Spring Cloud NetFlix 默認(rèn)的服務(wù)發(fā)現(xiàn)框架卵沉，但目前 2.0 版本已閉源，只剩下 1.9 版本的處于維護(hù)狀態(tài)法牲。

Eureka 使用盡力而為同步的方式提供弱一致的服務(wù)列表史汗。當(dāng)一個(gè)服務(wù)注冊(cè)時(shí)，Eureka 會(huì)嘗試將其同步到其他節(jié)點(diǎn)上拒垃，但不提供一致性的保證停撞。

因此，Eureka 可以提供過(guò)時(shí)的或是已不存在的服務(wù)列表(在服務(wù)發(fā)現(xiàn)場(chǎng)景下悼瓮，返回舊的總比什么也不返回好)戈毒。

如果在 15 分鐘內(nèi)超過(guò) 85% 的客戶端節(jié)點(diǎn)都沒(méi)有正常的心跳，那么 Eureka 就會(huì)認(rèn)為客戶端與注冊(cè)中心出現(xiàn)了網(wǎng)絡(luò)故障(出現(xiàn)網(wǎng)絡(luò)分區(qū))横堡，進(jìn)入自我保護(hù)機(jī)制埋市。

此時(shí)：

Eureka Server 會(huì)保護(hù)服務(wù)注冊(cè)表中的信息，不再刪除服務(wù)命贴。這是由于如果出現(xiàn)網(wǎng)絡(luò)分區(qū)導(dǎo)致其他微服務(wù)和該 Eureka Server 無(wú)法通信道宅，Eureka Server 就會(huì)判定這些微服務(wù)失效，但很可能這些微服務(wù)都是健康的胸蛛。Eureka Server 仍能接受新服務(wù)的注冊(cè)和查詢請(qǐng)求污茵，但這些數(shù)據(jù)不會(huì)被同步到其他節(jié)點(diǎn)。當(dāng)網(wǎng)絡(luò)恢復(fù)時(shí)葬项，這個(gè) Eureka Server 節(jié)點(diǎn)的數(shù)據(jù)會(huì)被同步到其他節(jié)點(diǎn)中泞当。

優(yōu)點(diǎn)：Eureka Server 可以很好的應(yīng)對(duì)因網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點(diǎn)失聯(lián)的情況，而不會(huì)像 ZK 那樣如果有一半不可用的情況會(huì)導(dǎo)致整個(gè)集群不可用玷室。

②服務(wù)網(wǎng)關(guān)

微服務(wù)的拆分導(dǎo)致服務(wù)分散零蓉，如果一個(gè)大的業(yè)務(wù)要對(duì)外提供輸出笤受，每個(gè)服務(wù)單獨(dú)對(duì)外提供調(diào)用對(duì)接入方不友好并且調(diào)用也會(huì)很復(fù)雜穷缤。

所以出現(xiàn)了網(wǎng)關(guān)敌蜂，網(wǎng)關(guān)主要實(shí)現(xiàn)請(qǐng)求的路由轉(zhuǎn)發(fā)，負(fù)載均衡津肛，統(tǒng)一校驗(yàn)章喉，請(qǐng)求過(guò)濾等功能。

目前社區(qū)主流的網(wǎng)關(guān)有三個(gè)：

ZuulKongSpring Cloud GateWay

Zuul：是 Netflix 公司的開(kāi)源項(xiàng)目身坐，Spring Cloud 在 Netflix 項(xiàng)目中也已經(jīng)集成了 Zuul秸脱，依賴名叫：spring-cloud-starter-netflix-zuul。

Zuul 構(gòu)建于 Servlet 2.5部蛇，兼容 3.x摊唇，使用的是阻塞式的 API，不支持長(zhǎng)連接涯鲁，比如 Websockets巷查。

我們現(xiàn)在說(shuō)的 Zuul 指 Zuul 1.x，Netflix 最新的 Zuul 2.x一直跳票抹腿，所以 Spring Cloud 在 Zuul 2.x 沒(méi)有出的時(shí)候依靠社區(qū)的力量發(fā)展出了新的網(wǎng)關(guān)組件：Spring Cloud Gateway岛请。

Zuul 的核心功能就是基于 Servlet 提供了一系列的過(guò)濾器：

身份認(rèn)證與安全：識(shí)別每個(gè)資源的驗(yàn)證要求，并拒絕那些與要求不符的請(qǐng)求警绩。審查與監(jiān)控：在邊緣位置追蹤有意義的數(shù)據(jù)和統(tǒng)計(jì)結(jié)果崇败，從而帶來(lái)精確的生產(chǎn)視圖。動(dòng)態(tài)路由：動(dòng)態(tài)地將請(qǐng)求路由到不同的后端集群肩祥。壓力測(cè)試：逐漸增加指向集群的流量后室，以了解性能。負(fù)載分配：為每一種負(fù)載類型分配對(duì)應(yīng)容量混狠，并啟用超出限定值的請(qǐng)求岸霹。靜態(tài)響應(yīng)處理：在邊緣位置直接建立部分響應(yīng)，從而避免其轉(zhuǎn)發(fā)到內(nèi)部集群檀蹋。

Spring Cloud Gateway：構(gòu)建于 Spring 5+松申，基于 Spring Boot 2.x 響應(yīng)式的、非阻塞式的 API俯逾。

同時(shí)贸桶，它支持 Websockets，和 Spring 框架緊密集成桌肴，開(kāi)發(fā)體驗(yàn)相對(duì)來(lái)說(shuō)十分不錯(cuò)皇筛。

Spring Cloud Gateway 是基于 WebFlux 框架實(shí)現(xiàn)的，而 WebFlux 框架底層則使用了高性能的 Reactor 模式通信框架 Netty坠七。

總體來(lái)說(shuō)水醋，Spring Cloud Gateway 與 Zuul 功能差別不大旗笔，最大的出入是在底層性能的提升上。

Zuul 本身是基于 Servlet 容器來(lái)實(shí)現(xiàn)的過(guò)濾拄踪，Servlet 采用的是單實(shí)例多線程的處理方案蝇恶，Servlet 會(huì)為每一個(gè) Request 分配一個(gè)線程。

如果當(dāng)前線程比較耗時(shí)那么會(huì)一直等到線程處理完畢才會(huì)返回惶桐。所以說(shuō) Zuul 是基于 Servlet 之上的一個(gè)阻塞式處理模型撮弧。

同步阻塞模型對(duì)于網(wǎng)關(guān)這種比較在意響應(yīng)耗時(shí)和調(diào)用頻繁的組件來(lái)說(shuō)，必然會(huì)引發(fā)一些性能問(wèn)題姚糊，所以 Zuul 2 已經(jīng)做出了改良贿衍，從 Zuul 2 開(kāi)始已經(jīng)使用 Netty。

但是不幸的是 Spring 官方已經(jīng)對(duì)它的更新頻率感到失望救恨，所以縱然更新了也沒(méi)有被選用贸辈。

Spring Cloud Gateway 底層基于 Webflux。Webflux 模式替換了舊的 Servlet 線程模型肠槽。

用少量的線程處理 request 和 response io 操作擎淤，這些線程稱為 Loop 線程。

Webflux 的 Loop 線程署浩，正好就是著名的 Reactor 模式 IO 處理模型的 Reactor 線程揉燃，如果使用的是高性能的通信框架 Netty，這就是 Netty 的 EventLoop 線程筋栋。

所以整體來(lái)看炊汤，Spring Cloud Gateway 的性能要比目前在用的 Zuul 高。但是 Webflux 的編程方式可能大家不是很能接收弊攘。

③服務(wù)降級(jí)

降級(jí)限流在微服務(wù)中屬于銀彈抢腐，一般不用，一旦用上那就是拯救宇宙般存在襟交。

目前業(yè)界通用的降級(jí)限流工具主要有三款：

HystrixSentinelResilience4j

Hystrix 的關(guān)注點(diǎn)在于以隔離和熔斷為主的容錯(cuò)機(jī)制迈倍，超時(shí)或被熔斷的調(diào)用將會(huì)快速失敗，并可以提供 Fallback 機(jī)制捣域。

Hystrix 是元老級(jí)別的存在啼染，但是在 2018 年 11 月 Netflix 官方宣布停止更新（就是這么不靠譜，說(shuō)跳票就跳票）焕梅。雖然停止更新迹鹅，但是社區(qū)又推出了新的替代工具：Resilience4j。

Resilience4j 的模塊化做的比較好贞言，將每個(gè)功能點(diǎn)（如熔斷斜棚、限速器、自動(dòng)重試）都拆成了單獨(dú)的模塊。

這樣整體結(jié)構(gòu)很清晰弟蚀，用戶也只需要引入相應(yīng)功能的依賴即可蚤霞；另外 Resilience4j 是針對(duì) Java 8 和函數(shù)式編程設(shè)計(jì)的，API 比較簡(jiǎn)潔優(yōu)雅义钉。

同時(shí)與 Hystrix 相比昧绣，Resilience4j 增加了簡(jiǎn)單的限速器和自動(dòng)重試特性，使用場(chǎng)景更加豐富断医。

相比 Hystrix 滞乙， Resilience4j 的優(yōu)勢(shì)在于：

針對(duì) Java 8 和函數(shù)式編程設(shè)計(jì)奏纪，提供函數(shù)式和響應(yīng)式風(fēng)格的 API鉴嗤。增加了 rate limiting 和 automatic retrying 兩個(gè)模塊。其中 rate limiting 引入了簡(jiǎn)單的速率控制實(shí)現(xiàn)序调，補(bǔ)充了流量控制這一塊的功能醉锅。而 automatic retrying 則是封裝了自動(dòng)重試的邏輯，簡(jiǎn)化了異撤⒕睿恢復(fù)的流程硬耍。

Resilience4j 屬于一個(gè)新興項(xiàng)目，社區(qū)也在蓬勃發(fā)展边酒【瘢總的來(lái)說(shuō)，Resilience4j 是比較輕量的庫(kù)墩朦，在較小較新的項(xiàng)目中使用還是比較方便的坯认。

但是 Resilience4j 只包含限流降級(jí)的基本場(chǎng)景，對(duì)于非常復(fù)雜的企業(yè)級(jí)服務(wù)架構(gòu)可能無(wú)法很好地 cover 住氓涣。

同時(shí) Resilience4j 缺乏生產(chǎn)級(jí)別的配套設(shè)施（如提供規(guī)則管理和實(shí)時(shí)監(jiān)控能力的控制臺(tái)）牛哺。

Sentinel 是一款面向分布式服務(wù)架構(gòu)的輕量級(jí)流量控制組件，主要以流量為切入點(diǎn)劳吠，從流量控制引润、熔斷降級(jí)、系統(tǒng)自適應(yīng)保護(hù)等多個(gè)維度來(lái)幫助用戶保障服務(wù)的穩(wěn)定性痒玩。

Sentinel 的核心思想：根據(jù)對(duì)應(yīng)資源配置的規(guī)則來(lái)為資源執(zhí)行相應(yīng)的流控/降級(jí)/系統(tǒng)保護(hù)策略嗅虏。在 Sentinel 中資源定義和規(guī)則配置是分離的。

用戶先通過(guò) Sentinel API 給對(duì)應(yīng)的業(yè)務(wù)邏輯定義資源龄糊，然后可以在需要的時(shí)候動(dòng)態(tài)配置規(guī)則叽讳。

整體功能對(duì)比：

從上面的參照看，Sentinel 的功能相對(duì)要多一些便瑟，但是多并不意味著所有缆毁，合適的才是最好的，對(duì)于你用不到的功能到涂，簡(jiǎn)單才是美麗脊框。

④統(tǒng)一配置中心

統(tǒng)一配置中心概念的提出也是伴隨著微服務(wù)架構(gòu)出現(xiàn)才出現(xiàn)颁督，單體應(yīng)用的時(shí)候所有的配置都可以集成在服務(wù)之中，多應(yīng)用的時(shí)候如果每個(gè)應(yīng)用都持有一份配置可能會(huì)有相同配置冗余的情況浇雹。

如果一共有 2000 臺(tái)機(jī)器沉御，其中一個(gè)配置發(fā)生更改，是否要登錄每一臺(tái)機(jī)器重新更改配置呢昭灵。

另外吠裆，更多的配置必然會(huì)帶來(lái)管理上的混亂，如果沒(méi)有集中管理的地方必然會(huì)越來(lái)越亂烂完。

分布式配置管理的本質(zhì)基本上就是一種推送-訂閱模式的運(yùn)用试疙。配置的應(yīng)用方是訂閱者，配置管理服務(wù)則是推送方抠蚣。

其中祝旷，客戶端包括管理人員 Publish 數(shù)據(jù)到配置管理服務(wù)，可以理解為添加/更新數(shù)據(jù)嘶窄；配置管理服務(wù) Notify 數(shù)據(jù)到訂閱者怀跛，可以理解為推送。

配置管理服務(wù)往往會(huì)封裝一個(gè)客戶端庫(kù)柄冲，應(yīng)用方則是基于該庫(kù)與配置管理服務(wù)進(jìn)行交互吻谋。

在實(shí)際實(shí)現(xiàn)時(shí)，客戶端庫(kù)可能是主動(dòng)拉取(pull)數(shù)據(jù)现横，但對(duì)于應(yīng)用方而言漓拾，一般是一種事件通知方式。

選型一個(gè)合格的配置中心长赞，至少需要滿足如下四個(gè)核心需求：

非開(kāi)發(fā)環(huán)境下應(yīng)用配置的保密性晦攒，避免將關(guān)鍵配置寫(xiě)入源代碼。不同部署環(huán)境下應(yīng)用配置的隔離性得哆，比如非生產(chǎn)環(huán)境的配置不能用于生產(chǎn)環(huán)境脯颜。同一部署環(huán)境下的服務(wù)器應(yīng)用配置的一致性，即所有服務(wù)器使用同一份配置贩据。分布式環(huán)境下應(yīng)用配置的可管理性栋操，即提供遠(yuǎn)程管理配置的能力。

Diamond：最開(kāi)始我接觸過(guò)的配置中心是淘寶的 Diamond饱亮，Diamond 中的數(shù)據(jù)是簡(jiǎn)單的 Key-Value 結(jié)構(gòu)矾芙。應(yīng)用方訂閱數(shù)據(jù)則是基于 Key 來(lái)訂閱，未訂閱的數(shù)據(jù)當(dāng)然不會(huì)被推送近上。

Diamond 是無(wú)單點(diǎn)架構(gòu)剔宪，在做更新配置的時(shí)候只做三件事：

寫(xiě)數(shù)據(jù)庫(kù)寫(xiě)本地通知其他機(jī)器到數(shù)據(jù)庫(kù)拉更新

本地的設(shè)計(jì)就是為了緩存，減少對(duì)數(shù)據(jù)庫(kù)的壓力。作為一個(gè)配置中心葱绒，高可用是最主要的需求感帅。

如何保持高可用，Diamond 持有多層的數(shù)據(jù)存儲(chǔ)地淀，數(shù)據(jù)被存儲(chǔ)在：數(shù)據(jù)庫(kù)失球，服務(wù)端磁盤(pán)，客戶端緩存目錄帮毁，以及可以手工干預(yù)的容災(zāi)目錄实苞。

客戶端通過(guò) API 獲取配置數(shù)據(jù)，按照固定的順序去不同的數(shù)據(jù)源獲取數(shù)據(jù)：容災(zāi)目錄烈疚，服務(wù)端磁盤(pán)黔牵，客戶端緩存。

Diamond 除了在容災(zāi)上做了很多方案胞得，在數(shù)據(jù)讀取方面也有很多特點(diǎn)荧止。客戶端采用推拉結(jié)合的策略在長(zhǎng)連接和短連接之間取得一個(gè)平衡阶剑，讓服務(wù)端不用太關(guān)注連接的管理，又可以獲得長(zhǎng)連接的及時(shí)性危号。

使用 Diamond 的流程如下：

發(fā)布配置

讀取配置

Diamond Server 是無(wú)中心節(jié)點(diǎn)的邏輯集群牧愁，這樣就能避免單點(diǎn)故障。

Diamond 的同質(zhì)節(jié)點(diǎn)之間會(huì)相互通信以保證數(shù)據(jù)的一致性外莲，每個(gè)節(jié)點(diǎn)都有其他節(jié)點(diǎn)的地址信息猪半，其中一個(gè)節(jié)點(diǎn)發(fā)生數(shù)據(jù)變更后會(huì)響應(yīng)的通知其他節(jié)點(diǎn)，保證數(shù)據(jù)的一致性偷线。

為了保證高可用磨确，Client 還會(huì)在 App 端緩存一個(gè)本地文件，這樣即使 Server 不可用也能保證 App 可用声邦。

Client 不斷長(zhǎng)輪詢 Server乏奥，獲取最新的配置推送，盡量保證本地?cái)?shù)據(jù)的時(shí)效性亥曹。

Client 默認(rèn)啟動(dòng)周期任務(wù)對(duì) Server 進(jìn)行長(zhǎng)輪詢感知 Server 的配置變化邓了，Server 感知到配置變化就發(fā)送變更的數(shù)據(jù)編號(hào)，客戶端通過(guò)數(shù)據(jù)編號(hào)再去拉取最新配置數(shù)據(jù)媳瞪；否則超時(shí)結(jié)束請(qǐng)求（默認(rèn) 10 秒）骗炉。

拉取到新配置后，Client 會(huì)通知監(jiān)聽(tīng)者（Message Listener）做相應(yīng)處理蛇受，用戶可以通過(guò) Diamond#addListener 監(jiān)聽(tīng)句葵。

但是 Diamond 一般用途是做 KV 存儲(chǔ)，如果用來(lái)做配置中心，他提供的能力不是太符合乍丈。

可以看到早期的配置中心處理的東西還是比較簡(jiǎn)單熊响，那個(gè)時(shí)候業(yè)務(wù)沒(méi)有那么復(fù)雜，讀取配置和更新配置沒(méi)有那么多花樣诗赌，持久化存儲(chǔ)和本地緩存汗茄，長(zhǎng)連接更新就可以。但是現(xiàn)在的配置中心隨著技術(shù)的發(fā)展承擔(dān)的作用可能更多铭若。

Spring Cloud Config：作為 Spring 官方提供的配置中心可能比較符合外國(guó)人的習(xí)慣洪碳。

Spring Cloud Config 將不同環(huán)境的所有配置存放在 Git 倉(cāng)庫(kù)中，服務(wù)啟動(dòng)時(shí)通過(guò)接口拉取配置叼屠。

遵循 {ServiceID}-{profile}.properties 的結(jié)構(gòu)瞳腌，按照 Profile 拉取自己所需的配置。

當(dāng)開(kāi)發(fā)者修改了配置項(xiàng)之后镜雨，需要結(jié)合 Spring Config Bus 將配置通知到對(duì)應(yīng)的服務(wù)嫂侍，實(shí)現(xiàn)配置的動(dòng)態(tài)更新。

可以看到荚坞，Spring Cloud Config 已經(jīng)具備了一個(gè)配置中心的雛形挑宠，可以滿足小型項(xiàng)目對(duì)配置的管理，但仍然有著很多局限性颓影。

配置使用 Git 庫(kù)進(jìn)行管理各淀，那么 Git 庫(kù)的權(quán)限如何來(lái)判斷？不同環(huán)境的安全性也得不到保障诡挂。

配置的添加和刪除碎浇，配置項(xiàng)的匯總，也只能通過(guò) Git 命令來(lái)實(shí)現(xiàn)璃俗，對(duì)運(yùn)維人員也并不友好奴璃。

Apollo（阿波羅）：是攜程框架部門(mén)研發(fā)的開(kāi)源配置管理中心，能夠集中化管理應(yīng)用不同環(huán)境城豁、不同集群的配置苟穆，配置修改后能夠?qū)崟r(shí)推送到應(yīng)用端，并且具備規(guī)范的權(quán)限钮蛛、流程治理等特性鞭缭。

Apollo 支持四個(gè)維度管理 Key-Value 格式的配置：

Application（應(yīng)用）：實(shí)際使用配置的應(yīng)用，Apollo 客戶端在運(yùn)行時(shí)需要知道當(dāng)前應(yīng)用是誰(shuí)魏颓，從而可以去獲取對(duì)應(yīng)的配置岭辣；每個(gè)應(yīng)用都需要有唯一的身份標(biāo)識(shí) – appId，應(yīng)用身份是跟著代碼走的甸饱，所以需要在代碼中配置沦童。Environment（環(huán)境）：配置對(duì)應(yīng)的環(huán)境仑濒，Apollo 客戶端在運(yùn)行時(shí)需要知道當(dāng)前應(yīng)用處于哪個(gè)環(huán)境，從而可以去獲取應(yīng)用的配置偷遗。Cluster（集群）：一個(gè)應(yīng)用下不同實(shí)例的分組墩瞳，比如典型的可以按照數(shù)據(jù)中心分，把上海機(jī)房的應(yīng)用實(shí)例分為一個(gè)集群氏豌，把北京機(jī)房的應(yīng)用實(shí)例分為另一個(gè)集群喉酌。對(duì)不同的 Cluster，同一個(gè)配置可以有不一樣的值泵喘，如 ZooKeeper 地址泪电。Namespace（命名空間）：一個(gè)應(yīng)用下不同配置的分組，可以簡(jiǎn)單地把 Namespace 類比為文件纪铺，不同類型的配置存放在不同的文件中相速，如數(shù)據(jù)庫(kù)配置文件，RPC 配置文件鲜锚，應(yīng)用自身的配置文件等突诬。應(yīng)用可以直接讀取到公共組件的配置 Namespace，如 DAL芜繁，RPC 等旺隙；應(yīng)用也可以通過(guò)繼承公共組件的配置 Namespace 來(lái)對(duì)公共組件的配置做調(diào)整，如 DAL 的初始數(shù)據(jù)庫(kù)連接數(shù)浆洗。

Apollo 配置中心包括：

Config Service：提供配置獲取接口催束、配置推送接口，服務(wù)于 Apollo 客戶端伏社。Admin Service：提供配置管理接口、配置修改發(fā)布接口塔淤，服務(wù)于管理界面 Portal摘昌。Portal：配置管理界面，通過(guò) MetaServer 獲取 Admin Service 的服務(wù)列表高蜂，并使用客戶端軟負(fù)載 SLB 方式調(diào)用 Admin Service聪黎。

上圖簡(jiǎn)要描述了 Apollo 的總體設(shè)計(jì)，我們可以從下往上看：

Config Service 提供配置的讀取备恤、推送等功能稿饰，服務(wù)對(duì)象是 Apollo 客戶端。Admin Service 提供配置的修改露泊、發(fā)布等功能喉镰，服務(wù)對(duì)象是 Apollo Portal（管理界面）。Config Service 和 Admin Service 都是多實(shí)例惭笑、無(wú)狀態(tài)部署侣姆，所以需要將自己注冊(cè)到 Eureka 中并保持心跳生真。在 Eureka 之上我們架了一層 Meta Server 用于封裝 Eureka 的服務(wù)發(fā)現(xiàn)接口。Client 通過(guò)域名訪問(wèn) Meta Server 獲取 Config Service 服務(wù)列表（IP+Port）捺宗，而后直接通過(guò) IP+Port 訪問(wèn)服務(wù)柱蟀，同時(shí)在 Client 側(cè)會(huì)做 Load Balance、錯(cuò)誤重試蚜厉。Portal 通過(guò)域名訪問(wèn) Meta Server 獲取 Admin Service 服務(wù)列表（IP+Port）长已，而后直接通過(guò) IP+Port 訪問(wèn)服務(wù)，同時(shí)在 Portal 側(cè)會(huì)做Load Balance昼牛、錯(cuò)誤重試术瓮。為了簡(jiǎn)化部署，我們實(shí)際上會(huì)把 Config Service匾嘱、Eureka 和 Meta Server 三個(gè)邏輯角色部署在同一個(gè) JVM 進(jìn)程中斤斧。

客戶端設(shè)計(jì)：

上圖簡(jiǎn)要描述了 Apollo 客戶端的實(shí)現(xiàn)原理：

客戶端和服務(wù)端保持了一個(gè)長(zhǎng)連接，從而能第一時(shí)間獲得配置更新的推送霎烙∏朔恚客戶端還會(huì)定時(shí)從 Apollo 配置中心服務(wù)端拉取應(yīng)用的最新配置。這是一個(gè) Fallback 機(jī)制悬垃，為了防止推送機(jī)制失效導(dǎo)致配置不更新游昼。客戶端定時(shí)拉取會(huì)上報(bào)本地版本尝蠕，所以一般情況下烘豌，對(duì)于定時(shí)拉取的操作，服務(wù)端都會(huì)返回 304 - Not Modified看彼。定時(shí)頻率默認(rèn)為每 5 分鐘拉取一次廊佩，客戶端也可以通過(guò)在運(yùn)行時(shí)指定 System Property: apollo.refreshInterval 來(lái)覆蓋，單位為分鐘靖榕”瓿客戶端從 Apollo 配置中心服務(wù)端獲取到應(yīng)用的最新配置后，會(huì)保存在內(nèi)存中茁计×匣剩客戶端會(huì)把從服務(wù)端獲取到的配置在本地文件系統(tǒng)緩存一份，在遇到服務(wù)不可用星压，或網(wǎng)絡(luò)不通的時(shí)候践剂，依然能從本地恢復(fù)配置。應(yīng)用程序從 Apollo 客戶端獲取最新的配置娜膘、訂閱配置更新通知逊脯。

配置更新：前面提到了 Apollo 客戶端和服務(wù)端保持了一個(gè)長(zhǎng)連接，從而能第一時(shí)間獲得配置更新的推送劲绪。

長(zhǎng)連接實(shí)際上是通過(guò) Http Long Polling 實(shí)現(xiàn)的男窟，具體而言：

客戶端發(fā)起一個(gè) Http 請(qǐng)求到服務(wù)端盆赤。服務(wù)端會(huì)保持住這個(gè)連接 60 秒，如果在 60 秒內(nèi)有客戶端關(guān)心的配置變化歉眷，被保持住的客戶端請(qǐng)求會(huì)立即返回牺六，并告知客戶端有配置變化的 Namespace 信息，客戶端會(huì)據(jù)此拉取對(duì)應(yīng) Namespace 的最新配置汗捡。如果在 60 秒內(nèi)沒(méi)有客戶端關(guān)心的配置變化淑际，那么會(huì)返回 Http 狀態(tài)碼 304 給客戶端∩茸。客戶端在收到服務(wù)端請(qǐng)求后會(huì)立即重新發(fā)起連接春缕，回到第一步。

考慮到會(huì)有數(shù)萬(wàn)客戶端向服務(wù)端發(fā)起長(zhǎng)連艘蹋，在服務(wù)端使用了 async servlet(Spring DeferredResult)來(lái)服務(wù) Http Long Polling 請(qǐng)求锄贼。

⑤調(diào)用鏈路分析

服務(wù)調(diào)用鏈路分析在微服務(wù)中是幕后至關(guān)重要的使者，試想幾百個(gè)服務(wù)摻雜在一起女阀，你想捋出誰(shuí)先調(diào)用了誰(shuí)宅荤，誰(shuí)被誰(shuí)調(diào)用，如果沒(méi)有一個(gè)可監(jiān)控的路徑浸策，光憑腦子跟蹤那得多累冯键。

基于這種需求，各路大神們集中腦汁展開(kāi)遐想弄出一套分布式鏈路追蹤神器來(lái)庸汗。

在介紹調(diào)用鏈監(jiān)控工具之前惫确，我們首先需要知道在微服務(wù)架構(gòu)系統(tǒng)中經(jīng)常會(huì)遇到兩個(gè)問(wèn)題：

跨服務(wù)調(diào)用發(fā)生異常，要求快速定位當(dāng)前這次調(diào)用出問(wèn)題在哪一步蚯舱「幕跨服務(wù)的調(diào)用發(fā)生性能瓶頸，要求迅速定位出系統(tǒng)瓶頸應(yīng)該如何做枉昏。

打個(gè)比方說(shuō)我們有兩個(gè)服務(wù)：訂單中心所袁，庫(kù)存中心。用戶下單凶掰，先去查詢庫(kù)存系統(tǒng)，那么調(diào)用鏈路分析系統(tǒng)對(duì)于一個(gè)下單查詢服務(wù)應(yīng)該記錄什么呢蜈亩？

我們?cè)斐鋈缦乱粡堈{(diào)用鏈路請(qǐng)求記錄表懦窘，表字段如下：

表字段說(shuō)明：

id：自增 idspan_id：唯一 idpspan_id：父級(jí) span_idservice_name：服務(wù)名稱api：api 路徑stage：階段/狀態(tài)timestamp：插入數(shù)據(jù)時(shí)的時(shí)間戳

上表中的 stage 中的狀態(tài)解釋為：

CS（Client Sent 客戶端發(fā)送）：客戶端發(fā)送一個(gè)請(qǐng)求，表示 Span 的開(kāi)始稚配。SR（Server Received 服務(wù)端接收）：服務(wù)端接收請(qǐng)求并開(kāi)始處理它畅涂。(SR - CS)等于網(wǎng)絡(luò)的延遲。SS（Server Sent 服務(wù)端發(fā)送）：服務(wù)端處理請(qǐng)求完成道川，開(kāi)始返回結(jié)束給服務(wù)端午衰。(SR - SS)表示服務(wù)端處理請(qǐng)求的時(shí)間立宜。CR（Client Received 客戶端接收）：客戶端完成接受返回結(jié)果，此時(shí) Span 結(jié)束臊岸。(CR - CS)表示客戶端接收服務(wù)端數(shù)據(jù)的時(shí)間橙数。

根據(jù)這個(gè)表我們就能很快的分析上面提到的兩個(gè)問(wèn)題：

如果以上任何一步有問(wèn)題，那么當(dāng)前調(diào)用就不是完整的帅戒，我們必然能追蹤出來(lái)灯帮。通過(guò)每一步的調(diào)用時(shí)間進(jìn)行分析，我們也必然知道阻塞在哪一步逻住，從而對(duì)調(diào)用慢的地方進(jìn)行優(yōu)化钟哥。

現(xiàn)有的分布式 Trace 基本都是采用了 Google 的 Dapper 標(biāo)準(zhǔn)。

Dapper 的思想很簡(jiǎn)單瞎访，就是在每一次調(diào)用棧中腻贰，使用同一個(gè) TraceId 將不同的 Server 聯(lián)系起來(lái)。

一次單獨(dú)的調(diào)用鏈也可以稱為一個(gè) Span扒秸，Dapper 記錄的是 Span 的名稱播演，以及每個(gè) Span 的 ID 和父 ID，以重建在一次追蹤過(guò)程中不同 Span 之間的關(guān)系鸦采。

對(duì)于一個(gè)特定的 Span宾巍，記錄從 Start 到 End，首先經(jīng)歷了客戶端發(fā)送數(shù)據(jù)渔伯，然后 Server 接收數(shù)據(jù)顶霞，然后 Server 執(zhí)行內(nèi)部邏輯，這中間可能去訪問(wèn)另一個(gè)應(yīng)用锣吼。執(zhí)行完了 Server 將數(shù)據(jù)返回选浑，然后客戶端接收到數(shù)據(jù)。

在整個(gè)過(guò)程中玄叠，TraceId 和 ParentId 的生成至關(guān)重要古徒。首先解釋下 TraceId 和 ParentId。

TraceId 是標(biāo)識(shí)這個(gè)調(diào)用鏈的 Id读恃，整個(gè)調(diào)用鏈隧膘，從瀏覽器開(kāi)始放完，到 A 到 B 到 C寺惫，一直到調(diào)用結(jié)束疹吃，所有應(yīng)用在這次調(diào)用中擁有同一個(gè) TraceId，所以才能把這次調(diào)用鏈在一起西雀。

既然知道了這次調(diào)用鏈的整個(gè) Id萨驶，那么每次查找問(wèn)題的時(shí)候，只要知道某一個(gè)調(diào)用的 TraceId艇肴，就能把所有這個(gè) Id 的調(diào)用全部查找出來(lái)腔呜，能夠清楚的知道本地調(diào)用鏈經(jīng)過(guò)了哪些應(yīng)用叁温，產(chǎn)生了哪些調(diào)用。但是還缺一點(diǎn)核畴，那就是鏈膝但。

基于這種需求，目前各大廠商都做出了自己的分布式追蹤系統(tǒng)：

目前國(guó)內(nèi)開(kāi)源的有：阿里的鷹眼膛檀，美團(tuán)的 CAT锰镀，京東的 Hydra，還有廣為人知的個(gè)人開(kāi)源 Apache 頂級(jí)項(xiàng)目 SkyWalking咖刃。國(guó)外的有：Zipkin泳炉，Pinpoint。

Spring Cloud Sleuth+Zipkin：Spring Cloud Sleuth 實(shí)現(xiàn)了一種分布式的服務(wù)鏈路跟蹤解決方案嚎杨，通過(guò)使用 Sleuth 可以讓我們快速定位某個(gè)服務(wù)的問(wèn)題花鹅。

簡(jiǎn)單來(lái)說(shuō)，Sleuth 相當(dāng)于調(diào)用鏈監(jiān)控工具的客戶端枫浙，集成在各個(gè)微服務(wù)上刨肃，負(fù)責(zé)產(chǎn)生調(diào)用鏈監(jiān)控?cái)?shù)據(jù)。

通過(guò) Sleuth 產(chǎn)生的調(diào)用鏈監(jiān)控信息箩帚，讓我們可以得知微服務(wù)之間的調(diào)用鏈路真友，但是監(jiān)控信息只輸出到控制臺(tái)始終不太方便查看。

所以我們需要一個(gè)圖形化的工具紧帕，這時(shí)候就輪到 Zipkin 出場(chǎng)了盔然。Zipkin 是 Twitter 開(kāi)源的分布式跟蹤系統(tǒng)，主要用來(lái)收集系統(tǒng)的時(shí)序數(shù)據(jù)是嗜，從而追蹤系統(tǒng)的調(diào)用問(wèn)題愈案。

Spring Cloud Slueth 聚焦在鏈路追蹤和分析，將信息發(fā)送到 Zipkin鹅搪，利用 Zipkin 的存儲(chǔ)來(lái)存儲(chǔ)信息站绪。

當(dāng)然，Zipkin 也可以使用 ELK 來(lái)記錄日志和展示丽柿，再通過(guò)收集服務(wù)器性能的腳本把數(shù)據(jù)存儲(chǔ)到 ELK恢准，則可以展示服務(wù)器狀況信息。

Pinpoint：數(shù)據(jù)分析非常完備甫题。提供代碼級(jí)別的可見(jiàn)性以便輕松定位失敗點(diǎn)和瓶頸顷歌，對(duì)于執(zhí)行的 SQL 語(yǔ)句，都進(jìn)行了記錄幔睬。

還可以配置報(bào)警規(guī)則等，設(shè)置每個(gè)應(yīng)用對(duì)應(yīng)的負(fù)責(zé)人芹扭，根據(jù)配置的規(guī)則報(bào)警麻顶，支持的中間件和框架也比較完備赦抖。

Pinpoint 是一個(gè)完整的性能監(jiān)控解決方案：有從探針、收集器辅肾、存儲(chǔ)到 Web 界面等全套體系队萤。

Pinpoint 提供有 Java Agent 探針，通過(guò)字節(jié)碼注入的方式實(shí)現(xiàn)調(diào)用攔截和數(shù)據(jù)收集矫钓，可以做到真正的代碼無(wú)侵入要尔，只需要在啟動(dòng)服務(wù)器的時(shí)候添加一些參數(shù)，就可以完成探針的部署新娜。

對(duì)于這一點(diǎn)赵辕，Zipkin 使用修改過(guò)的類庫(kù)和它自己的容器(Finagle)來(lái)提供分布式事務(wù)跟蹤的功能。

但是概龄，它要求在需要時(shí)修改代碼还惠。Pinpoint 是基于字節(jié)碼增強(qiáng)的方式，開(kāi)發(fā)人員不需要修改代碼私杜，并且可以收集到更多精確的數(shù)據(jù)因?yàn)橛凶止?jié)碼中的更多信息蚕键。

相對(duì)來(lái)說(shuō)，Pinpoint 界面顯示的更加豐富衰粹，具體到調(diào)用的 DB 名锣光，Zipkin 的拓?fù)渚窒抻诜?wù)于服務(wù)之間。

SkyWalking：和 Pinpoint 有一種既生瑜何生亮的感嘆铝耻。

SkyWalking 邏輯上分為四部分:

探針(SkyWalking-agent)平臺(tái)后端(oap-server)存儲(chǔ)(es)用戶界面(apm-webapp)

探針基于不同的來(lái)源可能是不一樣的（原生代理誊爹，SDK 以及 Zipkin，Jaeger 和 OpenCensus ）田篇，但作用都是收集數(shù)據(jù)替废、將數(shù)據(jù)格式化為 SkyWalking 適用的格式。

平臺(tái)后端是一個(gè)支持集群模式運(yùn)行的后臺(tái)泊柬、用于數(shù)據(jù)聚合椎镣、數(shù)據(jù)分析以及驅(qū)動(dòng)數(shù)據(jù)流從探針到用戶界面的流程。

平臺(tái)后端還提供了各種可插拔的能力兽赁，如不同來(lái)源數(shù)據(jù)(如來(lái)自 Zipkin)格式化状答、不同存儲(chǔ)系統(tǒng)以及集群管理，你甚至還可以使用觀測(cè)分析語(yǔ)言來(lái)進(jìn)行自定義聚合分析刀崖。

存儲(chǔ)是開(kāi)放式的惊科，你可以選擇一個(gè)既有的存儲(chǔ)系統(tǒng)，如 ElasticSearch亮钦，H2 或 MySQL 集群(Sharding-Sphere 管理)馆截、也可以選擇自己實(shí)現(xiàn)一個(gè)存儲(chǔ)系統(tǒng)。

用戶界面對(duì)于 SkyWalking 的最終用戶來(lái)說(shuō)非常炫酷且強(qiáng)大、同樣它也是可定制以匹配你已存在的后端的蜡娶。

總結(jié)

以上是微服務(wù)全鏈路過(guò)程中需要經(jīng)歷的階段混卵，當(dāng)然還不包括發(fā)布系統(tǒng)的搭建，底層數(shù)據(jù)治理能力窖张。

所以提倡微服務(wù)可以幕随，但是真的做起來(lái)不是所有公司都能做得到。小公司能做到服務(wù)拆分但是相應(yīng)的配套設(shè)施不一定能跟上宿接，大公司有人有錢(qián)有時(shí)間赘淮，才能提供這些基礎(chǔ)設(shè)施。