作者簡介 劉學斌 用友暢捷通架構專家
大家下午好！很榮幸在 DevOps 國際峯會與各位業界同仁分享微服務架構設計實踐。
首先自我介紹一下，我來自用友暢捷通公司，目前專注用友暢捷通雲平臺應用架構設計和流程建模、領域建模、物理建模。
今天給大家分享以下幾方面內容。
第一，問題的背景，給大家介紹一下我們爲什麼使用微服務； 第二，針對這個問題進行分析並給出方案和思路； 第三，具體介紹我們具體的微服務設計中能力建模方法； 最後，做一個總結。
一. 問題的背景
在介紹具體問題之前，我們先回顧一下過去我們企業信息系統發展的歷史。
這就是企業信息化非常典型的發展歷程，也即所謂的企業信息化1.0。
其歷史可以追溯到上世紀90年代。當時在企業裏面，信息化剛剛起步，企業在其業務發展過程中，在不同的時期對不同的業務問題由不同的團隊乃至採用不同的技術棧研發或者外購一些獨立的系統，這些系統面向各自領域問題，相互之間獨立運行。
這些獨立的“煙囪”型系統，很多相似的功能在不同系統之間重複建設，浪費嚴重；
另一方面，企業作爲一個有機的整體，客觀上要求這些系統能夠相互協作和交互，不同系統之間的集成是一個複雜的問題，耗時耗力；
此外，由於重複建設，同一套業務邏輯在多處出現，可維護性差，維護業務邏輯一致性是一個挑戰。
所以針對這個問題，我們過去有主數據管理管理，處理各個系統數據集成和統一的問題；
採用ESB平臺解決各個獨立系統之間交互問題。
但是，無論是主數據管理還是ESB總線，它只是一種技術方案，在具體實踐中不僅費時、費力，而且可靠性差，極大限制了信息系統的價值。
針對剛纔的問題，從2000年初開始，一些企業軟件公司把各種企業應用系統在統一的應用平臺或技術平臺上進行開發，提供一個集成的系統，這也就是企業信息化2.0階段。
這種方案應該一部分解決了1.0階段數據集成問題以及系統交互問題。但是我們知道，對一個大型企業來說，一個系統很難解決企業所有的問題。
我曾經調研過一個銀行，一共有100多套系統，有自研的，也有外購的。很難想象一個集成的系統或者一家軟件供應商解決企業所有的問題。
從這個意義上講，系統之間互操作和集成是個必然需求。
剛纔我們一起回顧了企業信息化的兩個階段，我們再看一下與企業信息化相關的技術發展歷程，總的來說，技術發展的歷史就是重用技術的發展史。
上圖是一個概要的軟件重用技術發展歷程。
早期的時候我們把常用的一些功能放在一個文件裏面，例如C語言的動態鏈接庫DLL，JAVA語言的JAR包，文件可以自由分發，其他人可以通過引入文件來重用常用的功能，這也就是函數庫重用。
隨着函數越來越多，查詢和使用共享功能變得複雜，我們就把類似的函數、功能有機組合在一起，封裝成所謂的組件，也就是Windows平臺的ActiveX組件和JAVA平臺的JavaBeans組件，這也就是我們通常說的組件重用。該種技術要求調用者和被調用者必須在一個機器和進程上，使用上受到位置的約束。
隨着技術的發展，後來出現DCOM，調用方和被調用方可以位於不同的進程中，也可以部署在不同的機器上，但是必須侷限在一個內網上，並且一種平臺的組件只能由同一平臺的技術進行調用。例如windows平臺的DCOM組件只能在Windows平臺技術調用。到後來的CORBA、COM+標準，調用者和被調用者不僅能在不同的機器上，而且不同的技術平臺都可以互相交流。
到現在爲止，我們發展了微服務架構以及過去的SOA架構，就是說我們可以在廣域網的範圍內以及跨平臺進行調用。
縱觀整個技術發展歷史，可以看到，技術發展始終追求的是服務、功能能夠隨時隨地的被調用。
所謂隨時，也就是說不管它在什麼平臺上都能調用；
所謂隨地就是不管在內網、本機、外網都能調用。
爲什麼要追求這個重用，一方面我們可以降低複雜性，另一方面可以促進內部、外部的協作。如果說程序是由數據結構加算法（邏輯）組成，共享lib包本質上是重用算法，而服務重用本質是重用數據結構和算法。
二. 問題分析及方案思路
我們剛纔從技術方面、系統建設方面回顧了信息系統的發展歷程，再說我們面臨的問題是什麼？
無論是在信息化1.0階段還是2.0階段，系統的重複建設是一個問題，重複建設不僅浪費了有限的IT資源，並且增加了維護成本。其次，組織是一個有機的整體，各個部門之間需要相互協作，服務於企業共同的業務目標。現實有打通系統的客觀需求，但是打通系統並不是一件簡單的工作。
再一個最要命的問題是：這些獨立開發的系統都是基於具體的部門級業務問題進行獨立開發，很多是採用項目化開發模式，很難站在企業的高度對服務進行抽象。
即使我們從技術上解決了服務之間互操作問題（例如採用SOA，微服務技術架構等），這些遺留在系統中的服務很難被其它的業務系統所重用，也很難通過演進適應未來業務的變化。
針對這些問題怎麼去解決呢？看來不僅僅是一個技術問題，不是簡單引入一種微服務架構就可以解決。需要從技術和業務兩個方面着手。
建立企業基礎業務能力，支持業務快速創新；
- 能力建模
- 領域建模/物理建模
- DDD方法
業務服務隨時可用（鬆耦合、協議透明、位置獨立）
- 微服務架構
我今天主要分享的是“建立企業基礎業務能力”的方法和實踐。
三. 業務能力建模
3.1 能力的分層架構
這個是大家在一些講座或者是網站看到的微服務架構圖，基本上都是類似的，基礎服務、平臺服務、支撐服務還有領域服務，我今天要講的這一塊就是應用服務和領域服務的建模，這塊內容離問題最近，解決問題更有效。
我們在講能力建模之前我們先說一下什麼是能力？
我們說到能力就會說到三個詞，一個是知識、一個是能力，還有一個是技能。
什麼是知識？知識是對一些理論規則的理解，我們叫知識；
能力一般是指自然的或者內嵌的東西；
技能是學習到的一些行爲。我們說游泳是一項技能，游泳對應的知識是浮力作用力、反作用力原理；但是游泳的能力是什麼？就是手部的肌肉、腿部肌肉很發達這種能力，技能是蝶泳、仰泳。
我們說能力相比技能來說，能力一般是比較穩定的，但是獲得的時間比較長。知識一般是學習書本，能力是通過長期的訓練。
對於技能、能力、知識，我們在人力資源招聘人的時候把人當成一個系統，無外乎也從這三個角度即知識、能力和技能三個方面對求職者進行評估，大公司更多關注能力，小公司更多關注技能。技能很快就能上手幹活，能力更多體現在將來發展潛力，而且能力培養週期比較長。
我們構建一個系統也一樣，將系統的技能和系統的能力進行分離解耦，我們把能力和知識的服務叫做領域服務，技能服務叫做應用服務。
3.2 能力架構設計
我們剛纔說的是能力以及技能之間的區別，我們怎麼去進行能力架構設計？在講述具體能力拆分之前，先談談業務能力有哪些特徵。
業務能力首先是唯一性特徵，所謂唯一性就是一種能力在企業不同的業務域中只會出現一次，不可重複出現，通過依賴關係與其它能力相關，並且應該有明確的界限。其次是穩定性，相對技能，能力應該變化較小。
舉個例子，航空公司提供值機的能力，過去採用手工值機方式，隨着互聯網技術的發展，現在廣泛使用移動APP值機，或者機場自助機器值機。雖然值機的技術手段變化了，值機的能力並沒有變化。最後能力還有可分解的特點，高層的能力可以分解爲底層具體能力。只有將抽象泛化的能力分解爲具體細化的能力，才能更好實現能力服務。
接下來我會舉了一個例子就是業務能力建模，能力拆分。我們說從一個大的方向上，系統的目標是說協作企業進行人、財、貨、客的管理，我們怎麼能把它進行拆分？
我們首先從人、財、貨、客這個角度進行拆分。例如，財務屬於覈算的範疇，從業務的高度視角拆分爲戰略財務（決策層）、財務會計（對外）和管理會計（對內）。
對於“貨”，從業務運作的角度進行拆分，分解爲採購、庫存、銷售。這兩個拆分的視角不一樣，我們把一個大的系統拆成了很多小的塊，拆成小的塊就是我們剛纔所說的能力，能力有一個重要的特點一個是唯一的，另一個特點是穩定的。
我們拆分了一些能力塊，有些能力可能是在這邊存在，在那邊也存在，但是我們說能力有唯一性特點，需要將重複的能力識別出來，並獨立出來，建立與原始能力域之間的關係，這就是能力規範化。
我們抽取像產品、計量單位、組織等能力域後，再把這些能力進行分層，像應用層，還有領域層。領域層包括核心層、支持層、通用層。核心層包含核心領域服務，一般是業務人員可感知的，一般映射爲具體業務部門；支撐層包含支持一般是支持業務的某一方面的能力服務；通用層包括一些公共能力服務，例如產品、計量單位等。
我們剛纔分了很多能力模塊，然後按照這幾層的職責把它落下來，大概就是這個樣子。
我們把一個能力，或者說我們把企業的戰略從自頂向下拆分成很多能力塊，然後再進行規範化，每個塊是很簡單具體的。
一個領域被切分爲很多子域，每個子域的職責如何定義？如果子域很少，這個似乎不難；如果子域很多，這個也不簡單。也就是說，通過領域切分，我們有效控制了每個領域內部的複雜性，但是完成一個有價值的業務，需要多個子域協作和配合，協作的複雜性提高了。定義子域的職責，必須採用一定的方法。我們採用用例驅動的方式，並藉助系統序列圖，劃分子域職責。
切分能力域之後，採用以上UML序列圖的方式，採用用例驅動方法，給每個能力域定義職責。
3.3 領域建模
我們剛纔通過能力建模自頂向下基於企業戰略拆分了很多能力域，以及確定了每個能力域的職責，我們現在要深入到能力域內部。
一個系統我們不僅要確定它的外觀，同時我們也希望看到內部結構是什麼樣的，這就是領域建模，特別是做大型的複雜的業務系統領域建模非常重要，我不知道有多少人用過。
如果沒有領域建模的話，基本上做的是一個東西的表象，很難洞悉到業務的本質。我們經常說業務經常發生變化，需求經常發生變化。客觀來說，很多時候是業務表象發生了變化，其業務需要（或者need）並沒有變化。
我們在講領域模型之前，先說一下什麼叫領域。
所謂領域就是問題域，面對的是具體業務世界。什麼叫模型？模型對應了兩個關鍵詞，一個是簡化，一個是抽象。
所謂簡化就是抽取與問題相關的東西，將與解決問題無關的東西忽略掉，減輕人腦的負載。所謂抽象是由表及裏，洞悉事物本質。模型按照目的不同可分爲兩種，即分析模型和設計模型。
分析模型目的是認識一箇舊世界，設計模型的目的是爲了建設一個新世界。所謂領域模型是分析模型，是我認識領域的一種方式，我們把領域裏的一種概念，以及概念中的相互關係，一般通過圖表的方式把它表達出來。
我們在溝通的時候，包括跟業務人員溝通的時候我們都用領域模型，領域統一語言也是基於領域模型建立起來的。
我們舉一個領域模型的例子，我們做個業務系統的人都會用過計量單位。計量單位比較簡單的一種設計方式就是設計一個計量單位組，計量單位組裏面可以包含多個計量單位，單位與單位之間有一個換算關係。計量單位組中的單位和單位之間換算關係都交給用戶自己定義。
我們知道，世界上計量單位類型是有限和確定的。
我們看一下它的模型是這樣的，它一般是計量單位類型，什麼叫計量單位類型，我們說長度是計量單位類型，時間也是計量單位類型。
計量單位類型有兩種，一種是基本計量單位類型，基本單位類型是物理量裏的7種，長度、時間、質量等。
什麼叫導出單位類型，就是由基本計量單位組成的，導出單位與基本單位之間存在量綱換算關係。例如面積單位是導出單位，是由長度單位的平方組成的。無論是基本單位類型的單位，還是導出單位類型的單位，其單位和單位之間的換算率是確定的，這些數據系統可以預製。
更重要一點的是，由於導出單位類型與基本單位類型之間存在確定的量綱換算關係，只要設置基本單位的換算關係，就可以推導出導出單位類型的單位換算關係。
這些都是計量單位的領域知識，在剛纔的模型中並沒有包含這部分知識，下面的模型就內涵量計量單位領域知識，不僅預置了計量單位及其換算關係，而且還預置了導出量綱與基本量綱換算關係，豐富了模型知識。
建立好領域模型可以方便我們理解領域概念和知識，促進內外溝通，指導我們面向對象開發。
但是僅僅停留在這個層面還是不夠的，我們需要基於領域模型轉化成物理模型。
物理模型是領域模型的關係表達，物理模型與領域模型不是嚴格的一一對應，基本原則是採用簡單映射，與領域模型結構基本一致；但是有時需要考慮性能、複雜性等因素，需要做一些取捨。
建立好物理模型之後，領域模型落實到數據表中。
在開發過程中，基於數據庫表生成Repository和Model層代碼，領域模型設計成果也反饋到代碼中，真正指導開發工作。
四. 總結
剛纔分享了微服務架構下業務能力建模的方法和實踐，總結下來有以下幾點：
- 簡單採用微服務技術架構不能實現支持業務持續發展和業務快速創新，過去SOA項目化所走過的坑已經說明了這一點；
- 業務世界紛繁複雜，業務能力相對穩定，業務能力建模的過程是洞悉業務本質的過程。企業能力建模的目的是讓軟件能以較低的成本和風險應對將來的變化（雲產品尤其如此），模型的質量決定產品的未來。
- 能力建模是一個複雜過程，不可一蹴而就，大處着眼，小處着手，迭代開發，循序漸進。此外，對領域理解的深度影響模型質量，充分與領域專家溝通，學習業界先進經驗和參考模型，並藉助工具和方法讓建模能夠落地；
- 當今能用錢解決的問題都不是問題，充分利用業界成熟的技術服務，有限的資源聚焦於企業自身核心競爭力。
本文根據用友劉學斌老師在 DOIS 2018 · 北京站分享整理而成。