微服務(wù)系統(tǒng)和數(shù)據(jù)庫設(shè)計(jì)方案

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

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

3、性強(qiáng)：服務(wù)依賴、多版本問題? 性能（服務(wù)間通訊成本高）： 無狀態(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)中，通常會考慮通過數(shù)據(jù)的最終一致性來 解決數(shù)據(jù)瞬時(shí)一致帶來的系統(tǒng)不可用。? 重復(fù)開發(fā)：微服務(wù)理念崇尚每個(gè)微服務(wù)作為一個(gè)產(chǎn)品看待， 有自己的團(tuán)隊(duì)開發(fā)， 甚至可以有自 己完全不同的技術(shù)、 框架， 那么與其他微服務(wù)團(tuán)隊(duì)的技術(shù)共享就產(chǎn)生了矛盾， 重復(fù)開發(fā)的工作即產(chǎn)生了。4. 架構(gòu)設(shè)計(jì)4.1. 思維設(shè)計(jì)DevOps 理念方可微服務(wù)架構(gòu)設(shè)計(jì)的根本目的是實(shí)現(xiàn)價(jià)值交付，微服務(wù)架構(gòu)只有

4、遵循進(jìn)行的更順暢，思維方式的轉(zhuǎn)變是最重要的。Ooi kvi< ir*i|CiiJLKrf fki IjZDukwpv-r J«n4iini M<0 v adlw SVN MonfiteirSvruir GpdGlMek FmdflUq<£THT*«N& Jurril Mg.£k Jmrtwr 冊很st* Niwo® Splunk T5P SRP 宀&A實(shí)現(xiàn)微服務(wù)技術(shù)架構(gòu)，現(xiàn)有產(chǎn)品需要進(jìn)行技術(shù)上的改進(jìn)以及相關(guān)配套服務(wù)的實(shí)現(xiàn)，采用分階段實(shí)施、以及試點(diǎn)產(chǎn)品優(yōu)先實(shí)施的策略，主要包括如下：一、技術(shù)上的改進(jìn)：1、 前后端分

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

6、rekaZuulPnWFt4gnAjc««ContrrlUsers Ro leiWFB JIHvktlJAMicnnServicfslMicirtervicf?Feign ClientSpring Cloud Ccnfiu Sei verDe tab a seinA OCA FtfpcMHMBDdtabaze2架構(gòu)圖111flZM* 心dlest1仙砒F00T1UttMliyiJi kJLfrl玄叫井杰克日主耳臺'：4( *i£ . j_n ： .r sKlhann架構(gòu)圖 21 、我們把整個(gè)系統(tǒng)根據(jù)業(yè)務(wù)拆分成若干個(gè)子系統(tǒng)或微服務(wù)。2 、每個(gè)子系統(tǒng)可以部署多

7、個(gè)應(yīng)用，多個(gè)應(yīng)用之間使用負(fù)載均衡。3 、需要一個(gè)服務(wù)注冊中心 Eureka ，所有的服務(wù)都在注冊中心注冊，負(fù)載均衡也是 通過在注冊中心注冊的服務(wù)來使用一定策略來實(shí)現(xiàn)。 Eureka 可部署多個(gè)， 進(jìn)行高可用保證。4 、所有的客戶端都通過同一個(gè)網(wǎng)關(guān)地址訪問后臺的服務(wù)， 通過路由配置 ZUUL 網(wǎng)關(guān) 來判斷一個(gè) URL 請求由哪個(gè)服務(wù)處理。請求轉(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ù)的問題而導(dǎo)致整體系統(tǒng)的癱瘓。7 、還需要一個(gè)監(jiān)控功能，監(jiān)控每個(gè)服務(wù)調(diào)用花費(fèi)的時(shí)

8、間等。8、使用 SpringCloud Config進(jìn)行統(tǒng)一的配置管理，需要考慮與公司的配置管理平臺如何配合使用。9 、 Hystrix ，監(jiān)控和斷路器。我們只需要在服務(wù)接口上添加 Hystrix 標(biāo)簽，就可以實(shí) 現(xiàn)對這個(gè)接口的監(jiān)控和斷路器功能。10 、 Hystrix Dashboard ，監(jiān)控面板，他提供了一個(gè)界面，可以監(jiān)控各個(gè)服務(wù)上的 服務(wù)調(diào)用所消耗的時(shí)間等。11 、 Turbine ，監(jiān)控聚合，使用 Hystrix 監(jiān)控，我們需要打開每一個(gè)服務(wù)實(shí)例的監(jiān) 控信息來查看。而 Turbine 可以幫助我們把所有的服務(wù)實(shí)例的監(jiān)控信息聚合到一個(gè)地方統(tǒng) 一查看。這樣就不需要挨個(gè)打開一個(gè)個(gè)的頁面一個(gè)

9、個(gè)查看。架構(gòu)的可靠性保證：在關(guān)鍵節(jié)點(diǎn)做主備、集群部署，防止單點(diǎn)故障。 待后續(xù)確認(rèn)問題：1、Access Control ： Zuul 網(wǎng)關(guān)提供了相關(guān)控制功能，與我司 CAS 如何結(jié)合使用2 、Config Server ：Spring Cloud 提供了遠(yuǎn)程配置中心，與我司的配置管理平臺如何結(jié)合使用5. 設(shè)計(jì)階段5.1. 總體設(shè)計(jì)1、功能規(guī)劃：對產(chǎn)品功能進(jìn)行拆分，拆分為若干個(gè)微服務(wù)；一個(gè)功能可以創(chuàng)建多個(gè)微 服務(wù)并部署在多個(gè)服務(wù)器節(jié)點(diǎn)上，以便進(jìn)行負(fù)載均衡。2、設(shè)計(jì)原子服務(wù)層，梳理和抽取核心應(yīng)用、公共應(yīng)用，作為獨(dú)立的服務(wù)下沉到核心和 公共能力層，逐漸形成穩(wěn)定的服務(wù)中心，使應(yīng)用能更快速的響應(yīng)多變的客

10、戶需求。3 、為每個(gè)服務(wù)設(shè)計(jì) API 接口（ REST 方式）4、為不同的服務(wù)進(jìn)行分類，不同類型的服務(wù)需要的資源不同，可以配置不同的資源， 包括 CPU 、內(nèi)存、存儲等。5.2. 服務(wù)拆分原則1、粒度微小： 根據(jù)業(yè)務(wù)功能劃分服務(wù)粒度，總的原則是服務(wù)內(nèi)部高內(nèi)聚，服務(wù)之間低耦合。2、責(zé)任單一： 每個(gè)服務(wù)只做一件事，即單一職責(zé)原則。3、隔離性原則： 每個(gè)服務(wù)相互隔離，且不互相影響4、業(yè)務(wù)無關(guān)優(yōu)先原則：基礎(chǔ)服務(wù)，是一些基礎(chǔ)組件，與具體的業(yè)務(wù)無關(guān)。比如：短信服務(wù)、郵件服務(wù)。這 里的服務(wù)最容易劃分出來做微服務(wù)，也是我們第一優(yōu)先級分離出來的服務(wù)。5.3. 服務(wù)規(guī)劃如果沒導(dǎo)致消費(fèi)者調(diào)用服務(wù)時(shí)產(chǎn)生調(diào)為實(shí)現(xiàn)負(fù)載均

11、衡， 允許相同的服務(wù)在多個(gè)節(jié)點(diǎn)注冊相同的服務(wù)名， 不同的端口。有前期的規(guī)劃， 不同的服務(wù)提供者可能會注冊相同的服務(wù)名， 用混亂。因此，需進(jìn)行服務(wù)名的統(tǒng)一規(guī)劃：1、規(guī)劃期統(tǒng)一制定每個(gè)服務(wù)提供者的服務(wù)名或者模塊標(biāo)示。2 、服務(wù)名的命名規(guī)則 :ModuleName_ServiceName ，且所有字符小寫，不同單詞之 間以下劃線分隔。 如用戶管理模塊提供了獲取用戶信息的服務(wù)， 則命名為： user_get_info3、新增服務(wù)名時(shí)，需要提出申請，審批通過后方可使用，為減少審批復(fù)雜度，可只審 批 ModuleName ，即在模塊內(nèi)部可以自由增加服務(wù)名，不需要進(jìn)行審批。5.4. 開發(fā)策略總體原則：不同的

12、微服務(wù)需進(jìn)行物理隔離。1、SVN 策略： SVN 上創(chuàng)建獨(dú)立的分支，不同微服務(wù)的代碼提交不受相互影響；- 由配置管理員統(tǒng)一控制。 問題：開發(fā)分支與集成分支，都將增加很多，維護(hù)工作量增加。2、編譯策略：代碼編譯時(shí)，各個(gè)微服務(wù)獨(dú)立編譯、打包，杜絕直接的依賴；3、工程構(gòu)建：代碼開發(fā)時(shí)，各微服務(wù)創(chuàng)建獨(dú)立的工程，工程之間不能產(chǎn)生直接依賴4、持續(xù)集成：每個(gè)微服務(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ù)級增加。 在

13、服務(wù)之間依賴較多時(shí)， 每個(gè)服務(wù)的升級或降級都將影 響其他服務(wù)的正常運(yùn)行。因此需執(zhí)行如下策略：1、所有服務(wù)的版本制作交由專業(yè)的版本管理員執(zhí)行。2、采用自動(dòng)化的版本制作策略，最大程度的減少人工操作。3、每個(gè)服務(wù)的版本必須有詳細(xì)的版本計(jì)劃、版本說明，對于版本說明要制定模板，明 確需要提交的內(nèi)容、版本號、 SVN 標(biāo)簽等。4、對項(xiàng)目經(jīng)理的要求提升，需對整體的版本計(jì)劃有嚴(yán)格的制定，尤其是版本之間的依 賴關(guān)系要非常明確，版本升級、降級的風(fēng)險(xiǎn)評估需完全充分。5 、接口管理： 嚴(yán)格執(zhí)行接口管理制度， 任何接口的變更必須進(jìn)行審批、 發(fā)公告等流程。5.6. 數(shù)據(jù)庫挑戰(zhàn)與策略每個(gè)微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫， 那么后

14、臺管理的聯(lián)合查詢怎么處理？這應(yīng)該是大家 會普遍遇到的一個(gè)問題，有四種處理方案。1) 嚴(yán)格按照微服務(wù)的劃分來做，微服務(wù)相互獨(dú)立，各微服務(wù)數(shù)據(jù)庫也獨(dú)立，后臺需要 展示數(shù)據(jù)時(shí)， 調(diào)用各微服務(wù)的接口來獲取對應(yīng)的數(shù)據(jù)， 再進(jìn)行數(shù)據(jù)處理后展示出來， 這是標(biāo) 準(zhǔn)的用法，也是最麻煩的用法。2) 將業(yè)務(wù)高度相關(guān)的表放到一個(gè)庫中，將業(yè)務(wù)關(guān)系不是很緊密的表嚴(yán)格按照微服務(wù)模 式來拆分，這樣既可以使用微服務(wù)，也避免了數(shù)據(jù)庫分散導(dǎo)致后臺系統(tǒng)統(tǒng)計(jì)功能難以實(shí)現(xiàn)， 是一個(gè)折中的方案。3) MySQL+MHA 高可用架構(gòu) 、 MySQL 分布式 Proxy 水平擴(kuò)展架構(gòu)、 MySQL 緩 存高并發(fā)讀架構(gòu)、 MySQL 小文件系統(tǒng)

15、大字段存取架構(gòu)、 MySQL Inforbright/Greenplum 統(tǒng)計(jì)分析架構(gòu)。4) 數(shù)據(jù)庫嚴(yán)格按照微服務(wù)的要求來切分，以滿足業(yè)務(wù)高并發(fā)，實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)將各微 服務(wù)數(shù)據(jù)庫數(shù)據(jù)同步到 NoSQL 數(shù)據(jù)庫中， 在同步的過程中進(jìn)行數(shù)據(jù)清洗， 用來滿足后臺業(yè) 務(wù)系統(tǒng)的使用，推薦使用 MongoDB 、 HBase 等。第一種方案適合業(yè)務(wù)較為簡單的小公司； 第二種方案， 適合在原有系統(tǒng)之上， 慢慢演化 為微服務(wù)架構(gòu)的公司； 第三種適合大型高并發(fā)的互聯(lián)網(wǎng)公司； 第四種適合超大型擴(kuò)張能力強(qiáng) 高并發(fā)公司。建議，我們當(dāng)前采用第二種方案。5.7. 負(fù)載均衡不再采用一般的增加負(fù)載均衡服務(wù)器的方式進(jìn)行負(fù)載均衡

16、，如F5 、Nginx 、LVS 等，而是把負(fù)載均衡的功能以庫的方式集成到服務(wù)消費(fèi)方的進(jìn)程內(nèi)，這種方案稱為軟負(fù)載均衡 ( Soft Load Balancing )或者客戶端負(fù)載均衡。在 Spring Cloud 中配合 Eureka 的服務(wù) 注冊功能， Ribbon 子項(xiàng)目則為 REST 客戶端實(shí)現(xiàn)了負(fù)載均衡。CUEMT!JI.J . FE1CN ”WUHL LIJUU U j CDNFK :；Al/TH SERVICEi mii1D&COVtRlf!IlEHJRIKA1 «!1ViARCATEWfAYZi&JUILHVSTHIX *:HVSTWX ；:HtSTPU

17、XHI.» MMkTOR : i DUHSOARD I: ；!TUSBIM 匚使用Ribbon進(jìn)行負(fù)載均衡，其工作原理可以概括為下面四個(gè)步驟:1. Ribbon首先根據(jù)其所在 Zone優(yōu)先選擇一個(gè)負(fù)載較少的Eureka Server;2. 定期從Eureka Server更新并過濾服務(wù)實(shí)例列表；3. 根據(jù)指定的負(fù)載均衡策略，從可用的服務(wù)器列表中選擇一個(gè)服務(wù)實(shí)例的地址4. 然后通過RestClient進(jìn)行服務(wù)調(diào)用。Ribbon本身提供了下面幾種負(fù)載均衡策略:Rou ndRob in Rule:輪詢策略，Ribbon以輪詢的方式選擇服務(wù)器，這個(gè)是默認(rèn)值。所以示例中所啟動(dòng)的兩個(gè)服務(wù)會被循環(huán)

18、訪問；Ra ndomRule:隨機(jī)選擇，也就是說 Ribbon會隨機(jī)從服務(wù)器列表中選擇一個(gè)進(jìn)行訪問；BestAvailableRule:最大可用策略，即先過濾出故障服務(wù)器后，選擇一個(gè)當(dāng)前并發(fā)請求數(shù)最小的；WeightedRespo nseTimeRule:帶有加權(quán)的輪詢策略，對各個(gè)服務(wù)器響應(yīng)時(shí)間進(jìn)行加權(quán)處理，然后在采用輪詢的方式來獲取相應(yīng)的服務(wù)器>AvailabilityFilteri ngRule:可用過濾策略，先過濾出故障的或并發(fā)請求大于閾值一部分服務(wù)實(shí)例，然后再以線性輪詢的方式從過濾后的實(shí)例清單中選出一個(gè)；?Zon eAvoida nceRule:區(qū)域感知策略，先使用主過濾條件（區(qū)

19、域負(fù)載器，選擇最優(yōu)區(qū)域）對所有實(shí)例過濾并返回過濾后的實(shí)例清單，依次使用次過濾條件列表中的過濾條 件對主過濾條件的結(jié)果進(jìn)行過濾，判斷最小過濾數(shù)（默認(rèn)1）和最小過濾百分比（默認(rèn)0），最后對滿足條件的服務(wù)器則使用RoundRobinRule（輪詢方式）選擇一個(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ù)、 語言、框架等，以便能更快速的使用新技術(shù)、新框架等響應(yīng)特定客戶需求，解決單體應(yīng)用架構(gòu)更新技術(shù)

20、、更 新框架時(shí)面臨的困難或阻礙。但這也同時(shí)帶來了諸多問題，如下：1、各服務(wù)是否可以任意使用自己的技術(shù)、自己的組件、框架呢？如果這樣，勢必帶來 更大的管理困難、維護(hù)困難、技術(shù)共享困難。2、公共的方法如何實(shí)現(xiàn)共享？如格式化時(shí)間的一個(gè)簡單方法需要共享，也需要封裝為 一個(gè)服務(wù)接口嗎？管理策略：1、總體原則：仍然需要進(jìn)行統(tǒng)籌考慮，所有組件統(tǒng)一管理，組件放置在產(chǎn)品倉庫中，每個(gè)產(chǎn)品或服務(wù)需要共享組件時(shí)，從產(chǎn)品倉庫獲取。匸戀址汀購炬取0用系?ftG訶才吾礙弋遼訶護(hù)*產(chǎn)爲(wèi)力布產(chǎn)話詬毓*打蠱產(chǎn)呂走店磁式*盧呂由拓?cái)[供小產(chǎn)品.尊昇”珀春戶 破C ,民雖田強(qiáng)自己的臨品2、特殊情況：特殊服務(wù)需要使用特殊的組件、框架，需

21、提出申請，統(tǒng)籌規(guī)劃后進(jìn)行決策。6. 開發(fā)階段6.1. 服務(wù)的調(diào)用6.1.1. AIP網(wǎng)關(guān)調(diào)用所有服務(wù)通過Zuul網(wǎng)關(guān)進(jìn)行調(diào)用，不允許直接調(diào)用微服務(wù)提供者。Zuul可能會成為系統(tǒng)瓶頸，在項(xiàng)目復(fù)雜時(shí)可考慮為Zuul進(jìn)行主備或負(fù)載均衡處理。ZuuH弋理機(jī)制L UMf 1RQlt:*t厲審盤僵務(wù)lDept1凋川詩聲韋t 1Comptnv J* M/Batis MyBarisRPCOi (SpfingBooi)Niff MEZuul代理WPC 廚)8< SpringCloud Mvflatls客戶睪6.12 同步調(diào)用采用HTTP REST方式進(jìn)行調(diào)用，針對業(yè)務(wù)需求可以進(jìn)行負(fù)載均衡，負(fù)載均衡的調(diào)用

22、方式有兩種：1、FeignClient2、RestTemplate建議使用FeignClient方式進(jìn)行服務(wù)調(diào)用。不管是什么方式，他都是通過REST接口調(diào)用服務(wù)的http接口，參數(shù)和結(jié)果默認(rèn)都是通過Jackson 序列化和反序列化。因?yàn)镾pring MVC 的RestController定義的接口，返回的數(shù)據(jù)都是通過 Jackson序列化成JSON數(shù)據(jù)。6.1.3. 異步調(diào)用6.1.4.服務(wù)間調(diào)用的權(quán)限驗(yàn)證?Spri ng Cloud Stream，基于 Redis、Rabbit、Kafka 實(shí)現(xiàn)的消息微服務(wù)，簡單聲明模型用以在 Spri ng Cloud應(yīng)用中收發(fā)消息。rabbitMq 、k

23、afka、Spring Cloud Stream均是可以選擇的方案。token 或者般我們的API接口都需要某種授權(quán)才能訪問，登陸成功以后，然后通過cookie等方式才能調(diào)用接口。使用Spring Cloud Netfix框架的話，登錄的時(shí)候，把登錄請求轉(zhuǎn)發(fā)到相應(yīng)的用戶服務(wù)上，登陸成功后，會設(shè)置cookie或header token等。然后客戶端接下來的請求就會帶著 這些驗(yàn)證信息，從 Zuul網(wǎng)關(guān)傳到相應(yīng)的服務(wù)上進(jìn)行驗(yàn)證。Zuul網(wǎng)關(guān)在把請求轉(zhuǎn)發(fā)到后臺的服務(wù)的時(shí)候，會默認(rèn)把一些header傳到服務(wù)端，如：Cookie、Set-Cookie、Authorization。這樣，客戶端請求的相關(guān)he

24、aders 就可以傳遞到服務(wù)端，服務(wù)端設(shè)置的cookie也可以傳到客戶端。但是，如果你想禁止某些header透傳到服務(wù)端，可以在Zuul網(wǎng)關(guān)的application.yml配置里通過下面的方式禁用：zuul:routes:users:path: /users/*sensitiveHeaders: Cookie,Set-Cookie,AuthorizationserviceId: user剛才說了我們的某個(gè)服務(wù)有時(shí)候需要調(diào)用另一個(gè)服務(wù)，這時(shí)候，這個(gè)請求不是客戶端發(fā)起，他的請求的header里面也不會有任何驗(yàn)證信息。這時(shí)候，要么，通過防火墻等設(shè)置，保證服務(wù)間調(diào)用的接口，只能某幾個(gè)地址訪問；要么，就

25、通過某種方式設(shè)置 header。同時(shí)，如果你想在某個(gè)服務(wù)里面獲得這個(gè)請求的真是IP，（因?yàn)檎埱蟮耐ㄟ^網(wǎng)關(guān)轉(zhuǎn)發(fā)而來，你直接通過request獲得ip得到的是網(wǎng)關(guān)的IP），就可以從headerX-Forwarded-Host獲得。如果想禁用這個(gè) header，也可以：zuul.addProxyHeaders = false如果你使用RestTemplate 的方式調(diào)用，可以在請求里面添加一個(gè)有header的OptionsBea npublic Request In terceptor requestI nterceptor() return new RequestI nterceptor() Ov

26、erridepublic void apply(RequestTemplate template) Stri ng authToke n = getToke n(); template.header(AUTH_TOKEN_HEADER, authToke n);服務(wù)編排主要的作用是減少項(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)用鏈對開發(fā)運(yùn)維人員來說就是災(zāi)難。有這樣一個(gè)好辦法可以盡量的減少項(xiàng)目的相互依賴，

27、就是服務(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中來處理，W服務(wù)使用a的時(shí)候去調(diào)用b，使用b的時(shí)候 W去調(diào)用c。其實(shí)可以理解為面向?qū)ο蟮脑O(shè)計(jì)，減少方法之間的一層層嵌套調(diào)用，而采取一個(gè)方法進(jìn)行業(yè)務(wù)流程的串聯(lián)，如方法W實(shí)現(xiàn)一個(gè)完整的業(yè)務(wù)處理，則采取下面方式：fun ctio n w（）1、調(diào)用方法a ；2、調(diào)用方法b ;3、調(diào)用方法c;62 服務(wù)的熔斷處理在服務(wù)之間進(jìn)行調(diào)用時(shí)，由于各種原因會導(dǎo)致遠(yuǎn)程服務(wù)不可用或壓力過載等異常導(dǎo)致的故障蔓延，此時(shí)需要有一種機(jī)制進(jìn)行保護(hù)處理。SpringCloud通過Netflix的H

28、ystrix件實(shí)現(xiàn)熔斷和降級處理解決此問題。斷路器（Cricuit Breaker）是一種能夠在遠(yuǎn)程服務(wù)不可用時(shí)自動(dòng)熔斷（打開開關(guān)），并在遠(yuǎn)程服務(wù)恢復(fù)時(shí)自動(dòng)恢復(fù) （閉合開關(guān)）的設(shè)施，Spring Cloud 通過Netflix的Hystrix組件提供斷路器、資源隔離與自我修復(fù)功能。Spring cloud Hystrix 熔斷器rast TailingClrcuN BrvaKir Scaw DiagramHALF-OPENsuccws dos* circuitopen口ne requestrw requesttry山口a drcultHystrix熔斷夕卜理微m和f63 統(tǒng)一日志管理不同微服務(wù)

29、部署在不同節(jié)點(diǎn)上，登錄每個(gè)節(jié)點(diǎn)查看日志是比較麻煩的，同時(shí)對于需要關(guān)聯(lián)多個(gè)微服務(wù)日志聯(lián)合查看分析的情況將更加麻煩。伴隨節(jié)點(diǎn)數(shù)量的增加，如果沒有合適的管理機(jī)制與工具，定位問題、發(fā)現(xiàn)問題的復(fù)雜性將越來越大，將成指數(shù)級增長，因此需要進(jìn)行統(tǒng)一日志管理。1、建立統(tǒng)一的日志管理規(guī)范；2、 開發(fā)并使用統(tǒng)一的日志組件， 為所有微服務(wù)提供統(tǒng)一的日志服務(wù)，由Iog4j或Blitz4j 封裝；3、 在每個(gè)服務(wù)節(jié)點(diǎn)上部署日志采集Age nt組件，由此Age nt進(jìn)行日志的采集與轉(zhuǎn)發(fā)；4、建立統(tǒng)一的日志中心，所有日志寫入日志中心。說明：上述日志的實(shí)現(xiàn)由公司的“日志管理平臺” 進(jìn)行實(shí)現(xiàn)，采用的是ELK集合框架。6.4.統(tǒng)一

30、監(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)對這個(gè)接口的監(jiān)控和斷路器功能。2、 Hystrix Dashboard，監(jiān)控面板，他提供了一個(gè)界面，可以監(jiān)控各個(gè)服務(wù)上的服 務(wù)調(diào)用所消耗的時(shí)間等。3、Turbine ，監(jiān)控聚合，使用Hystrix 監(jiān)控，我們需要打開每一個(gè)服務(wù)實(shí)例的監(jiān)控 信息來查看。而Turbine可以幫助我們把所有的服務(wù)實(shí)例的監(jiān)控信息聚合到一個(gè)地方統(tǒng) 查看。這樣就不需要挨個(gè)打開一個(gè)個(gè)的頁面一個(gè)個(gè)查看。6.5.統(tǒng)一配置管理實(shí)現(xiàn)各微服務(wù)的統(tǒng)一參數(shù)配

31、置以及版本管理，可采用公司的配置管理平臺或者Spri ngCloud Co nfig配置中心。Spri ng Cloud Config配置中心Ciert AClient ECl enL CConfig ServerSpring Cloud Co nfig就是我們通常意義上的配置中心。Spring Cloud Con fig-把應(yīng)用原本放在本地文件的配置抽取出來放在中心服務(wù)器，本質(zhì)是配置信息從本地遷移到云端 c從而能夠提供更好的管理、發(fā)布能力。Spring Cloud Config分服務(wù)端和客戶端，服務(wù)端負(fù)責(zé)將git ( svn )中存儲的配置文件發(fā)布成REST接口，客戶端可以從服務(wù)端REST接

32、口獲取配置。但客戶端并不能主動(dòng)感知到配置的變化，從而主動(dòng)去獲取新的配置，這需要每個(gè)客戶端通過POST方法觸發(fā)各自的 /refresh 。為解決配置信息能及時(shí)通知到各服務(wù)，同時(shí)減少每個(gè)微服務(wù)處理配置信息更新的復(fù)雜 度，為此我們通過消息總線來解決此問題，方案如下：1. Git 倉庫、Config Server 、以及微服務(wù)"Service A”"、Service B ” 的實(shí)例中都引入了 Spri ng Cloud Bus，所以他們都連接到了RabbitMQ的消息總線上。2. 從Git倉庫中配置的修改到發(fā)起 /bus/refresh 的POST請求這一步可以通過 Git 倉庫的

33、 Web Hook 來自動(dòng)觸發(fā)。3. /bus/refresh請求不再發(fā)送到具體服務(wù)實(shí)例上，而是發(fā)送給Co nfig Server，并通過destination參數(shù)來指定需要更新配置的服務(wù)或?qū)嵗?. 由于所有連接到消息總線上的應(yīng)用都會接受到更新請求，所以在Web Hook中就不需要維護(hù)所有節(jié)點(diǎn)內(nèi)容來進(jìn)行更新，從而解決了通過Web Hook來逐個(gè)進(jìn)行刷新的問題。66 分布式 session采用Redis作為緩存組件以及 session的共享組件。6.7. REST資源響應(yīng)結(jié)構(gòu)制定規(guī)范和解析方法。6.8. API調(diào)用鏈追蹤微服務(wù)架構(gòu)上通過業(yè)務(wù)來劃分服務(wù)的，通過REST調(diào)用，對外暴露的一個(gè)接口，可

34、能需要都會很多個(gè)服務(wù)協(xié)同才能完成這個(gè)接口功能，如果鏈路上任何一個(gè)服務(wù)岀現(xiàn)問題或者網(wǎng)絡(luò)超時(shí)，形成導(dǎo)致接口調(diào)用失敗。隨著業(yè)務(wù)的不斷擴(kuò)張，服務(wù)之間互相調(diào)用會越來越復(fù)雜。Spri ngCloud Sleuth主要功能就是在分布式系統(tǒng)中提供追蹤解決方案，并且兼容支持了zipkin，你只需要在pom文件中引入相應(yīng)的依賴即可。Spin £ 鼻m Id X 年dA Hi B CWnl 5wri$PRn H!SB!W Stfil：I11命ar Id ET哄jId F|1 Scruxir comk! 1TiiHd H X 矗p«n Id - &I1J*End time*mc*-f.ri

35、 van*ElfMi -TrKrtfiG zlpfcln ciDWlk 0I CH*4C ?"2fiiE :匸 u hamsFldi t iTKe6.9.單元測試做微服務(wù)架構(gòu),測試是必不可少的。舅*6 事IwiFhcn/loon信iwgin/trKiiij1 北丁DOMtoCSaaaB'ftienlMiM.rwi _曹 IWISlUnftS02W3U31<n； W進(jìn)行系統(tǒng)測試的復(fù)雜度較大,為保證產(chǎn)品質(zhì)量與開發(fā)、測試效率，單元可采用Mock方式進(jìn)行測試模擬，由持續(xù)集成進(jìn)行自動(dòng)化單元測試的執(zhí)行以及結(jié)果輸 出。6.10. 代碼調(diào)試對于單體架構(gòu)系統(tǒng)， 可直接本地化調(diào)試，但對于微

36、服務(wù)架構(gòu)， 接口間的調(diào)用需采用遠(yuǎn)程通訊的方式，也就是說被調(diào)用的服務(wù)必須啟動(dòng)后方可被調(diào)用，因此當(dāng)微服務(wù)增多時(shí)，你可能需要啟動(dòng)大量的微服務(wù)或者 web服務(wù)器，這給本地化調(diào)用與調(diào)試帶來了困難。解決方案待研究。7. 測試User Story Case'Taak乳孚元能試7.1. 自動(dòng)化測試? 單元測試：由開發(fā)人員實(shí)現(xiàn)。采用Mock方式進(jìn)行測試模擬，由持續(xù)集成進(jìn)行自動(dòng)化單元測試的執(zhí)行以及結(jié)果輸出。業(yè)務(wù)測試:開發(fā)進(jìn)行實(shí)現(xiàn)，測試也需考慮如何實(shí)現(xiàn)。將多個(gè)服務(wù)或業(yè)務(wù)單元進(jìn)行串聯(lián)，測試一個(gè)完整的業(yè)務(wù)，甚至是不同業(yè)務(wù)之間組成的系統(tǒng)測試，需要采用相關(guān)的自動(dòng)化測試框架執(zhí)行，如RobotFramework自動(dòng)化測試框架。王刊卡皿成72依賴測試也可以稱為接口測試或者契約測試， 在微服務(wù)逐漸增多的情況下， 如何有效保證服務(wù)之 間能夠按照接口的約定正常工作， 即符合契約，成為微服務(wù)實(shí)施過程中， 測試面臨的主要挑 戰(zhàn)。一、開發(fā)自動(dòng)化的接口測試工具，1、檢測接口是否滿足約定2、檢測接口是否發(fā)生變化3、檢測接口是否可以正常被調(diào)用。二