宜信微服務架構落地及其演進|分享實錄

1、應用服務架構演進及微服務架構介紹

1.1 應用架構的演進歷程

應用服務架構一直處於不斷演進的過程當中，上圖經過對比5種比較主流的架構模式，展現應用架構的演進歷程和變化。

• 單體架構（All in One）。在業務發展初期，爲了快速落地應用，知足客戶需求，通常會使用All in One的單體架構。單體架構的特色是：全部模塊都耦合在一個進程裏，系統徹底封閉且很複雜，牽一髮動全局。
• 豎井式架構（Vertical Application）。隨着業務的增加，單體架構愈來愈臃腫，咱們對系統作了垂直化的拆分，應用架構進入第二階段即豎井式架構。豎井式架構，就是根據業務屬性將一個大的單體拆分紅一些不一樣的模塊或子系統，子系統之間沒有直接關聯。豎井式架構依然存在緊耦合的問題，系統也是徹底封閉的，且存在大量的重複代碼拷貝及模塊功能需大量重複造輪子的狀況。

單體架構和豎井式架構都是圍繞web容器打包及部署的架構模式，隨着業務的快速發展，要求實現服務的快速迭代和快速交付，應用架構也由此演進爲以服務爲中心的架構模式。主流的面向服務的架構模式有：RPC架構、ESB中心化架構和微服務架構。

• RPC架構。RPC架構在如今的應用系統中仍是比較常見的架構模式，適用於高併發場景，性能比較好。Dubbo就是一個典型的RPC架構。RPC架構也存在一些問題：經過共享分佈式對象實現遠程方法調用，若是在其中一個對象裏添加一個屬性，就會對共享對象的生產者與消費者產生影響，因此RPC架構也是緊耦合的模式，系統交互採用RPC私有TCP協議，服務生產者和消費者存在強代碼依賴，異構系統集成不友好。
• ESB中心化架構。ESB中心化架構實現了鬆耦合，依賴於ESB消息總線技術實現異構系統的信息交互和集成集中式架構管理，所以它雖然是面向服務的，但它本質上依舊是一箇中心化的架構。其優點在於：基於WebService技術，重量級的消息通信機制，咱們稱之爲「智能管道啞終端」，當團隊規模比較大、要實現異構系統集成時，它能夠提供統一的解決方案和技術實現方式，快速集成異構系統對外服務。ESB中心化架構的問題也比較明顯：中心化架構難以知足靈活性的服務迭代和需求交付。
• 微服務架構。微服務架構實現了系統解耦和持續集成，有清晰的服務邊界，粒度相對ESB架構和傳統SOA架構來講更小，使用輕量級的通信機制交互，具有更強的擴展性和彈性，可以更靈活、更快響應業務變化。

經過上述對比，咱們不難發現，應用服務架構是在不斷演進的，並且其演進背後存在必定的邏輯，服務架構的演進主要取決於如下2個維度：

• 業務維度，技術架構是由業務發展所處的時期和階段決定的，技術架構要可以解決業務發展過程當中的痛點。在進行架構選型時，須要考慮這個架構是否能知足當前業務的需求，業務需求可否隨着架構的演進實現增量式的迭代。
• 技術維度，一方面要知足非功能需求，使得業務快速跟上技術生態的發展；另外一方面出於商業的技術考量，好比去IOE、 去V、 採用開源的技術解決方案的需求，逐漸完成服務底層使用的商業軟件的技術隔離，知足業務快速交付。

1.2 微服務架構的定義

關於微服務的定義，此處引用ThoughtWorks首席科學家Martin Fowler給出的描述。

其中如下特性值得特別注意：

• 微服務架構是一種架構模式，提倡將單⼀應⽤程序劃分紅⼀組⼩的服務。
• 服務之間採用輕量級的通訊機制。
• 服務能夠獨立部署。
• 應當儘可能避免統⼀的、集中式的服務管理機制。
• 具體的⼀個服務能夠選擇合適的語⾔、⼯具對其進⾏構建。

Martin Fowler對於微服務架構的表述更偏向學術上的定義，沒有給出明確的落地標準或規範，只是提供了一些構建微服務架構的原則。

1）面向開發者和業務實現

• 拆分紅粒度小的服務。
• 各自獨立的進程實現服務運行隔離。
• 服務運行經過輕量級的基於HTTP協議的RESTful API的通訊機制進行。
• 服務關注圍繞業務領域之上構建。

2）面向服務的交付和運維

• 在服務交付方式上，強調可獨立部署。
• 支持去中心化的設計，服務通常不須要集中化的管理。

1.3 如何篩選微服務

微服務架構模式有如此多的優勢，那是否是全部的業務都要採用這種架構模式呢？又該如何篩選微服務？

左邊圖中，橫座標表明系統複雜度、縱座標表明開發生產力、藍色線表示微服務架構、綠色線表示單體架構。由圖可知，當項目複雜度較低時，單體架構的生產力更高；隨着項目複雜度愈來愈高，單體架構的生產力逐漸降低，微服務架構的生產力則顯著提升。

1）3種場景能夠考慮使用微服務（Are you tall enough? ）

• 規模大，團隊超過10人。
• 業務複雜度高，系統超過5個子模塊。
• 須要長期演進，項目週期超過半年。

2）其餘因素篩選微服務

• 軟件功能變化頻繁，以快速迭代、縮短交付週期爲核心的業務。
• 模塊有獨立的生命週期，微服務強調服務複用，減小重複造輪子，實現降本增效。
• 有獨立的隔離性需求和擴展性需求（容錯）。
• 簡化的外部依賴。好比Facade模式場景，後端系統使用統一的對外暴露的形式提供服務。

1.4 如何拆分構建微服務

鑑別出哪些業務須要使用微服務架構模式後，須要決定如何拆分和構建微服務。

1）服務拆分

如何進行服務拆分，是在微服務過程當中業務方常常會問到的問題。

其實不少團隊已經開始在作一些微服務化的工做，好比把大的工程拆分紅不一樣的模塊或子系統，這種對業務模塊進行的靜態劃分，至關於已經完成了微服務改造的第一步拆分。

上圖是DDD（領域驅動設計）的開發模式，若是業務方案已經肯定採用微服務的架構模式，在整個工程領域咱們傾向於使用DDD模式來對業務架構和服務進行拆分。

DDD是基於領域模型的建模而不是數據庫表驅動的建模，須要咱們對業務領域有深入的洞察，瞭解服務的邊界和上下文信息傳遞。

康威定律指出：在微服務架構和設計系統組織，其產生的設計等價於組織間的溝通結構。就是說微服務架構不只是技術上的演進，同時對使用技術的組織提出了要求，拆分的服務是咱們和服務之間的溝通方式。

2）微服務構建

咱們採用微服務的12因子做爲微服務建設的架構原則。微服務的12因子也叫雲原生12因子，它提供了一種業務上雲或微服務改造的最佳實踐。重點介紹其中幾個因子：

• 基準代碼，建議項目使用一份基準代碼、多份部署。項目在拆分時可能會存在多份基準代碼，形成大量重複性的不一樣版本的代碼共存的現象。在進行微服務構建時，須要把公共服務和公共代碼抽取出來，統一支撐不一樣版本的業務。
• 顯式依賴，顯式聲明依賴關係。對於 Java 程序，在 Gradle 或者Maven中寫明依賴關係；
• 配置，在環境中存儲配置。根據當前的環境變量決定使用什麼樣的配置文件。
• 後端服務，把後端服務當成一個附加資源。
• 構建、發佈、運行的分離機制，強調服務和構建在運行時，不能夠直接修改運行中的代碼，而是須要經過構建發佈流程統一發布。
• 無狀態進程，以一個或多個無狀態的進程運行應用。

1.5 微服務架構2種建設思路

微服務看起來很是好，但實際上是須要一個技術體系或平臺體系來支撐的，若是沒有這樣一個服務架構平臺體系的建設，不推薦使用微服務。

微服務架構建設分爲2種思路：SDK模式、ServiceMesh模式。

1）SDK模式

典型表明是SpringCloud，SpringCloud是基於SpringBoot的一整套實現微服務的框架。SDK模式的底層運行平臺能夠是PaaS平臺，也能夠是Kuberneters平臺或Docker容器。

• 優點：面向應用和開發人員，定製化、協議支持靈活，適合徹底自治的服務狀態，方便線下調試，對操做系統平臺無依賴。
• 缺點：應用需引入額外SDK依賴包，SDK自己佔用內存及系統資源，對業務是侵入性的；須要構建微服務基礎設施作業務能力支撐；須要使用SideCar模式實現異構系統集成。

2）ServiceMesh模式

Istio 是ServiceMesh模式的典型表明。ServiceMesh模式的優缺點與SDK模式正好相反。

• 優點：不須要額外引入SDK依賴包，對應用無侵入，且對Kubernetes自然友好支持。
• 缺點：部署比較複雜，對底層系統有必定的依賴；通信協議類型支持受限，須要依賴Mesh平臺兼容。

2、SpringCloud微服務生態體系介紹

SpringCloud是基於SpringBoot發展而來的一整套成熟的微服務架構解決方案。SpringCloud具備如下優點：

• 面向開發者，以開發者爲中心，開發者生態友好。
• 以Java技術棧爲主要開發語言，代碼可複用，微服務轉型成本低。
• 基礎設施完備，提供端到端的微服務架構解決方案。
• 有不少大廠作背書，如Pivital、Netflix,、alibaba等公司都是其生態和源代碼貢獻者，技術經歷過大規模商業應用的考驗。

2.1 SpringCloud的技術生態

SpringCloud自己也是一個逐漸演進的架構模式：最先是基於IOC/AOP的編程思想產生的；而後在Spring的基礎上發展出SpringBoot，基於註解的方式實現快速的應用開發；後來在SpringBoot的基礎上開發出SpringCloud底層微服務構架。

上圖展現了SpringCloud的技術生態，SpringCloud技術棧包含了不少技術模塊，好比Ribbon、Zuul、Eureka、SpringCloud Stream等，這些技術模塊共同組成了SpringCloud生態圈，爲開發者提供豐富的微服務架構基礎設施支撐。

2.2 微服務和SpirngCloud架構的複雜性

微服務和SpirngCloud的架構是比較複雜的，如配置管理、服務註冊與發現、API網關、打包部署調度、安全、服務故障自愈、流量控制和彈性伸縮等非功能需求，都是微服務須要包含的架構模塊。上圖中藍色字表示SpirngCloud、Kubernetes等用來解決雲原生和微服務架構問題的技術方案。

從圖中能夠看出微服務架構的複雜性，要想實現一套微服務架構來支撐和交付業務，須要在底層封裝不少基礎組件，構建一套底層基礎架構來隔離底層的非功能需求，作到讓業務系統無感知、平滑地對外提供服務。

3、宜信微服務架構和SIA網關的4種模式

SpringCloud提供的框架或基礎設施是一個半成品，咱們在SpirngCloud的基礎上進行了二次開發，抽象和封裝了一些微服務架構的通用基礎設施平臺，不一樣的業務團隊共享這些基礎設施，下降技術學習和接入成本，讓業務團隊更專一於業務邏輯的實現，聚焦業務開發。

3.1 宜信微服務架構

上圖所示爲宜信的微服務架構：

• 微服務網關，sia-gateway使用了去中心化的網關接入方案。
• 元數據服務層，用Eureka-plus和sia-config對註冊中心Eureka和配置中心作了加強與優化。
• 任務管理，基於微服務的思想，開發和開源了微服務任務調度平臺SIA-TASK。
• 容器平臺，實現了快速的自動化構建、部署和服務編排。
• DevOps，微服務的交付頻率、速度比較快，須要有持續集成、持續開發工具和手段來保障項目質量和服務正常運行，對此咱們有自研的UAVStack監控系統、自動化測試系統等工具鏈。

3.2 SIA微服務網關架構

有別於其餘的架構模式，微服務架構裏出現了一個重要的基礎設施變化-增長了微服務網關模塊。網關主要解決的問題是：服務拆分以後，每個服務粒度都比較小，服務之間的交互會呈現網狀的結構，須要一個聚合的節點來聚合這些微服務。

所以咱們在SpringCloud微服務架構的基礎上二次開發出SIA微服務網關，如圖所示，重點介紹其中的2個核心模塊：

• 網關組，網關組裏封裝了兩種網關：同步網關和異步網關。
• OAM，自助式網關管理平臺，全部業務節點的生命週期管理都經過這個模塊來進行。

3.3 SIA微服務網關的4種模式

SIA微服務網關的4種模式：同步託管式、同步註解式、異步託管式、異步註解式。

1）同步託管式

採用單一源碼庫進行代碼管理，交付方式是容器交付，去中心化的設計。目前大部分生產環境和業務都採用同步託管模式。

• 優勢：網關交付對業務方徹底透明；只要在容器平臺申請一個網關資源，就能夠獲得網關服務；基於Filter開發運維簡單，容量小。
• 缺點：定製化不夠強。

2）同步註解式

在跟業務團隊對接時，咱們發現不少業務系統已經實現了一些獨特的業務邏輯，難以遷移到網關，因此咱們採用一種比較兼容的註解的方式去適應這些業務邏輯，在原有項目的基礎上加一個註解，將它們歸入到整個網關管理體系中來。同步註解式是基於SpringCloud-Zuul 1實現的分佈式微網關體系，管理業務方源碼庫，根據業務方環境進行交付。

• 優勢：對項目的控制力比較強，業務團隊獨立運維，支持擴展定製化；基於Filter開發運維簡單，容量小。
• 場景：業務定製化場景比較多。若是要加載初始化、加大資源，或對業務的Filter攔截機制有定製化需求，均可以用同步註解模式。

SpringCloud和Zuul使用的後端技術是基於Servlet，其線程處理模型是一個請求對應一個線程，當請求量過多，線程棧溢出，就會佔用很是多的資源，致使網關沒法提供額外的線程資源來處理新進來的請求。所以咱們採用了SpringCloud自研的SCG技術方案。

SpringCloud-Gateway基於Netty和反應式編程模式，採用收斂式的線程處理模型，只要用少數線程就能夠處理高併發的流量請求。目前已經實現了基於SpringCloud-Gateway的異步模式，當同步模式在線上運行過程當中出現資源透支的狀況，就選擇使用異步模式。異步模式也分爲2種：異步託管式、異步註解式。

3）異步託管式

經過單一源碼庫進行代碼管理，採用容器交付。主要使用場景是流量型，若是業務多對高併發、高吞吐場景，建議使用異步託管式。

4）異步註解式

若是想在異步網關基礎上作定製開發，可使用異步註解的模式。

網關的4種模式來源於業務的需求：爲兼容業務已有邏輯演進出註解模式；當出現性能瓶頸、資源浪費時，採用異步模式應對高併發流量。

上圖是網關測試環境的一個截圖， 包括上述4種模式。每個小方格表明業務的一個網關組，方格中的小圓圈表明它屬於哪種網關。業務系統在選擇網關模式時要作一個判斷：訴求是支持業務的快速集成，仍是對流量有必定要求。

3.4 SIA微網關的核心Feature

如圖將SIA微網關的核心Feature分紅2個層面：

• 數據面，負責數據包的處理邏輯。路由轉發、負載均衡、灰度發佈、日誌審計、熔斷限流等都是從數據層面對流量進行管理。
• 控制面，負責服務粒度上的管理。統一視圖管理、多租戶管理、註冊中心、配置管理、路由組件綁定等是從控制層面來保障和管理服務。

3.5 SIA微網關對微服務的生命週期管理

微服務網關貫穿了整個微服務生命週期的管理。

SIA微服務網關的功能包括：

• Swagger UI、模塊複用對應服務文檔中心模塊的功能。
• 動態路由、共享能力集中在分佈式網關節點。
• 日誌管理、管控組件是網關Master提供的功能。

各功能模塊對應的生命週期：

• 服務文檔中心，對應整個軟件生命週期的初期開發和設計階段，網關提供一個個統一的API視圖，前端和後臺能夠經過Swagger UI來聯調開發。
• 分佈式網關節點，在開發和部署階段會涉及到一些共享能力的部署和運行。
• 網關Master，在運維階段經過自動化運維提升運維效率；在管理方面，提供數據統計的功能，生成數據報告用於管控。

SIA微服務網關做用於軟件生命週期的各個階段，經過標準協同、業務測試/前端後端溝通、服務模塊複用、可視化管理、數據統計管控等實現業務的統一融合、降本增效。

3.6 總結：微服務架構與中臺&後臺

2016年，Gartner 發佈了一個關於應用變化速率的報告《Pace-Layered Application Strategy》，以應用變化速率爲標準將業務應用分爲三層：

• SOI-敏態業務：好比互聯網業務，需求變動快，要求快速迭代 、快速交付。
• SOR-穩態業務： 好比傳統業務，變動週期⻓、變化頻率低、變化成本高、變化⻛險高。
• SOD-中臺業務： 齒輪匹配失衡，中臺就像是在前臺與後臺之間添加的⼀組「變速⻮輪」，將前臺與後臺的速率進行匹配，提高⽤戶響應力。

中臺的目標是圍繞業務組織進行可複用能力的有機整合，協助業務落地實施、改造、試錯、轉型，提高組織效率，下降系統成本。

中臺和微服務有什麼關係呢？微服務架構是面向開發的架構，不少基礎服務能夠沉澱到微服務架構裏，同時，微服務架構把中臺的能力快速釋放出來，知足敏態業務快速變動的業務需求。

4、應用場景及典例分析

4.1 分解&聚合

上圖是路由管理裏的一個截圖，當一個大的單體或不一樣的服務要對外提供統一服務時，能夠把服務聚合到網關上；同時一個巨型應用也能夠經過網關分解成微服務。

4.2 複用&個性化

微服務架構中有不少非功能需求，或者說是技術導向型的需求，包括日誌管理、限流、藍綠部署、版本管理等，能夠經過組件的方式下沉到網關上，業務系統經過將服務與組件綁定實現對組件功能的複用。

咱們還提供了一個插件機制，當業務有獨特的需求，能夠根據其業務邏輯在網關上進行功能的個性化定製。

4.3 API&契約

在開發或先後端聯調時，先後端能夠經過網關服務文檔中心的Swagger UI功能模塊訪問後端服務調用接口的分析。

只要在後端服務之上加一個Swagger註解，網關就能夠把全部對外暴露的服務抓取出來，這至關因而一種契約式的開發。

4.4 容錯&保護

咱們對網關應用作了容錯和保護機制，固然這也是SpringCloud自己自帶的一個技術模塊，咱們的容錯機制是基於SpringCloud的Hystrix實現的，當發現後端服務調用請求一直在返回錯誤時，會開啓熔斷，避免因爲一直髮送錯誤請求致使雪崩的狀況發生。

除此以外，咱們還會採用Guava限流的方式對服務進行保護。在大促或秒殺的場景下，會有大量請求進來，這時會經過限流來保護服務的穩定。

4.5 監控&治理

宜信微服務架構平臺有一個很重要的功能是網關服務運行狀態和後端鏈接狀態可觀測，提供了不少監控方面的功能組件，如圖所示，能夠統計當前請求的頻率、服務健康度。

預警方面重點介紹網關拓撲圖。當請求失敗，當前鏈路出現異常，經過網關拓撲圖能夠快速跟蹤和判斷業務系統哪一個節點出現問題，而後對有問題的節點進行摘除或其餘操做。

咱們的網關運行在Docker平臺上，Docker平臺在出現問題或重啓以後日誌會丟失，咱們的日誌系統會把日誌歸集，存儲到ES中，便於對歷史日誌溯源。

4.6 統計&分析

網關中有一個組件叫「監控統計」，這個模塊默認是不打開的，若是你想對請求作延時，或者想看請求的明細調用狀況，能夠經過組件管理中打開這個組件，對容器的請求作統計和分析。監控統計組件會對當前請求的最大延遲、最小延遲、失敗個數、平均延遲進行排序，一目瞭然。

5、微服務化架構建設遇到的問題

5.1 設計初期的問題

1）如何隔離業務網關，同時有統一的管理視圖？

構建微服務網關初期，業務同事比較關注咱們的業務網關和別人的網關是否存在耦合問題，他的業務請求是否會影響到我。咱們選用去中心的網關設計方式，同時經過OAM實現對全部網關節點的統一管理。

2）平臺型系統建設初期是否要考慮同步異步網關融合？

咱們的微服務網關是按照DDD領域驅動模式來建設的，沒有把網關綁定在某一個特殊的技術實現上，而是把它做爲一個抽象封裝來統一管理後端的節點，若是換一種技術實現也不會影響到前端業務的正常工做。所以在架構建設初期要考慮清楚你的業務系統和後端技術架構之間是否解耦。

5.2 使用開源方案的問題

3）開源系統自己的bug

雖然每一種開源方案在開源以前都通過了長時間的考驗，但其實依然可能存在bug，基於這些開源方案進行二次開發時仍可能遇到一些坑，咱們會不斷對開源系統進行bug修復和功能加強。

4）系統的性能問題

Zuul自己存在性能瓶頸，當出現性能問題時，咱們考慮是否是要用線程收斂的模式來加強網關的性能。

5.3 上線生產運維方面的問題

5）如何克服Eureka註冊中心的CAP問題？

在網關應用中會遇到Eureka的CAP問題，由於Eureka消息註冊以可用性（Availability）優先，在一致性（Consistency）上相對較弱。爲解決這個問題，咱們基於Eureka的特色提供SynchSpeed服務，若是業務須要保證狀態一致性，能夠開啓這個服務。

6）SpringCloud與SpirngBoot不一樣版本的兼容問題？ K8S平臺與微服務註冊中心狀態同步？

這兩個問題是指當雲容器平臺的狀態發生變動，卻沒有及時通知到註冊中心，致使服務在兩個平臺的狀態不一致，這就須要作上下文關聯繫統（StakeHolder）的整合。

內容來源：宜信技術學院第8期技術沙龍-線上直播|宜信微服務架構落地及其演進

主講人：宜信高級架構師 & 宜信科技中心基礎研發部SIA微服務網關負責人王佩華