大家可以看到實際中臺概念比微服務出來的晚，很多人覺得中臺被網際網路網和相關廠商炒作的太例會，最終從建設成效，投入產出比多方面都沒有達到企業的希望，也服務敏捷滿足企業的業務戰略需求，因此現在又很多人站出來提拆中臺或反中臺。

任何一個新鮮事物，本來架構設計或思想是好的，但是脫離了企業實際的業務目標，業務場景和需求空談，那麼再好的東西就變成了垃圾。

微服務究竟在談什麼？

我不準備再重新去闡述微服務的概念和定義，而是重新來思考下微服務這個概念的出現和應用場景。實際上你可以看到，在沒有微服務這個概念的時候我們也在做一些類似的事情。

比如在很多年前我們做SRM系統，後續準備在SRM系統裡面擴充套件招投標管理模組，但是後來一思考發現招投標管理本身由招投標部負責，業務相對獨立，功能也高度自治，和外部SRM介面整合點也體現粗粒度特性。

因此我們將招投標作為一個獨立的子系統進行建設。

再比如企業引入了ERP系統後，發現對於採購，物流，合同，預算等能力都需要在ERP上二次開發才能夠滿足需求。但是實際發現這些能力本身和ERP之間也是松耦合關係，比如對於採購管理中的詢價，洽談，流程審批等。ERP只管理最終的供應商，採購請購單和採購訂單，而實際你這些單據如何形成往往並不關係。對於ERP的財務模組也一樣，ERP只關心最終形成的應付憑證或總賬憑證，對於這些憑證應該走什麼的報銷或審批流程形成ERP也不關心。

那麼外圍的很多擴充套件業務實際和ERP核心是松耦合的關心，因此可以看到很多企業圍繞ERP系統構建了外部多個獨立的子系統，類似採購，報賬，預算，合同，HR人力資源管理等。這些系統最終又和ERP之間完成整合和協同。

所以你看到在微服務概念沒出來前我們就在做一件事。

簡單來說就說不要把系統做得越來越大，系統越龐大後續可能越難管理，系統本身也難以擴充套件和運維。如果發現高度自治和松耦合的業務，可以考慮獨立建設。

注意這個實際和當前微服務談的大的單體應用要拆分為更小的微服務是一個道理。在網際網路電商架構裡面經常看到使用者中心，訂單中心，庫存中心，支付中心。這個映射回企業內部IT，不是已經拆分為了類似主資料平臺，採購子系統，WMS子系統，報賬子系統嗎？所以並不是說原來IT系統構建的時候沒有考慮拆分，而僅僅是拆分到哪個度的問題。

網際網路為何先搞微服務和單體應用拆分？

網際網路應用由於特殊性，直接面對C端使用者的時候，往往會出現海量資料和大併發量呼叫。這樣就導致原來的單體應用在效能上撐不住了，也沒法進行能力擴充套件，無法進行後續的運維和管控，不得不拆分。其次就是由於同時存在PC端和APP端，發現很多東西重複開發了，需要整合，因此出現橫向進一步拆分和前後端分離。

那麼再回來到企業內部IT來說，一個採購系統本身使用者主要是採購部門人員，業務量和併發量都完全可控，也沒有明細的效能問題。原來單體的叢集擴充套件和冗餘設計也完全能夠滿足業務需求。

那麼這個時候你再去拆分為更小的微服務的理由是啥？

再次明確傳統的微服務架構改造，一定是圍繞業務目標和場景驅動，而不是簡單的技術驅動。比如集團型企業搞了集中化，全集團幾十萬使用者使用系統，同時又要考慮去IOE，那麼傳統的單體應用無法支撐和擴充套件，這個時候才是推動微服務的驅動力。

對於任何一個企業的IT建設，都應該是基於業務場景和業務目標需求，採用當前最適合的技術和工具來解決問題，而不是採用最先進的技術。任何一個先進的技術往往都需要當前企業在組織架構，專案管理，團隊，技術儲備，管控治理各方面的能力儲備達到一定程度來配合。否則先進技術反而帶來的是低效能。

微服務帶來哪些問題？

如果企業本身的IT成熟度沒有達到一定階段，顯然是不可能推行實施微服務架構的。這個道理前面已經談到過，在企業IT建設中，如果連粗粒度的業務系統以及它們之間的整合都管理不好，那麼更沒有能力管理細粒度的微服務模組。

即使企業IT技術和成熟度達到一定水平，在推廣微服務架構還存在的難點如下：

首先是架構設計能力的顯性化導致的內部問題暴露，即架構設計這個工作的輸入，輸出和過程需要更加的顯性化出來形成團隊都認同的標準工件。一個業務系統沒有拆分開時候，雖然有架構設計和元件劃分，但是這個工作是屬於團隊內部的事情，即使架構設計不合理，在後期整合也可以透過諸多變通方式解決掉。而現在是不同的微服務模組可能分派到兩個獨立的團隊開發，原來屬於自己內部黑盒的問題變為團隊間問題。

簡單來說你原來藏著或沒做規範的東西太多，而現在這些不能再藏著掖著了，當真要把這些東西拿出來的時候，你才會發現你原來架構能力是有欠缺的。正如我們理解了一個東西，那麼要讓我們清楚的講出來困難，那麼我們的理解有欠缺。對於我們能講清楚的東西，要系統的寫下來有困難，那麼說明我們講的結構和條理有欠缺。

其次管控要求和規範體系的建立不及時，對於管控要求可以看到如果兩個微服務模組分給同一個團隊開發，如何才能保證開發的團隊保持兩個模組的完全獨立和解耦，兩個模組間不會出現相互交叉的資料庫直接呼叫，也不會存在直接繞開Service介面的其它耦合呼叫？這些如果沒有完整的管控和檢查體系我們很難約束。

其三是微服務架構下導致的開發複雜度增加， 只談微服務架構的松耦合和高擴充套件性，而不談開發和整合複雜度的都是耍流氓。

實際上當前很多企業對微服務架構並沒有如此迫切，網際網路很多企業推行微服務架構更多的還是考慮到巨大的業務併發量下的系統彈性擴充套件能力，而實際大多數企業內應用往往並沒有如此海量併發。其次，即使在併發量增加的情況下透過進行程式碼本身的最佳化，資料庫調優或者升級硬體伺服器資源都可以較好的解決效能問題。而做這些事情投入的成本遠遠小於微服務架構帶來的開發複雜度增加成本，後期的運維管控成本。

要做到完全微服務模組獨立，微服務架構下最大的一個變化就是資料庫也拆分開了，原來的一個業務系統如果分為5個微服務模組，那理論上就是5個獨立的後臺資料庫，而且資料庫間還不能隨便相互連線和訪問。只有這樣微服務模組才能做到獨立部署和管理。

由於資料庫拆分帶來兩個問題，其一是我們原來很簡單的一個跨表查詢操作現在無法做了，我們必須呼叫兩個微服務模組提供的服務，查詢到資料後再到邏輯層進行組合。其次最大的問題就是如果一個業務操作需要同時更新兩個微服務模組的資料，由於服務本身無狀態，導致了這種分散式事務問題很難解決。

企業內業務系統很大一個特點就是業務邏輯和規則相對網際網路更加複雜，而且有更高的事務一致性要求。正是由於這個原因，無法解決好分散式事務的問題都將直接導致後續資料不一致和業務錯誤。

原來透過呼叫專案內一個API方法就能解決的問題，現在要呼叫遠端WS接口才能解決，這本身就增加了開發和除錯的複雜度。一個微服務模組與外部其它模組的整合和協同越少，你會發現該微服務模組和傳統業務系統開發沒太大區別，但是當其涉及到完成任何一個功能都需要呼叫外部微服務模組的服務介面時候，其開發模式和效率上就會帶來巨大的變化。

其四是微服務架構下導致的整合複雜度增加， 任何一個微服務模組在外部協同上都存在兩個點，一個是模組本身要消費和呼叫其它微服務模組提供的服務介面，另外一個是模組本身又需要將其業務能力暴露為服務介面給其它微服務模組使用。

如果一個微服務模組要同時支撐PC端和APP端，可以看到微服務模組暴露的服務還需要統一提供給前端的展示用。那麼可以看到一個微服務模組需要完成自身元件層和展現層間的整合，同時又需要完成多個微服務模組元件間的橫向服務整合。

如果我們將訊息，日誌，流程，4A等能力下層到平臺層微服務模組，那麼一個元件要跑起來還涉及到和平臺層的多個技術類微服務模組整合。在如此複雜的整合場景下，要將複雜的跨多個微服務模組的橫向端到端業務跑通，其涉及到的模組數，介面數都遠超原有單一系統的模式。

一個業務系統如果沒有拆分為微服務模組，那麼其它內的模組間整合和整合測試是系統內部的事情，但是一旦拆分為多個微服務模組，那麼這種整合就變成外部第三方的事情，或者必須要顯性的事情。

對於一個微服務模組來說，當其需要整合的外部微服務模組和介面都變多的時候帶來什麼問題呢？這個問題大家容易理解，即該模組究竟是否穩定已經不是模組本身的事情了，而是涉及到諸多外部依賴模組是否穩定。

更簡單說本來原來我自己可以確認穩定的事情，現在我無法確認了。即使每個模組的穩定度都90%，但是你會發現一整合起來90%*90%*90%，那麼穩定性就下降得很厲害。正是由於這個原因，我們要求在一個大體系裡面，每個微服務模組的開發質量都要得到保證，這已經不是單個模組自己的事情，而是直接影響到大系統的質量。

最後是微服務架構下的運維問題， 在實施了微服務架構後，運維的複雜度也是成倍增加，任何一個微服務模組出問題都可能影響到整個業務應用的功能使用。我們在運維時候不僅僅要健康單個微服務模組，還需要健康所有的介面服務監控狀態。

如果跟Docker集成了，我們看到整個效能監控和問題分析都會變麻煩了，沒有實施微服務架構前發現問題，我們直接可以看應用伺服器上類似tomcat或jboss日誌，而實施了微服務架構後，應用容器已經是自動部署和動態分配的，原有的故障診斷模式行不通，而需要PaaS平臺本身提供完整的預警和日誌分析能力。

再次，如果發現了效能問題或故障，我們的解決方案是如何的？我們如何保證不影響到業務執行，不出現資料的丟失，或者在微服務模組擴充套件的時候不出現業務中斷等。這些已經不是簡單的部署架構層面的冗餘能解決的問題，而涉及到我們在整個微服務架構中的訊息策略，事務管理機制，持久化機制等問題。

再次總結下前面講的內容，簡單來說就是兩點。

其一就是企業要有明確的業務目標和需求來推動微服務轉型，而不是單純的技術驅動。其次及時有了明確需求，也需要你前期進行相應的組織，團隊和技術儲備和積累，建立好相應的管控機制，否則導致的是一片混亂。

當前很多人批微服務，最多的地方同樣是單體拆分為微服務粒度太細，導致了大量微服務整合，介面濫用，後續無法管控和治理的問題。引入微服務本身是為了自治和解耦，結果最終實施完，你發現整個應用架構反而更加耦合了。這個不是微服務的錯，而是規劃和架構設計不到位的錯。

下面再談下微服務轉型中常見的一些問題和實踐思考。

單體應用不拆分是否就無法擴充套件？

單體應用存在資料庫和應用兩層，應用層往往容易叢集擴充套件，而資料庫是最難叢集擴充套件的。如果資料庫效能出現問題，優先要考慮的是程式碼和資料庫層面的SQL最佳化（對於企業大部分應用來說效能問題不是伺服器資源或能力不夠，而是程式碼寫的太爛。），其次是進行相應的讀寫分離或資料庫拆分等。

傳統單體微服務拆分顆粒度？

傳統單體應用微服務拆分顆粒度為6到8個合適，這是一個畢竟粗的說法。但是傳統應用本身存在流程驅動型和資料驅動型，類似OA或工單系統即流程驅動，這類應用拆分再多影響都不大，而對於資料驅動型如資產系統，那麼務必注意底層共享資料層不要隨便拆分，否則引入後續大量分散式事務問題。

微服務拆分和資料庫拆分在我們實施總結兩個概念要分開，資料庫拆分後對應的上層應用模組你還可以進一步拆分為為多個獨立元件，但是暫時不要去考慮獨立部署。

微服務如何拆分？

微服務拆分是業務驅動而非技術驅動，需要深入地理解業務場景和業務流程，業務分析清楚後才能夠明白哪些業務功能和業務資料應該聚合在一起，這樣相互之間耦合性最小。不論是基於傳統企業架構還是領域建模設計，核心都是基於業務驅動建模和拆分微服務。

其次微服務拆分要理解為兩個層面的內容。其一是微服務模組和資料庫的拆分，其二是拆分後接口的定義和識別。

是不是用了微服務框架就是微服務？

現在很多人對微服務的理解就是隻要用了類似SpringCLoud等微服務框架就是微服務架構。這是很大的一個誤解。微服務架構的核心在於微服務的拆分，粗粒度API介面設計，各個微服務之間的松耦合。如果這個要求沒有達到不是微服務架構。

實施微服務需要哪些能力儲備？

在技術上重點是對主流微服務開發框架的熟悉，其次是需要構建一個技術能力平臺，實現共性技術能力下沉和共享，類似訊息，快取，4A，流程引擎，任務排程等。這些技術能力首先需要從微服務中剝離出來。只有這樣微服務模組才能夠將重心轉移到對業務功能實現上。

在研發和過程管理上，重點是需要考慮開發團隊的劃分，敏捷方法論的推進，其次就是對持續整合或DevOps的過程實踐。如果這些過程管理和自動化支撐工具跟不上，那麼實施微服務往往帶來巨大的後續實施運維工作量。

舉個簡單的例子，原來系統部署就一個大的WAR包，而現在變成了20個微服務模組，這個如果還依靠人工來完成顯然是不現實的。

再次，微服務拆分實際和開發團隊是匹配的，開發團隊先拆分然後是微服務化的拆分，只有這樣才能夠徹底解耦。一個開發團隊就2個人，一個後端開發人員管理拆分後的8個微服務模組，可以想象下這個開發人員完全無法做到按微服務邊界和約束來是實現。本來該API介面呼叫的，反正都是自己做，又變成了直接訪問資料庫呼叫等。

為何微服務化後反而緊耦合？

這個實際是很多企業都遇到的問題，簡單來說要給微服務架構的實施，如果微服務拆分後微服務間仍然沒有達到解耦的目標，那麼還不如不進行微服務化改造。

對於緊耦合的原因本身又體現在兩點。

其一是微服務劃分不合理，本來不應該拆分為2個微服務的你偏要去拆分，拆分後發現兩個微服務間大量介面互動呼叫，自己給自己找麻煩。

其二是前期的微服務治理管控工作不到位，特別是對於微服務暴露的API介面的使用約束和標準規範等。在一個大的微服務框架下，所有的微服務共享一個服務註冊中心，該微服務模組暴露的API介面完全可以被其它微服務模組訪問和消費使用，也就是說微服務間的API介面訪問和使用完全不受控，那麼後續多個微服務間自然導致緊耦合的問題。

APM或服務鏈監控是否能解決服務治理問題？

再次強調下，APM或服務鏈監控可以幫助你改善和最佳化效能問題，服務呼叫不合理問題。但是這個已經是事後補償操作，任何事情應該是需求和設計驅動，在一開始就避免問題，而不是出現了問題再變更和最佳化。

很多人觀點是反正後續可以透過鏈路監控檢視到服務鏈路呼叫關係和效能損耗等，那麼在設計和開發階段，我API介面隨意呼叫也無所謂，這個是很錯誤的一個認識。包括很多人在實踐微服務的時候又同時配合Scrum敏捷研發，導致微服務整個建設中完全沒有架構設計工作，這本身又是一個給後期管控運維帶來巨大的地雷的地方。

APM和鏈路監控不能沒有，但是這個絕對不是你前期偷懶的理由。

高可用，高擴充套件和可運維

首先要認識到微服務架構下的高可用性設計往往比傳統單體架構的高可用更加困難和複雜。前面談到了拆分微服務的理由在於效能和可擴充套件性，以及業務能力上的解耦。

但是要注意到三者之間往往相互制約，當微服務化後效能和擴充套件能力確實提升，但是對於高可用性保障難度增加，對於可運維的難度增加。

很多企業在實施微服務的時候，前期在拆分的時候搞得很爽，但是後期發現拆分後的微服務太多，整合複雜度指數級上升，同時應用出現問題後連快速定位問題都難。這個也是典型的沒有考慮清楚三者的均衡性問題。