導讀:本系列文章將經過介紹一個真實大型企業數字化轉型過程當中遇到的層層困難,以及微服務架構如何落地,涉及到的各類真實的解決方案。不空談,不泛談,講事實是本系列文章的原則。
企業數字化轉型是近些年來很是火熱的話題,而企業作數字化轉型的必經之路就是微服務架構升級。微服務架構升級廣泛都會說起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.業務基於現有的擴展點增長擴展實現,實現本身的個性化業務。
上述一、二、3步驟是一個按部就班的過程,不可能一蹴而就的。由於企業本身的業務流程會隨着市場的變化而不斷的變化,隨着業務的變化,可能會新增一些擴展點和不一樣的擴展實現。前端