基于SpringCloud微服務系統(tǒng)設計方案

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

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

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

4、是實現(xiàn)價值交付，微服務架構只有遵循devops理念方可進行的更順暢，思維方式的轉(zhuǎn)變是最重要的。實現(xiàn)微服務技術架構，現(xiàn)有產(chǎn)品需要進行技術上的改進以及相關配套服務的實現(xiàn)，采用 分階段實施、以及試點產(chǎn)品優(yōu)先實施的策略，主要包括如下：一、技術上的改進：1、前后端分離，web 前端通過http/https協(xié)議調(diào)用微服務的api 網(wǎng)關，由api 網(wǎng)關再經(jīng)過路由服務調(diào)用相應的微服務. . . . 可編輯2、不同微服務之間通過rest 方式互相調(diào)用3、微服務之間通過消息中間件實現(xiàn)消息交互機制二、配套服務與功能實現(xiàn)：1、需要進行相應的自動化服務實現(xiàn)，包括自動化構建、 自動化安裝部署、 自動化測試、自動化平臺發(fā)布

5、（docker 實現(xiàn)）2、管理服務，對于微服務架構，必須配套相應的監(jiān)控與管理服務、日志管理服務等3、協(xié)作服務，運用devops 思想提升開發(fā)、測試、運維的高效溝通與協(xié)作，實現(xiàn)開發(fā)與運維的一體化4.2. 微服務架構設計 1、我們把整個系統(tǒng)根據(jù)業(yè)務拆分成若干個子系統(tǒng)或微服務。 2、每個子系統(tǒng)可以部署多個應用，多個應用之間使用負載均衡。. . . . 可編輯 3、需要一個服務注冊中心eureka，所有的服務都在注冊中心注冊，負載均衡也是通過在注冊中心注冊的服務來使用一定策略來實現(xiàn)。eureka可部署多個，進行高可用保證。 4、所有的客戶端都通過同一個網(wǎng)關地址訪問后臺的服務，通過路由配置zuul網(wǎng)關來

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

7、控各個服務上的服務調(diào)用所消耗的時間等。 11、turbine，監(jiān)控聚合，使用hystrix 監(jiān)控，我們需要打開每一個服務實例的監(jiān)控信息來查看。而 turbine 可以幫助我們把所有的服務實例的監(jiān)控信息聚合到一個地方統(tǒng)一查看。這樣就不需要挨個打開一個個的頁面一個個查看。架構的可靠性保證：在關鍵節(jié)點做主備、集群部署，防止單點故障。待后續(xù)確認問題：1、access control：zuul 網(wǎng)關提供了相關控制功能，與我司cas如何結合使用2、config server：spring cloud 提供了遠程配置中心，與我司的配置管理平臺如何結合使用. . . . 可編輯5. 設計階段5.1. 總體設計

8、1、功能規(guī)劃 ：對產(chǎn)品功能進行拆分，拆分為若干個微服務；一個功能可以創(chuàng)建多個微服務并部署在多個服務器節(jié)點上，以便進行負載均衡。2、設計 原子服務層 ，梳理和抽取核心應用、公共應用，作為獨立的服務下沉到核心和公共能力層，逐漸形成穩(wěn)定的服務中心，使應用能更快速的響應多變的客戶需求。3、為每個服務 設計 api接口 （rest 方式）4、為不同的 服務進行分類，不同類型的服務需要的資源不同，可以配置不同的資源，包括 cpu、內(nèi)存、存儲等。5.2. 服務拆分原則1、粒度微小：根據(jù)業(yè)務功能劃分服務粒度，總的原則是服務內(nèi)部高內(nèi)聚，服務之間低耦合。2、責任單一：每個服務只做一件事，即單一職責原則。3、隔離性

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

10、 。如用戶管理模塊提供了獲取用戶信息的服務，則命名為：user_get_info 。3、新增服務名時，需要提出申請，審批通過后方可使用，為減少審批復雜度，可只審批 modulename ，即在模塊內(nèi)部可以自由增加服務名，不需要進行審批。5.4. 開發(fā)策略總體原則：不同的微服務需進行物理隔離。1、svn策略： svn上創(chuàng)建 獨立的分支 ，不同微服務的代碼提交不受相互影響；-由配置管理員統(tǒng)一控制。問題：開發(fā)分支與集成分支，都將增加很多，維護工作量增加。2、編譯策略：代碼編譯時，各個微服務獨立編譯、打包，杜絕直接的依賴；3、工程構建：代碼開發(fā)時，各微服務創(chuàng)建獨立的工程，工程之間不能產(chǎn)生直接依賴4、持

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

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

13、式來拆分，這樣既可以使用微服務，也避免了數(shù)據(jù)庫分散導致后臺系統(tǒng)統(tǒng)計功能難以實現(xiàn)，是一個折中的方案。3）數(shù)據(jù)庫嚴格按照微服務的要求來切分，以滿足業(yè)務高并發(fā)，實時或者準實時將各微服務數(shù)據(jù)庫數(shù)據(jù)同步到nosql 數(shù)據(jù)庫中，在同步的過程中進行數(shù)據(jù)清洗，用來滿足后臺業(yè)務系統(tǒng)的使用，推薦使用mongodb、hbase等。第一種方案適合業(yè)務較為簡單的小公司；第二種方案， 適合在原有系統(tǒng)之上，慢慢演化為微服務架構的公司；第三種適合大型高并發(fā)的互聯(lián)網(wǎng)公司。建議，我們當前采用第二種方案。5.7. 負載均衡不再采用一般的增加負載均衡服務器的方式進行負載均衡，如f5、nginx、lvs等，而是把負載均衡的功能以庫的方

14、式集成到服務消費方的進程內(nèi)，這種方案稱為軟負載均衡（soft load balancing） 或者客戶端負載均衡。 在 spring cloud中配合 eureka 的服務注冊功能，ribbon 子項目則為rest 客戶端實現(xiàn)了負載均衡。. . . . 可編輯使用 ribbon 進行負載均衡，其工作原理可以概括為下面四個步驟：1.ribbon 首先根據(jù)其所在zone 優(yōu)先選擇一個負載較少的eureka server; 2.定期從 eureka server 更新并過濾服務實例列表; 3.根據(jù)指定的負載均衡策略，從可用的服務器列表中選擇一個服務實例的地址; 4.然后通過restclient 進行

15、服務調(diào)用。ribbon 本身提供了下面幾種負載均衡策略：roundrobinrule:輪詢策略， ribbon 以輪詢的方式選擇服務器，這個是默認值。所以示例中所啟動的兩個服務會被循環(huán)訪問; randomrule:隨機選擇，也就是說ribbon 會隨機從服務器列表中選擇一個進行訪問; bestavailablerule:最大可用策略，即先過濾出故障服務器后，選擇一個當前并發(fā)請求數(shù)最小的 ; weightedresponsetimerule:帶有加權的輪詢策略， 對各個服務器響應時間進行加權處理，然后在采用輪詢的方式來獲取相應的服務器; . . . . 可編輯availabilityfilter

16、ingrule:可用過濾策略，先過濾出故障的或并發(fā)請求大于閾值一部分服務實例，然后再以線性輪詢的方式從過濾后的實例清單中選出一個; zoneavoidancerule:區(qū)域感知策略， 先使用主過濾條件 （區(qū)域負載器， 選擇最優(yōu)區(qū)域）對所有實例過濾并返回過濾后的實例清單，依次使用次過濾條件列表中的過濾條件對主過濾條件的結果進行過濾，判斷最小過濾數(shù)（默認1）和最小過濾百分比（默認0），最后對滿足條件的服務器則使用roundrobinrule( 輪詢方式 ) 選擇一個服務器實例。5.8. 性能策略1、網(wǎng)絡優(yōu)化：優(yōu)化組網(wǎng)結構，提升網(wǎng)絡間通訊性能；2、配置優(yōu)化：優(yōu)化spring cloud 組件集以及其

17、他組件的配置信息，使得性能最大化。5.9. 技術管理策略微服務的架構理念中指出各微服務可以獨立建設，可以使用不同的技術、語言、框架等， 以便能更快速的使用新技術、新框架等響應特定客戶需求，解決單體應用架構更新技術、更新框架時面臨的困難或阻礙。但這也同時帶來了諸多問題，如下：1、各服務是否可以任意使用自己的技術、自己的組件、框架呢？如果這樣，勢必帶來更大的管理困難、維護困難、技術共享困難。2、公共的方法如何實現(xiàn)共享？如格式化時間的一個簡單方法需要共享，也需要封裝為一個服務接口嗎？管理策略：1、總體原則：仍然需要進行統(tǒng)籌考慮，所有組件統(tǒng)一管理，組件放置在產(chǎn)品倉庫中，每個產(chǎn)品或服務需要共享組件時，從

18、產(chǎn)品倉庫獲取。. . . . 可編輯2、特殊情況：特殊服務需要使用特殊的組件、框架，需提出申請，統(tǒng)籌規(guī)劃后進行決策。6. 開發(fā)階段6.1. 服務的調(diào)用6.1.1. aip網(wǎng)關調(diào)用所有服務通過zuul 網(wǎng)關進行調(diào)用，不允許直接調(diào)用微服務提供者。zuul 可能會成為系統(tǒng)瓶頸，在項目復雜時可考慮為zuul 進行主備或負載均衡處理。. . . . 可編輯6.1.2. 同步調(diào)用采用 http rest 方式進行調(diào)用，針對業(yè)務需求可以進行負載均衡，負載均衡的調(diào)用方式有兩種：1、feignclient 2、resttemplate 建議使用 feignclient方式進行服務調(diào)用。不管是什么方式，他都是通過

19、rest 接口調(diào)用服務的http 接口，參數(shù)和結果默認都是通過 jackson序列化和反序列化。因為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 實現(xiàn)的消息微服務，簡單聲明模型用以在spring cloud 應用中收發(fā)消息。6.1.4. 服務間調(diào)用的權限驗證一般我們的api接口都需要某種授權才能訪問，登陸成功以后， 然后通過

20、 token 或者 cookie等方式才能調(diào)用接口。. . . . 可編輯使用 spring cloud netfix 框架的話，登錄的時候，把登錄請求轉(zhuǎn)發(fā)到相應的用戶服務上，登陸成功后， 會設置 cookie 或 header token 等。然后客戶端接下來的請求就會帶著這些驗證信息，從zuul 網(wǎng)關傳到相應的服務上進行驗證。zuul 網(wǎng)關在把請求轉(zhuǎn)發(fā)到后臺的服務的時候，會默認把一些header 傳到服務端，如：cookie、set-cookie、authorization 。這樣，客戶端請求的相關headers 就可以傳遞到服務端，服務端設置的cookie 也可以傳到客戶端。但是，如果你

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

22、得這個請求的真是ip，（因為請求的通過網(wǎng)關轉(zhuǎn)發(fā)而來，你直接通過request 獲得 ip得到的是網(wǎng)關的ip），就可以從headerx-forwarded-host獲得。如果想禁用這個header，也可以：zuul.addproxyheaders = false 如果你使用 resttemplate 的方式調(diào)用，可以在請求里面添加一個有header 的 options 。也可以通過如下的攔截器的方式設置，它對resttemplate 方式和 feignclient的方式都可以起作用：. . . . 可編輯bean public requestinterceptor requestintercep

23、tor() return new requestinterceptor() override public void apply(requesttemplate template) string authtoken = gettoken(); template.header(auth_token_header, authtoken); ; 6.1.5. 服務編排主要的作用是減少項目中的相互依賴。比如現(xiàn)在有項目a 調(diào)用項目b，項目 b 調(diào)用項目c.一直到 h，是一個調(diào)用鏈，那么項目上線的時候需要先更新最底層的h 再更新 g.更新 c更新 b 最后是更新項目a。這只是這一個調(diào)用鏈，在復雜的業(yè)務中有

24、非常多的調(diào)用，如果要記住每一個調(diào)用鏈對開發(fā)運維人員來說就是災難。有這樣一個好辦法可以盡量的減少項目的相互依賴，就是服務編排， 一個核心的業(yè)務處理項目，負責和各個微服務打交道。比如之前是a 調(diào)用 b，b 掉用 c， c調(diào)用 d，現(xiàn)在統(tǒng)一在一個核心項目w 中來處理， w 服務使用 a 的時候去調(diào)用b，使用 b 的時候 w 去調(diào)用 c。其實可以理解為面向?qū)ο蟮脑O計，減少方法之間的一層層嵌套調(diào)用，而采取一個方法進行業(yè)務流程的串聯(lián)，如方法w 實現(xiàn)一個完整的業(yè)務處理，則采取下面方式：function w （） 1、調(diào)用方法a；2、調(diào)用方法b；3、調(diào)用方法c； . . . . 可編輯6.2. 服務的熔斷處理

25、在服務之間進行調(diào)用時，由于各種原因會導致遠程服務不可用 或壓力過載等異常導致的故障蔓延 ，此時需要有一種機制進行保護處理。spring cloud 通過 netflix 的 hystrix 組件實現(xiàn)熔斷和降級 處理解決此問題。斷路器(cricuit breaker)是一種能夠在遠程服務不可用時自動熔斷(打開開關 )，并在遠程服務恢復時自動恢復(閉合開關 )的設施， spring cloud 通過 netflix 的hystrix 組件提供斷路器、資源隔離與自我修復功能。spring cloud hystrix 熔斷器6.3. 統(tǒng)一日志管理不同微服務部署在不同節(jié)點上，登錄每個節(jié)點查看日志是比較麻

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

27、 組件進行服務的監(jiān)控，使用nagios 進行服務器等資源的監(jiān)控。 1、hystrix，監(jiān)控和斷路器。我們只需要在服務接口上添加hystrix 標簽，就可以實現(xiàn)對這個接口的監(jiān)控和斷路器功能。 2、 hystrix dashboard，監(jiān)控面板，他提供了一個界面，可以監(jiān)控各個服務上的服務調(diào)用所消耗的時間等。 3、turbine，監(jiān)控聚合，使用hystrix 監(jiān)控，我們需要打開每一個服務實例的監(jiān)控信息來查看。而turbine 可以幫助我們把所有的服務實例的監(jiān)控信息聚合到一個地方統(tǒng)一查看。這樣就不需要挨個打開一個個的頁面一個個查看。. . . . 可編輯6.5. 統(tǒng)一配置管理實現(xiàn)各微服務的統(tǒng)一參數(shù)配置

28、以及版本管理，可采用公司的配置管理平臺或者spring cloud config 配置中心。spring cloud config配置中心spring cloud config就是我們通常意義上的配置中心。spring cloud config-把應用原本放在本地文件的配置抽取出來放在中心服務器，本質(zhì)是配置信息從本地遷移到云端。從而能夠提供更好的管理、發(fā)布能力。spring cloud config分服務端和客戶端，服務端負責將git （svn）中存儲的配置文件發(fā)布成rest接口 ，客戶端可以從服務端rest接口獲取配置。但客戶端并不能主動感知到配置的變化，從而主動去獲取新的配置，這需要每個客

29、戶端通過post方法觸發(fā)各自的/refresh。為解決配置信息能及時通知到各服務，同時減少每個微服務處理配置信息更新的復雜度，為此我們通過消息總線來解決此問題，方案如下：. . . . 可編輯1.git 倉庫、 config server、以及微服務“ service a ”、“service b”的實例中都引入了 spring cloud bus，所以他們都連接到了rabbitmq 的消息總線上。2.從 git 倉庫中配置的修改到發(fā)起/bus/refresh的 post請求這一步可以通過git 倉庫的 web hook來自動觸發(fā)。3./bus/refresh請求不再發(fā)送到具體服務實例上，而是

30、發(fā)送給config server，并通過destination參數(shù)來指定需要更新配置的服務或?qū)嵗?.由于所有連接到消息總線上的應用都會接受到更新請求，所以在web hook中就不需要維護所有節(jié)點內(nèi)容來進行更新，從而解決了通過web hook來逐個進行刷新的問題。6.6. 分布式 session 采用 redis作為緩存組件以及session 的共享組件。. . . . 可編輯6.7. rest 資源響應結構制定規(guī)范和解析方法。6.8. api 調(diào)用鏈追蹤微服務架構上通過業(yè)務來劃分服務的，通過 rest 調(diào)用， 對外暴露的一個接口，可能需要很多個服務協(xié)同才能完成這個接口功能，如果鏈路上任何一個

31、服務出現(xiàn)問題或者網(wǎng)絡超時，都會形成導致接口調(diào)用失敗。隨著業(yè)務的不斷擴張，服務之間互相調(diào)用會越來越復雜。spring cloud sleuth 主要功能就是在分布式系統(tǒng)中提供追蹤解決方案，并且兼容支持了zipkin ，你只需要在pom文件中引入相應的依賴即可。. . . . 可編輯6.9. 單元測試做微服務架構，進行系統(tǒng)測試的復雜度較大，為保證產(chǎn)品質(zhì)量與開發(fā)、測試效率， 單元測試是必不可少的。. . . . 可編輯可采用 mock 方式進行測試模擬， 由持續(xù)集成進行自動化單元測試的執(zhí)行以及結果輸出。6.10. 代碼調(diào)試對于單體架構系統(tǒng)，可直接本地化調(diào)試，但對于微服務架構，接口間的調(diào)用需采用遠程通

32、訊的方式， 也就是說被調(diào)用的服務必須啟動后方可被調(diào)用，因此當微服務增多時，你可能需要啟動大量的微服務或者web 服務器，這給本地化調(diào)用與調(diào)試帶來了困難。解決方案待研究。7. 測試7.1. 自動化測試單元測試：由開發(fā)人員實現(xiàn)。采用 mock 方式進行測試模擬，由持續(xù)集成進行自動化單元測試的執(zhí)行以及結果輸出。業(yè)務測試：開發(fā)進行實現(xiàn)，測試也需考慮如何實現(xiàn)。將多個服務或業(yè)務單元進行串聯(lián)，測試一個完整的業(yè)務，甚至是不同業(yè)務之間組成. . . . 可編輯的系統(tǒng)測試，需要采用相關的自動化測試框架執(zhí)行，如robotframework 自動化測試框架。7.2. 依賴測試也可以稱為接口測試或者契約測試，在微服務逐

33、漸增多的情況下，如何有效保證服務之間能夠按照接口的約定正常工作，即符合契約， 成為微服務實施過程中，測試面臨的主要挑戰(zhàn)。一、 開發(fā)自動化的接口測試工具，1、檢測接口是否滿足約定2、檢測接口是否發(fā)生變化3、檢測接口是否可以正常被調(diào)用。二、測試方法：采取基于消費者驅(qū)動的契約測試，測試架構如下：. . . . 可編輯其優(yōu)勢如下：從價值實現(xiàn)的角度定義契約從消費者使用契約的角度出發(fā)，首先保證消費者基于此契約是可以實現(xiàn)價值的，有了這個前提， 再使用契約來驗證提供者，如果提供者提供的契約同定義的契約一致，則證明提供者提供的契約是能夠?qū)崿F(xiàn)服務消費者的。通過這種方式， 使得更聚焦于如何從價值實現(xiàn)出發(fā)。隔離消費者和提供者的測試對于契約的消費者和提供者可以分開獨立測試，有效解決傳統(tǒng)集成測試服務架構的弊端，將微服務的接口測試成本降到最低。三