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

1、微服務(wù)系統(tǒng)設(shè)計(jì)方案1.微服務(wù)本質(zhì)微服務(wù)架構(gòu)從本質(zhì)上說(shuō)其實(shí)就是分布式架構(gòu)，與其說(shuō)是一種新架構(gòu)，不如說(shuō)是一種微服務(wù)架構(gòu)風(fēng)格。簡(jiǎn)單來(lái)說(shuō)，微服務(wù)架構(gòu)風(fēng)格是要開(kāi)發(fā)一種由多個(gè)小服務(wù)組成 的應(yīng)用。每個(gè)服務(wù)運(yùn) 行于獨(dú) 立的進(jìn)程，并且采用 輕量級(jí)交互。多數(shù)情況下是一個(gè)HTTP的資源API。這些服務(wù)具備獨(dú)立業(yè)務(wù)能力并可以通過(guò)自動(dòng)化部署方式獨(dú)立部 署。這種風(fēng)格使最小化集中管理，從而可以使用多種不同的編程語(yǔ)言和數(shù)據(jù)存儲(chǔ)技術(shù)。對(duì)于微服務(wù)架構(gòu)系統(tǒng)，由于其服務(wù)粒度小，模塊化清晰，因此首先要做的是對(duì)系統(tǒng)整體進(jìn)行功能、服務(wù)規(guī) 劃，優(yōu)先考慮如何在交付過(guò)程中，從工程實(shí)跋出發(fā)，組織好代碼結(jié)構(gòu)、配置、測(cè)試、部署、運(yùn)維、監(jiān)控 的整個(gè)過(guò)程

2、，從而有效體現(xiàn)微服務(wù)的獨(dú)立性與可部署性。本文將從微服務(wù)系統(tǒng)的設(shè)計(jì)階段、開(kāi)發(fā)階段、測(cè)試階段、部署階段進(jìn)行綜合闡述。理解微服務(wù)架構(gòu)和理念是核心。2-系統(tǒng)環(huán)境名稱(chēng)版本說(shuō)明JDK1.8SPring BootSPring FrameWOrkRibbo nkafkaRabbitMQ3. 微服務(wù)架構(gòu)的挑戰(zhàn)可靠性：由于采用遠(yuǎn)程調(diào)用的方式，任何一個(gè)節(jié)點(diǎn)、網(wǎng)絡(luò)出現(xiàn)問(wèn)題，都將使得服務(wù)調(diào)用失敗，隨著微服務(wù)數(shù)量 的增多，潛在故障點(diǎn)也將增多。也就是沒(méi)有充分的保障機(jī)制，則單點(diǎn)故障會(huì)大量增加。運(yùn)維要求高：系統(tǒng)監(jiān)控、高可用性、自動(dòng)化技術(shù)分布式復(fù)雜性：網(wǎng)絡(luò)延遲、系統(tǒng)容錯(cuò)、分布式事務(wù)部署依賴性強(qiáng)：服務(wù)依賴、多版本問(wèn)題性能（服務(wù)間通

3、訊成本高）：無(wú)狀態(tài)性、進(jìn)程間調(diào)用、跨網(wǎng)絡(luò)調(diào)用 數(shù)據(jù)一致性：分布式事務(wù)管理需要跨越多個(gè)節(jié)點(diǎn)來(lái)保證數(shù)據(jù)的瞬時(shí)一致性，因此比起傳統(tǒng)的單體架構(gòu)的事務(wù)，成本要高得多。另外，在分布式系統(tǒng)中，通常會(huì)考慮通過(guò)數(shù)據(jù)的最終一致性來(lái)解決數(shù)據(jù)瞬時(shí)一致帶來(lái)的系統(tǒng)不可用。重復(fù)開(kāi)發(fā)：微服務(wù)理念崇尚每個(gè)微服務(wù)作為一個(gè)產(chǎn)品看待，有自己的團(tuán)隊(duì)開(kāi)發(fā)，甚至可以有自己完全不同的技術(shù)、框架，那么與其他微服務(wù)團(tuán)隊(duì)的技術(shù)共享就產(chǎn)生了矛盾，重復(fù)開(kāi)發(fā)的工作即產(chǎn)生了。沒(méi)有最好的/只有最適合自己的。4. 架構(gòu)設(shè)計(jì)4.1 思維設(shè)計(jì)微服務(wù)架構(gòu)設(shè)計(jì)的根本目的是實(shí)現(xiàn)價(jià)值交付，行的更順暢，思維方式的轉(zhuǎn)變是最重要的。微服務(wù)架構(gòu)只有遵循DeVoPS理念方可進(jìn)ZL

4、a0 r Ril Pcm11 n -hlw Hb= llldlMq ZcokWIJB-nklm IMavn GrjB-Ulv SVN Moniitor SenAi-Ci3Dl%* 即在模塊內(nèi)部可以自由增加服務(wù)名，不需要進(jìn)行審批。5.4. 開(kāi)發(fā)策略總體原則：不同的微服務(wù)需進(jìn)行物理隔離。1、SVN策略：SVN上創(chuàng)建獨(dú)立的分支，不同微服務(wù)的代碼提交不受相互影響；“由配置管理員統(tǒng)一控制。問(wèn)題：開(kāi)發(fā)分支與集成分支，都將增加很多，維護(hù)工作量增加。2、編譯策略：代碼編譯時(shí)，各個(gè)微服務(wù)獨(dú)立編譯、打包，杜絕直接的依賴；3、工程構(gòu)建：代碼開(kāi)發(fā)時(shí)，各微服務(wù)創(chuàng)建獨(dú)立的工程，工程之間不能產(chǎn)生直接依賴4、持續(xù)集成：每個(gè)微

5、服務(wù)獨(dú)立執(zhí)行持續(xù)集成。5、版本集成：由統(tǒng)一的集成工具，實(shí)現(xiàn)自動(dòng)化的版本集成，將所有微服務(wù)集成到統(tǒng)一的版本發(fā)布包中。5.5. 版本策略每個(gè)微服務(wù)可以獨(dú)立制作版本，伴隨著服務(wù)的增多，SVN分支增多，版本也將增多，版本管理的復(fù)雜度將成 指數(shù)級(jí)增加。在服務(wù)之間依賴較多時(shí)，每個(gè)服務(wù)的升級(jí)或降級(jí)都將影響 其他服務(wù)的正常運(yùn)行。因此需執(zhí)行如下策略：1、所有服務(wù)的版本制作交由專(zhuān)業(yè)的版本管理員執(zhí)行。2、采用自動(dòng)化的版本制作策略，最大程度的減少人工操作。3、每個(gè)服務(wù)的版本必須有詳細(xì)的版本計(jì)劃、版本說(shuō)明，對(duì)于版本說(shuō)明要制定模板，明確需要提交的內(nèi)容、版 本號(hào)、SVN標(biāo)簽等。4、對(duì)項(xiàng)目經(jīng)理的要求提升，需對(duì)整體的版本計(jì)劃有

6、嚴(yán)格的制定，尤其是版本之間的依賴矢系要非常明確，版 本升級(jí)、降級(jí)的 風(fēng)險(xiǎn)評(píng)估 需完全充分。5、接管理：嚴(yán)格執(zhí)行接管理制度，任何接口的變更必須進(jìn)行審批、發(fā)公告等流程。5.6. 數(shù)據(jù)庫(kù)挑戰(zhàn)與策略每個(gè)微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫(kù)，那么后臺(tái)管理的聯(lián)合查詢?cè)趺刺幚?？這應(yīng)該是大家 會(huì)普遍遇到的一個(gè)問(wèn) 題，有三種處理方案。1）嚴(yán)格按照微服務(wù)的劃分來(lái)做，微服務(wù)相互獨(dú)立，各微服務(wù)數(shù)據(jù)庫(kù)也獨(dú)立，后臺(tái)需要 展示數(shù)據(jù)時(shí)，調(diào)用各 微服務(wù)的接來(lái)獲取對(duì)應(yīng)的數(shù)據(jù)，再進(jìn)行數(shù)據(jù)處理后展示出來(lái)，這是標(biāo)準(zhǔn)的用法，也是最麻煩的用法。2）將業(yè)務(wù)高度相矢的表放到一個(gè)庫(kù)中，將業(yè)務(wù)矢系不是很緊密的表嚴(yán)格按照微服務(wù)模式來(lái)拆分，這樣既可以 使用微服

7、務(wù)，也避免了數(shù)據(jù)庫(kù)分散導(dǎo)致后臺(tái)系統(tǒng)統(tǒng)計(jì)功能難以實(shí)現(xiàn)，是一個(gè)折中的方案。3）數(shù)據(jù)庫(kù)嚴(yán)格按照微服務(wù)的要求來(lái)切分，以滿足業(yè)務(wù)高并發(fā)，實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)將各微服務(wù)數(shù)據(jù)庫(kù)數(shù)據(jù)同步到NoSQL數(shù)據(jù)庫(kù)中，在同步的過(guò)程中進(jìn)行數(shù)據(jù)清洗，用來(lái)滿足后臺(tái)業(yè)務(wù)系統(tǒng)的使用，推薦使 用MongoDB、HBase 等。第一種方案適合業(yè)務(wù)較為簡(jiǎn)單的小公司：第二種方案，適合在原有系統(tǒng)之上，慢慢演化為微服務(wù)架構(gòu)的公 司；第三種適合大型高并發(fā)的互聯(lián)網(wǎng)公司。建議，我們當(dāng)前采用第二種方案。5.7. 負(fù)載均衡不再采用一般的增加負(fù)載均衡服務(wù)器的方式逬行負(fù)載均衡，如F5、Nginx、LVS等，而是把負(fù)載均衡的功能以庫(kù)的方式集成到服務(wù)消費(fèi)方的進(jìn)程內(nèi)

8、，這種方案稱(chēng)為軟負(fù)載均衡(Soft Load Balancing咸者客戶端負(fù)載均衡。在SPring Clolld中配合EUreka的服務(wù)注冊(cè)功能，Ribbon子項(xiàng)目則為REST客戶端實(shí)現(xiàn)了負(fù)載均衡。AVailabilityFilteri ngRule:可用過(guò)濾策略，先過(guò)濾出故障的或并發(fā)請(qǐng)求大于閾值一t CLIEMTfSHuNC CUUDC NflCAPICATEWAY；AUTH SEftVKEZUUL:SOc%KI：J DtSCOVEIIVURCKAIRDBBOHHYSTRIXHYSTRtIM ； HYSTRIXMCMIIT DASHflOARDiTIUIIB-IINE使用Ribbon進(jìn)行負(fù)載

9、均衡，其工作原理可以概括為下面四個(gè)步驟：1. RibbOn首先根據(jù)其所在Zone優(yōu)先選擇一個(gè)負(fù)載較少的EUreka Server;2. 定期從EUreka SerVer更新并過(guò)濾服務(wù)實(shí)例列表；3. 根據(jù)指定的負(fù)載均衡策略，從可用的服務(wù)器列表中選擇一彳、服務(wù)實(shí)例的地址4. 然后通過(guò)ReStClient進(jìn)行服務(wù)調(diào)用。RibbOn本身提供了下面幾種負(fù)載均衡策略：* RoundRobinRule:輪詢策略，RibbOn以輪詢的方式選擇服務(wù)器，這個(gè)是默認(rèn)值。所以示例中所啟動(dòng)的兩個(gè)服務(wù)會(huì)被循環(huán)訪問(wèn)；* RandomRule:隨機(jī)選擇，也就是說(shuō)RibbOn會(huì)隨機(jī)從服務(wù)器列表中選擇一個(gè)進(jìn)行訪問(wèn)* BestAv

10、ailableRule:最大可用策略，即先過(guò)濾出故障服務(wù)器后，選擇一個(gè)當(dāng)前并發(fā)請(qǐng)求數(shù)最小的；* WeightedReSP On SeTimeRule:帶有加權(quán)的輪詢策略對(duì)各個(gè)服務(wù)器響應(yīng)時(shí)間進(jìn)行加權(quán)處理，然后在采用輪詢的方式來(lái)獲取相應(yīng)的服務(wù)器部分服務(wù)實(shí)例，然后再以線性輪詢的方式從過(guò)濾后的實(shí)例清單中選出一個(gè)；* Zo neAvoida nceRule:區(qū)域感知策略，先使用主過(guò)濾條件（區(qū)域負(fù)載器，選擇最優(yōu)區(qū)域）對(duì)所有實(shí)例過(guò)濾并返回過(guò)濾后的實(shí)例清單，依次使用次過(guò)濾條件列表中的過(guò)濾條件對(duì)主過(guò)濾條件的結(jié)果進(jìn)行過(guò)濾，判斷最小過(guò)濾數(shù)（默認(rèn)1）和最小過(guò)濾百分比（默認(rèn)0）,最后對(duì)滿足條件的服務(wù)器則使用RoUndR

11、obinRule （輪詢方式）選擇一個(gè)服務(wù)器實(shí)例。5.8. 性能策略1、網(wǎng)絡(luò)優(yōu)化：優(yōu)化組網(wǎng)結(jié)構(gòu)，提升網(wǎng)絡(luò)間通訊性能；2、配置優(yōu)化：優(yōu)化SPring Cloud組件集以及其他組件的配置信息，使得性能最大化。5.9. 技術(shù)管理策略微服務(wù)的架構(gòu)理念中指出各微服務(wù)可以獨(dú)立建設(shè)，可以使用不同的技術(shù)、語(yǔ)言、框架等，以便能更快速的使用新技術(shù)、新框架等響應(yīng)特定客戶需求，解決單體應(yīng)用架構(gòu)更新技術(shù)、更新框架時(shí)面臨的困 難或阻礙。但這也同時(shí)帶來(lái)了諸多問(wèn)題，如下：1、各服務(wù)是否可以任意使用自己的技術(shù)、自己的組件、框架呢？如果這樣，勢(shì)必帶來(lái)更大的管理困難、維護(hù)困難、技術(shù)共享困難。2、公共的方法如何實(shí)現(xiàn)共享？如格式化時(shí)間

12、的一個(gè)簡(jiǎn)單方法需要共享，也需要封裝為一個(gè)服務(wù)接嗎？管理策略：1、總體原則：仍然需要進(jìn)行統(tǒng)籌考慮，所有組件統(tǒng)一管理，組件放置在產(chǎn)品倉(cāng)庫(kù)中，每個(gè)產(chǎn)品或服務(wù)需要共享組件時(shí)，從產(chǎn)品倉(cāng)庫(kù)獲取。訂、曲30%打潔產(chǎn)品令潔審式產(chǎn)品白店提供J、產(chǎn)呂由玄戶購(gòu)買(mǎi)I兵三皓蕓自三的紡討2特殊情況：特殊服務(wù)需要使用特殊的組件框架，需提出申請(qǐng)，統(tǒng)籌規(guī)劃后進(jìn)行決策。6 開(kāi)發(fā)階段61 服務(wù)的調(diào)用6.1.1. AIP網(wǎng)矢調(diào)用所有服務(wù)通過(guò)ZUUI網(wǎng)矢進(jìn)行調(diào)用，不允許直接調(diào)用微服務(wù)提供者。ZUUI可能會(huì)成為系統(tǒng)瓶頸，在項(xiàng)目復(fù)雜時(shí)可考慮為Zuul逬行主備或負(fù)載均衡處理。ZIJUI儲(chǔ)機(jī)制 MVBatiSINmWWAUrRost%|r峯戶

13、端川!承CarnP4 i%y路山規(guī)凹SSfFJalRI %AMVbatiRPC曲燿(SPringeaot/RPCrfiai MVeatiS612 冋步調(diào)用采用HTTP REST方式逬行調(diào)用，針對(duì)業(yè)務(wù)需求可以逬行負(fù)載均衡，負(fù)載均衡的調(diào)用方式有兩種：1、FeignClient2、ReStTemPlate建議使用FeignClient方式進(jìn)行服務(wù)調(diào)用。不管是什么方式，他都是通過(guò)REST接口調(diào)用服務(wù)的http接口，參數(shù)和結(jié)果默認(rèn)都是通過(guò)JaCkSon序列化和反序列化。因?yàn)镾Pring MVC的ReStCOntroller定義的接口，返回的數(shù)據(jù)都是通過(guò)JaCkSOn序列化成JSON數(shù)據(jù)。FeignriQ

14、tf甩5簡(jiǎn)單聲明模型用以在rabbitMq、kafka、SPring Cloud Stream 均是可以選擇的方案。 SPring Cloud Stream，基于 Redis、Rabbit、Kafka實(shí)現(xiàn)的消息微服務(wù)SPring Cloud應(yīng)用中收發(fā)消息。6工4 服務(wù)間調(diào)用的權(quán)限驗(yàn)證般我們的API接口都需要某種授權(quán)才能訪問(wèn)，登陸成功以后，然后通過(guò)token或者cookie等方式才能調(diào)用接口。使用SPring Cloud NetfiX框架的話，登錄的時(shí)候，把登錄請(qǐng)求轉(zhuǎn)發(fā)到相應(yīng)的用戶服務(wù)上，登陸成功后，會(huì)設(shè)置cookie或header token等。然后客戶端接下來(lái)的請(qǐng)求就會(huì)帶著這些驗(yàn)證信息，從Z

15、UUI網(wǎng)矢?jìng)鞯较鄳?yīng)的服務(wù)上 進(jìn)行驗(yàn)證。ZUUI網(wǎng)矢在把請(qǐng)求轉(zhuǎn)發(fā)到后臺(tái)的服務(wù)的時(shí)候，會(huì)默認(rèn)把一些header傳到服務(wù)端，如：Cookie、Set-CoOkie、AUthOriZatiOn 。這樣，客戶端請(qǐng)求的相尖headers就可以傳遞到服務(wù)端， 服務(wù)端設(shè)置的cookie也可以傳到客戶端。但是，如果你想禁止某些header透?jìng)鞯椒?wù)端，可以在Zuul網(wǎng)矢的即PliCatiOn.yml配置里通過(guò)下面的方式禁用：zuul:routes:users:path: /users/*Sen SitiVeHeaders: COOkie,Set-Cookie,Authorizati OnSerViGeld: U

16、Ser岡財(cái)說(shuō)了我們的某個(gè)服務(wù)有時(shí)候需要調(diào)用另一個(gè)服務(wù)，這時(shí)候，這個(gè)請(qǐng)求不是客戶端發(fā)起，他的請(qǐng)求的header里面也不會(huì)有任何驗(yàn)證信息。這時(shí)候，要么，通過(guò)防火墻等設(shè)置，保證服務(wù)間調(diào)用的接口，只能某幾個(gè)地址訪問(wèn)；要么，就通過(guò)某種方式設(shè)置 header。同時(shí)，如果你想在某個(gè)服務(wù)里面獲得這個(gè)請(qǐng)求的真是IP ,（因?yàn)檎?qǐng)求的通過(guò)網(wǎng)尖轉(zhuǎn)發(fā)而來(lái)、你直接通過(guò) request獲得ip得到的是網(wǎng)矣的IP），就可以從headerX-Forwarded-Host獲得。如果想禁用這個(gè)header,也可以：zuul.addProxyHeaders = false如果你使用ReS訂emPlate的方式調(diào)用，可以在請(qǐng)求里面添加

17、一個(gè)有header的OPtiOnSBea nPublic Request In terceptor requestl nterceptor() return new ReqlleStl nterceptor() 也可以通過(guò)如下的攔截器的方式設(shè)置，它對(duì)ReStTemPlate方式和FeignClient的方式都可以起作用:OVerridePUbliC void apply(RequestTemplate template) Stri ng authToke n = getToke n(); template.header(AUTH_TOKEN_HEADER, authToken)；主要的作用是減

18、少項(xiàng)目中的相互依賴。比如現(xiàn)在有項(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.更新C更新b最后是更新項(xiàng)目a。這只是這一個(gè)調(diào)用鏈，在復(fù)雜的業(yè)務(wù)中有非常多的調(diào)用，如果要 記住每一個(gè)調(diào)用鏈對(duì)開(kāi)發(fā) 運(yùn)維人員來(lái)說(shuō)就是災(zāi)難。有這樣一個(gè)好辦法可以盡量的減少項(xiàng)目的相互依賴，就是服務(wù)編排，一個(gè)核心的業(yè)務(wù)處理項(xiàng)目，負(fù)責(zé)和各個(gè)微服務(wù)打交道。比如之前是a調(diào)用b，b掉用c, C調(diào)用d，現(xiàn)在統(tǒng)一在一個(gè)核心項(xiàng)目W中來(lái)處理，W服務(wù)使用a的時(shí)候去調(diào)用b、使用b的時(shí)候W去調(diào)用CO其實(shí)可以理解為面向?qū)ο蟮脑O(shè)計(jì)，減少方法之間的一層層嵌套調(diào)用，而采取一個(gè)方法進(jìn)行業(yè)務(wù)流程的串聯(lián)

19、，如方法W實(shí)現(xiàn)一個(gè)完整的業(yè)務(wù)處理，則采取下面方式：function W（）1 調(diào)用方法a；2、調(diào)用方法b； 3、調(diào)用方法c；62服務(wù)的熔斷處理在服務(wù)之間進(jìn)行調(diào)用時(shí)，由于各種原因會(huì)導(dǎo)致遠(yuǎn)程服務(wù)不可用或壓力過(guò)載等異常導(dǎo)致的故障蔓延，此時(shí)需要有一種機(jī)制進(jìn)行保護(hù)處理。SPring Cloud通過(guò)NetfliX的HyStriX組件實(shí)現(xiàn)熔斷和降級(jí)處理解決此問(wèn)題。斷路器（CriCUit Breaker）是一種能夠在遠(yuǎn)程服務(wù)不可用時(shí)自動(dòng)熔 斷（打開(kāi)開(kāi) 矢），并在遠(yuǎn)程服務(wù)恢復(fù)時(shí)自動(dòng)恢復(fù)（閉合開(kāi)矢）的設(shè)施，SPring CloUd通過(guò)NetfliX的HyStriX組件提供斷路器、資源隔離與自我修復(fù)功能。SPrin

20、g cloud HyStriX 熔斷器n3S!tr&rt ingclose CifCUItn3S!tr&rt ingfailCiFCUII BreakVr SUitD DiBlgrarnHyStriX熔斷處理1. m%TW2. 帆陽(yáng)3. 贏戡強(qiáng)機(jī)63統(tǒng)一日志管理不同微服務(wù)部署在不同節(jié)點(diǎn)上，登錄每個(gè)節(jié)點(diǎn)查看日志是比較麻煩的，同時(shí)對(duì)于需要矢聯(lián)多個(gè)微服務(wù)日志聯(lián)合查看分析的情況將更加麻煩。伴隨節(jié)點(diǎn)數(shù)量的增加，如果沒(méi)有合適的管理機(jī)制與工具，定位問(wèn)題、發(fā)現(xiàn)問(wèn)題的復(fù) 雜性將越來(lái)越大，將成指數(shù)級(jí)增長(zhǎng)，因此需要進(jìn)行統(tǒng)一日志管理。Iog4j 或 BlitZ4j1、建立統(tǒng)一的日志管理規(guī)范；2、開(kāi)發(fā)并使用統(tǒng)一的日志組

21、件，為所有微服務(wù)提供統(tǒng)一的日志服務(wù)，由封裝；3、在每個(gè)服務(wù)節(jié)點(diǎn)上部署日志采集Agent組件，由此Agent進(jìn)行日志的采集與轉(zhuǎn)發(fā)； 4、建立統(tǒng)一的日志中心，所有日志寫(xiě)入日志中心。說(shuō)明：上述日志的實(shí)現(xiàn)由公司的“日志管理平臺(tái)”進(jìn)行實(shí)現(xiàn)，采用的是ELK集合框架。64統(tǒng)一監(jiān)控管理使用HyStriX組件進(jìn)行服務(wù)的監(jiān)控，使用NagioS進(jìn)行服務(wù)器等資源的監(jiān)控。1、 HyStriX，監(jiān)控和斷路器。我們只需要在服務(wù)接口上添加HyStriX標(biāo)簽，就可以實(shí)現(xiàn)對(duì)這個(gè) 接口的監(jiān)控和斷路器功能。2、HyStriX DaShbOard，監(jiān)控面板，他提供了一個(gè)界面，可以監(jiān)控各個(gè)服務(wù)上的服務(wù)調(diào)用所消耗的時(shí)間 等。3、TUrbi

22、ne,監(jiān)控聚合，使用 HyStriX監(jiān)控，我們需要打開(kāi)每一個(gè)服務(wù)實(shí)例的監(jiān)控信息來(lái)查看。而 TUrbine可以幫助我們把所有的服務(wù)實(shí)例的監(jiān)控信息聚合到一個(gè)地方統(tǒng)一查看。這樣就不需要挨個(gè)打開(kāi)一個(gè)個(gè)的頁(yè)面一個(gè)個(gè)查看。SPri ng65統(tǒng)一配置管理實(shí)現(xiàn)各微服務(wù)的統(tǒng)一參數(shù)配置以及版本管理，可采用公司的配置管理平臺(tái)或者Cloud Config配置中心。SPri ng Cloud Config 配置中心CnenT ACllerl bClient C(t_Config Server Remcxe Git repositorySPri ng Cloud Co nfig就是我們通常意義上的配置中心。SPring

23、Cloud Con fig- 把應(yīng)用原本放在本地文件的配置抽取出來(lái)放在中心服務(wù)器，本質(zhì)是配置信息從本地遷移到云端從而能夠提供更好的管理、發(fā)布能力。SPring Cloud Config分服務(wù)端和客戶端，服務(wù)端負(fù)責(zé)將git ( SVn)中存儲(chǔ)的配置文件發(fā)布成REST 接口，客戶端可以從服務(wù)端REST接口獲取配置。但客戶端并不能主動(dòng)感知到配置的變化，從而主動(dòng)去獲取新的配 置，這需要每個(gè)客戶端通過(guò)POST方法觸發(fā)各自的/refresh 。為解決配置信息能及時(shí)通知到各服務(wù)，同時(shí)減少每個(gè)微服務(wù)處理配置信息更新的復(fù)雜度，為此我們通過(guò)消息總線來(lái)解決此問(wèn)題，方案如下：Serwice A 21. Git 倉(cāng)庫(kù)、

24、Config SerVer、以及微服務(wù)SerViCe A ”、SerViCe B的實(shí)例中都RabbitMQ的消息總線上。弓I入了 SPring Cloud BUS，所以他們都連接到了 2.從Git倉(cāng)庫(kù)中配置的修改到發(fā)起/buSefresh的PoST請(qǐng)求這一步可以通過(guò)Git倉(cāng)庫(kù)的Web Hook來(lái)自動(dòng)觸發(fā)。3. /bus/refresh 請(qǐng)求不再發(fā)送到具體服務(wù)實(shí)例上，而是發(fā)送給Config SerVer ,并通過(guò)dest in ati On參數(shù)來(lái)指定需要更新配置的服務(wù)或?qū)嵗?. 由于所有連接到消息總線上的應(yīng)用都會(huì)接受到更新請(qǐng)求，所以在WebHook中就不需要維護(hù)所有節(jié)點(diǎn)內(nèi)容來(lái)進(jìn)行更新，從而解決

25、了通過(guò)Web Hook來(lái)逐個(gè)進(jìn)行刷新的問(wèn)題。66分布式SeSSiOn采用RediS作為緩存組件以及SeSSiOn的共享組件。%?Flji%T7SDK Rr1MiCOSerViCelNilgQSIfrFHic1 1 WgSeryi | ceFA |6.7. REST資源響應(yīng)結(jié)構(gòu)制定規(guī)范和解析方法。6.8. API調(diào)用鏈追蹤微服務(wù)架構(gòu)上通過(guò)業(yè)務(wù)來(lái)劃分服務(wù)的，通過(guò)REST調(diào)用，對(duì)外暴露的一個(gè)接口，可能需要很多個(gè)服務(wù)協(xié)同才能完成這個(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ù)雜。SPring Cloud SleUth主要

26、功能就是在分布式系統(tǒng)中提供追蹤解決方案并且兼容支持了你只需要在ziPkin，Pom文件中引入相應(yīng)的依賴即可。Slln UirW20V11 31%Wrzt *DW%ndff | ctHZvpRk) rivafitigote wyscom oBhvwcor Ed aDe|enddnclttDyraMQrt;Q DtOhr QCremv%( MlT%HJ SMMi； QS22 久 T%33.C42f%5S.D7%*%5%=%s%DHh-s Fit%、4C | .A%fibB CIIJ hcn,E1n%KE69單元測(cè)試做微服務(wù)架構(gòu)，進(jìn)行系統(tǒng)測(cè)試的復(fù)雜度較大，為保證產(chǎn)品質(zhì)量與開(kāi)發(fā)測(cè)試效率，單元 測(cè)試是必

27、不可少的。可采用MoCk方式進(jìn)行測(cè)試模擬，由持續(xù)集成進(jìn)行自動(dòng)化單元測(cè)試的執(zhí)行以及結(jié)果輸出。6.10. 代碼調(diào)試對(duì)于單體架構(gòu)系統(tǒng)，可直接本地化調(diào)試，但對(duì)于微服務(wù)架構(gòu)，接口間的調(diào)用需采用遠(yuǎn)程 通訊的方式，也就是 說(shuō)被調(diào)用的服務(wù)必須啟動(dòng)后方可被調(diào)用，因此當(dāng)微服務(wù)增多時(shí)，你可能需要啟動(dòng)大量的微服務(wù)或者Web服務(wù)器，這給本地化調(diào)用與調(diào)試帶來(lái)了困難。解決方案待研究。兀測(cè)試二皐元鹹BacwgUser Stoy1 tt 竦充5 代說(shuō)評(píng) 審和豪構(gòu)7.1. 自動(dòng)化測(cè)試單元測(cè)試：由開(kāi)發(fā)人員實(shí)現(xiàn)。采用MoCk方式進(jìn)行測(cè)試模擬，由持續(xù)集成進(jìn)行自動(dòng)化單元測(cè)試的執(zhí)行以及結(jié)果輸出。業(yè)務(wù)測(cè)試：開(kāi)發(fā)進(jìn)行實(shí)現(xiàn)，測(cè)試也需考慮如何實(shí)現(xiàn)。將多個(gè)服務(wù)或業(yè)務(wù)單元進(jìn)行串聯(lián)，測(cè)試一個(gè)完整的業(yè)務(wù)，甚至是不同業(yè)務(wù)之間組成的系統(tǒng)測(cè)試，需要采用相矢的自動(dòng)化測(cè)試框架執(zhí)行/如RobotFrameWork自動(dòng)化測(cè)試框架。%干專(zhuān)冷ir sx72依賴測(cè)試也可以稱(chēng)為接口測(cè)試或者契約測(cè)試，在微服務(wù)逐漸增多的情況下，如何有效保證服務(wù)之間能夠按照接的約定正常工作，即符合契約，成為微服務(wù)實(shí)施過(guò)程中，測(cè)試面臨的主要挑 戰(zhàn)。、開(kāi)發(fā)自動(dòng)化的接測(cè)試工具，1檢測(cè)接是否滿足約定2、檢測(cè)接是否發(fā)生變化3、檢測(cè)接是否可以正常被調(diào)用。二、測(cè)試方法