導讀：本系列文章將通過介紹一個真實大型企業數字化轉型過程中遇到的層層困難，以及微服務架構如何落地，涉及到的各種真實的解決方案。不空談，不泛談，講事實是本系列文章的原則。
企業數字化轉型是近些年來非常火熱的話題，而企業做數字化轉型的必經之路就是微服務架構升級。微服務架構升級普遍都會提及DevOps、容器化、API閘道器、微服務治理、AKF擴充套件立方體等技術概念。在大型集團企業微服務架構升級的過程中，往往會遇到如何擴充套件已有微服務應用，來適應不同組織之間業務的多樣性和集團的整體管控性的問題。針對這個問題，國內網際網路行業的先驅阿里提出了“厚中臺，薄前端”的概念。但如果實現呢？本文通過描述一個大型集團企業微服務架構升級的過程，如何通過微服務擴充套件來實現企業數字化轉型的大中臺業務。
第1步選定原型開始微服務之旅
大型企業在微服務架構升級的過程中，一般會先選一個A組織（原型組織）為代表，基於這個A組織及企業數字化轉型的目標，開發出一套原型產品，並在A組織內不斷的優化和改進。這個過程，特別注重的是微服務架構的技術升級，例如需要引入微服務治理框架，DevOps平臺、分散式事物等等。做出來的產品業務上和已有的系統沒有什麼本質的區別，只是我們用了一套高大上的微服務架構。這時候企業的組織架構並沒有任何改變，由A組織負責的研發部門負責研發了一套基於微服務架構的新產品，這個研發組織負責這幾十個微服務的開發和運維工作。老闆覺得這套系統很不錯，這套產品基於微服務架構做的，那就開始全集團推廣吧，讓其它組織也用上這套系統，享受一下數字化帶來的便利。
第2步產品推廣微服務架構下如何“二開”？
A組織的資訊化部門開始興高采烈的去給B組織推廣他們開發的這套產品，說這套系統是基於現在最前沿的微服務架構實現的，可以如何改進你們現有的流程，減少成本等。B組織覺得很不錯，那也試用一下吧，但是我們在某些地方和這套產品的現有業務有點差別，能幫忙改一下，支援一下我們的特有業務嗎？A組織為了推廣產品，爽快的答應了。但是在改的過程中，發現原有的業務流程和程式碼和自己的一部分特有業務關聯的比較緊密，修改起來要費不少功夫。為了推廣給B組織使用，還是硬著頭皮給改完了，這其中帶來了大量的業務程式碼修改及迴歸測試。
老闆看著產品在B組織推廣的也不錯，那繼續推廣給其它組織使用吧。A組織在繼續推廣給其它C、D……組織的時候，發現都存在B組織類似的問題。他們80％的業務和A組織相同，但是有20％的業務有自己的特色。其它組織也要求A組織修改一下原有的微服務，來支援他們的特色業務。這時候A組織不幹了，說你們都有自己的資訊化部門，也有研發人員，你們基於我現在做的微服務去修改吧。那麼問題來了，其它組織如何“二開”呢？把整套產品的原始碼都共享給其它組織，他們基於這套原始碼修改及開發自己的新產品，然後獨立部署。這時候老闆站出來不幹了，你們這樣搞下去，和原來的軟體模式有什麼區別，我們微服務架構的優勢去哪了，整個企業的集中管控如何做？這時候大家又想起了做數字化轉型的“厚中臺，薄前端”的業務架構，我們的業務中臺在哪裡呢？如何實現業務中臺？
第3步微服務擴充套件實現業務中臺的利器
接下來我麼該聊聊什麼是微服務擴充套件？如何利用微服務擴充套件實現業務中臺？
核心微服務 - 流程分解
功能域：可以簡化理解為對應一個微服務
域服務：對應一個服務介面
能力：對應服務介面上的一個具體方法
擴充套件點：服務介面方法實現中插入的一個外掛（介面）
以訂單建立過程為例來談談什麼是微服務擴充套件，以及如何用微服務擴充套件來實現訂單的業務中臺。訂單建立的過程其實是一系列功能的組合，如庫存校驗，商品價格計算訂單校驗等。每個功能都對應到一個領域服務，如庫存校驗對應到庫存領域服務，商品價格計算對應到價格領域服務。每個領域服務都會提供一些核心的能力，如庫存領域服務提供庫存查詢、校驗、扣減等能力。而每個能力可以提供一系列的擴充套件點，來根據不同的業務走不同的擴充套件實現。如庫存查詢的能力可以提供庫存策略的擴充套件點，根據業務需求可以實現商品級庫存，批次庫存等的擴充套件實現。訂單建立流程以及抽象出來的各種功能域及能力就是我們需要的業務中臺，而業務的差異化實現可以根據業務中臺提供的能力擴充套件點去實現自己的業務擴充套件。下圖是微服務擴充套件的基本概念圖。
微服務擴充套件 - 基本概念圖
那麼需要如何抽象出業務中臺呢？
1.首先需要梳理微服務的主業務流程，以及各組織之間可能存在的差異點。
2.根據梳理出來的主業務流程及可能存在的差異點，定義出上述的功能域、域服務、能力及擴充套件點。
3.業務基於現有的擴充套件點增加擴充套件實現，實現自己的個性化業務。
上述1、2、3步驟是一個循序漸進的過程，不可能一蹴而就的。因為企業自己的業務流程會隨著市場的變化而不斷的變化，隨著業務的變化，可能會新增一些擴充套件點和不同的擴充套件實現。