1、微服務系統設計方案1 .微服務本質微服務架構從本質上說其實就是分布式架構,與其說是一種新架構,不如說是一種微服務架構風格。簡單來說，微服務架構風格是要開發一種由多個小服務組成的應用。每個服務運行于獨立的進程，弁且采用輕量級交互。多數情況下是一個HTTP的資源APIo這些服務具備獨立業務能力弁可以通過自動化部署方式獨立部署。這種風格使最小化集中管理，從而可以使用多種不同的編程語言和數據存儲技術對于微服務架構系統，由于其服務粒度小，模塊化清晰，因此首先要做的是對系統整體進行功能、服務規劃，優先考慮如何在交付過程中，從工程實踐出發，組織好代碼結構、配置、測試、部署、運維、監控的整個由程，從而有效體現

2、微服務的獨立性與J部署性。本文將從微服務系統的設計階吊、開發階段、測試階段、部署階段進行綜合闡述。理解微服務架構和理念是核心。2 .系統環境1.8名稱版本說明JDKSpringBootSpringFrameworkRibbonkafkaRabbitMQ3 .微服務架構的挑戰可靠性：由于采用遠程調用的方式，任何一個節點、網絡出現問題，都將使得服務調用失敗，隨著微服務數量的增多，潛在故障點也將增多。也就是沒有充分的保障機制，則單點故障會大量增加。運維要求高：系統監控、高可用性、自動化技術分布式復雜性：網絡延遲、系統容錯、分布式事務部署依賴性強：服務依賴、多版本問題性能（服務間通訊成本高）：無狀態性

3、、進程間調用、跨網絡調用數據一致性：分布式事務管理需要跨越多個節點來保證數據的瞬時一致性，因此比起傳統的單體架構的事務，成本要高得多。另外，在分布式系統中，通常會考慮通過數據的最終一致性來解決數據瞬時一致帶來的系統不可用。重復開發：微服務理念崇尚每個微服務作為一個產品看待，有自己的團隊開發，甚至可以有自己完全不同的技術、框架，那么與其他微服務團隊的技術共享就產生了矛盾，重復開發的工作即產生了。4 .架構設計4.1. 思維設計微服務架構設計的根本目的是實現價值交付,更順暢，思維方式的轉變是最重要的。微服務架構只有遵循DevOps理念方可進行的實現微服務技術架構,段實施、以及試點產品優先實施的策略

4、1、前后|端分離，web前端通過經過路由服務調用相應的微服務Mb2、不同微服務之間通過REST方式互相調用3、微服務之間通過消息中間件實現消息交互機制二、配套服務與功能實現1、需要進行相應的自動化服再實現,包括自動化構建、自動化女裝部署、自動化測試、自動化平臺發布（Docker究見，2、管理服務，對，微服務架禮必須配套相應的監捽與管理旭春二日志例理服務庫3、,協作服務，運加Devdps職雁試、運雉的高效溝通與協作，實現開發4.2. 微加E構設計1、整個累統根據業務拆分成若干個子系統或微服務。2、每個子系統可以部署多個應用，多個皮用之間使用負載均衡3、需要一個服務注冊中心Eureka,所有的服務

5、都在注冊中心注冊，負載均衡也是通過在注冊中心注冊的服務來使用一定策略來實現。Eureka可部署多個，進行高可用保證。4、所有的客戶端都通過同一個網關地址訪問后臺的服務，通過路由配置ZUUL網關來判斷一個URL請求由哪個服務處理。請求轉發到服務上的時候使用負載均衡Ribbon。5、服務之間采用feign進行調用。6、使用斷路器hystrix,及時處理服務調用時的超時和錯誤，防止由于其中一個服務的問題而導致整體系統的癱瘓。7、還需要一個監控功能，監控每個服務調用花費的時間等。8、使用SpringCloudConfig進行統一的配置管理，需要考慮與公司的配置管理平臺如何配合使用。9、Hystrix,

6、監控和斷路器。我們只需要在服務接口上添加Hystrix標簽，就可以實現對這個接口的監控和斷路器功能。10、HystrixDashboard,監控面板，他提供了一個界面，可以監控各個服務上的服務調用所消耗的時間等。11、Turbine,監控聚合，使用Hystrix監控，我們需要打開每一個服務實例的監控信息來查看。而Turbine可以幫助我們把所有的服務實例的監控信息聚合到一個地方統一查看。這樣就不需要挨個打開一個個的頁面一個個查看。架構的可靠性保證：在關鍵節點做主備、集群部署，防止單點故障。待后續確認問題：1、AccessControl:Zuul網關提供了相關控制功能，與我司CAS如何結合使用2

7、、ConfigServer:SpringCloud提供了遠程配置中心，與我司的配置管理平臺如何結合使用5.設計階段6.2, 總體設計1、功能規劃：對產品功能進行拆分，拆分為若干個微服務；一個功能可以創建多個微服務弁部署在多個服務器節點上，以便進行負載均衡。2、設計原子服務層，梳理和抽取核心應用、公共應用，作為獨立的服務下沉到核心和公共能力層，逐漸形成穩定的服務中心，使應用能更快速的響應多變的客戶需求。3、為每個服務設計API接口（REST方式）4、為不同的服務進行分類，不同類型的服務需要的資源不同，可以配置不同的資源，包括CPU、內存、存儲等。6.3, 服務拆分原則1、粒度微小：根據業務功能劃

8、分服務粒度，總的原則是服務內部高內聚，服務之間低耦合。2、責任單一：每個服務只做一件事，即單一職責原則。3、隔離性原則：每個服務相互隔離，且不互相影響4、業務無關優先原則：基礎服務，是一些基礎組件，與具體的業務無關。比如：短信服務、郵件服務。這里的服務最容易劃分出來做微服務，也是我們第一優先級分離出來的服務。6.4, 服務規劃為實現負載均衡，允許相同的服務在多個節點注冊相同的服務名，不同的端口。如果沒有前期的規劃，不同的服務提供者可能會注冊相同的服務名，導致消費者調用服務時產生調用混亂。因此，需進行服務名的統一規劃：1、規劃期統一制定每個服務提供者的服務名或者模塊標示。2、服務名的命名規則：M

9、oduleName_ServiceName,且所有字符小寫，不同單詞之間以下劃線分隔。如用戶管理模塊提供了獲取用戶信息的服務，則命名為：user_get_info。3、新增服務名時，需要提出申請，審批通過后方可使用，為減少審批復雜度，可只審批ModuleName,即在模塊內部可以自由增加服務名，不需要進行審批。6.5, 開發策略總體原則：不同的微服務需進行物理隔離。1、SVN策略：SVN上創建獨立的分支，不同微服務的代碼提交不受相互影響；-由配置管理員統一控制。問題：開發分支與集成分支，都將增加很多，維護工作量增加。2、編譯策略：代碼編譯時，各個微服務獨立編譯、打包，杜絕直接的依賴；3、工程構

10、建：代碼開發時，各微服務創建獨立的工程，工程之間不能產生直接依賴4、持續集成：每個微服務獨立執行持續集成。5、版本集成：由統一的集成工具，實現自動化的版本集成，將所有微服務集成到統一的版本發布包中。6.6, 版本策略每個微服務可以獨立制作版本，伴隨著服務的增多，SVN分支增多，版本也將增多，版本管理的復雜度將成指數級增加。在服務之間依賴較多時，每個服務的升級或降級都將影響其他服務的正常運行。因此需執行如下策略：1、所有服務的版本制作交由專業的版本管理員執行。2、采用自動化的版本制作策略，最大程度的減少人工操作。3、每個服務的版本必須有詳細的版本計劃、版本說明，對于版本說明要制定模板，明確需要提

11、交的內容、版本號、SVN標簽等。4、對項目經理的要求提升，需對整體的版本計劃有嚴格的制定，尤其是版本之間的依賴關系要非常明確，版本升級、降級的風險評估需完全充分。5、接口管理：嚴格執行接口管理制度，任何接口的變更必須進行審批、發公告等流程。6.7, 數據庫挑戰與策略每個微服務都有自己獨立的數據庫，那么后臺管理的聯合查詢怎么處理？這應該是大家會普遍遇到的一個問題，有三種處理方案。1）嚴格按照微服務的劃分來做，微服務相互獨立，各微服務數據庫也獨立，后臺需要展示數據時，調用各微服務的接口來獲取對應的數據，再進行數據處理后展示出來，這是標準的用法，也是最麻煩的用法。2）將業務高度相關的表放到一個庫中，

12、將業務關系不是很緊密的表嚴格按照微服務模式來拆分，這樣既可以使用微服務，也避免了數據庫分散導致后臺系統統計功能難以實現，是一個折中的方案。3）數據庫嚴格按照微服務的要求來切分，以滿足業務高弁發，實時或者準實時將各微服務數據庫數據同步到NoSQL數據庫中，在同步的過程中進行數據清洗，用來滿足后臺業務系統的使用，推薦使用MongoDB、HBase等。第一種方案適合業務較為簡單的小公司；第二種方案，適合在原有系統之上，慢慢演化為微服務架構的公司；第三種適合大型高弁發的互聯網公司。建議，我們當前采用第二種方案。6.8, 負載均衡不再采用一般的增加負載均衡服務器的方式進行負載均衡，如F5、Nginx、L

13、VS等，而是把負載均衡的功能以庫的方式集成到服務消費方的進程內，這種方案稱為軟負載均衡（SoftLoadBalancing）或者客戶端負載均衡。在SpringCloud中配合Eureka的服務注冊功能，Ribbon子項目則為REST客戶端實現了負載均衡。MOUYORDASHKIMD使用Ribbon進行負載均衡，其工作原理可以概括為下面四個步驟：1.Ribbon首先根據其所在Zone優先選擇一個負載較少的EurekaServer;2,定期從EurekaServer更新弁過濾服務實例列表；3.根據指定的負載均衡策略，從可用的服務器列表中選擇一個服務實例的地址；4,然后通過RestClient進行服

14、務調用。Ribbon本身提供了下面幾種負載均衡策略：RoundRobinRule:輪詢策略，Ribbon以輪詢的方式選擇服務器，這個是默認值。所以示例中所啟動的兩個服務會被循環訪問；RandomRule:隨機選擇，也就是說Ribbon會隨機從服務器列表中選擇一個進行訪問BestAvailableRule:最大可用策略，即先過濾出故障服務器后，選擇一個當前弁發請求數最小的；WeightedResponseTimeRule:帶有加權的輪詢策略，對各個服務器響應時間進行加權處理，然后在采用輪詢的方式來獲取相應的服務器|AvailabilityFilteringRule:可用過濾策略，先過濾出故障的或

15、弁發請求大于閾值一部分服務實例，然后再以線性輪詢的方式從過濾后的實例清單中選出一個；ZoneAvoidanceRule:區域感知策略，先使用主過濾條件（區域負載器，選擇最優區域）對所有實例過濾弁返回過濾后的實例清單，依次使用次過濾條件列表中的過濾條件對主過濾條件的結果進行過濾，判斷最小過濾數（默認1）和最小過濾百分比（默認0）,最后對滿足條件的服務器則使用RoundRobinRule（輪詢方式）選擇一個服務器實例。性能策略1、網絡優化：優化組網結構，提升網絡間通訊性能；2、配置優化：優化SpringCloud組件集以及其他組件的配置信息，使得性能最大化。技術管理策略I微服務的架構理念中指出各微

16、服務可以獨立建設，可以使用不同的技術、語言、框架等，以便能更快速的使用新技術、新框架等響應特定客戶需求，解決單體應用架構更新技術、更新框架時面臨的困難或阻礙。但這也同時帶來了諸多問題，如下：1、各服務是否可以任意使用自己的技術、自己的組件、框架呢？如果這樣，勢必帶來更大的管理困難、維護困難、技術共享困難。2、公共的方法如何實現共享？如格式化時間的一個簡單方法需要共享，也需要封裝為一個服務接口嗎？管理策略：1、總體原則：仍然需要進行統籌考慮，所有組件統一管理，組件放置在產品倉庫中，每個產品或服務需要共享組件時，從產品倉庫獲取。忸q次h*.，i1d*曲一2、特殊情況：特殊服務需要使用特殊的組件、框

17、架，需提出申請，統籌規劃后進行決策。6.開發階段服務的調用AIP網關調用所有服務通過Zuul網關進行調用，不允許直接調用微服務提供者。Zuul可能會成為系統瓶頸，在項目復雜時可考慮為Zuul進行主備或負載均衡處理Zuul代理機制IMateRPCif<4SpnnfSod!flNfNM*CMausNyfiaiis同步調用采用HTTPREST方式進行調用，針對業務需求可以進行負載均衡，負載均衡的調用方式有兩種：1、FeignClient2、RestTemplate建議使用FeignClient方式進行服務調用。不管是什么方式，他都是通過REST接口調用服務的http接口，參數和結果默認都是通過

18、Jackson序列化和反序列化。因為SpringMVC的RestController定義的接口，返回的數據都是通過Jackson序列化成JSON數據。IMW異步瑁用rabbitMq、kafka、Spring-CloudStream均是可以選擇的方案。SpringCloudStream,基于Redis、Rabbit、Kafka實現的消息微服務，簡單聲明模型用以在SpringCloud應用中收發消息。登陸成功以后，然后通過token或者cookie服務間調用的權限驗證一般我們的API接口都需要某種授權才能訪問,等方式才能調用接口header傳到服務端,如:使用SpringCloudNetfix框架

19、的話，登錄的時候，把登錄請求轉發到相應的用戶服務上，登陸成功后，會設置cookie或headertoken等。然后客戶端接下來的請求就會帶著這些驗證信息，從Zuul網關傳到相應的服務上進行驗證。Zuul網關在把請求轉發到后臺的服務的時候，會默認把一些Cookie、Set-Cookie、Authorization。這樣，客戶端請求的相關headers就可以傳遞到服務端，服務端設置的cookie也可以傳到客戶端。但是，如果你想禁止某些header透傳到服務端，可以在Zuul網關的application.yml配置里通過下面的方式禁用：zuul:routes:users:path:/users/*s

20、ensitiveHeaders:Cookie,Set-Cookie,AuthorizationserviceId:userheader里面也不會剛才說了我們的某個服務有時候需要調用另一個服務，這時候，這個請求不是客戶端發起，他的請求的有任何驗證信息。這時候，要么，通過防火墻等設置，保證服務間調用的接口，只能某幾個地址訪問；要么，就通過某種方式設置header同時，如果你想在某個服務里面獲得這個請求的真是IP,(因為請求的通過網關轉發而來，你直接通過request獲得ip得到的是網關的IP),就可以從headerX-Forwarded-Host獲得。如果想禁用這個header,也可以:zuul.

21、addProxyHeaders=falseheader的Options如果你使用RestTemplate的方式調用，可以在請求里面添加一個有也可以通過如下的攔截器的方式設置，它對RestTemplate方式和FeignClient的方式都可以起作用:BeanpublicRequestinterceptorrequestInterceptor()returnnewRequestinterceptor()Overridepublicvoidapply(RequestTemplatetemplate)StringauthToken=getToken();template.header(AUTH_TO

22、KEN_HEADER,authToken););)服務編排主要的作用是減少項目中的相互依賴。比如現在有項目a調用項目b,項目b調用項目c.一直到h,是一個調用鏈，那么項目上線的時候需要先更新最底層的h再更新g.更新c更新b最后是更新項目a。這只是這一個調用鏈，在復雜的業務中有非常多的調用，如果要記住每一個調用鏈對開發運維人員來說就是災難。有這樣一個好辦法可以盡量的減少項目的相互依賴，就是服務編排，一個核心的業務處理項目，負責和各個微服務打交道。比如之前是a調用b,b掉用c,c調用d,現在統一在一個核心項目W中來處理，W服務使用a的時候去調用b,使用b的時候W去調用co其實可以理解為面向對象的設

23、計，減少方法之間的一層層嵌套調用，而采取一個方法進行業務流程的串聯，如方法W實現一個完整的業務處理，則采取下面方式：functionw()1、調用方法a;2、調用方法b;3、調用方法c;)服務的熔斷處理建服務之同建行調用時，由于各種原因會導致遠程服務不可用或壓力過載等異常導致的熔斷和降級處理解決此I問題。斷路器故隔曼延，此時需曝有一種機制進行保護處理。SpringCloud通過Netflix的Hystrix組件實現（CricuitBreaker）是一種能夠在遠程服務不可用時自動熔斷（打開開關），弁在遠程服務恢復時自動恢復（閉合開關）的設施，SpringCloud通過Netflix的Hystri

24、x組件提供斷路器、資源隔離與自我修復功能。SpringcloudHystrix熔斷器統一日志管理不同微服務部署在不同節點上,登泰每干節點巾日齦比較麻依的,同時對于需要關聯多個微服務日志聯合查看分析的情況將更加麻煩。伴隨節點數量的增加,如果沒有合適的將越來越大匕I臥1管理機制與工具，定位問題、發將成指數級增長，因此需要進行統一日志管理。建立統一的日志管理規范;封裝;2、開發并使用統一的日志組件，為所有微服務提供統一的日志服務，由log4j4、務節點上部署日志采集3、aAgent組件，由此Agent進行日志的采集工專發；LFeLK集合框架。的日志中心，所有日志寫入日志中心。志的實現由公司的“日志管

25、理平金”進行實現，采用的是說明:6.4,統gios進行服務器晞資源的監控。使用HyStrix組件進行服Hystrix標簽，就可以實現對口上添加卜界面，可以監控各個服務上的服務調2、HBSHXDashboardOW們只需要/服1、Hystrix,監控和這個接口的監控和斷路器功能。控管理"控，使用用所消耗的日】e,監控聚合，使用3、來查看。而3面板，他提供Hystrix監控，我們需要打開每一個服務實例的空/息bine可以幫助我們把所有的服務實例的監控信息聚合到一個地方統查看。L.這樣就不需要挨個打開一個個的頁面一個個查看。Spring6.5,統一配置管理實現各微服務的統一參數配置以及版本

26、管理，可采用公司的配置管理平臺或者CloudConfig配置中心。LgftAIkSpringCloudConfig配置中心SpringCloudConfig就是我們通常意義上的配置中心。SpringCloudConfig-把應用原本放在本地文件的配置抽取出來放在中心服務器，本質是配置信息從本地遷移到云端。從而能夠提供更好的管理、發布能力。SpringCloudConfig分服務端和客戶端，服務端負責將git(svn)中存儲的配置文件發布成REST接口,客戶端可以從服務端REST接口獲取配置。但客戶端弁不能主動感知到配置的變化從而主動去獲取新的配置，這需要每個客戶端通過POST方法觸發各自的/r

27、efresh。為解決配置信息能及時通知到各服務，同時減少每個微服務處理配置信息更新的復雜度，為此我們通過消息總線來解決此問題，方案如下：1.Git倉庫、ConfigServer、以及微服務“ServiceA"、aServiceB”的實例中都引入了SpringCloudBusL所以他們都連接到了“RabbitMQ的消息總線上。.從Git倉庫中配置的修改上發起/bus/refresh讓PT/這一步可以通過Git倉庫的WebHook來自動觸小矛?IyI./bus/refresh請求不再發送到具體服務實例上，而是發送給勺*1ConfigServer,并通過destination參數來指定需要

28、更新配置的服務或實例。.由于所有連接到消息總線上的應用都會接受到更新請求，所以在WebHook中就不需要維護所有節點內容來進行更新，從而解決了通過WebHook來逐個進行刷新的問題。分布式session采用Redis作為緩存組件以及session的共享組件REST資源響應結構制定規范和解析方法。API調用鏈追蹤都會微服務架構上通過業務來劃分服務的，通過REST調用，對外暴露的一個接口，可能需要很多個服務協同才能完成這個接口功能，如果鏈路上任何一個服務出現問題或者網絡超時，形成導致接口調用失敗。隨著業務的不斷擴張，服務之間互相調用會越來越復雜。w叩削1RequestKiIAI(Frontend)

29、，加fB(MddleTier)CjSpringCloudSleuth你只需要在pom文件/II%應的儂賴即可兮電式系統中提供追蹤解決方案，并且兼容支持了zipkin,I(Backend)I|DlpwlMiMmm，6.9,單元測試做微服務架構，進行系統測試的復雜度較大,為保證產品質量與開發、,測試效率,單元可采用Mock方式進行測試模擬"TU由特繳集般進行咱動他單兄測試的執伸斗及結果輸出6.10.代碼調試對于單體架構系統,可直接本地化調試,相對于微服務架構，接口，間的調用需采用遠程通訊的方式,也就是說被調用的服務必須啟動后方可1.fil因此當微服務增多時，你可能需要啟動大量的微服務或者服務器,webI單元測試:由開發人員實現。解決方案待研究。化調用與調試帶來了困難。mI采用'Mock方式進行測試模擬7.測試7.1.自動化測試.