作者：京東物流 趙勇萍
一. 前言
現在對于一個後端開發工程師來說，微服務，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. 領域服務進行天然分庫處理。
五. 總結
筆者通過采靈通業務場景的落地實踐，最大的感觸是在前期子域拆分時候的糾結，在此，給大家講個例子：
比如商品子產品，前期會考慮到底是拆成一個商品子域呢，還是拆成兩個子域：夥伴商品子域和供應商商品子域。如果是一個商品子域，業務實作上會簡單一些，但未來業務場景拓展會受限。如果拆成兩個子域，前期系統設計會增加複雜度，包括商品池的同步問題，資料一緻性問題，等等。但後期來說，會更适配業務場景，是以最終筆者的選擇是跟産品經理充分溝通過業務需求後，選擇了拆成兩個子域。
是以，作為一個業務架構師，第一要務是要有充分了解業務的能力，是以如何跟産品經理緊密配合，其實是一個業務架構師的核心能力。其次才是技術次元的能力，包括對六邊形架構的把控，對多種設計模式的應用，對系統高并發和高可用性的應對經驗等。後面所說的這些能力，對于一個技術宅來說是很好提升的，但對于前面的這個能力，可能就因人而異了。