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

1、微服務(wù)系統(tǒng)設(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)程 ，并且采用 輕量級(jí)交互 。多數(shù)情況下是一個(gè) HTTP的資源 API。這些服務(wù) 具備獨(dú)立 業(yè)務(wù)能力 并可以通過 自動(dòng)化部署 方式 獨(dú)立部署 。這種風(fēng)格使 最小化集中管理 ，從而可以使 用多種 不同的編程語言和數(shù)據(jù)存儲(chǔ)技術(shù) 。對(duì)于微服務(wù)架構(gòu)系統(tǒng)， 由于其服務(wù)粒度小， 模塊化清晰， 因此首先要做的是對(duì)系 統(tǒng)整體 進(jìn)行功能、服務(wù)規(guī)劃 ，優(yōu)先考慮如何在交付過程中，從 工程實(shí)踐出發(fā)

2、，組織好代碼結(jié)構(gòu)、 配置、測試、部署、運(yùn)維、監(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)故障會(huì)大量增加。運(yùn)維要求高： 系統(tǒng)監(jiān)控、高可用性、自動(dòng)化技術(shù) 分布式復(fù)雜性：網(wǎng)絡(luò)延遲

3、、系統(tǒng)容錯(cuò)、分布式事務(wù)部署依賴性強(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)中，通常會(huì)考慮通過數(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ì)微服務(wù)架構(gòu)設(shè)計(jì)的根本目的

4、是實(shí)現(xiàn)價(jià)值交付，微服務(wù)架構(gòu)只有遵循 DevOps 理念方可進(jìn)行的更順暢，思維方式的轉(zhuǎn)變是最重要的。實(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、前后端分離， 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)化平臺(tái)發(fā)布（ D

5、ocker 實(shí)現(xiàn)）2、管理服務(wù)，對(duì)于微服務(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ì)1、我們把整個(gè)系統(tǒng)根據(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ù)載均衡 也是通過在注冊(cè)中心注冊(cè)的服務(wù)來使用一定策略來實(shí)現(xiàn)。Eureka 可部署多個(gè)，進(jìn)行高可用保證。4、所有的客戶端都通過同一個(gè)網(wǎng)關(guān)地址訪問后臺(tái)的服務(wù)，通過路由配置ZUUL網(wǎng)關(guān)來判斷一個(gè) URL請(qǐng)求由哪

6、個(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ù)的問題而導(dǎo)致整體系統(tǒng)的癱瘓。7、還需要一個(gè)監(jiān)控功能，監(jiān)控每個(gè)服務(wù)調(diào)用花費(fèi)的時(shí)間等。8 、使用 SpringCloud Config 進(jìn)行統(tǒng)一的配置管理，需要考慮與公司的配置管理平臺(tái) 如何配合使用。9 、 Hystrix ，監(jiān)控和斷路器。我們只需要在服務(wù)接口上添加Hystrix 標(biāo)簽，就可以實(shí)現(xiàn)對(duì)這個(gè)接口的監(jiān)控和斷路器功能。10、 Hystrix Dashboard ，監(jiān)控面板，他提供了一個(gè)界面，可以監(jiān)

7、控各個(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è)個(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)程配置中心，與我司的配置管理平臺(tái)如何 結(jié)合使用5. 設(shè)計(jì)階段5.1. 總體設(shè)計(jì)

8、1、功能規(guī)劃 ：對(duì)產(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)多變的客戶需求。3、為每個(gè)服務(wù) 設(shè)計(jì) API 接口 （REST方式）4、為不同的 服務(wù)進(jìn)行分類 ，不同類型的服務(wù)需要的資源不同，可以配置不同的資源， 包括 CPU、內(nèi)存、存儲(chǔ)等。5.2. 服務(wù)拆分原則1、粒度微?。?根據(jù)業(yè)務(wù)功能劃分服務(wù)粒度，總的原則是服務(wù)內(nèi)部高內(nèi)聚，服務(wù)之間低耦合。2、責(zé)任單一： 每個(gè)服務(wù)只做一件事，即單一職責(zé)原則

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

10、 下 劃線分隔 。如用戶管理模塊提供了獲取用戶信息的服務(wù)，則命名為： user_get_info 。3、新增服務(wù)名時(shí)，需要提出申請(qǐng)， 審批通過后方可使用 ，為減少審批復(fù)雜度，可只審 批 ModuleName，即在模塊內(nèi)部可以自由增加服務(wù)名，不需要進(jìn)行審批。5.4. 開發(fā)策略總體原則：不同的微服務(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ú)立的工程 ，

11、工程之間不能產(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ù)級(jí)增加。 在服務(wù)之間依賴較多時(shí)， 每個(gè)服務(wù)的升級(jí)或降級(jí)都將影響 其他服務(wù)的正常運(yùn)行。因此需執(zhí)行如下策略：1、所有服務(wù)的版本制作交由專業(yè)的版本管理員執(zhí)行。2、采用自動(dòng)化的版本制作策略，最大程度的減少人工操作。3、每個(gè)服務(wù)的版本必須有詳細(xì)的版本計(jì)劃、版本說明，對(duì)于版本說明要制定模板，明 確需要提交的內(nèi)容、版本號(hào)、 SVN

12、標(biāo)簽等。4、對(duì)項(xiàng)目經(jīng)理的要求提升，需對(duì)整體的版本計(jì)劃有嚴(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è)微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫， 那么后臺(tái)管理的聯(lián)合查詢?cè)趺刺幚?？這應(yīng)該是大家 會(huì)普遍遇到的一個(gè)問題，有三種處理方案。1) 嚴(yán)格按照微服務(wù)的劃分來做，微服務(wù)相互獨(dú)立，各微服務(wù)數(shù)據(jù)庫也獨(dú)立，后臺(tái)需要 展示數(shù)據(jù)時(shí)， 調(diào)用各微服務(wù)的接口來獲取對(duì)應(yīng)的數(shù)據(jù)， 再進(jìn)行數(shù)據(jù)處理后展示出來， 這是標(biāo) 準(zhǔn)的用法，也是最麻煩的用法。2) 將業(yè)務(wù)高度相關(guān)的表放到一個(gè)庫中，

13、將業(yè)務(wù)關(guān)系不是很緊密的表嚴(yán)格按照微服務(wù)模 式來拆分，這樣既可以使用微服務(wù)，也避免了數(shù)據(jù)庫分散導(dǎo)致后臺(tái)系統(tǒng)統(tǒng)計(jì)功能難以實(shí)現(xiàn)， 是一個(gè)折中的方案。3) 數(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ù)清洗， 用來滿足后臺(tái)業(yè)務(wù) 系統(tǒng)的使用，推薦使用 MongoDB、 HBase等。第一種方案適合業(yè)務(wù)較為簡單的小公司； 第二種方案， 適合在原有系統(tǒng)之上， 慢慢演化 為微服務(wù)架構(gòu)的公司；第三種適合大型高并發(fā)的互聯(lián)網(wǎng)公司。建議，我們當(dāng)前采用第二種方案。5.7. 負(fù)載均衡不再采用一般的增加負(fù)載均衡服務(wù)器的方式進(jìn)行負(fù)載

14、均衡，如 F5、Nginx 、 LVS等，而 是把負(fù)載均衡的功能 以庫的方式集成到服務(wù)消費(fèi)方的進(jìn)程內(nèi) ，這種方案稱為 軟負(fù)載均衡 ( Soft Load Balancing )或者客戶端負(fù)載均衡。在 Spring Cloud 中配合 Eureka 的服務(wù)注 冊(cè)功能， Ribbon 子項(xiàng)目則為 REST客戶端實(shí)現(xiàn)了負(fù)載均衡。使用 Ribbon 進(jìn)行負(fù)載均衡，其工作原理可以概括為下面四個(gè)步驟：1. Ribbon 首先根據(jù)其所在 Zone 優(yōu)先選擇一個(gè)負(fù)載較少的 Eureka Server;2.定期從 Eureka Server 更新并過濾服務(wù)實(shí)例列表 ;3. 根據(jù)指定的負(fù)載均衡策略，從可用的服務(wù)器

15、列表中選擇一個(gè)服務(wù)實(shí)例的地址4. 然后通過 RestClient 進(jìn)行服務(wù)調(diào)用。Ribbon 本身提供了下面幾種負(fù)載均衡策略：RoundRobinRule: 輪詢策略， Ribbon 以輪詢的方式選擇服務(wù)器，這個(gè)是默認(rèn)值。 所以示例中所啟動(dòng)的兩個(gè)服務(wù)會(huì)被循環(huán)訪問 ;RandomRule: 隨機(jī)選擇，也就是說 Ribbon 會(huì)隨機(jī)從服務(wù)器列表中選擇一個(gè)進(jìn)行訪 問;BestAvailableRule: 最大可用策略，即先過濾出故障服務(wù)器后，選擇一個(gè)當(dāng)前并 發(fā)請(qǐng)求數(shù)最小的 ;WeightedResponseTimeRule: 帶有加權(quán)的輪詢策略， 對(duì)各個(gè)服務(wù)器響應(yīng)時(shí)間進(jìn)行加 權(quán)處理，然后在采用輪詢的

16、方式來獲取相應(yīng)的服務(wù)器 ;AvailabilityFilteringRule: 可用過濾策略，先過濾出故障的或并發(fā)請(qǐng)求大于閾 值一部分服務(wù)實(shí)例，然后再以線性輪詢的方式從過濾后的實(shí)例清單中選出一個(gè) ;ZoneAvoidanceRule: 區(qū)域感知策略，先使用主過濾條件（區(qū)域負(fù)載器，選擇最優(yōu) 區(qū)域）對(duì)所有實(shí)例過濾并返回過濾后的實(shí)例清單，依次使用次過濾條件列表中的過濾條 件對(duì)主過濾條件的結(jié)果進(jìn)行過濾， 判斷最小過濾數(shù) （默認(rèn) 1）和最小過濾百分比 （默認(rèn) 0）， 最后對(duì)滿足條件的服務(wù)器則使用 RoundRobinRule（ 輪詢方式 ） 選擇一個(gè)服務(wù)器實(shí)例。5.8. 性能策略1、網(wǎng)絡(luò)優(yōu)化：優(yōu)化組網(wǎng)結(jié)

17、構(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ù)、 更新框架時(shí)面臨的困難或阻礙。但這也同時(shí)帶來了諸多問題，如下：1、各服務(wù)是否可以任意使用自己的技術(shù)、自己的組件、框架呢？如果這樣，勢(shì)必帶來 更大的管理困難、維護(hù)困難、技術(shù)共享困難。2、公共的方法如何實(shí)現(xiàn)共享？如格式化時(shí)間的一個(gè)簡單方法需要共享，也需要封裝為 一個(gè)服務(wù)接口嗎？管理策略：1、總體原則

18、：仍然需要進(jìn)行統(tǒng)籌考慮，所有組件統(tǒng)一管理，組件放置在產(chǎn)品倉庫中， 每個(gè)產(chǎn)品或服務(wù)需要共享組件時(shí)，從產(chǎn)品倉庫獲取。2、特殊情況：特殊服務(wù)需要使用特殊的組件、框架，需提出申請(qǐng)，統(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 可能會(huì)成為系統(tǒng)瓶頸，在項(xiàng)目復(fù)雜時(shí)可考慮為 Zuul 進(jìn)行主備或負(fù)載均衡處理。6.1.2. 同步調(diào)用采用 HTTPR EST方式進(jìn)行調(diào)用，針對(duì)業(yè)務(wù)需求可以進(jìn)行負(fù)載均衡，負(fù)載均衡的調(diào)用方式 有兩種：1、FeignClient2、RestTemplate建議使用 FeignC

19、lient 方式進(jìn)行服務(wù)調(diào)用。不管是什么方式， 他都是通過 REST接口調(diào)用服務(wù)的 http 接口，參數(shù)和結(jié)果默認(rèn)都是通 過 Jackson 序列化和反序列化。因?yàn)?Spring MVC的 RestController 定義的接口，返回的數(shù) 據(jù)都是通過 Jackson 序列化成 JSON數(shù)據(jù)。6.1.3. 異步調(diào)用rabbitMq 、 kafka 、 Spring Cloud Stream 均是可以選擇的方案。Spring Cloud Stream ，基于 Redis 、 Rabbit 、 Kafka 實(shí)現(xiàn)的消息微服務(wù)，簡單聲明模 型用以在 Spring Cloud 應(yīng)用中收發(fā)消息。6.1.4

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

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

22、只能某幾個(gè)地址訪問；要么，就通過某種方式設(shè)置 header 。同時(shí)，如果你想在某個(gè)服務(wù)里面獲得這個(gè)請(qǐng)求的真是IP ，（因?yàn)檎?qǐng)求的通過網(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)用，可以在請(qǐng)求里面添加一個(gè)有 header 的 Options也可以通過如下的攔截器的方式設(shè)置，它對(duì) RestTemplate 方式和 FeignClient 的方式都可以起作用：Beanp

23、ublic RequestInterceptor requestInterceptor() return new RequestInterceptor() Overridepublic void apply(RequestTemplate template) String authToken = getToken(); template.header(AUTH_TOKEN_HEADER, authToken);6.1.5. 服務(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 再

24、更新 g. 更新c 更新 b 最后是更新項(xiàng)目 a 。這只是這一個(gè)調(diào)用鏈，在復(fù)雜的業(yè)務(wù)中有非常多的調(diào)用，如果 要記住每一個(gè)調(diào)用鏈對(duì)開發(fā)運(yùn)維人員來說就是災(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中來處理， 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ù)處理，則采取下面方式：function w （）

25、1、調(diào)用方法 a；2、調(diào)用方法 b；3、調(diào)用方法 c；6.2. 服務(wù)的熔斷處理在服務(wù)之間進(jìn)行調(diào)用時(shí)， 由于各種原因會(huì)導(dǎo)致遠(yuǎn)程 服務(wù)不可用 或壓力過載等異常導(dǎo)致的 故障蔓延 ，此時(shí)需要有一種機(jī)制進(jìn)行保護(hù)處理。 Spring Cloud 通過 Netflix 的 Hystrix 組 件實(shí)現(xiàn) 熔斷和降級(jí) 處理解決此問題。斷路器 （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 clou

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

27、的實(shí)現(xiàn)由公司的“日志管理平臺(tái)”進(jìn)行實(shí)現(xiàn)，采用的是ELK集合框架。6.4. 統(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、Turbine ，監(jiān)控聚合，使用 Hystrix 監(jiān)控，我們需要打開每一個(gè)服務(wù)實(shí)例的監(jiān)控 信息來查看。而 Turbine 可以幫助我們把所有的服務(wù)實(shí)例的監(jiān)控信息聚合到一個(gè)地方統(tǒng)一查

28、 看。這樣就不需要挨個(gè)打開一個(gè)個(gè)的頁面一個(gè)個(gè)查看。6.5. 統(tǒng)一配置管理實(shí)現(xiàn)各微服務(wù)的 統(tǒng)一參數(shù)配置以及版本管理 ，可采用公司的配置管理平臺(tái)或者 SpringCloud Config 配置中心。Spring Cloud Config 配置中心Spring Cloud Config 就是我們通常意義上的配置中心。 Spring Cloud Config- 把應(yīng)用 原本放在本地文件的配置抽取出來放在中心服務(wù)器， 本質(zhì)是配置信息從本地遷移到云端 。 從而能夠提供更好的管理、發(fā)布能力。Spring Cloud Config 分服務(wù)端和客戶端， 服務(wù)端負(fù)責(zé)將 git （svn ）中存儲(chǔ)的配置文 件發(fā)布成

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

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

31、蹤微服務(wù)架構(gòu)上通過業(yè)務(wù)來劃分服務(wù)的，通過REST調(diào)用，對(duì)外暴露的一個(gè)接口，可能需要很多個(gè)服務(wù)協(xié)同才能完成這個(gè)接口功能， 如果鏈路上任何一個(gè)服務(wù)出現(xiàn)問題或者網(wǎng)絡(luò)超時(shí)， 都會(huì)形 成導(dǎo)致接口調(diào)用失敗。隨著業(yè)務(wù)的不斷擴(kuò)張，服務(wù)之間互相調(diào)用會(huì)越來越復(fù)雜。Spring Cloud Sleuth主要功能就是在分布式系統(tǒng)中提供追蹤解決方案，并且兼容支持了zipkin ，你只需要在 pom 文件中引入相應(yīng)的依賴即可。6.9. 單元測試做微服務(wù)架構(gòu)， 進(jìn)行系統(tǒng)測試的復(fù)雜度較大， 為保證產(chǎn)品質(zhì)量與開發(fā)、 測試效率， 單元 測試是必不可少的?？刹捎?Mock 方式進(jìn)行測試模擬， 由持續(xù)集成進(jìn)行自動(dòng)化單元測試的執(zhí)行以及

32、結(jié)果輸出。6.10. 代碼調(diào)試對(duì)于單體架構(gòu)系統(tǒng)， 可直接本地化調(diào)試， 但對(duì)于微服務(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. 測試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ù)之間組成RobotFramework 自動(dòng)化測試框架。的系統(tǒng)測試，需要采用相關(guān)的自動(dòng)化測試框架執(zhí)行，如7.2. 依賴測試也可以稱為接口測試或者契約測試， 在微服務(wù)逐漸增多的情況下， 如何有效保證服務(wù)之 間能夠按照接口的約定正常工作， 即符合契約， 成為微服務(wù)實(shí)施過程中， 測