這次不談理念，不說方法，就用實際平臺講述我們是怎麼實現完整中臺架構的
上一篇我談到中臺架構能夠成為企業數字化破冰者的關鍵就是“合”“分”“聚”三言。而構成中臺的，又是“有業務”的業務中臺，和“有技術”的技術中臺兩語。掌握了三言兩語就可以簡單明瞭的在紛繁複雜的各種中臺架構、中臺產品和宣傳中搞清楚“非中臺”、“半中臺”以及“偽中臺”。
那麼完整的具備了
“
合分聚”三言和“有業務有技術”兩語的完整中臺長什麼樣兒呢？接下來我就以我團隊所構建的企業數字化開放中臺GiSP（Grand Insight Service Platform）為例，說說我們是如何實現完整的企業中臺的。鑑於篇幅，在這一篇裡我只能走馬觀花的將三言兩語中至關重要的“合分聚”的實現過程說一遍，讓大家有一個整體初步的印象。其中涉及的很多建模技術、開發技術、微服務管控技術都得在本系列的後面另外單獨分篇闡述，不會讓讀者你帶有遺憾的，只要你持續關注著，我更新不會太慢^_^
GiSP的中臺架構
1。 在GiSP中，傳統軟體“整體”生產交付模式被革新為以“零部件”生產的交付模式。即在GiSP中，所有開發都是以微服務為單位的，從需求到部署運營的整個流程，都是以微服務為單位而不是以系統為單位。每個微服務是一個產品/專案裡的一個子開發項，但每個微服務都是一個獨立的工程，它具有完整而獨立的生命週期。——是之為
“分”
。
下圖是GiSP開發平臺SA（Service Architecture）的一個截圖。SA相當於DevOps當中的Dev。在SA中每個微服務均是獨立開發和管理的。本例中，當前中臺專案裡共有354個微服務。
共享的微服務列表
這些微服務均獨立迭代，有新版本釋出時，它們會被推送到GiSP的SO（Service Operator）中。SO相當於DevOps中的Ops。下圖是SO部署管理功能的一個截圖，可以看到每個微服務都是獨立部署、運維和管理的。
待部署微服務列表
GiSP從規劃、需求、設計、開發、部署、測試、運營、監控實現了徹底的全程微服務化和自動化，從而將“分”字變成了自然而然的開發過程而不是特意的設計。
軟體方法和開發徹底微服務化
那麼，當一個完整系統被拆成這麼細粒度的服務之後，業務整體的整合性又是怎麼保證的呢？這就需要用“合”字來解決了。
2。 所有的業務能力均以微服務（零部件）的形式存在於業務中臺，相互之間對等共享，它們透過模型驅動方法組織為業務整體來保證拆散了的微服務整體的整合性。——是之為
“合”
。
具體來說，
“合”
是由資料的整合性—
資料模型
；業務的整合性—
業務模型
；系統的整合性—
整合模型
三個核心模型構成的。
資料模型由資料物件及資料物件之間的關係構成。
資料物件可認為是資料庫表的物件化定義。在GiSP中，資料物件的建立將遵循唯一性和共享規則，建模結果將形成全域唯一和共享的資料物件模型庫。資料物件之間的關係採用“Association”的語義，透過GiSP中稱為Lookup的機制實現。其建模結果是構建了一個如同人際關係網路的資料物件網狀關係網路。GiSP將會自動生成維護和訪問每一個數據對和它的資料關係網路的SPI和實現程式碼，並向微服務開放這些SPI。
由平臺自動生成的全域的資料關係模型
業務模型由資料物件根據業務實體的需求透過包含（Include）和引用（reference）兩種語義聚合而成。
用共享的資料物件組裝業務物件
利用資料物件的聚合來組裝業務物件，這一步在GiSP中稱為建立業務物件模型，即業務模型。它描述的是從領域模型驅動的角度來說，一個業務領域是如何由獨立資料物件聚合而成的。下圖是由GiSP自動生成的業務物件模型關係圖
由平臺自動生成的全域業務物件聚合模型
從平臺自動生成的業務模型圖來看，主物件、關聯物件以及這些物件在上一步資料模型中Lookup的其它物件，都會被聚合成一個業務物件整體。這個業務物件整體會被GiSP自動建立成一個Spring Cloud 微服務，並在微服務中自動生成針對這個業務物件處理的一系列API和實現程式碼。利用這些自動生成的API，處理這個領域物件開發者不需要寫一行程式碼。
在後續的業務處理中，服務消費者不再需要關心資料來自哪個資料物件，也不需要關心一個業務物件是由多少資料物件，是採用什麼關係組織起來的。只需要針對這個業務物件整體或部分進行操作即可。利用自動生成的微服務API，當服務消費者向服務提交全部或部分資料時，GiSP會根據業務物件模型識別資料操作，並自動呼叫上一步資料物件的SPI介面進行處理。
整合模型由微服務之間的相互依賴所構成的關係網路構成。
每個微服務就如同組成一部電腦的電子元器件，而依賴關係就是描述一個電子元器件與其它電子元器件的訊息交流通道。在GiSP中，微服務間的整合非常簡單，它被稱為服務依賴。根據實際業務需求，每個服務都可以依賴全域共享服務庫中的任何一個服務。在GiSP的中臺架構中，所有微服務都是可共享的，即使這個服務不是由自己團隊生產的，只要別的團隊共享給出來，它就可以被依賴。彷彿整合電路板將各種電子元器件連線在一起，整合模型將多個微服務整合在一起，共同構建起實際業務實現的流程和脈絡，組成一個複雜的業務構件。
設定當前微服務直接依賴的其它微服務
每個服務都有自己的依賴服務，所有的依賴關係形成一個服務之間訊息的傳遞網路。GiSP將實時進行全域運算分析，從而建立起全域的服務整合網路。如同整合電路板一樣，把作為電子元器件的微服務整合聯動起來。下圖展示了從訂單合同微服務出發，在全域範圍內形成的服務整合網路。在執行期，訊息將循著這些網路在服務間傳遞，將原本獨立執行的微服務整合聯動起來，最終實現了全景業務整合聯動的整合一體化。
由平臺自動生成的全域的服務整合模型
同樣，GiSP也會為這個整合關係網路生成相應的呼叫API。開發者並不需要了解這個複雜的整合結構，它是由平臺自動維護和展示的；開發者只知道在本微服務中有一系列外部介面的本地代理方法，他只需要像呼叫本地方法一樣呼叫這些本地代理方法即可。
可見，GiSP透過模型驅動的微服務架構技術，利用資料模型將資料物件“合”成全域資料模型，利用業務模型將資料物件“合”成一個獨立業務領域並自動生成一個微服務，再利用整合模型將微服務“合”成一個業務整體。從而實現了三言兩語當中的“合”。
現在，業務透過模型合在了一起，並以獨立微服務的方式像零部件一樣向外提供服務。業務場景又是怎麼透過這些零部件組裝出來的呢？這就要用到“聚”字訣了。
3。 在GiSP中，原來所謂的ERP/CRM/TMS/PMS等系統，是由共享的微服務像零部件一樣，用的不同組裝方式構成的——是之為
“聚”
。
在GiSP中，應用場景被稱為“模組”。每個模組都是一個可獨立執行的小場景。在下圖中可見，在GiSP中，連場景也是“分”成可獨立執行的模組的。這些模組構成了共享的業務場景庫。
在中臺中構建出來共享業務場景庫
一個模組由多個頁面，以及每個頁面上與使用者互動的多個按鈕和事件構成。在實際開發過程中，通常由UE工程師設計互動原型，模組設計者再依據互動原型將頁面和行為建模為模組。
為模組配置頁面和路由
接下來為每個頁面新增互動行為和事件。每個行為和事件均可從共享服務庫中選擇要繫結的微服務，指定微服務的版本，並將該行為或事件繫結到微服務的某個開放API上。
將頁面行為或事件繫結共享服務的開放API
將頁面行為或事件繫結共享服務的開放API
完成上述配置後，一個獨立模組就建立完成了。GiSP將會自動生成業務場景模型。我們看到一個結構清晰的，從場景到頁面，到行為，再到微服務的開放API的應用結構就生成了。
GiSP會根據上述的配置結果自動生成前端程式碼、打包、並生成可執行的部署包。下圖是GiSP自動生成的模組的執行效果。
業務場景的執行效果
一個業務場景經過幾步簡單的配置就可以執行，這並不神奇：因為它所呼叫的微服務是可執行的，微服務的業務構成邏輯是由之前建立好的業務模型和整合模型解釋和處理的，而資料的處理，則是由資料模型解釋和處理的。因此，我們就用模組這個組裝器，用頁面及頁面上的事件和行為將共享的微服務組裝成了一個個的配完即可執行的業務場景；不同的組裝代表不同的場景。這就是
“聚”
的作用。
不管怎麼組裝，模組都共享業務中臺中的同一組微服務，並由同一組模型來解釋，所以，不論業務場景怎麼獨立，怎麼變，最終業務是統一的，資料是一致的。業務場景可以快速組裝千變萬化，但回到業務中臺，又變回了企業的整合一體化本質。
這一步就是打通企業內部管理和網際網路創新之間屏障的關鍵！
這些組裝出來的所有模組則又變成了全域性共享的狀態，每個模組就成了一個可執行的業務元件，用於組裝最後的應用系統。GiSP甚至還實現了將多個模組組裝成更大模組的能力。這個以後再說。
最後一步，所謂的業務系統，不過是這些共享模組的組合罷了。我們只需要配置一個選單，按需求將共享的業務元件組織起來即可，GiSP將會把這些模組全部自動打包，生成業務系統的部署包。
用共享模組組裝業務系統
透過這樣的機制，為每個客戶建立個性化的業務系統簡直太方便了。下圖就是我們SaaS團隊為客戶組裝的一些業務系統。看似各不相干的那麼多系統，其實無非是模組的不同組裝罷了。而如果沒有適用的模組，我們會在專案上配置一個新的出來。這個新的立刻又會成為可複用的模組了。
下圖是我們地產行業ERP系統組裝執行結果。它當然不需要寫一行程式碼就能跑，因為每個模組都是獨立可執行的。我們也根本不用擔心它的整合性：模組可以隨便選，服務可以任意組裝，可以每個客戶都不一樣；但別忘了後臺它們透過
“合”
字訣已經是一個整合的整體了。
至此，中臺架構中至關重要的
“合分聚”
三字真言都實現了。中臺之所以是解決企業數字化轉型中必需的平臺，它的作用也就體現出來了：
“合”，讓企業實現了標準一致的管理，整合一體的業務，這是數字化的基礎；
“分”讓企業業務實現了獨立部署、彈性化、複用化、共享化，變成支撐企業數字生態無數業務場景的零部件。
“聚”讓企業得以快速的、任意的組合它們已經有的業務能力，去構建數字生態中的千人千面的個性化場景，但卻不會破壞企業管理的標準和一致。
這篇已經很長了……可以講的東西太多。我和我的團隊花費了整整四年時間來琢磨這些東西，不可能在短短几篇文章裡講完。讀者肯定還有很多疑問。慢慢來吧，反正這個系列我說過會很長……只要你有耐心，關注我，跟著我走完，不會讓你失望的。如果需要對這篇裡所講的GiSP平臺有更多瞭解，可以點一下文章最後的擴充套件連結。
下一篇，來講一個IT從業者一直夢寐以求的境界：GiSP是如何像搭積木一樣構建一個軟體的。
這將會是很長的一個系列。我會持續的把我這十多年在企業數字化過程中思考、架構、方法和技術，以及我團隊所研發的企業數字化中臺構建平臺釋出出來。相信對業界是有著重要的借鑑意義的。
如果您對企業中臺架構、企業數字化轉型和產業網際網路感興趣，請關注我並期待後續更新。
