微服務(wù)并不是孤立存在的，它們存在于一個(gè)環(huán)境里，微服務(wù)在這個(gè)環(huán)境里進(jìn)行交互。把這種環(huán)境看成微服務(wù)生態(tài)系統(tǒng)并分層，有助于理解微服務(wù)架構(gòu)。

　　在一個(gè)設(shè)計(jì)良好的微服務(wù)生態(tài)系統(tǒng)里，微服務(wù)與基礎(chǔ)設(shè)施之間是分離的。微服務(wù)與硬件、網(wǎng)絡(luò)、構(gòu)建和部署管道、服務(wù)發(fā)現(xiàn)和負(fù)載均衡都是分離的。它們都是微服務(wù)生態(tài)系統(tǒng)基礎(chǔ)設(shè)施的組成部分。如何以一種穩(wěn)定可靠的、可伸縮的、可容錯(cuò)的方式來構(gòu)建、維護(hù)和標(biāo)準(zhǔn)化基礎(chǔ)設(shè)施，是微服務(wù)運(yùn)維的根本。

　　基礎(chǔ)設(shè)施必須能夠支撐微服務(wù)生態(tài)系統(tǒng)。基礎(chǔ)設(shè)施工程師和架構(gòu)師的共同目標(biāo)是為微服務(wù)的開發(fā)工作隱藏底層的運(yùn)維細(xì)節(jié)，并構(gòu)建一個(gè)穩(wěn)定的、可伸縮的基礎(chǔ)設(shè)施平臺(tái)，讓開發(fā)者可以輕松地在上面構(gòu)建和運(yùn)行微服務(wù)。在一個(gè)穩(wěn)定的微服務(wù)生態(tài)系統(tǒng)里開發(fā)一個(gè)微服務(wù)應(yīng)該跟開發(fā)一個(gè)小型的標(biāo)準(zhǔn)應(yīng)用一樣，都需要一個(gè)出類拔萃的基礎(chǔ)設(shè)施的支持。

　　微服務(wù)生態(tài)系統(tǒng)可以被分為4 層，雖然層與層之間的邊界不一定都很清晰，但這些層會(huì)涉及基礎(chǔ)設(shè)施的幾個(gè)元素。底下的3 層是基礎(chǔ)設(shè)施層：最下面的是硬件層，其次是通信層（一直滲透到第4 層），緊接著的是應(yīng)用平臺(tái)層。第4 層（頂層）就是微服務(wù)所在的層。

　　微服務(wù)生態(tài)系統(tǒng)的4層模型

　　第1 層：硬件層

　　微服務(wù)生態(tài)系統(tǒng)的底層是硬件層。這一層是服務(wù)器物理機(jī)所在的層，它們是所有內(nèi)部工具和微服務(wù)運(yùn)行的基礎(chǔ)。這些服務(wù)器被放置在數(shù)據(jù)中心的機(jī)架上，由供電系統(tǒng)供給電力，使用著昂貴的HVAC 冷卻系統(tǒng)。這里有各種各樣的服務(wù)器：有些專門用于運(yùn)行數(shù)據(jù)庫，有些專門處理CPU 密集的任務(wù)。它們有些是某些公司私有的，有些是從所謂的“云服務(wù)提供商”那里租來的，比如Amazon Web Services Elastic Compute Cloud（AWS EC2）、Google Cloud Platform（GCP）或Microsoft Azure。

　　硬件的選擇取決于服務(wù)器的所有者。如果你的公司有自己的數(shù)據(jù)中心，硬件的選擇就是自己的事情，完全可以根據(jù)實(shí)際需要來定制服務(wù)器。如果你的服務(wù)器是在云端（這種情況比較普遍），你就沒有太多的選擇余地。是自己購買服務(wù)器還是選擇云服務(wù)并不是一個(gè)簡單的選擇題，它需要考慮購買成本、可用性、可靠性和運(yùn)營成本。

　　管理服務(wù)器是硬件層的職責(zé)之一。每臺(tái)服務(wù)器都需要安裝標(biāo)準(zhǔn)的操作系統(tǒng)。使用哪種操作系統(tǒng)并沒有一個(gè)標(biāo)準(zhǔn)的答案，這完全取決于你要構(gòu)建的應(yīng)用程序、構(gòu)建應(yīng)用程序所使用的編程語言以及構(gòu)建微服務(wù)所需要的軟件包和工具。主流的微服務(wù)生態(tài)系統(tǒng)一般會(huì)使用Linux 的變形版本，比如CentOS、Debian 或Ubuntu，不過一個(gè)使用了.NET 平臺(tái)的公司顯然會(huì)有不同的選擇。硬件層之上還可以有一些層，比如資源隔離、資源抽象（由Docker 和Apache Mesos 提供的）和數(shù)據(jù)庫（專門的或共享的）。

　　操作系統(tǒng)的安裝和硬件資源的配置是服務(wù)器的第一個(gè)層。每個(gè)主機(jī)必須被配置好，而且在安裝好操作系統(tǒng)之后，必須提供一個(gè)配置管理工具（比如Ansible、Chef 或Puppet）來安裝應(yīng)用程序，并做好必要的配置。

　　對(duì)主機(jī)進(jìn)行主機(jī)級(jí)別的監(jiān)控（使用Nagios）是有必要的，而且需要記錄主機(jī)級(jí)別的日志。在主機(jī)出現(xiàn)異常（磁盤錯(cuò)誤、網(wǎng)絡(luò)錯(cuò)誤或CPU 過載）時(shí)就可以方便地對(duì)它們進(jìn)行診斷，有助于問題的解決。

　　==硬件層的主要內(nèi)容==

　　微服務(wù)生態(tài)系統(tǒng)的硬件層（第1 層）包含：

　　- 物理服務(wù)器（公司自有或從云服務(wù)提供商那里租用）

　　- 數(shù)據(jù)庫（專有的或共享的）

　　- 操作系統(tǒng)

　　- 資源隔離和資源抽象

　　- 配置管理

　　- 主機(jī)級(jí)別的監(jiān)控

　　- 主機(jī)級(jí)別的日志

　　第2 層：通信層

　　微服務(wù)生態(tài)系統(tǒng)的第2 層是通信層。通信層滲透到生態(tài)系統(tǒng)的所有層（包括應(yīng)用平臺(tái)層和微服務(wù)層），因?yàn)槲⒎?wù)之間的交互會(huì)在多個(gè)層上進(jìn)行，所以很難清晰地對(duì)通信層與其他層之間的邊界進(jìn)行定義。雖然難以清晰地定義它們之間的邊界，但是這個(gè)層所涉及的元素是很明確的。第2 層一般包含網(wǎng)絡(luò)、DNS、RPC 和API 端點(diǎn)、服務(wù)發(fā)現(xiàn)、服務(wù)注冊(cè)以及負(fù)載均衡。

　　有關(guān)通信層網(wǎng)絡(luò)和DNS 元素的內(nèi)容已經(jīng)超出了本文的范疇，在這里，我們主要討論RPC、API 端點(diǎn)、服務(wù)發(fā)現(xiàn)、服務(wù)注冊(cè)和負(fù)載均衡。

　　RPC、端點(diǎn)和消息傳遞

　　微服務(wù)通過遠(yuǎn)程過程調(diào)用（RPC）或消息傳送與其他微服務(wù)進(jìn)行交互，這些調(diào)用通過網(wǎng)絡(luò)發(fā)送到其他微服務(wù)的API 端點(diǎn)上（如果使用的是消息傳遞，消息會(huì)被發(fā)送到消息代理，消息代理會(huì)對(duì)這些消息進(jìn)行路由）。基本原理是這樣的：使用一個(gè)特定的協(xié)議，一個(gè)微服務(wù)把符合特定格式的數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送到另一個(gè)服務(wù)（或者是另一個(gè)微服務(wù)的API 端點(diǎn)）或消息代理上（消息代理確保數(shù)據(jù)會(huì)被路由到其他微服務(wù)的API 端點(diǎn)上）。

　　微服務(wù)有幾種通信方式，第一種是最常用的HTTP+REST/Thrift。如果使用的是這種方式，各個(gè)服務(wù)使用超文本傳輸協(xié)議（HTTP）進(jìn)行網(wǎng)絡(luò)交互，它們向特定的REST 端點(diǎn)（使用各種HTTP 方法，比如GET、POST 等）或Thrift 端點(diǎn)發(fā)送請(qǐng)求或從這些端點(diǎn)接收響應(yīng)。發(fā)送的數(shù)據(jù)一般是JSON（或protocol buffer）格式。

　　HTTP+REST 是最便利的微服務(wù)通信方式。它使用起來很簡單，而且穩(wěn)定可靠。不過它的不足之處在于它是同步（阻塞）的。

　　第二種通信方式是消息傳遞。消息傳遞是異步（非阻塞）的，不過相對(duì)復(fù)雜。消息傳遞的工作原理是這樣的：一個(gè)微服務(wù)把數(shù)據(jù)（消息）通過網(wǎng)絡(luò)（HTTP 或其他）發(fā)送給一個(gè)消息代理，消息代理會(huì)把消息路由到其他微服務(wù)上。

　　消息傳遞也有幾種模式，最流行的兩種分別是發(fā)布和訂閱以及請(qǐng)求和響應(yīng)。如果使用的是發(fā)布和訂閱模式，客戶端會(huì)訂閱一個(gè)主題，它將從主題上收到發(fā)布者發(fā)布的任何一個(gè)消息。請(qǐng)求和響應(yīng)模式就更直接了，客戶端發(fā)送一個(gè)請(qǐng)求到一個(gè)服務(wù)（或消息代理）上，這個(gè)服務(wù)會(huì)對(duì)這個(gè)請(qǐng)求做出響應(yīng)。有些消息中間件同時(shí)支持兩種模式，比如ApacheKafka。Celery 和Redis（或Celery 和RabbitMQ）可以為Python 微服務(wù)傳送消息（并處理任務(wù)）：Celery 處理任務(wù)或消息，Redis 或RabbitMQ 作為消息代理。

　　消息傳遞有幾個(gè)缺點(diǎn)需要注意。消息傳遞不會(huì)比HTTP+REST 具備更強(qiáng)的伸縮性，如果你的系統(tǒng)對(duì)伸縮性有要求的話一定要清楚這一點(diǎn)。消息傳遞對(duì)變更不友好，因?yàn)樗羌惺降模@樣會(huì)導(dǎo)致消息隊(duì)列和消息代理變成整個(gè)生態(tài)系統(tǒng)的故障點(diǎn)。它的異步特性在并發(fā)環(huán)境里會(huì)導(dǎo)致競(jìng)賽條件，如果沒有處理好，還會(huì)出現(xiàn)無限循環(huán)。在使用消息傳遞時(shí)，如果能夠處理好上述這些問題，它會(huì)變得跟同步解決方案同樣穩(wěn)定和高效。

　　服務(wù)發(fā)現(xiàn)、服務(wù)注冊(cè)和負(fù)載均衡

　　在單體應(yīng)用架構(gòu)里，所有的業(yè)務(wù)流量都被發(fā)送給負(fù)載均衡器，然后被分發(fā)到應(yīng)用服務(wù)器上。而在微服務(wù)架構(gòu)里，業(yè)務(wù)流量被路由到大量不同的應(yīng)用程序上，然后再被分發(fā)給部署了特定微服務(wù)的服務(wù)器。為了能夠高效地實(shí)現(xiàn)上述場(chǎng)景，微服務(wù)架構(gòu)需要在通信層實(shí)現(xiàn)三項(xiàng)技術(shù)：服務(wù)發(fā)現(xiàn)、服務(wù)注冊(cè)和負(fù)載均衡。

　　一般來說，如果微服務(wù)A 需要向微服務(wù)B 發(fā)起請(qǐng)求，那么微服務(wù)A 需要知道微服務(wù)B 的IP 地址和端口。微服務(wù)的通信層需要知道這些微服務(wù)的IP 地址和端口，才能正確地路由這些請(qǐng)求。這個(gè)問題可以通過服務(wù)發(fā)現(xiàn)（比如etcd、Consul、Hyperbahn 或ZooKeeper）來解決，服務(wù)發(fā)現(xiàn)可以確保請(qǐng)求會(huì)被路由到它們本該去的地方，而且只會(huì)被路由到正常運(yùn)行的實(shí)例上（這非常重要）。服務(wù)發(fā)現(xiàn)需要用到服務(wù)注冊(cè)，服務(wù)注冊(cè)中記錄了生態(tài)系統(tǒng)里所有微服務(wù)的IP 地址和端口。

　　動(dòng)態(tài)伸縮和端口分配

　　在微服務(wù)架構(gòu)里，在對(duì)微服務(wù)進(jìn)行橫向擴(kuò)展和重新部署時(shí)（比如使用了像Apache Mesos 這樣的硬件抽象層），端口和IP 地址會(huì)發(fā)生變化。在這種情況下，可以考慮為每個(gè)微服務(wù)分配一個(gè)靜態(tài)端口（包括前端和后端）。

　　除非你的所有微服務(wù)都部署在同一個(gè)實(shí)例上（一般不太可能），否則需要在通信層使用負(fù)載均衡。簡單地說，負(fù)載均衡可以做到：如果你有10 個(gè)微服務(wù)實(shí)例，負(fù)載均衡器（軟件或硬件）可以確保業(yè)務(wù)流量被（均衡地）分發(fā)到所有的實(shí)例上。在微服務(wù)生態(tài)系統(tǒng)里，只要涉及請(qǐng)求轉(zhuǎn)發(fā)，都需要用到負(fù)載均衡器，這意味著一個(gè)大型的微服務(wù)生態(tài)系統(tǒng)將包含多層負(fù)載均衡。常見的負(fù)載均衡器有Amazon Web Services Elastic Load Balancer、Netflix 的Eureka、HAProxy 和Nginx。

　　==通信層的主要內(nèi)容==

　　微服務(wù)生態(tài)系統(tǒng)的通信層（第2 層）包含：

　　- 網(wǎng)絡(luò)

　　- DNS

　　- 遠(yuǎn)程過程調(diào)用（RPC）

　　- 端點(diǎn)

　　- 消息傳遞

　　- 服務(wù)發(fā)現(xiàn)

　　- 服務(wù)注冊(cè)

　　- 負(fù)載均衡

　　第3 層：應(yīng)用平臺(tái)層

　　應(yīng)用平臺(tái)層是微服務(wù)生態(tài)系統(tǒng)的第3 層，這一層包含了所有獨(dú)立于微服務(wù)的內(nèi)部工具和服務(wù)。這一層所包含的集中式的工具和服務(wù)跨越了整個(gè)生態(tài)系統(tǒng)，因?yàn)橛辛诉@些工具和服務(wù)，微服務(wù)開發(fā)團(tuán)隊(duì)就可以把精力集中在微服務(wù)的開發(fā)上。

　　一個(gè)好的應(yīng)用平臺(tái)需要為開發(fā)者提供一套內(nèi)部的自助工具，包括標(biāo)準(zhǔn)化的開發(fā)流程、集中式的自動(dòng)化構(gòu)建和發(fā)布系統(tǒng)、自動(dòng)化測(cè)試、標(biāo)準(zhǔn)化和集中式的部署方案以及集中式的日志和微服務(wù)級(jí)別的監(jiān)控。這些元素的細(xì)節(jié)此處不進(jìn)行探討，不過我們也會(huì)簡要地介紹其中的幾個(gè)元素，闡述一些基本的概念。

　　內(nèi)部自助開發(fā)工具

　　有很多東西可以被納入內(nèi)部自助開發(fā)工具的范疇，它們是否可以被歸為這類工具不僅取決于開發(fā)者對(duì)工具的需求，還要考慮基礎(chǔ)設(shè)施和生態(tài)系統(tǒng)的整體抽象度和復(fù)雜性。決定使用哪一種工具，首先要對(duì)責(zé)任領(lǐng)域進(jìn)行切分，然后對(duì)開發(fā)者所要完成的任務(wù)進(jìn)行評(píng)估，以便設(shè)計(jì)、構(gòu)建和維護(hù)他們的服務(wù)。

　　在一個(gè)已經(jīng)使用了微服務(wù)架構(gòu)的公司里，給工程團(tuán)隊(duì)指派職責(zé)要十分謹(jǐn)慎。最簡單的做法是為微服務(wù)生態(tài)系統(tǒng)的每一個(gè)層組建一個(gè)工程子團(tuán)隊(duì)。這些工程子團(tuán)隊(duì)將負(fù)責(zé)處理它們所在層的所有相關(guān)事務(wù)：運(yùn)維團(tuán)隊(duì)負(fù)責(zé)第1 層，基礎(chǔ)設(shè)施團(tuán)隊(duì)負(fù)責(zé)第2 層，應(yīng)用平臺(tái)團(tuán)隊(duì)負(fù)責(zé)第3 層，微服務(wù)團(tuán)隊(duì)負(fù)責(zé)第4 層（這看起來很簡單，只要你能明白就好了）。

　　在這種組織結(jié)構(gòu)里，工作在上層的工程師需要使用自助工具對(duì)下層的一些東西進(jìn)行配置。例如，負(fù)責(zé)消息服務(wù)的團(tuán)隊(duì)?wèi)?yīng)該為其他開發(fā)者提供一個(gè)自助工具，當(dāng)微服務(wù)團(tuán)隊(duì)的開發(fā)者需要為他們的服務(wù)配置消息系統(tǒng)時(shí)，他們就可以使用這個(gè)工具，而無須過多地了解紛繁復(fù)雜的消息系統(tǒng)。

　　使用這些集中式的自助工具是有原因的。在一個(gè)多元化的微服務(wù)生態(tài)系統(tǒng)里，一個(gè)團(tuán)隊(duì)的普通工程師對(duì)其他團(tuán)隊(duì)的系統(tǒng)和服務(wù)并不了解（或知之甚少），他們也不可能成為面面俱到的專家。每個(gè)開發(fā)人員只對(duì)自己負(fù)責(zé)的部分比較了解，但從整個(gè)生態(tài)系統(tǒng)來看，這些開發(fā)人員組合在一起就無所不知了。為生態(tài)系統(tǒng)的每一部分構(gòu)建易用的用戶界面，為開發(fā)人員提供相關(guān)的培訓(xùn)，以便教會(huì)他們?nèi)绾问褂眠@些工具，而不是試圖讓每個(gè)開發(fā)人員了解這些工具和服務(wù)紛繁復(fù)雜的內(nèi)部細(xì)節(jié)。把所有的事情放到一個(gè)黑匣子里，然后提供詳細(xì)的說明文檔。

　　使用這些工具的第二個(gè)理由是，你不需要其他團(tuán)隊(duì)的人來對(duì)你的服務(wù)和系統(tǒng)做任何關(guān)鍵性的改動(dòng)，因?yàn)檫@些人可能會(huì)給你們帶來麻煩。對(duì)于底層（第1 層、第2 層和第3 層）的服務(wù)和系統(tǒng)來說，更是如此。讓他們?cè)谶@些層上面做出改動(dòng)，或者要求（更糟糕的是期待）他們成為某方面的專家有可能會(huì)釀成大禍。舉一個(gè)配置管理的例子：不具備相關(guān)專門知識(shí)的微服務(wù)團(tuán)隊(duì)開發(fā)人員對(duì)系統(tǒng)配置做了一些變更，這有可能導(dǎo)致大規(guī)模的服務(wù)癱瘓，因?yàn)樗麄兯龅淖兏锌赡懿恢皇怯绊懙剿麄冏约旱姆?wù)。

　　開發(fā)周期

　　開發(fā)人員在對(duì)已有微服務(wù)進(jìn)行修改或構(gòu)建新的微服務(wù)時(shí)，對(duì)開發(fā)流程進(jìn)行流水線化、標(biāo)準(zhǔn)化和自動(dòng)化可以大幅提升開發(fā)效率。對(duì)開發(fā)流程進(jìn)行標(biāo)準(zhǔn)化將在第4 章進(jìn)行探討。有些東西需要被放在微服務(wù)生態(tài)系統(tǒng)的第3 層，讓穩(wěn)定可靠的開發(fā)成為可能。

　　首先是集中式的版本控制系統(tǒng)，這個(gè)系統(tǒng)保存了所有代碼，允許對(duì)代碼進(jìn)行跟蹤、版本管理和搜索。這個(gè)可以通過一些工具來實(shí)現(xiàn)，比如GitHub 或者自有的git 或svn 代碼倉庫，可以將這些倉庫和一些協(xié)作工具集成起來，比如Phabrictor，以簡化代碼的維護(hù)和審查工作。

　　其次是穩(wěn)定高效的開發(fā)環(huán)境。眾所周知，在微服務(wù)生態(tài)系統(tǒng)里實(shí)現(xiàn)一個(gè)這樣的開發(fā)環(huán)境是很困難的，因?yàn)槲⒎?wù)之間的依賴太過復(fù)雜。不過它們都是最基本的因素，我們無法避免。一些工程組織傾向于在本地完成開發(fā)工作（在開發(fā)人員的電腦上），不過這樣會(huì)導(dǎo)致糟糕的部署，因?yàn)殚_發(fā)人員并不清楚他們修改的代碼是如何被部署到生產(chǎn)環(huán)境的。最穩(wěn)定可靠的構(gòu)建開發(fā)環(huán)境的方式是為生產(chǎn)環(huán)境創(chuàng)建一個(gè)鏡像（不是為了預(yù)生產(chǎn)，也不是為了收集反饋，更不是為了生產(chǎn)），這個(gè)鏡像包含所有復(fù)雜的依賴關(guān)系鏈。

　　測(cè)試、構(gòu)建、打包和發(fā)布

　　開發(fā)過程中的測(cè)試、構(gòu)建、打包和發(fā)布應(yīng)該盡量被標(biāo)準(zhǔn)化和集中化。在開發(fā)結(jié)束之后，當(dāng)有代碼變更被提交，需要運(yùn)行相關(guān)的測(cè)試用例，然后自動(dòng)構(gòu)建和打包即將發(fā)布的新版本。這個(gè)時(shí)候，持續(xù)集成工具就可以派上用場(chǎng)，一些現(xiàn)成的解決方案（比如Jenkins）不僅功能齊全而且使用方便。這些工具可以讓整個(gè)過程自動(dòng)化，幾乎不留給人類任何犯錯(cuò)的機(jī)會(huì)。

　　部署管道

　　在經(jīng)過了開發(fā)、測(cè)試、構(gòu)建、打包和發(fā)布這些步驟之后，部署管道是新代碼走向生產(chǎn)環(huán)境的另一個(gè)流程。在一個(gè)微服務(wù)生態(tài)系統(tǒng)里，部署會(huì)在很短的時(shí)間內(nèi)變得極其復(fù)雜，每天上百個(gè)部署都是很平常的事。開發(fā)團(tuán)隊(duì)需要為開發(fā)構(gòu)建工具，并對(duì)開發(fā)過程進(jìn)行標(biāo)準(zhǔn)化。

　　日志和監(jiān)控

　　所有的微服務(wù)都應(yīng)該把與它們的請(qǐng)求和響應(yīng)相關(guān)的重要信息記錄到日志里。因?yàn)槲⒎?wù)變更的速度太快，如果系統(tǒng)發(fā)生了錯(cuò)誤，重建當(dāng)時(shí)的系統(tǒng)狀態(tài)變得很困難，導(dǎo)致代碼的缺陷難以重現(xiàn)。使用微服務(wù)級(jí)別的日志可以幫助開發(fā)人員更好地了解他們的服務(wù)在過去某個(gè)時(shí)刻或當(dāng)前時(shí)刻的狀態(tài)。在微服務(wù)級(jí)別對(duì)微服務(wù)的關(guān)鍵度量指標(biāo)進(jìn)行監(jiān)控也是出于同樣的目的：實(shí)時(shí)準(zhǔn)確的監(jiān)控可以幫助開發(fā)人員了解服務(wù)的狀態(tài)和健康狀況。

　　微服務(wù)生態(tài)系統(tǒng)的應(yīng)用平臺(tái)層（第3 層）包含：

　　- 內(nèi)部自助開發(fā)工具

　　- 開發(fā)環(huán)境

　　- 測(cè)試、構(gòu)建、打包和發(fā)布工具

　　- 部署管道

　　- 微服務(wù)級(jí)別的日志

　　- 微服務(wù)級(jí)別的監(jiān)控

　　第4 層：微服務(wù)層

　　微服務(wù)生態(tài)系統(tǒng)的頂層是微服務(wù)層（第4 層）。這一層是微服務(wù)以及微服務(wù)所有相關(guān)事物所在的層，它與底下的基礎(chǔ)設(shè)施層完全分離，比如硬件、部署、服務(wù)發(fā)現(xiàn)、負(fù)載均衡和通信。微服務(wù)層唯一沒有被分離的是使用自助工具所做的配置。

　　在軟件工程里，應(yīng)用的配置一般會(huì)被集中化，針對(duì)某個(gè)工具或某些工具（配置管理、資源隔離或部署工具）的配置可以和這些工具保存在一起。例如，應(yīng)用程序的自定義部署配置一般會(huì)和部署工具的代碼保存在一起，而不是和應(yīng)用程序的代碼保存在一起。這種方式對(duì)單體應(yīng)用架構(gòu)或小型的微服務(wù)生態(tài)系統(tǒng)來說是沒有問題的，但在包含了大量微服務(wù)和內(nèi)部工具（每個(gè)工具都有自定義的配置）的大型微服務(wù)生態(tài)系統(tǒng)里，這種方式就會(huì)造成混亂：處在上層的微服務(wù)團(tuán)隊(duì)需要修改處在下層的工具代碼，他們會(huì)經(jīng)常忘記哪些地方包含了配置信息（或者不包含）。為了解決這個(gè)問題，可以把與微服務(wù)相關(guān)的配置放在微服務(wù)代碼庫里，然后開放給下層的工具和系統(tǒng)訪問。

　　==微服務(wù)層的主要內(nèi)容==

　　微服務(wù)生態(tài)系統(tǒng)的微服務(wù)層（第4 層）包含：

　　- 微服務(wù)

　　- 微服務(wù)相關(guān)的配置

相關(guān)電子資料下載

• 一文詳解ZGC關(guān)鍵技術(shù) 26
• SpringBoot物理線程、虛擬線程、Webflux性能比較 37
• Rust語言為什么這么卷？ 21
• 什么是分布式鎖 Redis的五種分布式鎖方案 32
• Guava中這些Map的操作，讓我的代碼量減少了50% 70
• java實(shí)現(xiàn)定時(shí)器的四種方式 83
• 基于OkHttp 3.10.0的源碼案例解析 26
• 如何用Rust通過JNI和Java進(jìn)行交互 120
• JVM指針壓縮的工作原理 66
• 什么是SQL注入？Java項(xiàng)目防止SQL注入方式 37