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

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

到了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的封裝。

總結

以上是生活随笔為你收集整理的【2018可信云大会】太平洋保险丰隽玮：微服务架构实施与治理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。