作者：京東物流 趙勇萍
一. 前言
現在對於一個後端開發工程師來說，微服務，DDD都是掛在嘴邊的東西，感覺大家接觸到多，也瞭解的多。但筆者個人的感受是，對微服務架構的理解就像我小時候讀三國，在不同年齡讀的時候感觸都不一樣。微服務對於開發人員來說亦是如此，一千個人有一千種解讀，而隨著每個人自己的業務經驗和架構能力的提升，每個人看到的風景也會不一樣的。今天筆者想結合一下自己的業務實踐，分享一下自己基於微服務架構實踐後的心路歷程。
二. 首先，我們需要思考一下： 什麼是微服務架構？
在筆者看來，微服務架構並沒有一個準確的定義，但他會有很多特徵，透過描述他的特徵用來把控它是什麼。
a. 白馬是馬。
這是一個哲學命題，表明個別和一般的關係。我認為，任何的技術和架構都不是憑空出現的，一定是發展而來，而微服務架構的前身就是SOA，面向服務的程式設計。SOA是一種架構設計模式，也是一種思想。所以微服務理應繼承了SOA的這種架構思想，所以我認為微服務就是那個白馬，他將一個複雜系統，以業務的視角，分成獨立的模組，每個模組都有提供服務的能力，基於這些能力，去構建一個複雜的系統架構，在此基礎上，再演化出去中心化，和分散式思想。
b. 服務治理
以上說的是思想層級，在戰術層級，微服務架構的核心訴求和能力是服務治理，包括服務定址，流量管理，可觀測性等。
c. 十二要素
Heroku創始人Adam Wiggins 提出的微服務十二要素，下面，我貼出我對微服務十二要素的解讀：
這十二要素可以說是微服務架構的方法論，有了思想，方法論和戰術維度，我覺得就可以完整的描繪出一個微服務架構的全景圖。然後，我將我理解的微服務架構總結成一句話：
微服務架構是 ： 一種去中心化的分散式服務架構，架構擁有服務定址，故障容錯，流量排程，控制訪問和可觀測性的服務治理能力，從而實現服務的隔離性，可移植性，可擴充套件性，穩定性。
三. 其次，我們的問題焦點：微服務架構的難點是什麼？
筆者認為，微服務的兩個核心點正事他的難點：
第一個難點， 微服務的服務治理和流量治理。
對於這個難點，現階段已經有了很好的解決，因為服務治理和流量治理是去業務場景化的，所以有很多前人透過他們的努力，以及貢獻的開源框架，讓我們可以直接可以拿來落地的，並且可以做到很好的相容。下圖是一個比較標準的微服務治理架構圖：
第二個難點， 微服務拆分的架構思想.
如何基於DDD方法論落地服務的分解。該處設計很多核心能力，包括子域劃分，限界上下文定義，實體，聚合根的抽象，基於領域事件的事件驅動設計，除此之外，還有工廠模式，策略等等設計模式的應用。
這第二個難點是很難做到直接的遷移，因為我們面對的業務場景千差萬別，前人的經驗只能總結成思想來指導我們，但具體的落地就會考驗每個架構師自己的過往經驗和理解。 就像一為畫家，對與同一片風景的理解不同，畫出的畫面也是不同的，所以，就會出現有的人是梵高，有的人是畢加索。而對於筆者現階段來說，可能只是一個剛入門的素描者，不過我願意在此拋磚引玉，介紹一下我採靈通專案對於微服務落地的經驗，供大家做一個簡單參考。
四. 最後，來點乾貨： 採靈通系統--微服務架構落地實踐
筆者負責的採靈通業務是一個相對複雜的系統，帶領了20人的開發團隊總共歷時5個月，完成從0到1的設計，開發和上線。該系統基本涵蓋了一個ToB全供應鏈數字化相關的全場景業務。筆者將透過 業務場景分析， 技術架構解析，和服務落地幾個方面對該系統的落地實踐進行解讀。
1. 業務場景解析
理解DDD的前提是先要理解業務場景，筆者的業務場景是採靈通SAAS系統，在此簡單做一個業務介紹：
採靈通是一個標準的提供B商城觸達的，同時解決企業數字化採購供應鏈的SAAS平臺，核心能力包括多供應商協同，訂單管理，商品管理，客戶管理，及B商城的搭建和管理，具體如下圖所示：
2. 技術架構解析
基於以上業務場景，我們構建出我們的技術架構方案，如下圖所示：
在技術架構上，整體分為四層，自上而下為： 業務前端層， 閘道器層， 業務服務層，技術底座層。
1. 業務前端層：前端根於業務場景，有多個觸達端，最主要的端有供應商管理端，夥伴管理端，PC商城端，H5商城端， 頁面裝修系統。前端封裝有統一的元件庫，保證了整個系統的前端互動風格一致性。
2. 閘道器層：入口閘道器為nginx反向代理，主要功能是對不同域名的SSL解析和路徑對映，部分前端靜態資源的直接對映。入口閘道器下為業務閘道器，包括COP閘道器和通用業務域閘道器。
通用業務域閘道器：主要功能是將前端有狀態的HTTP請求（header:jwt資訊加密和域名資訊過濾），進行鑑權，過濾，路由。同時解析為明文上下文Map,存於header中，可供業務層服務使用。其中針對不同域名的路由資訊是採用了nacos的配置中心進行統一管理，並下發至gateway，實現一個動態的域名路由管理。
COP閘道器：負責系統對外開放平臺的API介面鑑權和路由代理。
3. 業務服務層。
該層又有細分，分為COP服務，業務平臺服務，資料平臺服務。
a. COP：主要是封裝對外開發介面統一認證服。透過COP，SAAS系統可以實現對下游來說，對接第三方供應鏈的介面平臺；對上游來說，對接夥伴的客戶ERP系統，政採平臺，OMS系統等。
b. 業務平臺：分為核心的領域服務層和聚合/介面卡服務層。
領域服務層是基於DDD領域驅動設計思想，對現有業務進行抽象，按照不同的子域劃分不同的服務，每個領域服務內都有針對該子域的聚合根的抽象封裝。而聚合服務是針對不同的業務場景，對領域服務呼叫進行一層聚合，使其可以更好的為前端提供介面服務。
應用聚合層主要是針對業務場景進行封裝和聚合。
介面卡層是針對不具有領域概念的但又有一定意義的服務封裝，比如基於CQRS的設計理念下的查詢服務；其次是一些後臺非同步任務服務，如資料匯入匯出，資料同步等等。
以上這幾層可以看成是對六邊形架構的一個很好的分解和落地。
c. 資料平臺層：針對SAAS系統的產生核心資料，例如訂單，商品，基於CQRS理念，將資料進行整合和同步，實現多場景下單資料複雜查詢和BI資料分析。
4. 技術底座層
該層細分的話，可以分為TPAAS服務和BPAAS服務兩部分。
TPAAS： 包括k8s,容器化編排， Istio流量管理 ,日誌採集和檢視，鏈路追蹤監控，中介軟體（資料儲存，MQ），CI/CD等
BPAAS：包含一些基礎jar包，如低程式碼框架，安全元件。還有一些基礎服務，工作流服務，任務排程服務，分散式ID生成器服務等。
3. 最終服務落地
採靈通系統總計服務65個，按照服務分類分層的概念，結合DDD的六邊形架構思想，可以分為：
前端服務，BFF服務，組合服務，介面卡服務，領域服務，基礎服務，閘道器服務。
其中這些服務有一些設計規約：
1. 領域服務不可依賴組合/聚合服務、介面卡服務和BFF服務。
2. 組合/聚合服務和介面卡服務不可依賴BFF服務
3. 領域服務進行天然分庫處理。
五. 總結
筆者透過採靈通業務場景的落地實踐，最大的感觸是在前期子域拆分時候的糾結，在此，給大家講個例子：
比如商品模組，前期會考慮到底是拆成一個商品子域呢，還是拆成兩個子域：夥伴商品子域和供應商商品子域。如果是一個商品子域，業務實現上會簡單一些，但未來業務場景擴充會受限。如果拆成兩個子域，前期系統設計會增加複雜度，包括商品池的同步問題，資料一致性問題，等等。但後期來說，會更適配業務場景，所以最終筆者的選擇是跟產品經理充分溝透過業務需求後，選擇了拆成兩個子域。
所以，作為一個業務架構師，第一要務是要有充分理解業務的能力，所以如何跟產品經理緊密配合，其實是一個業務架構師的核心能力。其次才是技術維度的能力，包括對六邊形架構的把控，對多種設計模式的應用，對系統高併發和高可用性的應對經驗等。後面所說的這些能力，對於一個技術宅來說是很好提升的，但對於前面的這個能力，可能就因人而異了。