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

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

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

3、、系統(tǒng)容錯、分布式事務(wù)部署依賴性強(qiáng)：服務(wù)依賴、多版本問題性能（服務(wù)間通訊成本高） ： 無狀態(tài)性、進(jìn)程間調(diào)用、跨網(wǎng)絡(luò)調(diào)用 數(shù)據(jù)一致性：分布式事務(wù)管理需要跨越多個節(jié)點(diǎn)來保證數(shù)據(jù)的瞬時一致性， 因此比起傳統(tǒng)的單體 架構(gòu)的事務(wù)，成本要高得多。另外， 在分布式系統(tǒng)中，通常會考慮通過數(shù)據(jù)的最終一致性來 解決數(shù)據(jù)瞬時一致帶來的系統(tǒng)不可用。重復(fù)開發(fā)：微服務(wù)理念崇尚每個微服務(wù)作為一個產(chǎn)品看待， 有自己的團(tuán)隊開發(fā)， 甚至可以有自 己完全不同的技術(shù)、 框架， 那么與其他微服務(wù)團(tuán)隊的技術(shù)共享就產(chǎn)生了矛盾， 重復(fù)開發(fā)的工 作即產(chǎn)生了。沒有最好的，只有最適合自己的。4. 架構(gòu)設(shè)計4.1. 思維設(shè)計微服務(wù)架構(gòu)設(shè)計的根本目的

4、是實(shí)現(xiàn)價值交付，微服務(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)的自動化服務(wù)實(shí)現(xiàn)， 包括自動化構(gòu)建、自動化安裝部署、自動化測試、 自動化平臺發(fā)布（ D

5、ocker 實(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è)計1、我們把整個系統(tǒng)根據(jù)業(yè)務(wù)拆分成若干個子系統(tǒng)或微服務(wù)。2、每個子系統(tǒng)可以部署多個應(yīng)用，多個應(yīng)用之間使用負(fù)載均衡。3、需要一個服務(wù)注冊中心 Eureka ，所有的服務(wù)都在注冊中心注冊，負(fù)載均衡 也是通過在注冊中心注冊的服務(wù)來使用一定策略來實(shí)現(xiàn)。Eureka 可部署多個，進(jìn)行高可用保證。4、所有的客戶端都通過同一個網(wǎng)關(guān)地址訪問后臺的服務(wù)，通過路由配置ZUUL網(wǎng)關(guān)來判斷一個 URL請求由哪

6、個服務(wù)處理。 請求轉(zhuǎn)發(fā)到服務(wù)上的時候使用負(fù)載均衡 Ribbon 。5、服務(wù)之間采用 feign 進(jìn)行調(diào)用。6、使用斷路器 hystrix ，及時處理服務(wù)調(diào)用時的超時和錯誤， 防止由于其中一 個服務(wù)的問題而導(dǎo)致整體系統(tǒng)的癱瘓。7、還需要一個監(jiān)控功能，監(jiān)控每個服務(wù)調(diào)用花費(fèi)的時間等。8 、使用 SpringCloud Config 進(jìn)行統(tǒng)一的配置管理，需要考慮與公司的配置管理平臺 如何配合使用。9 、 Hystrix ，監(jiān)控和斷路器。我們只需要在服務(wù)接口上添加Hystrix 標(biāo)簽，就可以實(shí)現(xiàn)對這個接口的監(jiān)控和斷路器功能。10、 Hystrix Dashboard ，監(jiān)控面板，他提供了一個界面，可以監(jiān)

7、控各個服務(wù)上 的服務(wù)調(diào)用所消耗的時間等。11、 Turbine ，監(jiān)控聚合，使用 Hystrix 監(jiān)控，我們需要打開每一個服務(wù)實(shí)例 的監(jiān)控信息來查看。 而 Turbine 可以幫助我們把所有的服務(wù)實(shí)例的監(jiān)控信息聚合到一個地方 統(tǒng)一查看。這樣就不需要挨個打開一個個的頁面一個個查看。架構(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è)計階段5.1. 總體設(shè)計

8、1、功能規(guī)劃 ：對產(chǎn)品功能進(jìn)行拆分，拆分為若干個微服務(wù)；一個功能可以創(chuàng)建多個微 服務(wù)并部署在多個服務(wù)器節(jié)點(diǎn)上，以便進(jìn)行負(fù)載均衡。2、設(shè)計 原子服務(wù)層 ，梳理和抽取核心應(yīng)用、公共應(yīng)用，作為獨(dú)立的服務(wù)下沉到核心和 公共能力層，逐漸形成穩(wěn)定的服務(wù)中心，使應(yīng)用能更快速的響應(yīng)多變的客戶需求。3、為每個服務(wù) 設(shè)計 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é)任單一： 每個服務(wù)只做一件事，即單一職責(zé)原則

9、。3、隔離性原則： 每個服務(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ī)劃為實(shí)現(xiàn)負(fù)載均衡， 允許相同的服務(wù)在多個節(jié)點(diǎn)注冊相同的服務(wù)名， 不同的端口。 如果沒 有前期的規(guī)劃， 不同的服務(wù)提供者可能會注冊相同的服務(wù)名， 導(dǎo)致消費(fèi)者調(diào)用服務(wù)時產(chǎn)生調(diào) 用混亂。因此，需進(jìn)行服務(wù)名的統(tǒng)一規(guī)劃：1、規(guī)劃期統(tǒng)一制定每個服務(wù)提供者的服務(wù)名或者模塊標(biāo)示。2、服務(wù)名的命名規(guī)則 :ModuleName_ServiceName ，且 所有字符小寫 ，不同單詞之間以

10、 下 劃線分隔 。如用戶管理模塊提供了獲取用戶信息的服務(wù)，則命名為： user_get_info 。3、新增服務(wù)名時，需要提出申請， 審批通過后方可使用 ，為減少審批復(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、編譯策略：代碼編譯時，各個微服務(wù)獨(dú)立編譯、打包，杜絕直接的依賴 ；3、工程構(gòu)建：代碼開發(fā)時，各微服務(wù) 創(chuàng)建獨(dú)立的工程 ，

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

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

13、將業(yè)務(wù)關(guān)系不是很緊密的表嚴(yán)格按照微服務(wù)模 式來拆分，這樣既可以使用微服務(wù)，也避免了數(shù)據(jù)庫分散導(dǎo)致后臺系統(tǒng)統(tǒng)計功能難以實(shí)現(xiàn)， 是一個折中的方案。3) 數(shù)據(jù)庫嚴(yán)格按照微服務(wù)的要求來切分，以滿足業(yè)務(wù)高并發(fā)，實(shí)時或者準(zhǔn)實(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)公司。建議，我們當(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ù)注 冊功能， Ribbon 子項(xiàng)目則為 REST客戶端實(shí)現(xiàn)了負(fù)載均衡。使用 Ribbon 進(jìn)行負(fù)載均衡，其工作原理可以概括為下面四個步驟：1. Ribbon 首先根據(jù)其所在 Zone 優(yōu)先選擇一個負(fù)載較少的 Eureka Server;2.定期從 Eureka Server 更新并過濾服務(wù)實(shí)例列表 ;3. 根據(jù)指定的負(fù)載均衡策略，從可用的服務(wù)器

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

16、方式來獲取相應(yīng)的服務(wù)器 ;AvailabilityFilteringRule: 可用過濾策略，先過濾出故障的或并發(fā)請求大于閾 值一部分服務(wù)實(shí)例，然后再以線性輪詢的方式從過濾后的實(shí)例清單中選出一個 ;ZoneAvoidanceRule: 區(qū)域感知策略，先使用主過濾條件（區(qū)域負(fù)載器，選擇最優(yōu) 區(qū)域）對所有實(shí)例過濾并返回過濾后的實(shí)例清單，依次使用次過濾條件列表中的過濾條 件對主過濾條件的結(jié)果進(jìn)行過濾， 判斷最小過濾數(shù) （默認(rèn) 1）和最小過濾百分比 （默認(rèn) 0）， 最后對滿足條件的服務(wù)器則使用 RoundRobinRule（ 輪詢方式 ） 選擇一個服務(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ù)、 更新框架時面臨的困難或阻礙。但這也同時帶來了諸多問題，如下：1、各服務(wù)是否可以任意使用自己的技術(shù)、自己的組件、框架呢？如果這樣，勢必帶來 更大的管理困難、維護(hù)困難、技術(shù)共享困難。2、公共的方法如何實(shí)現(xiàn)共享？如格式化時間的一個簡單方法需要共享，也需要封裝為 一個服務(wù)接口嗎？管理策略：1、總體原則

18、：仍然需要進(jìn)行統(tǒng)籌考慮，所有組件統(tǒng)一管理，組件放置在產(chǎn)品倉庫中， 每個產(chǎn)品或服務(wù)需要共享組件時，從產(chǎn)品倉庫獲取。2、特殊情況：特殊服務(wù)需要使用特殊的組件、框架，需提出申請，統(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ù)雜時可考慮為 Zuul 進(jìn)行主備或負(fù)載均衡處理。6.1.2. 同步調(diào)用采用 HTTPR EST方式進(jìn)行調(diào)用，針對業(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 框架的話，登錄的時候，把登錄請求轉(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ù)的時候，會默認(rèn)把一些 header 傳到服務(wù)端，如： Cookie 、 Set-Cookie 、 Authorization 。這樣，客戶端請求的相關(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剛才說了我們的某個服務(wù)有時候需要調(diào)用另一個服務(wù)，這時候，這個請求不是客戶端發(fā)起，他的請求的 header 里面也不會有任何驗(yàn)證信息。這時候，要么，通過防火墻等設(shè)置，保證服務(wù)間調(diào)用的接口，

22、只能某幾個地址訪問；要么，就通過某種方式設(shè)置 header 。同時，如果你想在某個服務(wù)里面獲得這個請求的真是IP ，（因?yàn)檎埱蟮耐ㄟ^網(wǎng)關(guān)轉(zhuǎn)發(fā)而來，你直接通過request 獲得 ip得到的是網(wǎng)關(guān)的 IP ），就可以從 headerX-Forwarded-Host 獲得。如果想禁用這個 header，也可以：zuul.addProxyHeaders = false如果你使用 RestTemplate 的方式調(diào)用，可以在請求里面添加一個有 header 的 Options也可以通過如下的攔截器的方式設(shè)置，它對 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，是一個調(diào)用鏈， 那么項(xiàng)目上線的時候需要先更新最底層的h 再

24、更新 g. 更新c 更新 b 最后是更新項(xiàng)目 a 。這只是這一個調(diào)用鏈，在復(fù)雜的業(yè)務(wù)中有非常多的調(diào)用，如果 要記住每一個調(diào)用鏈對開發(fā)運(yùn)維人員來說就是災(zāi)難。 有這樣一個好辦法可以盡量的減少項(xiàng)目的相互依賴， 就是服務(wù)編排， 一個核心的業(yè)務(wù)處理項(xiàng) 目，負(fù)責(zé)和各個微服務(wù)打交道。比如之前是 a調(diào)用 b，b 掉用 c，c調(diào)用 d，現(xiàn)在統(tǒng)一在一個 核心項(xiàng)目 W中來處理， W服務(wù)使用 a的時候去調(diào)用 b，使用 b 的時候 W去調(diào)用 c。其實(shí)可以理解為面向?qū)ο蟮脑O(shè)計， 減少方法之間的一層層嵌套調(diào)用， 而采取一個方法進(jìn) 行業(yè)務(wù)流程的串聯(lián)，如方法 W實(shí)現(xiàn)一個完整的業(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)用時， 由于各種原因會導(dǎo)致遠(yuǎn)程 服務(wù)不可用 或壓力過載等異常導(dǎo)致的 故障蔓延 ，此時需要有一種機(jī)制進(jìn)行保護(hù)處理。 Spring Cloud 通過 Netflix 的 Hystrix 組 件實(shí)現(xiàn) 熔斷和降級 處理解決此問題。斷路器 （Cricuit Breaker） 是一種能夠在遠(yuǎn)程服務(wù)不可 用時自動熔斷 （打開開關(guān) ） ，并在遠(yuǎn)程服務(wù)恢復(fù)時自動恢復(fù) （閉合開關(guān) ）的設(shè)施， Spring Cloud 通過 Netflix 的 Hystrix 組件提供斷路器、資源隔離與自我修復(fù)功能。Spring clou

26、d Hystrix 熔斷器6.3. 統(tǒng)一日志管理不同微服務(wù)部署在不同節(jié)點(diǎn)上， 登錄每個節(jié)點(diǎn)查看日志是比較麻煩的， 同時對于需要關(guān) 聯(lián)多個微服務(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ù)， 由 log4j 或 Blitz4j 封裝；3、在每個服務(wù)節(jié)點(diǎn)上部署日志采集Agent 組件，由此 Agent 進(jìn)行日志的采集與轉(zhuǎn)發(fā)；4、建立統(tǒng)一的日志中心，所有日志寫入日志中心。說明：上述日志

27、的實(shí)現(xiàn)由公司的“日志管理平臺”進(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)對這個接口的監(jiān)控和斷路器功能。2、 Hystrix Dashboard ，監(jiān)控面板，他提供了一個界面，可以監(jiān)控各個服務(wù)上的服 務(wù)調(diào)用所消耗的時間等。3、Turbine ，監(jiān)控聚合，使用 Hystrix 監(jiān)控，我們需要打開每一個服務(wù)實(shí)例的監(jiān)控 信息來查看。而 Turbine 可以幫助我們把所有的服務(wù)實(shí)例的監(jiān)控信息聚合到一個地方統(tǒng)一查

28、 看。這樣就不需要挨個打開一個個的頁面一個個查看。6.5. 統(tǒng)一配置管理實(shí)現(xiàn)各微服務(wù)的 統(tǒng)一參數(shù)配置以及版本管理 ，可采用公司的配置管理平臺或者 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 ）中存儲的配置文 件發(fā)布成

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

30、fresh 的 POST請求這一步可以通過 Git 倉庫的 Web Hook來自動觸發(fā)。3. /bus/refresh 請求不再發(fā)送到具體服務(wù)實(shí)例上，而是發(fā)送給Config Server ，并通過 destination 參數(shù)來指定需要更新配置的服務(wù)或?qū)嵗?. 由于所有連接到消息總線上的應(yīng)用都會接受到更新請求，所以在Web Hook中就不需要維護(hù)所有節(jié)點(diǎn)內(nèi)容來進(jìn)行更新，從而解決了通過WebH ook 來逐個進(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)用，對外暴露的一個接口，可能需要很多個服務(wù)協(xié)同才能完成這個接口功能， 如果鏈路上任何一個服務(wù)出現(xiàn)問題或者網(wǎng)絡(luò)超時， 都會形 成導(dǎo)致接口調(diào)用失敗。隨著業(yè)務(wù)的不斷擴(kuò)張，服務(wù)之間互相調(diào)用會越來越復(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)行自動化單元測試的執(zhí)行以及

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