最新基于SringCloud微服務(wù)系統(tǒng)設(shè)計(jì)方案精選版整理版

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

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

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

4、的.Drkr li r r Spri nCloud Dubbin RnbhHMg ZDn4i«m-p»r Jhvnkim MvviMni 3rnifl* SVNi MonHor Serrar CpnCheck rindBuqps-TnstNia Junit M9ck JmAMir lQadflHFRunri4>r Maaicv Splujift T.SP SR P電:wtl "加 開我 w 實(shí)現(xiàn)微效勞技術(shù)架構(gòu),現(xiàn)有產(chǎn)品需要進(jìn)行技術(shù)上的改進(jìn)以及相關(guān)配套效勞的實(shí)現(xiàn),采用分階段實(shí)施、以及試點(diǎn)產(chǎn)品優(yōu)先實(shí)施的策略,主要包括如下：一、技術(shù)上的改進(jìn)： 1、前后端別離,we

5、b前端通過 / s協(xié)議調(diào)用微效勞的 API網(wǎng)關(guān),由API網(wǎng)關(guān)再 經(jīng)過路由效勞調(diào)用相應(yīng)的微效勞2、不同微效勞之間通過 REST方式互相調(diào)用3、微效勞之間通過消息中間件實(shí)現(xiàn)消息交互機(jī)制 二、配套效勞與功能實(shí)現(xiàn)：1、需要進(jìn)行相應(yīng)的自動(dòng)化效勞實(shí)現(xiàn),包括自動(dòng)化構(gòu)建、自動(dòng)化安裝部署、自動(dòng)化測(cè)試、自動(dòng)化平臺(tái)發(fā)布Docker實(shí)現(xiàn)2、治理效勞,對(duì)于微效勞架構(gòu),必須配套相應(yīng)的監(jiān)控與治理效勞、日志治理效勞等3、協(xié)作效勞,運(yùn)用 DevOps思想提升開發(fā)、測(cè)試、運(yùn)維的高效溝通與協(xié)作,實(shí)現(xiàn)開發(fā) 與運(yùn)維的一體化4.2,微效勞架構(gòu)設(shè)計(jì)SpringGoudEureka ServerWEBU1NoSuQgrrRW'Rib

6、bonFeignWtrixMkroServicf?Ftiyn ClientDdidbSpring CJcudCuniig Sei wiUldlRppnDatab ase 1Us els kolfsRabbjlTdq KaficaAccess匚 rintml1產(chǎn) iSate'ayZMUl Proxy1、我們把整個(gè)系統(tǒng)根據(jù)業(yè)務(wù)拆分成假設(shè)干個(gè)子系統(tǒng)或微效勞.2、每個(gè)子系統(tǒng)可以部署多個(gè)應(yīng)用,多個(gè)應(yīng)用之間使用負(fù)載均衡.3、需要一個(gè)效勞注冊(cè)中央Eureka ,所有的效勞都在注冊(cè)中央注冊(cè),負(fù)載均衡也是通過在注冊(cè)中央注冊(cè)的效勞來使用一定策略來實(shí)現(xiàn).Eureka可部署多個(gè),進(jìn)行高可用保證.4、所有的客戶

7、端都通過同一個(gè)網(wǎng)關(guān)地址訪問后臺(tái)的效勞,通過路由配置 ZUUL網(wǎng)關(guān) 來判斷一個(gè)URL請(qǐng)求由哪個(gè)效勞處理.請(qǐng)求轉(zhuǎn)發(fā)到效勞上的時(shí)候使用負(fù)載均衡Ribbon .5、效勞之間采用feign進(jìn)行調(diào)用.6、使用斷路器hystrix ,及時(shí)處理效勞調(diào)用時(shí)的超時(shí)和錯(cuò)誤,預(yù)防由于其中一個(gè)效勞 的問題而導(dǎo)致整體系統(tǒng)的癱瘓.7、還需要一個(gè)監(jiān)控功能,監(jiān)控每個(gè)效勞調(diào)用花費(fèi)的時(shí)間等.8、使用SpringCloud Config 進(jìn)行統(tǒng)一的配置治理,需要考慮與公司的配置治理平臺(tái) 如何配合使用.9、Hystrix ,監(jiān)控和斷路器.我們只需要在效勞接口上添加Hystrix標(biāo)簽,就可以實(shí)現(xiàn)對(duì)這個(gè)接口的監(jiān)控和斷路器功能.10、Hys

8、trix Dashboard ,監(jiān)控面板,他提供了一個(gè)界面,可以監(jiān)控各個(gè)效勞上的效勞 調(diào)用所消耗的時(shí)間等.11、Turbine ,監(jiān)控聚合,使用 Hystrix監(jiān)控,我們需要翻開每一個(gè)效勞實(shí)例的監(jiān)控信 息來查看.而Turbine可以幫助我們把所有的效勞實(shí)例的監(jiān)控信息聚合到一個(gè)地方統(tǒng)一查看. 這樣就不需要挨個(gè)翻開一個(gè)個(gè)的頁面一個(gè)個(gè)查看.架構(gòu)的可靠性保證：在關(guān)鍵節(jié)點(diǎn)做主備、集群部署,預(yù)防單點(diǎn)故障.待后續(xù)確認(rèn)問題：1、Access Control : Zuul網(wǎng)關(guān)提供了相關(guān)限制功能,與我司 CAS如何結(jié)合使用2、Config Server : Spring Cloud 提供了遠(yuǎn)程配置中央,與我司的配

9、置治理平臺(tái)如何結(jié) 合使用5.設(shè)計(jì)階段5.1. 總體設(shè)計(jì)1、功能規(guī)劃：對(duì)產(chǎn)品功能進(jìn)行拆分,拆分為假設(shè)干個(gè)微效勞；一個(gè)功能可以創(chuàng)立多個(gè)微 效勞并部署在多個(gè)效勞器節(jié)點(diǎn)上,以便進(jìn)行負(fù)載均衡.2、設(shè)計(jì)原子效勞層,梳理和抽取核心應(yīng)用、公共應(yīng)用,作為獨(dú)立的效勞下沉到核心和 公共水平層,逐漸形成穩(wěn)定的效勞中央,使應(yīng)用能更快速的響應(yīng)多變的客戶需求.3、為每個(gè)效勞設(shè)計(jì)API接口REST方式4、為不同的 效勞進(jìn)行分類,不同類型的效勞需要的資源不同,可以配置不同的資源, 包才CPU、內(nèi)存、存儲(chǔ)等.5.2. 效勞拆分原那么1、粒度微?。焊鶕?jù)業(yè)務(wù)功能劃分效勞粒度,總的原那么是效勞內(nèi)部高內(nèi)聚,效勞之間低耦合.2、責(zé)任單一：

10、每個(gè)效勞只做一件事,即單一責(zé)任原那么.3、隔離性原那么：每個(gè)效勞相互隔離,且不互相影響4、業(yè)務(wù)無關(guān)優(yōu)先原那么：根底效勞,是一些根底組件,與具體的業(yè)務(wù)無關(guān).比方：短信效勞、郵件效勞.這 里的效勞最容易劃分出來做微效勞,也是我們第一優(yōu)先級(jí)別離出來的效勞.5.3. 效勞規(guī)劃為實(shí)現(xiàn)負(fù)載均衡,允許相同的效勞在多個(gè)節(jié)點(diǎn)注冊(cè)相同的效勞名,不同的端口.如果沒有前期的規(guī)劃,不同的效勞提供者可能會(huì)注冊(cè)相同的效勞名,導(dǎo)致消費(fèi)者調(diào)用效勞時(shí)產(chǎn)生調(diào)用混亂.因此,需進(jìn)行效勞名的統(tǒng)一規(guī)劃：1、規(guī)劃期統(tǒng)一制定每個(gè)效勞提供者的效勞名或者模塊標(biāo)示.2、效勞名的命名規(guī)那么 :ModuleName_ServiceName ,且所有字符

11、小寫,不同單詞之間以下劃線分隔.如用戶治理模塊提供了獲取用戶信息的效勞,那么命名為：user_get_info .3、新增效勞名時(shí),需要提出申請(qǐng),審批通過前方可使用,為減少審批復(fù)雜度,可只審批ModuleName ,即在模塊內(nèi)部可以自由增加效勞名,不需要進(jìn)行審批.5.4. 開發(fā)策略總體原那么：不同的微效勞需進(jìn)行物理隔離.1、SVN策略：SVN上創(chuàng)立獨(dú)立的分支,不同微效勞的代碼提交不受相互影響；一由配置治理員統(tǒng)一限制.問題：開發(fā)分支與集成分支,都將增加很多,維護(hù)工作量增加.2、編譯策略：代碼編譯時(shí),各個(gè)微效勞獨(dú)立編譯、打包,杜絕直接的依賴；3、工程構(gòu)建：代碼開發(fā)時(shí),各微效勞創(chuàng)立獨(dú)立的工程,工程之

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

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

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

15、以庫的方式集成到效勞消費(fèi)方的進(jìn)程內(nèi),這種方案稱為 軟負(fù)載均衡(Soft Load Balancing )或者客戶端負(fù)載均衡. 在Spring Cloud 中配合Eureka的效勞注冊(cè) 功能,Ribbon子工程那么為REST客戶端實(shí)現(xiàn)了負(fù)載均衡.CUfWTFEIGNWR NG CLOUD!CONFIG !AUTH SERVICE ；CUACKAAPI GATEWAYHU ULHYSTRIJC :HYSTWX :HYSTRIKIBlbvMCMHOKDMn BOARD : 1TURBINE使用Ribbon進(jìn)行負(fù)載均衡,其工作原理可以概括為下面四個(gè)步驟:1. Ribbon首先根據(jù)其所在Zone優(yōu)先選擇

16、一個(gè)負(fù)載較少的Eureka Server;2,定期從Eureka Server更新并過濾效勞實(shí)例列表 ；3.根據(jù)指定的負(fù)載均衡策略,從可用的效勞器列表中選擇一個(gè)效勞實(shí)例的地址；4,然后通過RestClient進(jìn)行效勞調(diào)用.Ribbon本身提供了下面幾種負(fù)載均衡策略： RoundRobinRule:輪詢策略,Ribbon以輪詢的方式選擇效勞器,這個(gè)是默認(rèn)值.所以例如中所啟動(dòng)的兩個(gè)效勞會(huì)被循環(huán)訪問； RandomRule: 隨機(jī)選擇,也就是說 Ribbon會(huì)隨機(jī)從效勞器列表中選擇一個(gè)進(jìn)行訪問； BestAvailableRule:最大可用策略,即先過濾出故障效勞器后,選擇一個(gè)當(dāng)前并發(fā)請(qǐng)求數(shù)最小的；

17、 WeightedResponseTimeRule:帶有加權(quán)的輪詢策略,對(duì)各個(gè)效勞器響應(yīng)時(shí)間進(jìn)行加權(quán)處理,然后在采用輪詢的方式來獲取相應(yīng)的效勞器； AvailabilityFilteringRule:可用過濾策略,先過濾出故障的或并發(fā)請(qǐng)求大于閾值一局部服務(wù)實(shí)例,然后再以線性輪詢的方式從過濾后的實(shí)例清單中選出一個(gè)； ZoneAvoidanceRule:區(qū)域感知策略,先使用主過濾條件區(qū)域負(fù)載器,選擇最優(yōu)區(qū)域?qū)λ袑?shí)例過濾并返回過濾后的實(shí)例清單,依次使用次過濾條件列表中的過濾條件對(duì)主過濾條件的結(jié)果進(jìn)行過濾,判斷最小過濾數(shù)默認(rèn) 1和最小過濾百分比默認(rèn) 0,最 后對(duì)滿足條件的效勞器那么使用RoundRo

18、binRule輪詢方式選擇一個(gè)效勞器實(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ù)治理策略微效勞的架構(gòu)理念中指出各微效勞可以獨(dú)立建設(shè),可以使用不同的技術(shù)、語言、框架等,以便能更快速的使用新技術(shù)、新框架等響應(yīng)特定客戶需求,解決單體應(yīng)用架構(gòu)更新技術(shù)、更 新框架時(shí)面臨的困難或阻礙.但這也同時(shí)帶來了諸多問題,如下：1、各效勞是否可以任意使用自己的技術(shù)、自己的組件、框架呢如果這樣,勢(shì)必帶來 更大的治理困難、維護(hù)困難、技術(shù)共享困難.2、公共的方法如何實(shí)現(xiàn)共享如格式化時(shí)間的一個(gè)簡(jiǎn)

19、單方法需要共享,也需要封裝為一個(gè)效勞接口嗎治理策略：1、總體原那么：仍然需要進(jìn)行統(tǒng)籌考慮,所有組件統(tǒng)一治理,組件放置在產(chǎn)品倉庫中,每個(gè)產(chǎn)品或效勞需要共享組件時(shí),從產(chǎn)品倉庫獲取.打好恃擰,看14上眄寸為盧應(yīng)濟(jì)后產(chǎn)品百后e庫打擊產(chǎn)昂由店用K ,盧品廢需出快小i1t品、專時(shí),由M戶購冢,靈JS旭裝自己的點(diǎn)品2、特殊情況：特殊效勞需要使用特殊的組件、框架,需提出申請(qǐng),統(tǒng)籌規(guī)劃后進(jìn)行決 策.6.開發(fā)階段6.1. 效勞的調(diào)用6.1.1. AIP網(wǎng)關(guān)調(diào)用所有效勞通過Zuul網(wǎng)關(guān)進(jìn)行調(diào)用,不允許直接調(diào)用微效勞提供者.Zuul可能會(huì)成為系統(tǒng)瓶頸,在工程復(fù)雜時(shí)可考慮為Zuul進(jìn)行主備或負(fù)載均衡處理.Zuul代理機(jī)

20、制嵋客戶端Euul代理iMMiui野鳥RPC施端(Spring8口ot)3rnpay用痛眼珈 86所何津川路也跳那么RPC后端 lSpringCloud)* MyBatls MyBatls* MyBsHs數(shù)據(jù)iJ.6.1.2. 同步調(diào)用采用 REST方式進(jìn)行調(diào)用,針對(duì)業(yè)務(wù)需求可以進(jìn)行負(fù)載均衡,負(fù)載均衡的調(diào)用方式有兩種：1、FeignClient2、RestTemplate建議使用FeignClient方式進(jìn)行效勞調(diào)用.不管是什么方式,他都是通過REST接口調(diào)用效勞的 接口,參數(shù)和結(jié)果默認(rèn)都是通過Jackson序列化和反序列化.由于Spring MVC的RestController定義的接口,返

21、回的數(shù)據(jù)都是通過Jackson序列化成JSON數(shù)據(jù).flir-eka6.1.3. 異步調(diào)用rabbitMq、kafka、Spring Cloud Stream均是可以選擇的方案. Spring Cloud Stream ,基于 Redis、Rabbit、Kafka實(shí)現(xiàn)的消息微效勞,簡(jiǎn)單聲明模型用 以在Spring Cloud 應(yīng)用中收發(fā)消息.6.1.4. 效勞間調(diào)用的權(quán)限驗(yàn)證一般我們的API接口都需要某種授權(quán)才能訪問,登陸成功以后,然后通過token或者cookie等方式才能調(diào)用接口.使用Spring Cloud Netfix 框架的話,登錄的時(shí)候,把登錄請(qǐng)求轉(zhuǎn)發(fā)到相應(yīng)的用戶效勞上, 登陸成功

22、后,會(huì)設(shè)置 cookie或header token等.然后客戶端接下來的請(qǐng)求就會(huì)帶著這些驗(yàn) 證信息,從Zuul網(wǎng)關(guān)傳到相應(yīng)的效勞上進(jìn)行驗(yàn)證.Zuul網(wǎng)關(guān)在把請(qǐng)求轉(zhuǎn)發(fā)到后臺(tái)的效勞的時(shí)候,會(huì)默認(rèn)把一些header傳到效勞端,如：Cookie、Set-Cookie、Authorization .這樣,客戶端t#求的相關(guān)headers就可以傳遞到效勞端,效勞端設(shè)置的 cookie也可以傳到客戶端.但是,如果你想禁止某些header透?jìng)鞯叫诙?可以在 Zuul網(wǎng)關(guān)的application.yml配置里通過下面的方式禁用：zuul:routes:users:path: /users/*sensitive

23、Headers: Cookie,Set-Cookie,Authorizationserviceld: user剛剛說了我們的某個(gè)效勞有時(shí)候需要調(diào)用另一個(gè)效勞,這時(shí)候,這個(gè)請(qǐng)求不是客戶端發(fā)起,他的請(qǐng)求的header里面也不會(huì)有任何驗(yàn)證信息.這時(shí)候,要么,通過防火墻等設(shè)置,保證效勞間調(diào)用的接口,只能某幾個(gè)地址訪問；要么,就通過某種方式 設(shè)置 header.同時(shí),如果你想在某個(gè)效勞里面獲得這個(gè)請(qǐng)求的真是IP,(由于請(qǐng)求的通過網(wǎng)關(guān)轉(zhuǎn)發(fā)而來,你直接通過request獲彳# ip得到的是網(wǎng)關(guān)的IP),就可以從headerX-Forwarded-Host 獲得.如果想禁用這個(gè) header ,也可以：zuu

24、l.addProxyHeaders = false如果你使用RestTemplate的方式調(diào)用,可以在請(qǐng)求里面添加一個(gè)有 header的Options.也可以通過如下的攔截器的方式設(shè)置,它對(duì)RestTemplate方式和FeignClient的方式都可以起作用：Beanpublic RequestInterceptor requestInterceptor() return new RequestInterceptor() Overridepublic void apply(RequestTemplate template) String authToken = getToken();temp

25、late.header(AUTH_TOKEN_HEADER, authToken););)6.1.5. 效勞編排主要的作用是減少工程中的相互依賴.比方現(xiàn)在有工程a調(diào)用工程b,工程b調(diào)用工程c.一直到h,是一個(gè)調(diào)用鏈,那么工程上線的時(shí)候需要先更新最底層的h再更新g.更新c更新b最后是更新工程a.這只是這一個(gè)調(diào)用鏈,在復(fù)雜的業(yè)務(wù)中有非常多的調(diào)用,如果要記住每一個(gè)調(diào)用鏈對(duì)開發(fā)運(yùn)維人員來說就是災(zāi)難.有這樣一個(gè)好方法可以盡量的減少工程的相互依賴,就是效勞編排,一個(gè)核心的業(yè)務(wù)處理項(xiàng)目,負(fù)責(zé)和各個(gè)微效勞打交道.比方之前是 a調(diào)用b, b掉用c, c調(diào)用d,現(xiàn)在統(tǒng)一在一個(gè)核心工程W中來處理,W效勞使用a的時(shí)候

26、去調(diào)用b,使用b的時(shí)候 W去調(diào)用co其實(shí)可以理解為面向?qū)ο蟮脑O(shè)計(jì),減少方法之間的一層層嵌套調(diào)用,而采取一個(gè)方法進(jìn)行業(yè)務(wù)流程的串聯(lián),如方法W實(shí)現(xiàn)一個(gè)完整的業(yè)務(wù)處理,那么采取下面方式：function w ()(1、調(diào)用方法a;2、調(diào)用方法b;3、調(diào)用方法c；)6.2. 效勞的熔斷處理在效勞之間進(jìn)行調(diào)用時(shí),由于各種原因會(huì)導(dǎo)致遠(yuǎn)程效勞不可用或壓力過載等異常導(dǎo)致的故障蔓延,此時(shí)需要有一種機(jī)制進(jìn)行保護(hù)處理.Spring Cloud通過Netflix的Hystrix組件實(shí)現(xiàn)熔斷和降級(jí)處理解決此問題.斷路器 Cricuit Breaker是一種能夠在遠(yuǎn)程效勞不可用時(shí)自動(dòng)熔斷翻開開關(guān),并在遠(yuǎn)程效勞恢復(fù)時(shí)自動(dòng)恢

27、復(fù)閉合開關(guān)的設(shè)施,Spring Cloud通過Netflix的Hystrix組件提供斷路器、資源隔離與自我修復(fù)功能.Spring cloud Hystrix 熔斷器opentryone requestlast 旬ingfallopn circuitcIom circuitClrcuK Breaker Stito PtsqramHystrix熔斷處理i.博城勝的:2.帆網(wǎng),曲3,點(diǎn)穌辨機(jī),6.3. 統(tǒng)一日志治理不同微效勞部署在不同節(jié)點(diǎn)上,登錄每個(gè)節(jié)點(diǎn)查看日志是比較麻煩的,同時(shí)對(duì)于需要關(guān)聯(lián)多個(gè)微效勞日志聯(lián)合查看分析的情況將更加麻煩.伴隨節(jié)點(diǎn)數(shù)量的增加,如果沒有適宜的治理機(jī)制與工具,定位問題、發(fā)現(xiàn)問

28、題的復(fù)雜性將越來越大,將成指數(shù)級(jí)增長(zhǎng),因此需要進(jìn)行統(tǒng)一日志治理.1、建立統(tǒng)一的日志治理標(biāo)準(zhǔn)；2、開發(fā)并使用統(tǒng)一的日志組件,為所有微效勞提供統(tǒng)一的日志效勞,由log4j或Blitz4j封裝；3、在每個(gè)效勞節(jié)點(diǎn)上部署日志采集Agent組件,由此Agent進(jìn)行日志的采集與轉(zhuǎn)發(fā)；4、建立統(tǒng)一的日志中央,所有日志寫入日志中央.說明：上述日志的實(shí)現(xiàn)由公司的“日志治理平臺(tái)進(jìn)行實(shí)現(xiàn),采用的是ELK集合框架.tlastic SearchKibahaA 配瘋ClusterServer6.4. 統(tǒng)一監(jiān)控治理使用Hystrix組件進(jìn)行效勞的監(jiān)控,使用 Nagios進(jìn)行效勞器等資源的監(jiān)控.1、Hystrix ,監(jiān)控和斷

29、路器.我們只需要在效勞接口上添加Hystrix標(biāo)簽,就可以實(shí)現(xiàn)對(duì)這個(gè)接口的監(jiān)控和斷路器功能.2、Hystrix Dashboard ,監(jiān)控面板,他提供了一個(gè)界面,可以監(jiān)控各個(gè)效勞上的效勞調(diào)用所消耗的時(shí)間等.3、Turbine ,監(jiān)控聚合,使用Hystrix監(jiān)控,我們需要翻開每一個(gè)效勞實(shí)例的監(jiān)控信息來查看.而Turbine可以幫助我們把所有的效勞實(shí)例的監(jiān)控信息聚合到一個(gè)地方統(tǒng)一查看.這樣就不需要挨個(gè)翻開一個(gè)個(gè)的頁面一個(gè)個(gè)查看.6.5. 統(tǒng)一配置治理實(shí)現(xiàn)各微效勞的統(tǒng)一參數(shù)配置以及版本治理,可采用公司的配置治理平臺(tái)或者SpringCloud Config 配置中央.Spring Cloud Conf

30、ig配置中央Spring Cloud Config 就是我們通常意義上的配置中央.Spring Cloud Config- 把應(yīng)用原本放在本地文件的配置抽取出來放在中央效勞器,本質(zhì)是配置信息從本地遷移到云端.從而能夠提供更好的治理、發(fā)布水平.Spring Cloud Config分效勞端和客戶端, 效勞端負(fù)責(zé)將git (svn)中存儲(chǔ)的配置文件 發(fā)布成REST接口,客戶端可以從效勞端 REST接口獲取配置.但 客戶端并不能主動(dòng)感知 到配置的變化,從而主動(dòng)去獲取新的配置,這需要 每個(gè)客戶端通過 POST方法觸發(fā)各自的 /refresh .為解決配置信息能及時(shí)通知到各效勞,同時(shí)減少每個(gè)微效勞處理配

31、置信息更新的復(fù)雜度,為此我們通過消息總線來解決此問題,方案如下:1. Git 倉庫、Config Server、以及微效勞 “Service A "、 aService B 的實(shí)例中都引 入了 Spring Cloud Bus ,所以他們都連接到了RabbitMQ 的消息總線上.2 .從Git倉庫中配置的修改到發(fā)起 /bus/refresh的POST請(qǐng)求這一步可以通過 Git倉庫的 Web Hook來自動(dòng)觸發(fā).3 . /bus/refresh請(qǐng)求不再發(fā)送到具體效勞實(shí)例上,而是發(fā)送給 Config Server ,并通過 destination參數(shù)來指定需要更新配置的效勞或?qū)嵗?4 .

32、由于所有連接到消息總線上的應(yīng)用都會(huì)接受到更新請(qǐng)求,所以在 Web Hook中就不需 要維護(hù)所有節(jié)點(diǎn)內(nèi)容來進(jìn)行更新,從而解決了通過Web Hook來逐個(gè)進(jìn)行刷新的問題.6.6. 分布式 session采用Redis作為緩存組件以及session的共享組件.6.7. REST資源響應(yīng)結(jié)構(gòu)制定標(biāo)準(zhǔn)和解析方法.6.8. API調(diào)用鏈追蹤微效勞架構(gòu)上通過業(yè)務(wù)來劃分效勞的,通過REST調(diào)用,對(duì)外暴露的一個(gè)接口,可能需要很多個(gè)效勞協(xié)同才能完成這個(gè)接口功能,如果鏈路上任何一個(gè)效勞出現(xiàn)問題或者網(wǎng)絡(luò)超時(shí),都會(huì)形成導(dǎo)致接口調(diào)用失敗.隨著業(yè)務(wù)的不斷擴(kuò)張,效勞之間互相調(diào)用會(huì)越來越復(fù)雜.Spring Cloud Sleu

33、th主要功能就是在分布式系統(tǒng)中提供追蹤解決方案,并且兼容支持了zipkin ,你只需要在pom文件中引入相應(yīng)的依賴即可9urt iim«mtEndWTW11 MEl看日;事-ZigKifiiJt -ftiwnziwi tllccMiT#iw.oom" .urttiOrtz5«pe»z D*lh：.EEiK!：11 b4r«22S»E 白55D7t通saxm-E: nrpy6.9. 單元測(cè)試做微效勞架構(gòu),進(jìn)行系統(tǒng)測(cè)試的復(fù)雜度較大,為保證產(chǎn)品質(zhì)量與開發(fā)、測(cè)試效率,單元 測(cè)試是必不可少的.可采用Mock方式進(jìn)行測(cè)試模擬,由持續(xù)集成進(jìn)行自動(dòng)化

34、單元測(cè)試的執(zhí)行以及結(jié)果輸出.6.10. 代碼調(diào)試對(duì)于單體架構(gòu)系統(tǒng), 可直接本地化調(diào)試,但對(duì)于微效勞架構(gòu), 接口間的調(diào)用需采用遠(yuǎn)程通訊的方式,也就是說被調(diào)用的效勞必須啟動(dòng)前方可被調(diào)用,因此當(dāng)微效勞增多時(shí),你可能需要啟動(dòng)大量的微效勞或者 web效勞器,這給本地化調(diào)用與調(diào)試帶來了困難.解決方案待研究.7 .測(cè)試3.甲國(guó)費(fèi)諾渺評(píng)1重*融7.1. 自動(dòng)化測(cè)試單元測(cè)試：由開發(fā)人員實(shí)現(xiàn).采用Mock方式進(jìn)行測(cè)試模擬,由持續(xù)集成進(jìn)行自動(dòng)化單元測(cè)試的執(zhí)行以及結(jié)果輸出.業(yè)務(wù)測(cè)試: 開發(fā)進(jìn)行實(shí)現(xiàn),測(cè)試也需考慮如何實(shí)現(xiàn).將多個(gè)效勞或業(yè)務(wù)單元進(jìn)行串聯(lián),測(cè)試一個(gè)完整的業(yè)務(wù),甚至是不同業(yè)務(wù)之間組成的系統(tǒng)測(cè)試,需要采用相關(guān)的自動(dòng)化測(cè)試框架執(zhí)行,如RobotFramework自動(dòng)化測(cè)試框架.愜m. w主干招Tg應(yīng)7.2. 依賴測(cè)試也可以稱為接口測(cè)試或者契約測(cè)試, 在微效勞逐漸增多的情況下, 如何有效保證效勞之 間能夠根據(jù)接口的約定正常工作, 即符合契