作者:人月神話,新浪博客同名
簡介:多年SOA規劃建設,私有雲PaaS平臺架構設計經驗,長期從事一線項目實踐
今天繼續談下傳統企業微服務架構轉型方面的內容,從最基本的問題訴求出發,到整體解決方案的思考,再到開發前的準備,開發和實施工作的重點分析等。
在前面很多文章裡面我們都做過分析,企業轉型到微服務架構實際上是增加了企業的IT治理和管控難度,如果企業本身的IT治理成熟度不夠往往遇到的問題更大。那麼傳統企業或者有一定信息化基礎的企業朝微服務架構轉型的動力究竟在哪裡?
採用微服務架構,僅僅是引入一種新的開發框架,將傳統的單體應用轉化為組件化和服務化的架構模式,或者說當前IT架構設計和開發流行微服務架構?感覺很多企業一股腦的上微服務架構,確實存在不少的企業為什麼要轉型,為什麼要實施微服務架構沒有想清楚,自身的IT成熟度也沒有評估,為了流行或趨勢而在不恰當的時間點實施微服務架構,本身就是一種激進的表現。
那麼微服務架構轉型,企業的真實訴求究竟有哪些?
共性技術能力下沉,從關注技術到關注業務
微服務架構思想帶來一個關鍵點,不僅僅是組件化和服務化開發,更加重要的是平臺+應用的構建模式,同時這個應用本身就是能夠通過鬆耦合的微服務模塊靈活組裝和構建的。
這個是轉型帶來的一個巨大好處,就是傳統的一個業務系統的開發模式不存在的了,取而代之的是單獨的業務組件或業務模塊的開發,通過共性平臺層服務能力的支撐,我們不再需要開發重複的類似流程引擎,4A,公共技術組件,而只需要將開發重心真正專注到業務功能和邏輯實現上。
有時候我們談微服務架構就會談到解耦,但是你微服務模塊劃分的越細,那麼這些模塊之間的集成往往更加複雜,再加上很多API接口本身就是同步實時調用模式實現,導致的不是模塊高度直治,反而是對外部基礎平臺或業務組件的依賴更大。
提升可變更,可運維,可擴展能力
即微服務架構化後,微服務模塊間的集成複雜度增加了,如果模塊劃分的不合理,那麼耦合性往往更強。那麼將單體應用劃分為微服務模塊,除了復用基礎平臺能力外,還有啥好處?
這個好處最重要的就是我們管理的單位更小,對於後期的IT運維和變更處理更加方便。這種方便性體現在業務模塊的性能擴展,也體現在業務模塊的功能和業務變更重新部署和發布。你會發現這些事務的影響比原來更加小。
比如一個微服務模塊變更,如果其接口沒有變化而是內部邏輯變化,那麼我們只需要對該模塊進行變更,並只對該模塊進行測試和發布即可,而不會影響到其它的業務功能組件和模塊。
同時在微服務架構下,我們更加容易實現微服務模塊的動態熱部署,在和容器技術結合後更加容易實現動態資源彈性擴展。
提升甲方對整個IT應用的過程管控能力
這個是微服務架構實施後帶來的一個重大好處,即原來是一個大的業務系統開發,那麼業務系統內部開發商過程如何管控,質量如何,內部組件接口是否設計能力,該暴露的能力是否暴露,這些內容對甲方來說都是黑盒,根本就無法展開有效的過程和質量管控。
而在實施微服務架構後最大的好處就是甲方的管控細化到微服務模塊,即真正打開原來開發商的內部黑盒,可以細化管理到每個模塊的交付,接口,過程質量,這帶來的是一個重大的甲方管控能力提升。
由於單體應用被拆分,強勢的甲方還可以提前制定好微服務架構開發框架和模式,引入DevOps過程和方法論,同時引入多個開發商來共同開發多個微服務模塊,真正將開發過程可視化,持續集成過程可視化,由事後的驗收和質量控制轉變為過程中的隨時管控,真正避免後期被單一開發商綁架的問題。
自動化和效率提升
自動化一定是微服務架構實施的另外一個受益點,這個自動化包括了DevOps過程自動化,也包括了後期運維監控,變更發布過程的自動化。如果一個微服務架構實施沒有能夠實現自動化,反而投入了更多的人力資源來實現過程管控,後期的運維監控,那麼微服務架構實施的初衷都沒有達到,不僅僅是增加了開發運維工作量,同時也增加了整體運維和管控的難度。
當然這個自動化的實現,一個是涉及到開發商的能力水平,同時本身也涉及到甲方本身的信息化經驗和成熟度,兩者缺一不可。
網際網路各種最佳實踐相對多,一定要意識到有些東西在短時間並不適合馬上應用到傳統企業。這不僅僅是IT能力方面的問題,也涉及到業務模式和管控本身的差異。
微服務架構下是我們前面談過的SOA關鍵思想的落地,即真正實現業務能力組件化和組件能力服務化,同時實現前端應用的可組裝化,只有這樣才可能真正搭建靈活的SOA架構,實現當前IT架構對業務變化,新業務模式開展下的快速響應和支撐能力。
快速響應並靈活的支撐業務,是微服務架構帶來的另外一個關鍵業務價值實現。
如果要做一個給傳統企業講解的企業微服務架構轉型的方案,那麼這個方案應該做?
對於傳統企業轉型微服務架構,包括涉及到工作內容和範圍,技術的關鍵點,實施方法等在前面博客多篇文章中都進行了詳細的闡述,那麼要做一個面向企業宣講的技術方案材料,初步考慮整體搭建思路應該為:
01-傳統企業IT架構的問題
系統是建設的最小單位,那麼這裡的業務系統實際就是我們說的單體應用,講問題實際上更多是講傳統單體應用存在的問題有哪些?
如果從整體生命周期來看,實際上是可以從規劃選型期,開發建設期,運維期幾個方面來談。本身裡面又包括了軟體工程,項目管理,過程支撐三個維度的內容。
規劃選型期更多選擇是廠商比較產品化的產品,你很難去定一套技術架構,開發標準和規範體系,這也是後續導致整體IT架構裡面多語言,多資料庫,多開發框架,多接口類型的一個主要原因。
對於開發建設期,實際上最主要的問題還是整個業務系統裡面各個模塊間緊耦合,無法拆分,其次就是大量共性的內容重複建設的問題。這裡可以畫圖描述,如何把各個業務系統共性內容統一掉,並下沉到平臺統一建設,構建平臺+應用,應用層通過微服務模塊構建思路來完全鬆耦合。
在開發建設期,實際上還需要談一個重要問題,就是傳統建設模式下響應變化的能力弱,都是業務需求和功能,前端和後臺邏輯完全綁定死的。而實際上引入SOA思路和微服務架構化後,應用構建邏輯發生了變化,即核心的SOA思路:
即先搭建中臺(技術中臺+業務中臺),然後暴露中臺關鍵能力和服務,再由這些服務來組裝上層的關鍵前端業務和流程。
對於標準規範體系,實際上仍然是包括三個方面的內容,項目管理類,軟體工程類,過程支撐類,再加上後續運維期的的話還包括IT治理和服務治理類。本身這些規範如何和敏捷方法論,DevOps和持續集成等融合。規範作用一個是使過程標準化,模板化,其次是加強甲方對整個項目的管控力度。
02-微服務架構概述
方案裡面還是需要對微服務架構做一個簡單的介紹,即解釋清楚什麼是單體應用,什麼是微服務架構,微服務架構的核心是什麼?其次解釋清楚微服務架構和SOA的關係。
對於微服務架構進一步解釋清楚判斷的標準是什麼?
同時要說明清楚,要實現一個完整的微服務架構,需要滿足哪些判斷準則,同時在微服務架構裡面有哪些關鍵的核心組件,這些組件是起什麼作用?具體選用的標準是什麼?
在這裡可以講解下SpringCloud框架以及框架中的各個開源組件,並把每個組件本身的作用講清楚。但是最後一定要強調到,不是採用SpringCLoud框架就是微服務架構,SpringCLoud框架只是微服務架構裡面的開發框架部分內容。
微服務架構業界通用的一個定義是如何的?
微服務架構的判斷標準和準則,可以表格化來說明。微服務架構實現中最基礎要具備的能力(開發框架,註冊中心,負載均衡,服務網關,流控+熔斷,安全)
微服務架構化和傳統企業業務系統間SOA集成的差別在哪裡?
實際上我們看到最主要的就是SOA集成思路深入到了業務系統的內部,業務系統本身的各個組件變化為微服務模塊,共性組件變化為採用平臺層能力,微服務模塊間通過Rest接口服務集成。
如果單業務系統還是一個廠商來做,實際上單業務系統本身就是一個SpingCLoud框架體系,通過服務網關發布接口服務能力,同時將接口服務進一步註冊到跨系統的輕量SOA服務總線上面來。即實際上的接口服務集成可以理解為兩層的集成,內部仍然可以走註冊中心點對點集成,有需要發布到外的通過微服務網關通過二次註冊將能力發布出來。
一個企業應該如何實施微服務架構?實際上在前面一篇文章裡面已經談到,應該包括了諮詢和規劃,開發和構建,管控和治理三個方面的內容。後續的介紹可以圍繞這三個方面的內容展開。
注意:這裡應該有一個完整的階段模式的流程圖來說明,一個完整的微服務架構規劃建設和實施過程是如何的,即包括了前期的規劃階段,開發建設階段,後續的運維治理階段。要體現每個階段究竟是完成什麼關鍵工作,每個階段是如何銜接的。
這張圖實際上相當關鍵,即後續你要展開描述的內容都應該在這張圖上有體現。
03-微服務架構-諮詢和規劃
諮詢規劃做什麼事情?首先應該是調研清楚當前企業的IT架構是如何的?當前的架構下存在什麼問題?然後是給出企業本身的微服務架構轉型思路,具體的微服務架構演進路線。
在演進路線規劃完成後,在第一階段,比如對一個老的應用系統進行遷移或者一個全新的業務系統進行微服務架構開發,那麼我們就需要基於這個實際的需求來分析如何進行微服務架構的實施?裡面的關鍵點仍然是如何劃分不同的微服務模塊?如何定義清楚微服務模塊間的接口關係?如何拆分好不同的資料庫?這些頂層設計工作都必須在前期做完。
對於諮詢規劃階段,重點應該包括如下幾個方面的關鍵內容
04-微服務架構-開發和構建
開發和構建實際上最好的方法是,我們只進行類似4A,流程引擎,MDM主數據等平臺層微服務模塊的開發,而對於業務類微服務模塊只是劃分清楚模塊,定義好接口,而實際的開發則轉給企業內部開發人員或其他開發商進行。而我們需要做的就是整體的項目群管理,後期的多個微服務模塊間的集成。
即我們拆分好微服務模塊和資料庫,定義了一套標準規範體系和技術開發框架,然後找了不同的開發商來進行多個微服務模塊的開發,我們最終要保證開發完成的內容能夠完整的集成起來,並滿足端到端業務流程的需要。同時我們會實施一套過程支撐工具來實現對DevOps過程的可視化支撐,通過過程支撐工具可以實現對整個應用開發的完全自動化,可視化管理能力。
這裡重點實際上是基於規劃階段講解的總體思路和內容,來演示清楚如果一個廠商單獨構建一個微服務模塊整個開發建設的過程是如何的?
我們大的原則就是廠商內部可以走獨立的SpingCLoud框架體系,但是廠商和廠商間接口服務集成,走外部的SOA服務總線來實現治理和管控。在這裡的一個前提是廠商進行微服務模塊的開發時候,前面的整體架構設計工作應該已經完成,即模塊和資料庫已經劃分好,接口也已經定義好。
這個過程就是微服務架構模式下的實施過程,即廠商如何進行開發,接入如何發布和註冊,如何消費接口,如何進行開發,如何提交部署和發布等一系列問題。這個和我們原來講的私有雲PaaS平臺思路是相當類似的。
首先從大思路和流程上講清楚如何做,其次還得講清楚兩個層面的內容,比如選用了SpringCLoud框架來實現微服務模塊,那麼基於SpringCLoud框架如何來做開發,開發完成的接口服務如何提交註冊,如何消費外部接口,如何和其它微服務模塊集成和聯調。如果啟用了容器化部署和DevOps,如何和這些支撐平臺更好的集成等,這些都需要進一步描述清楚。
以上都描述清楚後,接著講微服務架構+容器化+DevOps結合的最佳實踐,同時來介紹整個融合的過程和DevOps支撐平臺和工具集。即通過這個支撐平臺和工具集,如何更好的實現了敏捷和自動化,如何更好的支撐整個微服務模塊開發和集成的過程?
05-微服務架構-管控和治理
整體微服務架構最終上線後,馬上面臨的問題就是運維管控問題。
在運維管控上面需要考慮的內容就是微服務架構整體體系如何監控和運維?這個監控運維即包括了資源層面的,也包括了服務和服務鏈監控等APM層的內容;其次還需要考慮在整個架構體系下,變更如何處理?版本如何發布?
這些基礎的指導仍然是類似ITIL標準的方法論,但是在微服務架構和支撐平臺實施後,類似問題管理,變更管理,運維監控,版本發布等流程都需要配合微服務架構進行相應的調整和定製。比如在實施了DevOps和容器化部署後,對於整個部署過程都是自動化進行的,和原來的手工部署就尋找較大的差異。
06-企業實施微服務架構實施
在這裡需要介紹企業微服務架構實施步驟和演進路線規劃。同時詳細的介紹全新開發構建和遺留系統逐步遷移兩種方法下的實施方法區別等。
當然,光說好的地方還是不行,對於企業是否實施微服務架構,微服務架構本身存在哪些問題也需要一併進行介紹。實際上講風險點,更多的應該是講企業要實施微服務架構應該進行的前期準備工作,包括了已有的IT積累,人員積累,企業本身的IT項目管理成熟度和規範化等,這些內容都必須要強調到。
舉個簡單的例子,原來是6個業務系統,微服務架構化後變成了60個微服務模塊的管理和監控,如果後續的運維監控能力跟不上,對於後續的運維和變更管理反而是災難。
在架構規劃階段和傳統的企業架構規劃的差別點,對於企業架構規劃我在前面很多文章裡面都詳細闡述過,主要還是基於標準的Togaf方法論,以業務驅動IT,從流程分析入手,依次對業務架構,數據架構,應用架構(包括集成架構),技術架構的規劃。
微服務架構,簡單來說就是原來的單體應用的微服務模塊化,同時對於原來的集成接口服務化,這和我原來強調的業務能力組件化和組件能力服務化是一個思路。也就是說我們整個管理的最小粒度發生了變化,從原來的單體應用變化到了微服務模塊。
那麼為了達到這個要求,在規劃階段究竟要做哪些事情?或者說如果仍然按照企業架構規劃的思路,在結合微服務架構思想的時候,應該做哪些改進才能給更好的匹配。
01-業務架構和數據架構
對於端到端流程分析和業務架構階段,基本上不受影響,還是按照傳統的業務架構分析方法進行即可,只是對於業務架構本身的多層視圖要更加清晰,從業務價值鏈到業務域,從業務域到業務組件模塊。業務組件還可以考慮分層,特別要注意的就是業務組件本身是比原來的業務系統粒度更小的單位。
基於業務流程的分階段,基於原業務部門的分科室,仍然是我們找尋獨立自治的業務組件模塊的核心方法。
當我們在觀察企業內部的業務部門或科室的設置時候,也會發現兩種情況:
而實際我們在後面拆分和構建微服務模塊的時候仍然是這兩類,數據類+業務活動類。只是再增加了技術類而已。
數據架構分析,核心思路仍然一樣,但是會更加強調數據的CRUD分析,同時強調數據域的劃分。對於數據對象不是很粗的確定要業務域,而是要確定到具體的業務組件模塊。即你要確定你識別和定義的數據對象,其核心的Owner是哪個業務模塊。即我們傳統的資料庫DB在微服務架構下是要拆分到組件和模塊級的,即模塊劃分好後,模塊對應的資料庫表也要歸屬清楚。
在數據架構規劃和分析的時候,一定要加強對基礎主數據,核心共享動態數據的分析。可以看到,在後續構建整體基於微服務架構應用的中臺時候,核心中臺組件來源於基礎主數據和核心動態數據。業務組件模塊和底層數據拆分域是對應關係,1個數據拆分域只能有一個Owner的業務組件。但是一個業務組件卻可能沒有對應的底層數據對象,即該業務組件只是調用其它業務組件的數據能力。
應用架構規劃這裡存在大變化,即進一步強化平臺+應用的構建思想。同時對於應用層又體現了一個關鍵的概念即業務中臺的構建。
原來規劃應用架構,每一個應用都涉及到系統管理,流程引擎,消息緩存等技術組件,上層才是具體的業務功能模塊,而新模式下所有的技術組件全部下沉到技術平臺層,這和多年前我博客裡面強調的私有雲PaaS平臺構建思路完全一致。只有技術組件下沉到平臺,上層的業務模塊才能被徹底的微服務模塊化和組件化。
02-應用架構的規劃和建設
首先要考慮剛才談到的技術平臺的規劃和建設,哪些放到技術平臺去做,形成平臺+應用的構建模式。其次考慮中臺規劃和建設,注意在傳統企業架構規劃-應用架構規劃設計中是沒有這個概念的。而在微服務架構模型下,結合SOA架構思想,增加了中臺規劃和建設的思路。
如何構建中臺,即中臺應該包括了哪些中心,如何更加中臺的數據和業務能力來組裝和編排上層的業務,這些都在應用架構規劃的時候要考慮的事情。對於中臺如何構建,我們前面博客有專門的一篇文章來說,在這裡就不展開。但是在應用架構規劃中重點就是要規劃清楚中臺的微服務模塊,前臺的微服務模塊。
應用架構重點就是要確定微服務模塊,微服務模塊本身和前面業務架構規劃的業務組件是對應的。在微服務模塊的規劃和定義中,要確定哪些業務功能在該模塊,哪些能力提供在該模塊,哪些數據Owner到該模塊。同時要分清楚了微服務模塊本身的三種不同類型。
在微服務模塊劃分清楚後,接著要做的仍然是微服務模塊間的集成關係規劃,即每個微服務模塊究竟應該暴露哪些API能力接口,同時又需要調用哪些其它模塊提供的API接口。
實際上我們在看很多採用SpringCLoud開發框架進行微服務模塊開發的項目中,各個微服務模塊之間仍然緊耦合,核心原因除了模塊劃分不合理外,其次就是各個微服務模塊間的API接口調用相當雖然,不受任何控制。可想而知,在這種模式下,微服務模塊間是很難做到真正的獨立自治的。
我們這裡指的微服務模塊仍然是大模塊的概念,即傳統的一個單體應用拆分為6-8個微服務模塊的粒度比較適合。
比如一個供應鏈管理系統,那麼招投標,採購,供應商管理這些就是獨立的微服務模塊。在這種方式拆分後你會發現一個採購模塊可能仍然還複雜,裡面還需要進一步細分為不同的功能組件,那麼這裡的思路就是在一個微服務模塊本身內部還可以拆分微服務組件,一個微服務模塊就是一個獨立的SpingCloud體系,有獨立的註冊管理中心,服務網關能力。
對於內部的微服務組件間的交互可以不用精細化管理,但是大的微服務模塊間的接口交互就必須通過服務網關暴露的接口服務進行協同,並嚴格受控。
03-技術架構規劃
對於技術架構規劃,這裡不展開談。有兩個點要關注。
第一就是基於微服務架構的技術架構,開發框架,運行期框架,包括微服務架構規範標準體系這套東西要完整,以指導開發商進行微服務模塊的開發和集成工作。
第二就是對於PaaS層中間件資源池,需要結合最新的容器技術來規劃,要考慮容器技術如何和微服務模塊,DevOps過程集成在一起的。
再次強調,對於傳統企業的微服務架構轉型,和我在12年開始博客上寫作的企業私有雲架構平臺相當類似,其核心仍然是共性技術能力下沉形成平臺+應用(微服務模塊)的構建模式,其次就是傳統單體系統徹底的進行組件化和服務化的改造。
其中變化的點只是在於從傳統的PaaS變為了輕量的基於Docker容器+K8s的輕量PaaS平臺,對於微服務模塊的開發建議採用標準的類似SpringCloud開發框架,對於接口服務集成轉變為Rest接口服務集成,對於在私有雲架構裡面我談到的持續集成進一步完善為了完整的DevOps方法論。
因此對於企業實施微服務架構轉型,仍然可以先參考我原來的文章,特別是裡面的組件化架構和組件化開發部分,一定要清楚部署你採用了SpringCloud和Rest接口服務集成,就是微服務架構,技術人員崇尚技術,但是最容易犯的毛病就是認為技術就是架構方法論,認為採用了WS服務就是SOA,認為採用了SpringCloud就是微服務架構等。
註:對於企業私有雲PaaS平臺規劃,架構,可以參考我最近出版的《SOA與大數據實戰:企業私有雲平臺規劃和建設》一書,裡面有詳細的內容介紹。
對於傳統企業的微服務架構轉型,包括實施前的準備,我在博客上已經寫過一些專門的文章,這篇文章主要還是基於前面文章寫的核心思路進行一些關鍵內容的細化思考。
對於共性技術平臺的能力下沉和微服務模塊化
單體應用原來一般都會帶系統管理和流程引擎,基礎共性技術模塊等能力。但是在單體應用拆分為微服務模塊後,每個微服務模塊一定不能再保留這些內容,而是應該下沉到共性技術平臺,技術平臺再以服務化的提供這些能力。即我們常說的4A模塊,流程引擎模塊,技術服務模塊(可能包含多個,類似消息,緩存,文件,通知等各種技術服務能力)。
每個技術模塊本身就是一個微服務模塊,可以獨立開發,部署和管理運維。每一個技術模塊都必須實現多租戶能力,即應用層的各個應用產生的微服務模塊都是技術模塊的租戶。技術模塊提供技術服務能力,這些技術服務能力需要考慮足夠的可復用性,服務高可用性和可管理性。
共性技術平臺必須先行,這些共性技術能力剝離後上層的業務模塊才能夠真正變得足夠輕量,只需要去關注自己業務模塊裡面的業務功能和邏輯的實現即可。企業在實施微服務架構的時候一定要注意到這個平臺的重要性,只有把這個建好,才能夠為你上層的業務模塊開發提供足夠的支持。
原有的單體應用拆分為微服務模塊
注意,這個是業務問題和總體架構設計的問題,而不是技術問題。對於原有的單體應用拆分不要超過8個微服務模塊,一般為4到6個即可。微服務模塊拆分的越細,各個微服務模塊之間的集成和協同就越複雜。要知道每個微服務模塊就是一個小應用,需要能夠獨立完成需求,設計,開發,測試,部署上線和運維工作。
一般微服務模塊的拆分思路可以參考原來應用在進行業務架構設計,總體架構設計的時候模塊劃分的方法進行,但是這個不絕對。判斷拆分的關鍵標準還是拆分後是否足夠的鬆耦合,是否能夠滿足完全獨立管理的需要。舉例來說如果一個模塊拆分出來,需要和其它所有微服務模塊都交互,大量的接口調用,那麼這個微服務模塊拆分出來沒有任何意義。
再簡單點來說,以流程驅動的應用系統,可以以端到端流程大的階段來進行模塊拆分,以數據為主的應用應該在進行數據CRUD分析後以數據域劃分思路進行微服務模塊的拆分。
注意,在進行獨立的多個微服務模塊開發前要進行的一個關鍵工作就是進行微服務模塊的拆分,第一個是要把各個模塊拆分好,第二是要事先定義好各個微服務模塊間相互調用的接口。原來這個工作是在應用內部完成,但是現在這個工作應該被單獨拿出來進行規劃,這個架構設計的動作不能少,否則就容易在後面出現微服務模塊開發和接口管理失控的混亂。
怎樣保證每個微服務模塊的足夠獨立自治,如果一個人開發兩個微模塊模塊,要實現兩個微服務模塊的完全獨立是很難的事情,你總會發現在私下發生的一些不規範和不嚴謹的調用。因此最佳的做法仍然應該是開發每個微服務模塊的開發小組完全獨立運作,但是允許這個開發小組只有一個人的場景。只有這樣,微服務模塊間的協同才可能由隱性轉變為顯性。
關於開發環境的搭建和準備問題
對於傳統開發,如果我們談到開發環境,那麼一般只會說到開發資料庫,而對於應用中間件一般都在我們本地啟動和運行,方便進行開發自測和調試運行即可。而到了微服務架構下你會發現一個大的變化點,就是你自己的微服務模塊往往在你本機環境是無法正常運行和跑起來的,你的模塊要運行起來需要調用其它微服務模塊的Rest接口服務能力,那麼就需要這些微服務模塊處於運行狀態才可以。
同時微服務模塊大原則要求就是資料庫一定是拆分的,你只能訪問和控制你自己的資料庫,而其它微服務模塊的資料庫你都無法訪問,因此更加無法在開發中直接去訪問資料庫完成相關的業務了。
因此在微服務架構開發下,必須要有開發環境,類似前面說的4A,流程引擎,技術服務能力都必須要提前部署到開發環境去。同時你自己開發的微服務模塊有兩個思路,首先當你作為接口服務能力提供方的時候,你必須要及時的將你的模塊部署到開發環境上面以方面其它模塊使用,其次當你作為消費方和自己代碼功能調試的時候,你可以在你本機環境運行你的微服務模塊,但是對於訪問的外部接口服務地址都來源於開發環境各個模塊提供給你的能力接口。
一定要注意,在進行了微服務模塊拆分後,集成和協同的難度一定是增加了,同時對於整個微服務架構下的管控和治理難度也進一步提升。但是好處就是原來單體應用內部模塊間不規範和黑盒的東西全部暴露了出來,對於管控的精細度也進一步加強了。
再次強調下不要將微服務架構簡單理解為SpringCloud+Rest接口,更加重要的是組件化和服務化,平臺+應用的IT構建思路。
為何說微服務模塊不適合劃分的太細,上面已經講過的劃分的越細集成的難度就越大。在上篇文章裡面有個點沒有談到就是微服務模塊本身是需要帶自己Owner的資料庫的,而各個微服務模塊對應的資料庫是完全拆分的,這才是典型意義上的完全微服務架構化。
微服務拆分關鍵-資料庫拆分
前面講了可以按業務階段,按數據域來劃分微服務模塊,在微服務模塊劃分的時候不僅僅是前端業務功能的劃分,更加重要的是後端的資料庫表的Owner的劃分。即要搞清楚每個微服務模塊究竟管理哪些資料庫表,每個微服務模塊對應的資料庫,要麼有核心的業務對象和數據對象,要麼就是有核心的業務規則邏輯。
資料庫劃分清楚後,各個微服務模塊完全獨立,資料庫之間是不能有相互交叉訪問的,那麼微服務模塊間只能通過Rest接口進行交互。Spring Boot框架中很方便將Java API方法暴露和映射為Rest接口,這就很容易導致接口濫用,這也是前面一篇文章我重點強調了微服務模塊劃分好後,在架構設計的時候就要完成接口設計和定義,然後再開始各個微服務模塊的並行開發,然後再進行集成。
由於資料庫的拆分和採用無狀態的Rest接口服務,必然導致前端開發的複雜化,同時導致分布式事務問題,這個在博客前面很多文章都已經描述過,在這裡不再展開。
一個前端的微服務模塊完全可能是不掛資料庫,僅僅是使用底層中臺各個模塊暴露的接口服務能力,也可能掛一個資料庫,但是該資料庫僅僅是存儲臨時數據和單據。同時一個微服務模塊也完全可能僅僅是提供中臺接口服務能力,而沒有前端界面,對於前端完全支撐各種多樣性和靈活性,但是最終的數據需要落地到該中臺數據模塊。
同時還有一類微服務模塊,本身類似在SOA架構設計中的組合服務能力提供,即更多的是提供整合後的組合服務能力,同時做好事務處理和一致性管理,這類微服務模塊本身也可能不掛資料庫。
簡單來說,就是微服務模塊化拆分的時候除了縱向的微服務模塊是鬆耦合關係外,對於涉及到 資料庫+中臺模塊+前端模塊 這三者之間也是鬆耦合關係,可以根據業務的需要靈活的進行組合。
開發前期準備-接口部分
在要正式開始一個微服務模塊的開發的時候,開發前期的準備一個重要工作就是接口部分的準備。即你首先要搞清楚你這個微服務模塊要能夠成功的運行起來,你需要調用底層技術中臺哪些接口服務能力,同時你需要調用其它業務微服務模塊哪些業務Rest接口服務能力,同時你又需要暴露哪些接口服務能力給外部其它微服務模塊用。用硬體裡面話來說,就是你要把自己這個微服務模塊的南向接口和北向接口全部搞清楚。
而這些也正是為上篇文章裡面談到的,在整體應用的架構設計的時候,就應該把微服務模塊劃分好,應該把每個微服務模塊的南向接口和北向接口能力規劃和定義好。這才是一種自頂向下的設計思路,而不是後面想到哪裡做到哪裡,缺接口又隨便添加,導致後面微服務模塊間的接口交互完全失控。
對於技術中臺而言,往往一開始就可以將規劃和定義好的服務接口發布出來並部署到開發環境,但是對於業務微服務模塊間的接口就需要在各個開發小組開發過程中協作完成,那麼我們就要注意,當你開始開發你自己的微服務模塊的時候,更加重要的是先開發你需要對外提供和暴露的接口服務,因為只有這樣才不會影響到其它開發團隊的開發工作。否則,你就自己需要寫服務模擬端代碼,以確保你的模塊能夠正常跑起來。因此,我們建議的方法仍然是各個微服務模塊開發的時候接口先行,其次才是開發內部功能和業務邏輯。
其次,不管是對於接口的消費,還是接口服務的提供,最好有獨立的Proxy代理類來進行管理,即所有的對外出口和對外入口,都有統一的Java類來進行代理。因為我們實際在使用Spring Boot框架的時候,容易出現在很多個Controller類裡面都出現接口開發和映射註解,如果我們要查找究竟開發和消費了哪些接口後面自己都不好查詢,因此建議還是通過統一的Proxy代理類進行接管更好。
單個微服務模塊本身的前後端分離
再考慮下如果對於單個微服務模塊本身進行了前後端分離,即對於業務邏輯層+接口服務暴露單獨進行打包,對於前端應用開發單獨進行打包。那麼在這種情況下前端應用是否全部通過Rest接口服務進行底層能力訪問呢?
實際在在整個微服務架構開發裡面,對於微服務模塊應用自己Ower的資料庫操作,我們並不建議去走Rest接口服務去交互。舉例來說1個微服務應用的前端和後端可能有100個接口交互點,而這100個接口交互點裡面往往只有10個接口涉及到和外部微服務模塊交互,因此只需要將這10個接口暴露為Rest接口服務並註冊到註冊中心目錄庫即可。
最好的方式就是同樣一個API方法即可以實現內部調用使用,又很方便的通過註解發布為Rest接口服務能力供外部微服務模塊訪問。即滿足接口交互和協同的需要,又滿足內部模塊性能和開發效率的需要。
其次,單個模塊在構建的時候前端和後端模塊分離是必須,即對於前端模塊和後端模塊完全可以進行獨立的打包,同時前端和後端可以安排給不同的團隊或不同的人獨立開發。即我們看到對於微服務模塊首先安排到不同搞得開發小組和團隊,其次對於微服務模塊進一步拆分為前後端,可以安排到不同的人。前端開發負責前端界面展現,服務能力的組裝,互動設計和協同;後端模塊人員負責API接口能力的開發和暴露。
注意,在這種前後端分離的情況下,可以更加方便我們後面直接對微服務模塊API接口進行自動化的單元測試操作,這個可以和DevOps和持續集成做到無縫對接。
對于敏捷方法論我前面也有很多文章都談到過,敏捷方法論裡面核心的內容仍然是短周期迭代,持續集成和可視化,條目化需求管理和跟蹤等。
對於以上內容即使你不實施微服務架構,仍然都可以採用。在談敏捷方法論的時候我曾經談到過,如果是對於一個全新開發的系統,特別是底層模型複雜的時候,往往很難實施敏捷方法論,因為對於這種全新系統在前期保留架構一致性相對重要。
但是如果一個全新的系統,能夠在前期提前先做好微服務模塊的劃分,做好總體架構設計,數據模型設計和各個模塊的南北向接口設計和定義,那麼實際上前期架構一致性的工作就基本完成,那麼對於每個已經拆分後的微服務模塊,這個模塊本身的功能點,對應的資料庫,包括消費的接口,提供的接口這些內容都完全清楚了,那麼對於模塊裡面的各個功能點完全可以做到按敏捷方法論進行功能需求的條目化,並進行短周期迭代開發。
對於微服務架構和敏捷方法論在前面很多文章都已經詳細談到過,因此在這裡只談微服務架構和敏捷方法論在集成過程中涉及到的一些實施關鍵點。
首先,對于敏捷團隊本身跟著微服務架構進行拆分,即對於負責不同的微服務模塊的團隊單獨拆分開,每個團隊都會有對應的需求,設計和開發,測試人員。對於微服務模塊本身需要獨立自治,因此對於開發每個微服務模塊的團隊本身也是高度獨立自治的,能夠完成自我運轉。
在拆分後,每個微服務模塊的開發,完全可以按照傳統的敏捷方法論進行管理和監控,包括相應的需求條目化拆分,基於UserStory主線的跟蹤和管理,燃盡圖等實踐都沒有問題。但是在做這個事情之前,敏捷團隊一定要意識到,模塊的成功運行需要依賴外部的接口服務能力,這些接口服務能力必須提前得到管理和監控,作為模塊開發進度的關鍵前置依賴,否則將很容易由於外部原因影響到自身模塊的開發進度。
其次,對於持續集成這塊,我們首先可以做到的就是在編譯期無組件依賴,確保自身的微服務模塊可以正常編譯打包和部署。然後就是在持續集成後完成後需要進行單元測試,這個單元測試需要優先進行你消費的接口和你提供的接口的單元測試,其次才是內部業務功能的單元測試。對於模塊的自動編譯打包和部署,在採用容器資源池後,還需要和容器部署進行集成。
即在前面講的編譯和構建-》形成部署包-》鏡像製作-》容器化部署和託管。
在實施DevOps方法論後,上面整個過程需要做到完全的自動化,即每天下班你只需要將本機編譯通過的代碼檢入配置管理庫,其它的工作都應該是自動化完成,包括編譯打包,部署和單元測試。
在微服務架構場景下,將更加關注多個微服務模塊間的集成測試,同時這類集成本身還具備有前後關係,哪些模塊或接口應該先集成,哪些應該後集成,這些整個產品集成規劃和執行本身是在敏捷方法論外的內容,需要單獨進行考慮和設計。
最後,需要考慮形成兩級的敏捷項目管理方式,即首先是單個微服務模塊本身的敏捷項目管理,其次是多個微服務模塊組成的完整應用的敏捷項目群管理。單個微服務模塊的項目管理由各自的敏捷團隊自己完成,對於項目群的管理,則需要專門的人來進行管理和監控。實際上項目群管理的關鍵問題仍然是在前期微服務模塊的拆分,接口的定義和依賴,後期的多個微服務模塊的集成關係和順序。只有這些都梳理清楚了,多個微服務模塊間才能夠很好的完成協同形成一個完整的應用。
簡單的看板實際上很難完成上述的項目群管理工作,因此對於項目群的管理和監控仍然需要使用能夠明顯表達出前後依賴關係的可視化進度圖表來進行展示,比如甘特圖等。對於項目群的管理,個人認為是一個大的IT應用拆分為微服務架構後,實際上確保項目能夠正常執行和功能集成的關鍵。
前面已經談到過,微服務架構不是簡單的微服務開發框架的使用,更不是簡單的Restful接口的使用,而是大量的SOA,持續集成,組件化和服務化,雲平臺和容器,DevOps等思想的融合應用。因此在考慮轉型到微服務架構的時候可以首先進行相應的準備,而這些準備基本都是可以獨立完成並實施的,具體如下:
持續集成實踐:在很早就有持續集成的思想和最佳實踐,裡面涉及到配置管理,自動編譯部署,環境遷移,自動化的單元測試,每日構建和冒煙測試等方法和實踐的使用。這些即使沒有實施微服務架構,對單個業務系統也可以進行持續集成的實踐。持續集成和自動化的構建是後續微服務架構和DevOps的一個重要內容。
領域建模思想:對於領域驅動架構是面向對象分析和設計中的一個重要內容,通過領域服務層的構建可以很好的解決業務高內聚和粗粒度的服務接口提供的問題,而不是簡單的將對資料庫表的CRUD操作發布為服務接口,同時領域建模也很好的解決了原有的貧血業務邏輯層的問題,真正在業務建模和架構設計階段,從對數據對象的關注轉移到對業務領域對象的關注。粗粒度的服務接口即使在實施微服務架構後也是必須關注的內容,否則會出現微服務模塊間大量的接口交互的場景,這種接口越多越導致了微服務模塊之間越緊耦合。
SOA思想的深入理解:對於微服務架構實際上是SOA參考架構思想在原有的單體應用內部的實踐和落地,因此SOA思想是基礎,而SOA思想本質就是業務能力組件化,組件能力服務化,將業務流程或業務的實現轉變為多個鬆耦合的業務組件(微服務模塊),同時通過微服務模塊暴露的API服務接口實現組件之間業務功能的組合和編排,以完成完整的業務流程。
微服務開發框架的學習:比如對當前主流的Spring Cloud微服務框架的學習和理解,其中包括了服務目錄和服務註冊,微服務網關,服務的發布,服務後續的管控治理,服務運行監控等諸多內容。這些都需要去學習和理解。通過微服務開發框架,真正實現了各個微服務模塊的開發完全獨立自治,可以獨立進行設計,開發和最終的部署。而微服務模塊暴露的服務在註冊到微服務網關後又實現了多個微服務模塊之間的聯動。
關鍵技術的學習:這裡面主要包括了Web Service,消息中間件,事件引擎,Restful接口和面向資源的概念,CXF開發框架,Spring Boot和Spring Cloud,Maven構建,DevOps,雲和容器技術,前端技術等。這些都是在微服務架構實現和微服務模塊開發中會用到的內容,需要學習和掌握。
基礎平臺和技術組件和服務的學習:這裡面包括了常用的工作流引擎,4A和權限管理,日誌管理,緩存,文件服務,ETL數據集成,消息和通知等,這些也都是在實施微服務架構的時候可能會下沉到基礎平臺層統一規劃和實現的內容。
軟體過程改進方面的內容:企業遵循什麼樣的軟體開發過程和軟體生命周期模型?是傳統方法還是敏捷方法論?需求,架構,設計,開發,測試,發布完整的流程是如何的?對於配置,變更,評審和Review等過程又是如何的?這些都需要有一定程度的定義和標準。即使實施了微服務架構,也需要遵循傳統或敏捷的軟體工程方法論。而在微服務架構中,很重要的一個就是微服務模塊的劃分,微服務API接口的識別和定義,我們可以在傳統方法論中進一步補充這方面的內容。
今天還是想在談下企業微服務架構轉型中詳細實施步驟的一些細節問題。在前面的文章中已經談到過微服務架構轉型中的實施策略,今天重點談下微服務架構轉型中的實施步驟。
步驟1:4A和流程平臺的下沉和能力開放
這個是我談的最多的問題,即在實施微服務架構轉型的時候必須將4A(也可先狹義理解為原業務系統的系統管理模塊)和流程引擎下沉到平臺層共性建設,或者說優先要將這兩個模塊作為微服務模塊剝離出來,同時給上層的業務組件模塊提供API服務接口能力。
對於4A模塊剝離後,我們希望的是涉及到人員,組織,用戶,權限等能力的獲取都是通過服務接口實時查詢獲取,這些基礎主數據信息也不要落地。在進行這樣實施的時候確實會增加上層業務系統的改造工作量。對於流程平臺的籤出相對來說比較容易,最主要的還是給業務模塊提供流程啟動,暫停,獲取待辦已辦列表等關係服務接口信息為主。
進行4A和流程平臺的剝離核心目的仍然是是的後續需要進行拆分的業務模塊只包含業務功能,而不再包含共性的技術能力功能。
步驟2:基礎主數據模塊能力獨立建設
這是我們談的第二個重點,即希望將提供共享基礎主數據的功能單獨剝離出來進行獨立建設,比如建設獨立的主數據平臺或叫提供基礎主數據的各個數據中心模塊。然後數據能力以數據服務的方式暴露出去供上層業務系統使用,同樣我們希望上層業務模塊在使用這些基礎主數據的時候最好主數據不落地,實時用實時查。
在傳統PaaS平臺建設中會涉及到MDM主數據平臺的建設,到了徹底的微服務架構可能並不存在主數據平臺的概念,而是各個類似產品中心,供應商中心,客戶中心的各個微主數據中心模塊,這些微服務模塊也是我們常說的中臺的核心數據能力提供中心。
要規劃和建設中臺,首先要考慮的就是這種基礎數據中心,其次才是提供業務支撐和業務邏輯處理的中心。
步驟3:業務模塊的拆分到微服務模塊或逐步剝離出來
我們一直在講,傳統企業的微服務架構轉型是一個漸進的過程,是一個老的IT架構逐漸被新架構替換,老架構逐步消亡的過程。在步驟1和步驟2這種共性的基礎技術和數據能力下沉後,剩餘的業務系統遷移和微服務模塊拆分就可以開始逐步進行,逐步遷出。
對於一個業務系統的業務模塊逐步剝離出來,一個關鍵的策略就是優先剝離耦合性最低的業務功能模塊,在這個思路下最可能的實施策略就是先將業務系統支持流程的兩端(最前端流程或最後端流程)逐步剝離出來。因為兩端的流程往往是耦合性最小的流程。
拿採購系統來舉例,前端的招投標模塊是最容易剝離出來的,後端的採購過程跟蹤,採購評估等模塊往往也是最容易剝離出來的。這裡拿招投標模塊來舉例。
注意招投標模塊在剝離出來後,橫向的交互接口往往並不多,最多也就是招投標執行過程的結果信息或配額信息需要傳遞到採購管理模塊。而對於招投標本身的一些結果數據已經可以下沉到平臺層的主數據模塊中,而設計到流程處理部分也已經下沉到平臺層的流程引擎模塊,因此可以看到只要步驟1和2遷移到平臺層後,再遷移出招投標模塊基本就很容易了。
步驟4:及早的進行統一門戶的建設
要注意,在各個微服務模塊建設完成後,單個微服務模塊本身是不能提供支撐完整業務流程的能力。對於用戶來說並不關心是否進行了微服務架構化,而是關心涉及到業務流程處理的功能和操作是否能夠很方便的在一個業務應用裡面操作和完成。
而這些業務模塊基於業務流程,基於業務場景和使用部門的組裝和展現,就需要在門戶層完成。對於統一門戶不僅僅是提供統一認證和單點登錄,也還包括了統一的待辦集成和任務處理,統一的消息通知等共性功能能力。也就是說,只要是各個微服務模塊共性的一些需要展現的能力,都可以集中化到統一門戶層去集中處理和展現。
門戶層還有一個重要的功能就是進行微服務模塊的組裝,這些模塊組裝後可以為業務用戶提供完整的端到端業務流程功能支持,讓最終用戶的感覺就是在使用一個系統,沒有系統不停切換的感覺。因此實際上在門戶層不僅僅是簡單的模塊選擇,也還可以做一些展現層的編排和組合工作。
對於微服務模塊的靈活組裝也是相當困難的,因為很多模塊組裝最終都是體現到模塊提供的南北向接口的自動對接,這往往是比對服務組合和服務編排進行定製更加困難,對於這個問題後續將在單獨進行討論。