今天準備再談下微服務，對于微服務相關基礎文章，包括企業傳統IT架構如何平滑進行微服務化轉型都可以參考我頭條發布過的相關文章。

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

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

微服務究竟在談什么?

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

比如在很多年前我們做SRM系統，后續準備在SRM系統里面擴展招投標管理模塊，但是后來一思考發現招投標管理本身由招投標部負責，業務相對獨立，功能也高度自治，和外部SRM接口集成點也體現粗粒度特性。

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

 

[[378790]]

 

再比如企業引入了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和鏈路監控不能沒有，但是這個絕對不是你前期偷懶的理由。

高可用，高擴展和可運維

 

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

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

 

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