(完整版)基于SpringCloud微服務(wù)系統(tǒng)設(shè)計(jì)方案

(完整版)基于SpringCloud微服務(wù)系統(tǒng)設(shè)計(jì)方案微服務(wù)系統(tǒng)設(shè)計(jì)方案1.微服務(wù)本質(zhì)微服務(wù)架構(gòu)實(shí)質(zhì)上是分布式架構(gòu)的一種風(fēng)格，它由多個(gè)小服務(wù)組成的應(yīng)用構(gòu)成。每個(gè)服務(wù)運(yùn)行于獨(dú)立的進(jìn)程，采用輕量級(jí)交互，通常是一個(gè)HTTP的資源API。這些服務(wù)具備獨(dú)立業(yè)務(wù)能力，可以通過(guò)自動(dòng)化部署方式獨(dú)立部署，從而最小化集中管理，使用多種不同的編程語(yǔ)言和數(shù)據(jù)存儲(chǔ)技術(shù)。對(duì)于微服務(wù)架構(gòu)系統(tǒng)，首先要規(guī)劃功能和服務(wù)，從工程實(shí)踐出發(fā)，組織好代碼結(jié)構(gòu)、配置、測(cè)試、部署、運(yùn)維、監(jiān)控的整個(gè)過(guò)程，從而有效體現(xiàn)微服務(wù)的獨(dú)立性與可部署性。2.系統(tǒng)環(huán)境名稱：JDK、SpringBoot、SpringFramework版本：1.8說(shuō)明：Ribbon、kafka、RabbitMQ3.微服務(wù)架構(gòu)的挑戰(zhàn)微服務(wù)架構(gòu)面臨的挑戰(zhàn)包括可靠性、運(yùn)維要求高、分布式復(fù)雜性、部署依賴性強(qiáng)、性能、數(shù)據(jù)一致性和重復(fù)開(kāi)發(fā)。由于采用遠(yuǎn)程調(diào)用的方式，任何一個(gè)節(jié)點(diǎn)、網(wǎng)絡(luò)出現(xiàn)問(wèn)題，都將使得服務(wù)調(diào)用失敗，隨著微服務(wù)數(shù)量的增多，潛在故障點(diǎn)也將增多。系統(tǒng)監(jiān)控、高可用性、自動(dòng)化技術(shù)是必要的。網(wǎng)絡(luò)延遲、系統(tǒng)容錯(cuò)、分布式事務(wù)是分布式復(fù)雜性的主要問(wèn)題。服務(wù)依賴、多版本問(wèn)題是部署依賴性強(qiáng)的主要原因。無(wú)狀態(tài)性、進(jìn)程間調(diào)用、跨網(wǎng)絡(luò)調(diào)用導(dǎo)致了性能問(wèn)題。分布式事務(wù)管理需要跨越多個(gè)節(jié)點(diǎn)來(lái)保證數(shù)據(jù)的瞬時(shí)一致性，因此成本高。微服務(wù)理念崇尚每個(gè)微服務(wù)作為一個(gè)產(chǎn)品看待，有自己的團(tuán)隊(duì)開(kāi)發(fā)，甚至可以有自己完全不同的技術(shù)、框架，這就產(chǎn)生了重復(fù)開(kāi)發(fā)的工作。4.架構(gòu)設(shè)計(jì)4.1.思維設(shè)計(jì)微服務(wù)架構(gòu)設(shè)計(jì)的根本目的是實(shí)現(xiàn)價(jià)值交付，遵循DevOps理念方可進(jìn)行的更順暢，思維方式的轉(zhuǎn)變是最重要的。為了實(shí)現(xiàn)微服務(wù)技術(shù)架構(gòu)，我們需要進(jìn)行技術(shù)上的改進(jìn)和相關(guān)配套服務(wù)的實(shí)現(xiàn)。我們采用分階段實(shí)施和試點(diǎn)產(chǎn)品優(yōu)先實(shí)施的策略。具體包括以下兩個(gè)方面：一、技術(shù)上的改進(jìn)：1、實(shí)現(xiàn)前后端分離，讓web前端通過(guò)Http/Https協(xié)議調(diào)用微服務(wù)的API網(wǎng)關(guān)，再由API網(wǎng)關(guān)經(jīng)過(guò)路由服務(wù)調(diào)用相應(yīng)的微服務(wù)。2、不同微服務(wù)之間通過(guò)REST方式互相調(diào)用。3、微服務(wù)之間通過(guò)消息中間件實(shí)現(xiàn)消息交互機(jī)制。二、配套服務(wù)與功能實(shí)現(xiàn)：1、需要實(shí)現(xiàn)相應(yīng)的自動(dòng)化服務(wù)，包括自動(dòng)化構(gòu)建、自動(dòng)化安裝部署、自動(dòng)化測(cè)試、自動(dòng)化平臺(tái)發(fā)布（使用Docker實(shí)現(xiàn)）。2、必須配套相應(yīng)的監(jiān)控與管理服務(wù)、日志管理服務(wù)等管理服務(wù)，以實(shí)現(xiàn)微服務(wù)架構(gòu)的管理。3、需要協(xié)作服務(wù)，運(yùn)用DevOps思想提升開(kāi)發(fā)、測(cè)試、運(yùn)維的高效溝通與協(xié)作，實(shí)現(xiàn)開(kāi)發(fā)與運(yùn)維的一體化。除此之外，我們還需要進(jìn)行微服務(wù)架構(gòu)設(shè)計(jì)，具體包括以下幾個(gè)方面：1、根據(jù)業(yè)務(wù)拆分成若干個(gè)子系統(tǒng)或微服務(wù)。2、每個(gè)子系統(tǒng)可以部署多個(gè)應(yīng)用，多個(gè)應(yīng)用之間使用負(fù)載均衡。3、需要一個(gè)服務(wù)注冊(cè)中心Eureka，所有的服務(wù)都在注冊(cè)中心注冊(cè)，負(fù)載均衡也是通過(guò)在注冊(cè)中心注冊(cè)的服務(wù)來(lái)使用一定策略來(lái)實(shí)現(xiàn)。Eureka可部署多個(gè)，進(jìn)行高可用保證。4、所有的客戶端都通過(guò)同一個(gè)網(wǎng)關(guān)地址訪問(wèn)后臺(tái)的服務(wù)，通過(guò)路由配置ZUUL網(wǎng)關(guān)來(lái)判斷一個(gè)URL請(qǐng)求由哪個(gè)服務(wù)處理。請(qǐng)求轉(zhuǎn)發(fā)到服務(wù)上的時(shí)候使用負(fù)載均衡Ribbon。5、服務(wù)之間采用feign進(jìn)行調(diào)用。6、使用斷路器hystrix，及時(shí)處理服務(wù)調(diào)用時(shí)的超時(shí)和錯(cuò)誤，防止由于其中一個(gè)服務(wù)的問(wèn)題而導(dǎo)致整體系統(tǒng)的癱瘓。7、還需要一個(gè)監(jiān)控功能，監(jiān)控每個(gè)服務(wù)調(diào)用花費(fèi)的時(shí)間等。8、使用SpringCloudConfig進(jìn)行統(tǒng)一的配置管理，需要考慮與公司的配置管理平臺(tái)如何配合使用。9、Hystrix，監(jiān)控和斷路器。我們只需要在服務(wù)接口上添加Hystrix標(biāo)簽，就可以實(shí)現(xiàn)對(duì)這個(gè)接口的監(jiān)控和斷路器功能。10、HystrixDashboard，監(jiān)控面板，提供了一個(gè)界面，可以監(jiān)控各個(gè)服務(wù)上的服務(wù)調(diào)用所消耗的時(shí)間等。11、Turbine，監(jiān)控聚合，使用Hystrix監(jiān)控，可以幫助我們把所有的服務(wù)實(shí)例的監(jiān)控信息聚合到一個(gè)地方統(tǒng)一查看。這樣就不需要挨個(gè)打開(kāi)一個(gè)個(gè)的頁(yè)面一個(gè)個(gè)查看。最后，為了保證架構(gòu)的可靠性，我們需要不斷進(jìn)行測(cè)試和優(yōu)化，確保整個(gè)系統(tǒng)的穩(wěn)定性和可靠性。在設(shè)計(jì)階段，為了防止單點(diǎn)故障，可以在關(guān)鍵節(jié)點(diǎn)做主備或集群部署。同時(shí)，需要確認(rèn)如何將Zuul網(wǎng)關(guān)的AccessControl功能與公司的CAS結(jié)合使用，以及如何將SpringCloud提供的遠(yuǎn)程配置中心與公司的配置管理平臺(tái)結(jié)合使用。在總體設(shè)計(jì)階段，需要對(duì)產(chǎn)品功能進(jìn)行拆分，將其拆分為若干個(gè)微服務(wù)，并部署在多個(gè)服務(wù)器節(jié)點(diǎn)上，以進(jìn)行負(fù)載均衡。同時(shí)，需要設(shè)計(jì)原子服務(wù)層，將核心應(yīng)用和公共應(yīng)用作為獨(dú)立的服務(wù)下沉到核心和公共能力層，以形成穩(wěn)定的服務(wù)中心。每個(gè)服務(wù)需要設(shè)計(jì)API接口，并根據(jù)不同類型的服務(wù)配置不同的資源，包括CPU、內(nèi)存、存儲(chǔ)等。在服務(wù)拆分原則方面，需要根據(jù)業(yè)務(wù)功能劃分服務(wù)粒度，使服務(wù)內(nèi)部高內(nèi)聚，服務(wù)之間低耦合。每個(gè)服務(wù)只做一件事，即單一職責(zé)原則。每個(gè)服務(wù)相互隔離，且不互相影響?；A(chǔ)服務(wù)是一些基礎(chǔ)組件，與具體的業(yè)務(wù)無(wú)關(guān)，比如短信服務(wù)和郵件服務(wù)，最容易劃分出來(lái)做微服務(wù)，也是第一優(yōu)先級(jí)分離出來(lái)的服務(wù)。在服務(wù)規(guī)劃方面，為了實(shí)現(xiàn)負(fù)載均衡，允許相同的服務(wù)在多個(gè)節(jié)點(diǎn)注冊(cè)相同的服務(wù)名，不同的端口。為避免服務(wù)名混亂，需要進(jìn)行服務(wù)名的統(tǒng)一規(guī)劃，包括統(tǒng)一制定每個(gè)服務(wù)提供者的服務(wù)名或模塊標(biāo)示，命名規(guī)則為ModuleName_ServiceName，且所有字符小寫，不同單詞之間以下劃線分隔。新增服務(wù)名需要提出申請(qǐng)并經(jīng)過(guò)審批通過(guò)后方可使用。在開(kāi)發(fā)策略方面，不同的微服務(wù)需進(jìn)行物理隔離，可以在SVN上創(chuàng)建獨(dú)立的分支，不同微服務(wù)的代碼提交不受相互影響。但是，開(kāi)發(fā)分支與集成分支將增加很多，維護(hù)工作量增加，需要由配置管理員進(jìn)行統(tǒng)一控制。是采用服務(wù)網(wǎng)格技術(shù)進(jìn)行負(fù)載均衡。服務(wù)網(wǎng)格是一種架構(gòu)模式，它將網(wǎng)絡(luò)層和應(yīng)用層的負(fù)載均衡功能集成到應(yīng)用程序中，使得微服務(wù)之間的通信更加可靠和高效。服務(wù)網(wǎng)格技術(shù)可以自動(dòng)化地管理和監(jiān)控微服務(wù)之間的通信，提高了系統(tǒng)的可靠性和可維護(hù)性。我們建議采用Istio等服務(wù)網(wǎng)格技術(shù)來(lái)實(shí)現(xiàn)負(fù)載均衡。6.安全策略在微服務(wù)架構(gòu)中，由于服務(wù)之間的通信是通過(guò)網(wǎng)絡(luò)進(jìn)行的，因此安全問(wèn)題變得尤為重要。為了保障系統(tǒng)的安全性，我們需要采取以下策略：1、采用HTTPS協(xié)議來(lái)保障通信的安全性；2、采用OAuth2.0等授權(quán)機(jī)制來(lái)保障訪問(wèn)的安全性；3、采用JWT等令牌機(jī)制來(lái)保障身份的安全性；4、采用防火墻、入侵檢測(cè)等安全設(shè)施來(lái)保障系統(tǒng)的安全性；5、采用安全編碼規(guī)范、安全審計(jì)等手段來(lái)保障代碼的安全性?？傊?，微服務(wù)架構(gòu)的安全問(wèn)題需要全方位地考慮和解決，才能保障系統(tǒng)的安全性。7.監(jiān)控策略在微服務(wù)架構(gòu)中，由于服務(wù)之間的通信是通過(guò)網(wǎng)絡(luò)進(jìn)行的，因此監(jiān)控問(wèn)題變得尤為重要。為了保障系統(tǒng)的可靠性和可維護(hù)性，我們需要采取以下策略：1、采用ELK等日志管理工具來(lái)實(shí)現(xiàn)日志的收集和分析；2、采用Prometheus等監(jiān)控工具來(lái)實(shí)現(xiàn)系統(tǒng)的實(shí)時(shí)監(jiān)控；3、采用Zipkin等分布式跟蹤工具來(lái)實(shí)現(xiàn)服務(wù)之間的調(diào)用鏈跟蹤；4、采用Grafana等數(shù)據(jù)可視化工具來(lái)實(shí)現(xiàn)監(jiān)控?cái)?shù)據(jù)的可視化；5、采用自動(dòng)化運(yùn)維工具來(lái)實(shí)現(xiàn)系統(tǒng)的自動(dòng)化運(yùn)維?？傊?，微服務(wù)架構(gòu)的監(jiān)控問(wèn)題需要全方位地考慮和解決，才能保障系統(tǒng)的可靠性和可維護(hù)性。負(fù)載均衡是一種將請(qǐng)求分配到不同服務(wù)器的技術(shù)。軟負(fù)載均衡是將負(fù)載均衡的功能以庫(kù)的方式集成到服務(wù)消費(fèi)方的進(jìn)程內(nèi)，也稱為客戶端負(fù)載均衡。在SpringCloud中，Ribbon子項(xiàng)目與Eureka的服務(wù)注冊(cè)功能配合，實(shí)現(xiàn)了REST客戶端的負(fù)載均衡。使用Ribbon進(jìn)行負(fù)載均衡，其工作原理可以概括為以下四個(gè)步驟：首先根據(jù)其所在Zone優(yōu)先選擇一個(gè)負(fù)載較少的EurekaServer；然后定期從EurekaServer更新并過(guò)濾服務(wù)實(shí)例列表；接著根據(jù)指定的負(fù)載均衡策略，從可用的服務(wù)器列表中選擇一個(gè)服務(wù)實(shí)例的地址；最后通過(guò)RestClient進(jìn)行服務(wù)調(diào)用。Ribbon提供了多種負(fù)載均衡策略，包括輪詢策略、隨機(jī)選擇、最大可用策略、帶有加權(quán)的輪詢策略、可用過(guò)濾策略和區(qū)域感知策略。其中，輪詢策略是默認(rèn)值，示例中啟動(dòng)的兩個(gè)服務(wù)會(huì)被循環(huán)訪問(wèn)。在性能策略方面，可以通過(guò)優(yōu)化組網(wǎng)結(jié)構(gòu)和配置信息，提升網(wǎng)絡(luò)間通訊性能和最大化性能。在技術(shù)管理策略方面，微服務(wù)的架構(gòu)理念允許各微服務(wù)獨(dú)立建設(shè)，使用不同的技術(shù)、語(yǔ)言、框架等，以便更快速地響應(yīng)特定客戶需求，解決單體應(yīng)用架構(gòu)更新技術(shù)、更新框架時(shí)面臨的困難或阻礙。在微服務(wù)架構(gòu)中，服務(wù)之間的調(diào)用是必不可少的。但是這也帶來(lái)了一些問(wèn)題，例如是否允許各服務(wù)任意使用自己的技術(shù)、組件、框架，這樣會(huì)帶來(lái)更大的管理、維護(hù)和技術(shù)共享困難。為了解決這些問(wèn)題，我們需要采取一些管理策略?？傮w原則是所有組件都需要統(tǒng)一管理，放置在產(chǎn)品倉(cāng)庫(kù)中。當(dāng)一個(gè)產(chǎn)品或服務(wù)需要共享組件時(shí)，從產(chǎn)品倉(cāng)庫(kù)獲取。對(duì)于特殊情況，特殊服務(wù)需要使用特殊的組件、框架，需要提出申請(qǐng)，并進(jìn)行統(tǒng)籌規(guī)劃后進(jìn)行決策。在開(kāi)發(fā)階段，服務(wù)調(diào)用是一個(gè)重要的環(huán)節(jié)。所有服務(wù)都通過(guò)Zuul網(wǎng)關(guān)進(jìn)行調(diào)用，不允許直接調(diào)用微服務(wù)提供者。Zuul可能會(huì)成為系統(tǒng)瓶頸，在項(xiàng)目復(fù)雜時(shí)可考慮為Zuul進(jìn)行主備或負(fù)載均衡處理。在同步調(diào)用方面，我們可以采用HTTPREST方式進(jìn)行調(diào)用，并進(jìn)行負(fù)載均衡。建議使用FeignClient方式進(jìn)行服務(wù)調(diào)用。不管是什么方式，都是通過(guò)REST接口調(diào)用服務(wù)的http接口，參數(shù)和結(jié)果默認(rèn)都是通過(guò)Jackson序列化和反序列化。在異步調(diào)用方面，我們可以選擇rabbitMq、kafka、SpringCloudStream等方案。SpringCloudStream是基于Redis、Rabbit、Kafka實(shí)現(xiàn)的消息微服務(wù)，可以在SpringCloud應(yīng)用中收發(fā)消息。服務(wù)間調(diào)用的權(quán)限驗(yàn)證也是必不可少的。一般我們的API接口都需要某種授權(quán)才能訪問(wèn)，登陸成功以后，通過(guò)token或者cookie等方式才能調(diào)用接口。使用SpringCloudNetfix框架的話，登錄請(qǐng)求會(huì)被轉(zhuǎn)發(fā)到相應(yīng)的用戶服務(wù)上，登陸成功后，會(huì)設(shè)置cookie或headertoken等。然后客戶端接下來(lái)的請(qǐng)求就會(huì)帶著這些驗(yàn)證信息，從Zuul網(wǎng)關(guān)傳到相應(yīng)的服務(wù)上進(jìn)行驗(yàn)證。Zuul網(wǎng)關(guān)會(huì)默認(rèn)將一些header傳遞到服務(wù)端，例如Cookie、Set-Cookie和Authorization，從而實(shí)現(xiàn)客戶端請(qǐng)求的相關(guān)headers傳遞到服務(wù)端，服務(wù)端設(shè)置的cookie也可以傳遞到客戶端。但是，如果要禁止某些header透?jìng)鞯椒?wù)端，可以在Zuul網(wǎng)關(guān)的application.yml配置文件中通過(guò)sensitiveHeaders屬性禁用。當(dāng)一個(gè)服務(wù)需要調(diào)用另一個(gè)服務(wù)時(shí)，請(qǐng)求的header中不會(huì)包含任何驗(yàn)證信息。此時(shí)，可以通過(guò)防火墻等設(shè)置來(lái)保證服務(wù)間調(diào)用的接口只能被某幾個(gè)地址訪問(wèn)，或者通過(guò)設(shè)置header的方式來(lái)實(shí)現(xiàn)。同時(shí)，如果想要在某個(gè)服務(wù)中獲取請(qǐng)求的真實(shí)IP，可以從headerX-Forwarded-Host中獲取。如果要禁用該header，可以在Zuul網(wǎng)關(guān)的配置文件中設(shè)置addProxyHeaders屬性為false。如果使用RestTemplate方式調(diào)用，可以在請(qǐng)求中添加一個(gè)帶有header的Options。也可以通過(guò)攔截器的方式設(shè)置，該攔截器對(duì)RestTemplate方式和FeignClient方式都適用。服務(wù)編排的主要作用是減少項(xiàng)目中的相互依賴。例如，如果項(xiàng)目a調(diào)用項(xiàng)目b，項(xiàng)目b調(diào)用項(xiàng)目c，一直到h，形成了一個(gè)調(diào)用鏈，那么在項(xiàng)目上線時(shí)需要先更新最底層的h，然后再更新g，以此類推，這樣才能確保服務(wù)之間的依賴關(guān)系得到滿足。更新項(xiàng)目a需要調(diào)用b，這只是復(fù)雜業(yè)務(wù)中的一個(gè)調(diào)用鏈，對(duì)開(kāi)發(fā)和運(yùn)維人員來(lái)說(shuō)是災(zāi)難。為了盡量減少項(xiàng)目之間的相互依賴，可以采用服務(wù)編排。核心業(yè)務(wù)處理項(xiàng)目W負(fù)責(zé)和各個(gè)微服務(wù)打交道。以前是a調(diào)用b，b調(diào)用c，c調(diào)用d，現(xiàn)在統(tǒng)一在W中處理。W服務(wù)使用a時(shí)，調(diào)用b；使用b時(shí)，調(diào)用c。這可以理解為面向?qū)ο蟮脑O(shè)計(jì)，減少方法之間的嵌套調(diào)用，采取一個(gè)方法實(shí)現(xiàn)完整的業(yè)務(wù)處理。在服務(wù)之間進(jìn)行調(diào)用時(shí)，可能由于各種原因?qū)е逻h(yuǎn)程服務(wù)不可用或壓力過(guò)載等異常，這時(shí)需要有一種機(jī)制進(jìn)行保護(hù)處理。SpringCloud通過(guò)Netflix的Hystrix組件實(shí)現(xiàn)熔斷和降級(jí)處理解決此問(wèn)題。斷路器是一種能夠在遠(yuǎn)程服務(wù)不可用時(shí)自動(dòng)熔斷并在遠(yuǎn)程服務(wù)恢復(fù)時(shí)自動(dòng)恢復(fù)的設(shè)施。SpringCloud通過(guò)Netflix的Hystrix組件提供斷路器、資源隔離和自我修復(fù)功能。不同微服務(wù)部署在不同節(jié)點(diǎn)上，登錄每個(gè)節(jié)點(diǎn)查看日志是比較麻煩的，同時(shí)對(duì)于需要關(guān)聯(lián)多個(gè)微服務(wù)日志聯(lián)合查看分析的情況將更加麻煩。因此需要進(jìn)行統(tǒng)一日志管理。建立統(tǒng)一的日志管理規(guī)范，開(kāi)發(fā)并使用統(tǒng)一的日志組件，為所有微服務(wù)提供統(tǒng)一的日志服務(wù)，由log4j或Blitz4j封裝。在每個(gè)服務(wù)節(jié)點(diǎn)上部署日志采集Agent組件，由此Agent進(jìn)行日志的采集與轉(zhuǎn)發(fā)。建立統(tǒng)一的日志中心，所有日志寫入日志中心。這些日志的實(shí)現(xiàn)由公司的“日志管理平臺(tái)”進(jìn)行實(shí)現(xiàn)，采用的是ELK集合框架。為了統(tǒng)一監(jiān)控管理，可以使用Hystrix和HystrixDashboard。在服務(wù)接口上添加Hystrix標(biāo)簽，就可以實(shí)現(xiàn)對(duì)這個(gè)接口的監(jiān)控和斷路器功能。HystrixDashboard提供了一個(gè)界面，可以監(jiān)控各個(gè)服務(wù)上的服務(wù)調(diào)用所消耗的時(shí)間等。Turbine是一個(gè)監(jiān)控聚合工具，可以幫助我們將所有服務(wù)實(shí)例的監(jiān)控信息聚合到一個(gè)地方，以便統(tǒng)一查看。這樣就不需要逐個(gè)打開(kāi)每個(gè)服務(wù)實(shí)例的監(jiān)控信息頁(yè)面了。使用Hystrix組件進(jìn)行服務(wù)監(jiān)控，使用Nagios進(jìn)行服務(wù)器等資源監(jiān)控。實(shí)現(xiàn)各微服務(wù)的統(tǒng)一參數(shù)配置以及版本管理，可以采用公司的配置管理平臺(tái)或者SpringCloudConfig配置中心。SpringCloudConfig是一個(gè)配置中心，可以將應(yīng)用原本放在本地文件的配置抽取出來(lái)放在中心服務(wù)器，從而提供更好的管理、發(fā)布能力。SpringCloudConfig分為服務(wù)端和客戶端，服務(wù)端負(fù)責(zé)將存儲(chǔ)在git（svn）中的配置文件發(fā)布成REST接口，客戶端可以從服務(wù)端REST接口獲取配置。但客戶端并不能主動(dòng)感知到配置的變化，從而主動(dòng)去獲取新的配置，這需要每個(gè)客戶端通過(guò)POST方法觸發(fā)各自的/refresh。為了解決配置信息能及時(shí)通知到各服務(wù)，同時(shí)減少每個(gè)微服務(wù)處理配置信息更新的復(fù)雜度，我們通過(guò)消息總線來(lái)解決此問(wèn)題。具體方案如下：Git倉(cāng)庫(kù)、ConfigServer、以及微服務(wù)“ServiceA”、“ServiceB”的實(shí)例中都引入了SpringCloudBus，所以他們都連接到了RabbitMQ的消息總線上。從Git倉(cāng)庫(kù)中配置的修改到發(fā)起/bus/refresh的POST請(qǐng)求這一步可以通過(guò)Git倉(cāng)庫(kù)的WebHook來(lái)自動(dòng)觸發(fā)。/bus/refresh請(qǐng)求不再發(fā)送到具體服務(wù)實(shí)例上，而是發(fā)送給ConfigServer，并通過(guò)destination參數(shù)來(lái)指定需要更新配置的服務(wù)或?qū)嵗Ｓ捎谒羞B接到消息總線上的應(yīng)用都會(huì)接受到更新請(qǐng)求，所以在WebHook中就不需要維護(hù)所有節(jié)點(diǎn)內(nèi)容來(lái)進(jìn)行更新，從而解決了通過(guò)WebHook來(lái)逐個(gè)進(jìn)行刷新的問(wèn)題。采用Redis作為緩存組件以及session的共享組件，實(shí)現(xiàn)分布式session。制定規(guī)范和解析方法，以便更好地處理REST資源響應(yīng)結(jié)構(gòu)。API調(diào)用鏈追蹤。問(wèn)題。消費(fèi)者可以通過(guò)契約來(lái)驗(yàn)證提供者的服務(wù)是否符合預(yù)期，而提供者則可以通過(guò)契約來(lái)驗(yàn)證自己的服務(wù)是否符合約定。這種隔離的測(cè)試方式可以有效地降低測(cè)試的復(fù)雜度和成本。微服務(wù)架構(gòu)是通過(guò)業(yè)務(wù)來(lái)劃分服務(wù)的，這些服務(wù)通過(guò)REST調(diào)用對(duì)外暴露一個(gè)接口。但是，如果鏈路上任何一個(gè)服務(wù)出現(xiàn)問(wèn)題或者網(wǎng)絡(luò)超時(shí)，都會(huì)導(dǎo)致接口調(diào)用失敗。隨著業(yè)務(wù)的不斷擴(kuò)張，服務(wù)之間互相調(diào)用會(huì)越來(lái)越復(fù)雜。為了解決這個(gè)問(wèn)題，SpringCloudSleuth提供了追蹤解決方案，并且兼容支持了zipkin，只需要在pom文件中引入相應(yīng)的依賴即可。在微服務(wù)架構(gòu)下，進(jìn)行系統(tǒng)測(cè)試的復(fù)雜度較大，因此單元測(cè)試是必不可少的?？梢圆捎肕ock方式進(jìn)行測(cè)試模擬，并由持續(xù)集成進(jìn)行自動(dòng)化單元測(cè)試的執(zhí)行以及結(jié)果輸出。對(duì)于代碼調(diào)試，單