在前面頭條文章中我分享過鐘華老師的《企業IT架構轉型之道》這本書的讀書筆記，這本書基于阿里的中臺戰略，服務中心，SOA服務治理給出了相對多的最佳實踐，也給了傳統企業轉型很多有借鑒意義的思考，但是對于傳統企業IT架構轉型還是有許多問題值得思考。

因此今天對傳統企業IT架構轉型，傳統架構微服務化方面再做下總結整理。

傳統企業IT架構轉型概述

企業IT架構為什么要轉型

傳統企業內部信息化部門的核心目標仍然是基于業務驅動IT的思路，通過IT規劃和應用的建設更好的支撐企業業務流程，IT本身的價值都體現在IT系統建設對業務核心價值鏈的績效提升和增值上面，而不是體現在各種先進技術的應用，技術只是工具手段，最終業務能力提升才是最終目的。

企業信息化推進可以理解為三個階段。

第一階段是基礎應用建設解決基本的業務和流程協同自動化，提升基本的效率；第二階段是提供管理層的管理能力，實現基本的業務全流程協同和管控；第三階段則是到了決策層的輔助決策和商業智能能力。

雖然我們一直在強調業務推動IT，但是了第二和第三階段，你會發現往往強勢的IT部門會反推業務進行優化和變革，這也是在傳統企業經常會碰到的現場。

企業IT架構為什么要調整？核心原因仍然是在業務敏捷性和IT成本投入上。

首先是企業業務高速發展，IT系統的建設和能力無法匹配，這里面包括了業務功能，接口，性能，安全的匹配；也包括了對于有新的業務開展如何快速地迭代和版本升級后的變更匹配。在業務系統不能提供快速，準確，高性能和高易用的功能時候，往往IT就成為業務發展的瓶頸，業務人員也花大量時間在系統響應等待，數據協同等待，變更功能需求開發等待，數據核對等大量事務上面。對于如何更加敏捷地響應業務這個問題，我們就需要去考慮哪些是通過IT架構調整能夠更好的解決的。

我們常說的SOA參考架構的思想，實際和制造企業的敏捷和柔性生產思路完全一致，即面對前端需求的變更，我們如何做到整個IT應用的柔性和快速響應能力。

其次就是信息化部門經常遇到的IT系統管控困難和大量成本重復投入問題。企業在發展過程中IT系統越建設越多，很多相同的業務系統還3到5年就換一次，反復建設和重復投入，各種服務器，存儲硬件資源也大量購買而利用率低下。對于外包給供應商開發的業務系統后續自己無法運維管理，只能依托和受制于廠家，系統間的交付和接口也越來越復雜，很難真正看得上整個信息化建設后的全局應用架構視圖，以及IT對業務當前的支撐情況，包括差距分析等。

而這些問題最終都體現在能否通過IT架構的調整和統一規劃，來盡可能減少IT建設和運維期的重復投入，同時能夠將已經建設完成的企業應用真正變化為企業能夠自主掌控的IT資產。

企業IT架構優化的目標

當我們和傳統企業交流的時候，一定要避免兩個方面的問題。一個是企業直接就提出需要參考互聯網企業做法，要做企業內部私有云，要參考工業4.0的做法建設大數據平臺和ESB平臺等，或者還有直接就提出要實施容器化技術和微服務架構；還有一種情況就是我們在沒有了解企業當前業務和IT的現狀和問題的情況就直接先入為主的方式給客戶推廣某種主流技術和產品，這些都是雙方應該避免的做法。

IT架構優化的目標一定是為了解決前面說的兩個問題。

第一個問題：業務敏捷性和響應能力的提升上面，要解決這個問題就必須要考慮IT架構如何更好的基于SOA參考架構進行分層，真正將共性業務和技術能力下沉，變成服務中心和能力中心，同時各個中心暴露可以高度復用的能力接口，那么上層業務在新增或變革的時候，我們就很容易基于已有能力進行組合和編排。

你要做到這樣，正是SOA核心思想，即首先要找到可復用的業務組件，同時將業務組件能力通過服務化的接口暴露出來，通過這個做法也正是阿里說的中臺戰略和各中心建設的核心思路。

第二個問題：如何節約成本，我們在考慮應用層組件和服務復用的時候本身已經節約了成本，但是到了IT建設階段還可以考慮的就是資源層如何規劃提升利用率（IaaS平臺），平臺共性能力如何集中建設并復用，避免重復建設（PaaS平臺），后續功能如何靈活擴展而不是全部要新建系統（微服務架構和組件化），如何更加自動化地監控和管理整個業務環境(IT管控治理，DevOps，運維自動化等），當這些問題都思考清楚后，在如何降低成本上面的目標和思路也就清楚了。

IT架構和微服務轉型-關鍵需求分析

微服務架構這個概念出來已經很長一段時間，從最開始在互聯網企業的廣泛應用，到現在越來越多的企業開始關注和希望嘗試使用微服務架構并實施云原生整體解決方案。

對于企業從傳統IT架構到微服務架構的轉型，絕對不是盲目地跟風互聯網企業，而是企業的業務規范，企業的信息化水平和IT成熟度發展到一定階段后的比如訴求，那么這些關鍵的訴求究竟有哪些？

從系統規劃建設期到IT管控治理和運維期

首先可以看到當企業的信息化和IT系統建設發展到一定階段后，自然會從IT系統的規劃和建設期發展到后期的IT系統管控治理和運維期。到了后期不會再有大量的新系統規劃建設，而更多的都是為了業務流程優化進行的IT系統需求變更，優化和功能改造。那么關鍵的問題就變成了如何快速地響應業務需求變化并發布系統，同時如何又以最小的代價和影響來發布系統？

傳統的IT架構模式可以看到很難解決這個問題，每次需求或功能變更的發布周期相當長，同時由于是一個大單體應用全部發布，往往增加了一個新功能反而導致多個老功能出問題。這些都是我們經常遇到的問題，其核心的原因就是原來我們管理的業務系統本身的顆粒度太大了，其次就是從需求到開發到測試到發布整個過程如何自動化銜接。第一點涉及到微服務架構，第二點涉及到容器云PaaS平臺和DevOps過程支撐方面的內容。

在微服務架構下，我們管理的單位從原來的大單體應用變化為了細粒度的微服務模塊，自然在變更和發布的時候影響單位也相應變小到各個業務模塊粒度。這將有效的解決子在后期運維變更功能發布的影響。

業務組織和IT系統緊耦合到解耦需求

其次，在傳統IT系統規劃和建設中，在企業架構規劃設計中，我們經常談業務和流程驅動IT，強調端到端流程的貫通。但是系統規劃設計和實現的過程中，最普遍的現象就是不是業務驅動IT，而是業務部門驅動IT，導致我們的IT系統和業務部門是緊耦合的。舉例來說，一個企業只有供應鏈部，那么建設的系統就是供應鏈系統；但是如果一個企業有采購部，有物流部，那么建設完成的系統就是采購系統和物流系統。

在這種情況下，帶來的最大問題就是企業的業務組織架構一調整，往往帶來IT系統巨大的調整工作量，在我原來的企業也經常遇到IT系統經常配合業務組織架構調整的事情。這類工作已經不是簡單的HR系統組織結構調整，還包括了本身的業務系統中業務功能點的調整，已有的業務數據的調整，這些都需要進行動態切換和割接。

當企業建設的業務系統越多，和業務部門關系綁定得越緊密，這種調整帶來的復雜度和工作量也就越大。而真正的解決思路就是要將業務組織和部門和業務系統解耦。

如何解耦？

仍然是從業務流程驅動的角度去考慮和拆分具體的業務單元，這些業務單元形成獨立的業務組件（微服務架構中的微服務模塊），由于這些業務組件粒度已經足夠細，因此更加容易靈活的組裝或組合去滿足實際業務部門的日常業務需求。

舉例來說：如果是大的供應鏈部門，就配置供應商管理，物料管理，采購訂單，招投標，庫存管理，物流配送管理等多個微服務模塊。如果是拆分為采購部門和物流部門，那么采購部門配置供應商管理，物料管理，采購訂單，招投標管理，物流部門配置庫存管理，物流配送管理等微服務模塊。

在規劃和拆分微服務模塊的時候更多是業務和流程角度出發，只要劃分得足夠合理，就能夠最小化的減小業務組織架構調整對IT系統本身造成的影響。

從單打獨斗信息孤島到共享思路下的平臺戰略

企業信息化發展到一定階段，自己都會意識到按照傳統的一個個孤立的業務系統建設模式越來越行不通，這不僅僅是業務系統很多功能重復建設的問題，同時還導致了業務系統中數據不一致性，集成困難，后續的運維和變更處理困難等一系列問題。即典型的錢花得更多，但是系統卻越來越復雜和難用。

而解決這個問題的的關鍵就是平臺戰略，對于平臺戰略本身又有兩個重要的核心，即不是簡單的遺留系統能力直接服務化共享，而是首先要集中，其次才是共享。集中化是云的思路，而共享才是SOA的思路，兩個關鍵點都解決了才是云計算+SOA的關鍵思路融合。

為啥要把這個問題在微服務架構里面談，因為平臺+應用構建模式本身也是微服務架構實施的一個基礎條件，微服務模塊更多都應該是獨立承擔某個業務域的業務組件模塊，而不應該包括類似流程引擎，系統管理等共性底層組件，否則微服務模塊又變成很重的單體應用，沒有了任何價值。

要做好微服務架構，我們就必須做好底層基礎共性平臺的建設，只是微服務架構里面會談為共性的技術服務能力提供，都是一個道理，就是共性的東西或能力要下沉，然后再以標準的服務接口方式暴露或共享出來給上層的業務系統使用。

資源池的有效利用和資源動態調度

這是微服務架構結合PaaS容器化技術和動態調度技術后帶來的一個新的亮點，即可以真正實現按照業務需求和業務并發量動態的申請和分配資源，以滿足業務并發訪問的需求。在整個過程中不需要人為去干預，而只需要設置好相應的調度規則和資源動態擴展規則即可。

對于這個點實際當前并不是很強企業的訴求，只是后續成熟度發展到一定階段后帶來的亮點功能，真正解決了IT系統的靈活資源分配，擴展和動態調度問題。

問題解決和關鍵收益

前面談了傳統企業IT架構轉型的一些關鍵述求，那么在實施了微服務架構轉型后可以解決的關鍵問題或帶來的收益有哪些？

下面具體談下這方面的內容。

首先是進一步節約IT基礎設施建設投入，容器比虛擬機更加輕量化，同時結合Kurbernetes后可以實現自動化的資源調度，可以最大限度的提升資源的利用率。要明白，沒有真正實現PaaS層能力的企業云平臺，往往僅僅是簡單的實現了從物理機到虛擬機的使用轉變，而并沒真正解決資源利用率大幅提升的問題。要解決資源利用率的大幅提升就必須實現應用托管和資源動態調度，而是要非人為干預全部自動化完成。

徹底貫徹平臺+應用，以及業務部門和IT系統解耦的思想，以后企業擴展的都不再是業務系統，而是業務組件或模塊，同時逐漸不再有業務系統的概念，只有業務組件模塊的概念。業務部門不會和IT系統嚴格一一對應，而是通過業務組件的組合和組裝方式來快速搭建業務部門需要的功能。這是IT系統能夠更加靈活或柔性地適應企業業務流程，企業組織架構變化的關鍵一步。

進一步加強企業作為甲方的時候，對業務系統開發廠商的管控能力，即從粗粒度的業務系統管控到更加細粒度的微服務模塊。同時結合DevOps可以使整個從需求，開發，測試，上線的整個過程全部透明化，而不是作為開發商的黑盒。正是由于整個過程的全程可視和自動化，甲方企業才可能后續真正做到業務系統的接維。

轉型后可以進一步提升敏捷響應業務變化的能力，你會看到從業務部門提出業務需求或變更，到最終功能發布的上線時間會大大縮短。這種縮短的原因體現在整個流程中能夠自動化的工作，全部自動化掉了，包括打包，自動化的單元測試，環境遷移和部署等；其次變更發布影響的范圍減小，從影響一個業務系統變化到往往只需要影響一個微服務模塊，大大減少了變更發布的測試驗證工作量。最后，理想狀態下很多平臺層的能力和技術服務都全部實現，而實現業務組件的開發只需要關注業務本身，而不需要再去考慮任何技術層的共性能力，這本身也可大大提示業務組件和模塊的開發效率。

在整個微服務基礎框架+技術服務組件建設完成后，實際上單個業務微服務模塊開發本身反而更加容易，在這種情況下微服務模塊的開發人員并不需要完整的了解詳細的完整業務流程細節。而只需要按業務需求開發業務功能和實現業務邏輯，消費微服務API接口，并按要求提供和暴露共享接口即可。對于微服務模塊的集成和組裝可以由專門的技術架構人員來完成。

進一步提升企業對IT資產的管理水平，企業管理的不再是簡單的最終狀態的部署包，而是實現從最開始的需求到源代碼文件的全流程管理和檢查。

當企業所有應用都按照標準的微服務架構，開發工具和環境進行開發后，同時嚴格實施DevOps后，可以看到企業的運維就完全實現統一管控和運維。包括運維管理流程，運維工具，運維監控和預警等，安全管理等都可以進行統一。同時在這種運維能力統一并自動化后，IT運維人員效率提升，需要的IT運維人員數量也大幅減少。

厚平臺+薄應用的概念，真正實現了前端應用和后端服務的解耦和分離，服務可以更加靈活的組合和組裝來構建前端應用。同時可以支撐移動APP，BS網頁，Pad等多種前端應用類型。也可以更加靈活的支撐不同的前端業務應用使用相同可共享的業務服務或技術服務能力。

從傳統偏重的ESB服務總線集成模式轉變到輕量的去中心化的微服務網關集成模式，真正實現整個架構搭建中無中心化節點（也就是無關鍵瓶頸節點），從而實現整個架構極強的資源動態水平彈性擴展能力。另外從傳統的代碼編譯和部署包交付模式轉變為基于Docker容器的鏡像交付模式，極大的提升了部署和環境遷移的效率，同時提升了整個業務系統的彈性可伸縮性。

建設和實施難點分析

下面重點談下微服務架構在實施過程中的難點，特別是在已有IT架構已經基本成型的情況下轉型到微服務架構的實施難點。

首先是數據庫的拆分，如果數據庫沒有拆分而僅僅是應用組件拆分不能稱為完整意義上的微服務架構，傳統單體應用轉變為微服務架構后，從頁面前端到邏輯層到數據庫都應該完全獨立的一套，可以獨立進行需求，設計，開發，部署和后續的運維管理。因此要轉為微服務架構，首先數據庫要拆分，微服務模塊在拆分的時候一定要考慮對應數據庫拆分的合理性和自治性。

數據庫拆分后，原來簡單的底層數據庫關聯查詢，變化為需要通過領域服務層進行服務組合才能夠完成。原來數據庫層很容易控制的數據庫事務，轉變為了由于進行WS接口交互帶來的分布式事務問題。這個我們在談組件化和微服務架構的時候多次談到，是微服務架構實施的一個關鍵難點。

其次，基礎平臺層和技術服務能力的建設是轉型中第二個難點，這些能力有可能在傳統架構建設模式下已經獨立建設，如何將這些共性能力抽象出來并下沉到平臺層共性建設，并再將能力以WS接口方式開放出去供上層微服務模塊使用，是微服務架構轉型中必須首先考慮實施的內容。

要實施這點，就會造成原有業務模塊的較大改造，特別是對于原有各業務系統中的技術組件本身差異就大的情況下，這種統一往往更加困難，勢必對已有的業務系統造成較大的影響。這也是很早我們在談企業微服務架構實施策略中談到的盡量是逐步遷移，老系統或平臺也逐步消亡的漸進模式實施。

第三是新技術的引入，微服務架構思想的引入。對于微服務架構，前面已經強調過多次不僅僅是單純的微服務開發框架的引入，更加重點的是和容器化技術，和DevOps實踐的結合，進一步對組件化架構和領域建模思想的實踐，同時可能還涉及到EDA事件驅動架構方面的內容。在業務層面還涉及到如何去更好的劃分微服務模塊，這個粒度究竟如何把控，對于劃分完成的微服務模塊如何去識別和定義微服務接口，確保接口本身的復用性和粗粒度特性。

因此不是使用了WS接口就是SOA，也絕對不是簡單的使用了Rest接口，使用了Spring Cloud等微服務框架就是微服務架構。更加重要的是組件化和服務化，持續集成和DevOps等思想的最終實踐和落地。只有這些思想真正落地，才能夠解決我在上篇文章中談到的關鍵訴求所描述的問題。

第四是企業本身的軟件過程和IT管控治理能力的成熟度。如果一個企業原來就實施了組件化開發，或者原來就使用了一些開源了SOA總線或服務網關產品，已經實踐過了持續集成方法論，或者已經建立了自己的類似流程引擎，4A等基礎技術平臺，那么實施微服務架構相對就很容易。反之，如果一個企業在傳統IT架構下都沒有形成標準的開發過程，開發框架，技術組件積累，標準軟件生命周期，編碼規范和接口使用標準等，那么要實施微服務架構就相對難。

其次對于微服務架構下，我們管理的最小單位將從原來的一個大的單體應用變化為多個更加細粒度的微服務模塊，原來單體應用內部的接口和集成可能屬于混亂狀態，但是在黑盒內部沒有暴露出來，但是事實微服務架構后這些都會被完全暴露出來需要去管控。我們需要管理的微服務模塊數量，接口數量等都會成倍的增加，沒有一定的IT管控和治理流程的積累，要做好這些管控也是相當困難的事情。

最后談下運維監控能力差距，由于要管理的模塊數和接口服務數都成倍的增加，對管控和運維的能力要求都相應提升，如果還按照傳統的人工去運維的方式肯定行不通。這里面一方面就是要實現自動化的監控和運維能力，模塊和接口服務的性能分析和及時預警能力；其次就是要實施DevOps，真正將從需求開始，到設計，開發，測試，部署的全過程實現流水線式作業。

可以看到，對當前傳統企業和傳統IT架構建設和實施過程中，運維和后續管控的能力差距還很大，這就很容易發送上了微服務架構，后續服務很好的管控和運維的情況，人員疲于奔命的應付各類故障和問題，那么這樣不是節約了運維和管理工作量，反而是使整個運維管控流程復雜化了。

實施實施準備和實施策略

前面已經談到過，微服務架構不是簡單的微服務開發框架的使用，更不是簡單的Restful接口的使用，而是大量的SOA，持續集成，組件化和服務化，云平臺和容器，DevOps等思想的融合應用。因此在考慮轉型到微服務架構的時候可以首先進行相應的準備，而這些準備基本都是可以獨立完成并實施的。

在實施前具體需要考慮到多個方面的技術儲備和管理儲備。

對于技術儲備包括了微服務架構，微服務開發框架和開源組件，DevOps持續集成交付工具鏈，容器云PaaS平臺，領域分析和建模，API網關和事件引擎，前后端分離和前端開發框架，微服務治理框架。類似消息，緩存，日志，4A，流程引擎等各種技術組件和技術服務能力準備等。

對于管理和過程初步重點是Scrum敏捷研發方法論，DevOps研發運維一體化過程實踐方法，傳統的軟件工程和軟件生命周期管理，標準的過程規范和標準體系，測試和質量管控體系，IT治理和IT運維管控體系，需求端到端管理，安全管理等方面的內容。

當然這里面個人理解最重要的還是SOA和云平臺的架構思想的深入理解，包括當前的數字中臺，平臺+應用，前后端分離等很多都來源于以上兩個核心思想。

企業IT架構轉型的實施策略

企業IT架構轉型一定要明確清楚相關的業務驅動力和業務需求，同時在轉型實施過程中還需要有企業當前本身的IT治理水平相匹配，而不是盲目跟風各種互聯網先進技術。企業在信息化發展到一定階段后，往往隨著業務的高速發展，IT建設已經無法滿足和快速響應業務需求，這個實施轉型驅動力是最大的。

但是在IT架構轉型過程中，不是對原有IT架構的完全否定和推翻重來，而是應該考慮如何在轉型過程中對業務的影響最小，已經如何盡可能的復用已有的IT資產，這是IT架構實施過程中重要的實施策略。

對于傳統企業IT架構轉型，其最終要達到的目標仍然是我前面大量的SOA和云計算思想在企業內部的應用，企業私有云PaaS平臺建設，平臺+應用的構建模式，微服務架構+DevOps的全程貫通等。整體來說實施策略可以分為如下幾個大的步驟：

橫向統一：基礎和共性能力下沉

對于業務系統中的共性能力下沉是SOA參考架構和私有云平臺中平臺+應用的核心構建策略思想。對于傳統企業內部橫向統一就包括了幾個核心內容，第一個就是底層基礎平臺的建設，包括了4A平臺，公共流程平臺，基礎主數據平臺等，而對于上層則包括了統一的用戶門戶，統一認證和單點登錄等。

因為這些內容都是偏技術平臺的內容，因此這些共性能力的提取對已有的業務系統相對影響最小，同時在統一平臺化建設后，在后續新規劃的業務系統中就完全可以復用。

如果是大型集中化項目，技術平臺就不是僅供一個項目使用，而是需要為多個項目提供服務，類似我們前面很多文章都談到的平臺+應用模式，企業私有云PaaS平臺建設。在為多個業務子系統提供平臺層能力支撐的時候，那么一個關鍵就是這個平臺不會再內嵌在業務系統里面，而是應該獨立進行建設和部署，并將平臺層的能力通過接口的方式開放出來供上層應用使用。在這種模式下平臺層的建設一般會包括如下內容：

1. 獨立的門戶集成能力，提供門戶，統一身份認證，單點登錄能力。2. 提供4A能力，特別是統一用戶和統一授權，該能力可以集成在門戶中統一提供。3. 提供公共的流程平臺和流程引擎能力，對流程建模，執行，監控數據全部集中在流程平臺中管理。4. 提供一些關鍵的技術服務能力（其中包括消息，緩存，日志，安全，文件處理等）5. 整體的UI/UE標準規范制定，開發框架規范和技術制定。

其中1到3基本是一個最簡單的公共支撐平臺必須提供的，而對于4一開始可以先不提供，由各個業務系統自己去提供和解決。由于上述內容已經抽象到公共平臺進行統一提供，因此對于上層的業務子系統開發就更加簡單，具體包括的內容為：

1. 提供最基本的核心系統管理模塊能力(用戶，角色，授權，組織，菜單，數據字典等）2. 公共技術組件模塊(提供一些類似公共函數，緩存處理，日志封裝，異常封裝，安全等基礎能力)3. 使用統一平臺和整體應用架構制定的UI規范和開發框架進行開發

這也是我們常說的厚平臺+輕應用的模式，即能夠復用和共性的內容盡量下沉到平臺統一提供，上層的業務應用開發只需要關注業務流程和業務邏輯實現，而不再需要關心技術的內容。更詳細的內容介紹可以參考我去年出版的私有云PaaS平臺建設一書，可以網上書店搜索《SOA與大數據實戰：企業私有云平臺規劃和建設》，里面對這部分內容有詳細的介紹和說明。

縱向統一：軟件工程和研發管理

對于縱向統一包括軟件工程和研發過程管理兩個方面的內容。對于軟件工程本身包括了開發框架，技術框架，主流技術，服務接口標準，單業務系統架構選型，分層模式等常見的軟件工程域的相關內容。

對于研發管理則包括了標準的技術標準規范，UI/UE規范，開發規范，測試規范的統一。包括了業務系統在交維后的ITIL標準規范流程等方面的統一，安全管理標準規范的統一等。同時也包括了Scrum敏捷研發方法論，CI/CD持續集成和當前DevOps實踐方面內容。

內部統一：業務能力組件化和模塊化

在上面兩點統一后可以看到，剩下的就是業務系統的各個業務模塊了，那么要做的事情就是如何讓業務系統內部的各個模塊進一步的組件化和服務化，逐漸變化到我們常說的微服務架構，并且對于傳統業務系統的概念逐漸消亡，更多的就是基于平臺上建設了不同的多個微服務模塊，微模塊模塊可以朝上層靈活組合各類應用。

對于微服務架構的實施，我前面已經專門有文章講到過，企業IT能力成熟度如果沒有達到一定階段，實施微服務架構往往是增加了整個IT開發和后續管控的復雜度，因此對于微服務架構的實施核心建議策略也是需要從單獨新的的業務功能模塊逐步開始，或者從已有的共性基礎能力剝離開始，而不是完全推翻原有業務系統。