豐雋瑋：非常榮幸就我們在微服務架構上的實踐和大家做交流，主要內容是這幾個部分，一是我們目前對微服務這套體系的理解，二是我們在微服務架構設計上有哪些思考，三是我們在微服務落地方面的實踐，四是我們基於微服務的實踐看到的一些問題，重點關注治理方面。

其實大型的金融企業都是經過三個系統架構發展的階段，一是分散的階段，也就是各地的機構會自建他的系統，這種系統大多是單體架構的應用，非常簡單直接，主機時代典型的架構。

到了2000年左右，大家都在做總部大集中的事情，這時候是一種垂直的架構，很多很多的系統以豎井煙囪式來形成一組對業務的支撐能力。這個時候各系統之間的互動，我們就引入了SOA的架構方式，這種粗粒度、中心化的面向服務架構。

後來就步入了網際網路架構的時代，也就是雲階段。這個時候基礎設施已經做到了雲化，系統慢慢的向分散式架構、容器化、微服務、雲原生去演化，這時候強調原子服務，自治獨立部署、平臺治理，主要是這三個架構演化的過程。

技術趨勢一直在關注和強調共享和重用，它們相輔相成推動了技術的發展，並且都是採用同樣的思路，以大拆小的思路，把底層的技術難題往應用層去推，讓應用層解決這些問題。主要目前關注的四塊領域：

一是微服務這個領域，強調服務重用共享，流程重組、服務編排以及怎麼去敏捷開發、交付和部署。

四是平臺化的概念，我們把技術和業務做了一個分離，獨立成一個平臺來提升重用共享。對於技術的標準和一些落地的通用的技術服務，通過平臺化的方式提供。

SOA和微服務到底是什麼樣的關係？微服務不是憑空出來的，我們認為它還是SOA概念的一個演進，但微服務強調的是元件的拆分和獨立變化。對於SOA它主要解決整合技術標準和服務重用。微服務架構是在SOA的基礎上，解決實現SOA服務的載體自身怎麼去獨立快速變化的這麼一個問題。我們通俗的理解，微服務架構就是把一個大系統按照業務的功能拆成職責單一的小系統或者叫它元件，再利用一些簡單的方式使很多的小系統互相協作起來，形成我們想要的大系統，就是一個拆和合的過程。

我們認為微服務不是一個銀彈，既有優點也有挑戰。優點是簡單靈活、高內聚鬆耦合，由不同的團隊獨立開發運營，可以使用不同的語言和工具、輕量化的通訊互動、去中心化。在真正落地的層面上來看它有哪些優點？我們認為就是快和敏捷。對於我們開發過程來講，有利於敏捷開發，服務因為拆分細了，可以有一些小團隊獨立開發維護，效率提高了，溝通成本也低了，響應也快了，研發週期也短了，更好適應業務的變化。

二是便於橫向擴充套件，可以獨立分散式的部署，需要效能擴充套件的時候可以做一些有針對性的措施。

四是服務的獨立部署，服務間通過API介面依賴，把技術選型做到較強的無關性，有利於技術的快速升級。

微服務整體的架構規劃和架構設計層面對我們提出很多的挑戰，另外是跨服務的全流程測試更復雜了，全鏈路的運維工作也更加複雜了。還有一個最經典的問題，對於金融企業來講，事務一致性的問題是非常嚴重的，因為涉及到金融的交易，強一致性到最終一致性的轉變如何適應。

一是我們的需求交付的時效要求越來越高了，因為整個應用的重心從原來的E端、B端過渡到C端，對C端使用者的需求，要求IT如何去快速的迭代，敏捷的交付，提出一個很大的挑戰。

二是我們的系統壓力越來越大，我們也在做一些去小型機的工作，基本上X86已經全覆蓋了，原來這些巨無霸的應用再也沒有一個非常強大的集中式硬體體系去支撐它了，它的CPU、IO越來越高，如何去解決它？這是給我們帶來的兩個問題。

我們要做微服務化其實還有一些先決條件，首先對人員團隊層面來講，我要去做微服務化，需要敏捷交付的團隊，基於契約化去做團隊的協作，需要敏捷的平臺支撐的運維團隊，這是需要有一個持續改進的團隊組織來形成。

二是對技術儲備來講，我們的計算資源如何快速分配。我們原來是物理機過渡到虛擬機器，再過渡到容器化，可以讓全新的伺服器裝置在幾個小時乃至幾分鐘內就交付出來。關於基礎運維和監控層面如何快速檢測、定位有問題，這是一個必要必備的條件。另外是關於快速部署、自動化流水線這個層面，怎麼從開發到測試到預發、生產，有一個全流程的流水線去支撐它，這是我們在技術層面做了一些儲備。

下面講一下我們在架構設計層面的沉澱。這是微服務架構的一個例項，我們會有很多面向業務域的一些微服務，通過API的方式提供出來，然後再通過面向不同業務域的API閘道器向外提供服務，不管APP也好或者微信也好。底層會有一個微服務的治理平臺，統一的實現註冊、發現，熔斷，鏈路跟蹤等一些功能。

應用架構目前分了五層，最上層是終端使用者的裝置層，進來之後有一個企業級的負載均衡器來提供流量的接入。再下面是閘道器層，是按照不同的業務域提供的，將一些請求反向路由到微服務，負責技術接入，這一層跟業務邏輯無關的，無狀態部署。再下一層是BFF層，面向不同業務域聚合服務，裁剪加工後暴露給前端請求。再下面一層是領域服務層，這一層提供支援業務的核心領域服務，比如一些客戶服務、保單服務、支付服務等等。再下面是資料訪問層，提供對資料儲存、資料訪問的支援。。

另外我們建了兩個平臺，一個是微服務的登記平臺，主要是針對微服務和API生命週期管理的，還有一個微服務執行時的管理平臺，包括服務的註冊、發現、鑑權、熔斷、降級、鏈路跟蹤這些公共的服務。

再講一下我們如何考量這個微服務拆分的，有兩個維度。一是基於領域模型和業務因素去考量，二是基於技術和團隊因素考慮。首先是單一職能的原則，第二是業務差異性，這兩個結合起來考量，領域和業務因素。

這是一個例子，保險行業裡承保系統是非常關鍵的系統，我們基於DDD的領域驅動設計方式，對保單管理這一塊進行一個拆分。就拆分成了報價、投保、核保、續保等等一些環節。在投保環節中就發現了業務的差異，包括產品線不同，客戶群體不同，或者渠道不同的話，相應的投保流程服務也都不同。那麼再繼續拆，就拆成通用的投保、意外險的投保、個人車險的投保等等，面向各種不同場景的微服務。

下面是基於團隊和技術層面的考量。首先是運營時的隔離，會根據一些特定功能單獨拆分出來作為一個微服務。舉個例子，有一些檔案上傳的API，它的特徵是響應時間長，對IO的依賴也比較多，執行緒池也需要特殊配置，這種情況會把這些微服務做一些隔離。第四個原則是非常經典的康威定律，到底團隊影響拆分還是拆分影響團隊，是需要去平衡的。比如我們一些存量的系統，因為去拆分服務了而進行了團隊的拆分，可能會最後影響到團隊的穩定性和歸屬感。反之，如果團隊負責多種業務，也沒有明顯職責區分的話，這時候要考慮團隊的拆分，明確拆分後的團隊職責。

總結一下，對於正在執行的系統，如果我們要做微服務化的話，如何拆分和拆分成多大的粒度，本身是不能太過理論化和理想化的，還是需要深入到團隊內部和業務場景裡去，瞭解人和程式碼。既不是拆遷隊的方式，簡單粗暴，也不是修繕的方式，應該是合理的搭積木的這種方式。因為團隊不同、專案不同，實踐也是不同的，也沒有很多參考，所以找到自己團隊合適的方法就可以了。

再講一下我們在微服務實施方面的一些實踐，首先是技術選型。對於我們技術選型主要考量的是四個維度，一是本身的技術和功能這個維度，二是專案的運作模式，三是提供者的背景，四是生態環境。簡要來講，是不是這種技術大量在線上已經投入生產了，二是你的團隊是不是能cover住這種技術，基於這些點我們做一個技術的選型。

這裡列了一些主流的分散式框架，我們在考量的時候，其實也是基於上面幾個原則做了一些考量，同時我們也在關注Service Mesh，但其目前還不具備生產投產的基礎。基於這幾個評判維度我們做了一些微服務的技術選型，我們目前整個團隊還是以Java技術棧為主，這裡面有一些是基於開源專案的使用和修改，也會有一些是通過自研提供的能力。

這是我們在微服務實施過程中的階段，我們叫1.0階段，其實是一個專案級的階段，大量的C端應用起來的時候，我們把核心系統裡的服務能力重新網際網路化，做了一些微服務的拆分，拆完以後基於我們自研的API閘道器，提供出API服務出來，在前端對C端使用者提供業務能力。

這種模式在過程中也發現一些問題，首先並沒有真正做好服務的複用，其它專案要用到這些服務的時候，並沒有提供這個能力出來。二是缺少必備的一些服務治理的能力。後來就到了企業級的2.0階段，這個階段我們是把微服務按應用域歸併，在應用域內，一系列的服務通過域內的閘道器提供能力輸出。域和域之間還有一些域間閘道器，提供跨域的服務能力輸出。同時還通過登記平臺和管理平臺提供一些必備的治理能力。

剛才講了治理，我們面對治理有哪些需求呢？我們總結一下，兩個維度。一是服務的監控維度，二是服務的管控維度。服務的監控維度主要是哪些？服務的基礎資訊、質量、容量、依賴、分佈、統計、元資料、查詢、報表以及APM監控等等，對服務的全生命週期全鏈路跟蹤的維度去考量的。

二是服務的管控能力，對服務的上下線、服務的文件、升級、路由、限流降級、授權等。基於這個治理的需求，我們從技術層面也做了一些思考。因為整個服務治理來講是一個很大的體系，時間有限我也不展開講了。就從技術層面來講，首先對於開發環境，我們提供了整個微服務開發需要依賴的SDK、規範、專案模版、MockServer等。另外對微服務全生命週期管理提供一個登記平臺，包括業務域的管理、業務系統、應用、微服務到API以及相應的版本上下線整個生命週期的管理，覆蓋了服務的靜態、動態和管理屬性。

通過管理平臺解決微服務執行時全景的監控和管控，包括執行時詳情的檢視，路由的規則、流量的策略，包括配置管理、監控統計，API Store，註冊中心、配置中心的一些設定，這是一些截圖。這是系統的拓撲圖，這是呼叫查詢的跟蹤，斷路器，鏈路分析等。

對於開發環境標準化這一塊來講，一個企業如果要做微服務的話，首先對於技術的標準化這一塊，如果真正做到規範化和標準化，對於微服務化可能會帶來很大的一些便利。我們也做了很多標準化的工作，包括提供了一些規範和腳手腳，應用的開發規範、介面的規範、治理的規範，包括一整套微服務專案的模板。另外提供了一些微服務開發應用依賴的JAR包，包括日誌記錄、訪問控制，微服務容器相關功能，都封裝在SDK裡面。另外對於測試來講，提供服務Mock的功能，基於契約的方式去測試。

另一塊就是統一執行平臺，有註冊中心、配置中心、API閘道器，應用監控中心、斷路器監控中心、認證中心、日誌中心，還有對微服務執行期支援多版本的概念，還有服務容器，將一些必要的能力進行SDK的封裝。