今天準備再談下微服務(wù)，對于微服務(wù)相關(guān)基礎(chǔ)文章，包括企業(yè)傳統(tǒng)IT架構(gòu)如何平滑進行微服務(wù)化轉(zhuǎn)型都可以參考我頭條發(fā)布過的相關(guān)文章。

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

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

微服務(wù)究竟在談什么?

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

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

因此我們將招投標作為一個獨立的子系統(tǒng)進行建設(shè)。

再比如企業(yè)引入了ERP系統(tǒng)后，發(fā)現(xiàn)對于采購，物流，合同，預(yù)算等能力都需要在ERP上二次開發(fā)才能夠滿足需求。但是實際發(fā)現(xiàn)這些能力本身和ERP之間也是松耦合關(guān)系，比如對于采購管理中的詢價，洽談，流程審批等。ERP只管理最終的供應(yīng)商，采購請購單和采購訂單，而實際你這些單據(jù)如何形成往往并不關(guān)系。對于ERP的財務(wù)模塊也一樣，ERP只關(guān)心最終形成的應(yīng)付憑證或總賬憑證，對于這些憑證應(yīng)該走什么的報銷或?qū)徟鞒绦纬蒃RP也不關(guān)心。

那么外圍的很多擴展業(yè)務(wù)實際和ERP核心是松耦合的關(guān)心，因此可以看到很多企業(yè)圍繞ERP系統(tǒng)構(gòu)建了外部多個獨立的子系統(tǒng)，類似采購，報賬，預(yù)算，合同，HR人力資源管理等。這些系統(tǒng)最終又和ERP之間完成集成和協(xié)同。

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

簡單來說就說不要把系統(tǒng)做得越來越大，系統(tǒng)越龐大后續(xù)可能越難管理，系統(tǒng)本身也難以擴展和運維。如果發(fā)現(xiàn)高度自治和松耦合的業(yè)務(wù)，可以考慮獨立建設(shè)。

注意這個實際和當前微服務(wù)談的大的單體應(yīng)用要拆分為更小的微服務(wù)是一個道理。在互聯(lián)網(wǎng)電商架構(gòu)里面經(jīng)常看到用戶中心，訂單中心，庫存中心，支付中心。這個映射回企業(yè)內(nèi)部IT，不是已經(jīng)拆分為了類似主數(shù)據(jù)平臺，采購子系統(tǒng)，WMS子系統(tǒng)，報賬子系統(tǒng)嗎?所以并不是說原來IT系統(tǒng)構(gòu)建的時候沒有考慮拆分，而僅僅是拆分到哪個度的問題。

互聯(lián)網(wǎng)為何先搞微服務(wù)和單體應(yīng)用拆分?

互聯(lián)網(wǎng)應(yīng)用由于特殊性，直接面對C端用戶的時候，往往會出現(xiàn)海量數(shù)據(jù)和大并發(fā)量調(diào)用。這樣就導(dǎo)致原來的單體應(yīng)用在性能上撐不住了，也沒法進行能力擴展，無法進行后續(xù)的運維和管控，不得不拆分。其次就是由于同時存在PC端和APP端，發(fā)現(xiàn)很多東西重復(fù)開發(fā)了，需要整合，因此出現(xiàn)橫向進一步拆分和前后端分離。

那么再回來到企業(yè)內(nèi)部IT來說，一個采購系統(tǒng)本身用戶主要是采購部門人員，業(yè)務(wù)量和并發(fā)量都完全可控，也沒有明細的性能問題。原來單體的集群擴展和冗余設(shè)計也完全能夠滿足業(yè)務(wù)需求。

那么這個時候你再去拆分為更小的微服務(wù)的理由是啥?

再次明確傳統(tǒng)的微服務(wù)架構(gòu)改造，一定是圍繞業(yè)務(wù)目標和場景驅(qū)動，而不是簡單的技術(shù)驅(qū)動。比如集團型企業(yè)搞了集中化，全集團幾十萬用戶使用系統(tǒng)，同時又要考慮去IOE，那么傳統(tǒng)的單體應(yīng)用無法支撐和擴展，這個時候才是推動微服務(wù)的驅(qū)動力。

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

微服務(wù)帶來哪些問題?

如果企業(yè)本身的IT成熟度沒有達到一定階段，顯然是不可能推行實施微服務(wù)架構(gòu)的。這個道理前面已經(jīng)談到過，在企業(yè)IT建設(shè)中，如果連粗粒度的業(yè)務(wù)系統(tǒng)以及它們之間的集成都管理不好，那么更沒有能力管理細粒度的微服務(wù)模塊。

即使企業(yè)IT技術(shù)和成熟度達到一定水平，在推廣微服務(wù)架構(gòu)還存在的難點如下：

首先是架構(gòu)設(shè)計能力的顯性化導(dǎo)致的內(nèi)部問題暴露，即架構(gòu)設(shè)計這個工作的輸入，輸出和過程需要更加的顯性化出來形成團隊都認同的標準工件。一個業(yè)務(wù)系統(tǒng)沒有拆分開時候，雖然有架構(gòu)設(shè)計和組件劃分，但是這個工作是屬于團隊內(nèi)部的事情，即使架構(gòu)設(shè)計不合理，在后期集成也可以通過諸多變通方式解決掉。而現(xiàn)在是不同的微服務(wù)模塊可能分派到兩個獨立的團隊開發(fā)，原來屬于自己內(nèi)部黑盒的問題變?yōu)閳F隊間問題。

簡單來說你原來藏著或沒做規(guī)范的東西太多，而現(xiàn)在這些不能再藏著掖著了，當真要把這些東西拿出來的時候，你才會發(fā)現(xiàn)你原來架構(gòu)能力是有欠缺的。正如我們理解了一個東西，那么要讓我們清楚的講出來困難，那么我們的理解有欠缺。對于我們能講清楚的東西，要系統(tǒng)的寫下來有困難，那么說明我們講的結(jié)構(gòu)和條理有欠缺。

其次管控要求和規(guī)范體系的建立不及時，對于管控要求可以看到如果兩個微服務(wù)模塊分給同一個團隊開發(fā)，如何才能保證開發(fā)的團隊保持兩個模塊的完全獨立和解耦，兩個模塊間不會出現(xiàn)相互交叉的數(shù)據(jù)庫直接調(diào)用，也不會存在直接繞開Service接口的其它耦合調(diào)用?這些如果沒有完整的管控和檢查體系我們很難約束。

其三是微服務(wù)架構(gòu)下導(dǎo)致的開發(fā)復(fù)雜度增加， 只談微服務(wù)架構(gòu)的松耦合和高擴展性，而不談開發(fā)和集成復(fù)雜度的都是耍流氓。

實際上當前很多企業(yè)對微服務(wù)架構(gòu)并沒有如此迫切，互聯(lián)網(wǎng)很多企業(yè)推行微服務(wù)架構(gòu)更多的還是考慮到巨大的業(yè)務(wù)并發(fā)量下的系統(tǒng)彈性擴展能力，而實際大多數(shù)企業(yè)內(nèi)應(yīng)用往往并沒有如此海量并發(fā)。其次，即使在并發(fā)量增加的情況下通過進行代碼本身的優(yōu)化，數(shù)據(jù)庫調(diào)優(yōu)或者升級硬件服務(wù)器資源都可以較好的解決性能問題。而做這些事情投入的成本遠遠小于微服務(wù)架構(gòu)帶來的開發(fā)復(fù)雜度增加成本，后期的運維管控成本。

要做到完全微服務(wù)模塊獨立，微服務(wù)架構(gòu)下最大的一個變化就是數(shù)據(jù)庫也拆分開了，原來的一個業(yè)務(wù)系統(tǒng)如果分為5個微服務(wù)模塊，那理論上就是5個獨立的后臺數(shù)據(jù)庫，而且數(shù)據(jù)庫間還不能隨便相互連接和訪問。只有這樣微服務(wù)模塊才能做到獨立部署和管理。

由于數(shù)據(jù)庫拆分帶來兩個問題，其一是我們原來很簡單的一個跨表查詢操作現(xiàn)在無法做了，我們必須調(diào)用兩個微服務(wù)模塊提供的服務(wù)，查詢到數(shù)據(jù)后再到邏輯層進行組合。其次最大的問題就是如果一個業(yè)務(wù)操作需要同時更新兩個微服務(wù)模塊的數(shù)據(jù)，由于服務(wù)本身無狀態(tài)，導(dǎo)致了這種分布式事務(wù)問題很難解決。

企業(yè)內(nèi)業(yè)務(wù)系統(tǒng)很大一個特點就是業(yè)務(wù)邏輯和規(guī)則相對互聯(lián)網(wǎng)更加復(fù)雜，而且有更高的事務(wù)一致性要求。正是由于這個原因，無法解決好分布式事務(wù)的問題都將直接導(dǎo)致后續(xù)數(shù)據(jù)不一致和業(yè)務(wù)錯誤。

原來通過調(diào)用項目內(nèi)一個API方法就能解決的問題，現(xiàn)在要調(diào)用遠程WS接口才能解決，這本身就增加了開發(fā)和調(diào)試的復(fù)雜度。一個微服務(wù)模塊與外部其它模塊的集成和協(xié)同越少，你會發(fā)現(xiàn)該微服務(wù)模塊和傳統(tǒng)業(yè)務(wù)系統(tǒng)開發(fā)沒太大區(qū)別，但是當其涉及到完成任何一個功能都需要調(diào)用外部微服務(wù)模塊的服務(wù)接口時候，其開發(fā)模式和效率上就會帶來巨大的變化。

其四是微服務(wù)架構(gòu)下導(dǎo)致的集成復(fù)雜度增加， 任何一個微服務(wù)模塊在外部協(xié)同上都存在兩個點，一個是模塊本身要消費和調(diào)用其它微服務(wù)模塊提供的服務(wù)接口，另外一個是模塊本身又需要將其業(yè)務(wù)能力暴露為服務(wù)接口給其它微服務(wù)模塊使用。

如果一個微服務(wù)模塊要同時支撐PC端和APP端，可以看到微服務(wù)模塊暴露的服務(wù)還需要統(tǒng)一提供給前端的展示用。那么可以看到一個微服務(wù)模塊需要完成自身組件層和展現(xiàn)層間的集成，同時又需要完成多個微服務(wù)模塊組件間的橫向服務(wù)集成。

如果我們將消息，日志，流程，4A等能力下層到平臺層微服務(wù)模塊，那么一個組件要跑起來還涉及到和平臺層的多個技術(shù)類微服務(wù)模塊集成。在如此復(fù)雜的集成場景下，要將復(fù)雜的跨多個微服務(wù)模塊的橫向端到端業(yè)務(wù)跑通，其涉及到的模塊數(shù)，接口數(shù)都遠超原有單一系統(tǒng)的模式。

一個業(yè)務(wù)系統(tǒng)如果沒有拆分為微服務(wù)模塊，那么其它內(nèi)的模塊間集成和集成測試是系統(tǒng)內(nèi)部的事情，但是一旦拆分為多個微服務(wù)模塊，那么這種集成就變成外部第三方的事情，或者必須要顯性的事情。

對于一個微服務(wù)模塊來說，當其需要集成的外部微服務(wù)模塊和接口都變多的時候帶來什么問題呢?這個問題大家容易理解，即該模塊究竟是否穩(wěn)定已經(jīng)不是模塊本身的事情了，而是涉及到諸多外部依賴模塊是否穩(wěn)定。

更簡單說本來原來我自己可以確認穩(wěn)定的事情，現(xiàn)在我無法確認了。即使每個模塊的穩(wěn)定度都90%，但是你會發(fā)現(xiàn)一集成起來90%*90%*90%，那么穩(wěn)定性就下降得很厲害。正是由于這個原因，我們要求在一個大體系里面，每個微服務(wù)模塊的開發(fā)質(zhì)量都要得到保證，這已經(jīng)不是單個模塊自己的事情，而是直接影響到大系統(tǒng)的質(zhì)量。

最后是微服務(wù)架構(gòu)下的運維問題， 在實施了微服務(wù)架構(gòu)后，運維的復(fù)雜度也是成倍增加，任何一個微服務(wù)模塊出問題都可能影響到整個業(yè)務(wù)應(yīng)用的功能使用。我們在運維時候不僅僅要健康單個微服務(wù)模塊，還需要健康所有的接口服務(wù)監(jiān)控狀態(tài)。

如果跟Docker集成了，我們看到整個性能監(jiān)控和問題分析都會變麻煩了，沒有實施微服務(wù)架構(gòu)前發(fā)現(xiàn)問題，我們直接可以看應(yīng)用服務(wù)器上類似tomcat或jboss日志，而實施了微服務(wù)架構(gòu)后，應(yīng)用容器已經(jīng)是自動部署和動態(tài)分配的，原有的故障診斷模式行不通，而需要PaaS平臺本身提供完整的預(yù)警和日志分析能力。

再次，如果發(fā)現(xiàn)了性能問題或故障，我們的解決方案是如何的?我們?nèi)绾伪ＷC不影響到業(yè)務(wù)運行，不出現(xiàn)數(shù)據(jù)的丟失，或者在微服務(wù)模塊擴展的時候不出現(xiàn)業(yè)務(wù)中斷等。這些已經(jīng)不是簡單的部署架構(gòu)層面的冗余能解決的問題，而涉及到我們在整個微服務(wù)架構(gòu)中的消息策略，事務(wù)管理機制，持久化機制等問題。

微服務(wù)建設(shè)和實施中若干問題討論

再次總結(jié)下前面講的內(nèi)容，簡單來說就是兩點。

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

當前很多人批微服務(wù)，最多的地方同樣是單體拆分為微服務(wù)粒度太細，導(dǎo)致了大量微服務(wù)集成，接口濫用，后續(xù)無法管控和治理的問題。引入微服務(wù)本身是為了自治和解耦，結(jié)果最終實施完，你發(fā)現(xiàn)整個應(yīng)用架構(gòu)反而更加耦合了。這個不是微服務(wù)的錯，而是規(guī)劃和架構(gòu)設(shè)計不到位的錯。

下面再談下微服務(wù)轉(zhuǎn)型中常見的一些問題和實踐思考。

單體應(yīng)用不拆分是否就無法擴展?

單體應(yīng)用存在數(shù)據(jù)庫和應(yīng)用兩層，應(yīng)用層往往容易集群擴展，而數(shù)據(jù)庫是最難集群擴展的。如果數(shù)據(jù)庫性能出現(xiàn)問題，優(yōu)先要考慮的是代碼和數(shù)據(jù)庫層面的SQL優(yōu)化(對于企業(yè)大部分應(yīng)用來說性能問題不是服務(wù)器資源或能力不夠，而是代碼寫的太爛。)，其次是進行相應(yīng)的讀寫分離或數(shù)據(jù)庫拆分等。

傳統(tǒng)單體微服務(wù)拆分顆粒度?

傳統(tǒng)單體應(yīng)用微服務(wù)拆分顆粒度為6到8個合適，這是一個畢竟粗的說法。但是傳統(tǒng)應(yīng)用本身存在流程驅(qū)動型和數(shù)據(jù)驅(qū)動型，類似OA或工單系統(tǒng)即流程驅(qū)動，這類應(yīng)用拆分再多影響都不大，而對于數(shù)據(jù)驅(qū)動型如資產(chǎn)系統(tǒng)，那么務(wù)必注意底層共享數(shù)據(jù)層不要隨便拆分，否則引入后續(xù)大量分布式事務(wù)問題。

微服務(wù)拆分和數(shù)據(jù)庫拆分在我們實施總結(jié)兩個概念要分開，數(shù)據(jù)庫拆分后對應(yīng)的上層應(yīng)用模塊你還可以進一步拆分為為多個獨立組件，但是暫時不要去考慮獨立部署。

微服務(wù)如何拆分?

微服務(wù)拆分是業(yè)務(wù)驅(qū)動而非技術(shù)驅(qū)動，需要深入地理解業(yè)務(wù)場景和業(yè)務(wù)流程，業(yè)務(wù)分析清楚后才能夠明白哪些業(yè)務(wù)功能和業(yè)務(wù)數(shù)據(jù)應(yīng)該聚合在一起，這樣相互之間耦合性最小。不論是基于傳統(tǒng)企業(yè)架構(gòu)還是領(lǐng)域建模設(shè)計，核心都是基于業(yè)務(wù)驅(qū)動建模和拆分微服務(wù)。

其次微服務(wù)拆分要理解為兩個層面的內(nèi)容。其一是微服務(wù)模塊和數(shù)據(jù)庫的拆分，其二是拆分后接口的定義和識別。

是不是用了微服務(wù)框架就是微服務(wù)?

現(xiàn)在很多人對微服務(wù)的理解就是只要用了類似SpringCLoud等微服務(wù)框架就是微服務(wù)架構(gòu)。這是很大的一個誤解。微服務(wù)架構(gòu)的核心在于微服務(wù)的拆分，粗粒度API接口設(shè)計，各個微服務(wù)之間的松耦合。如果這個要求沒有達到不是微服務(wù)架構(gòu)。

實施微服務(wù)需要哪些能力儲備?

在技術(shù)上重點是對主流微服務(wù)開發(fā)框架的熟悉，其次是需要構(gòu)建一個技術(shù)能力平臺，實現(xiàn)共性技術(shù)能力下沉和共享，類似消息，緩存，4A，流程引擎，任務(wù)調(diào)度等。這些技術(shù)能力首先需要從微服務(wù)中剝離出來。只有這樣微服務(wù)模塊才能夠?qū)⒅匦霓D(zhuǎn)移到對業(yè)務(wù)功能實現(xiàn)上。

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

舉個簡單的例子，原來系統(tǒng)部署就一個大的WAR包，而現(xiàn)在變成了20個微服務(wù)模塊，這個如果還依靠人工來完成顯然是不現(xiàn)實的。

再次，微服務(wù)拆分實際和開發(fā)團隊是匹配的，開發(fā)團隊先拆分然后是微服務(wù)化的拆分，只有這樣才能夠徹底解耦。一個開發(fā)團隊就2個人，一個后端開發(fā)人員管理拆分后的8個微服務(wù)模塊，可以想象下這個開發(fā)人員完全無法做到按微服務(wù)邊界和約束來是實現(xiàn)。本來該API接口調(diào)用的，反正都是自己做，又變成了直接訪問數(shù)據(jù)庫調(diào)用等。

為何微服務(wù)化后反而緊耦合?

這個實際是很多企業(yè)都遇到的問題，簡單來說要給微服務(wù)架構(gòu)的實施，如果微服務(wù)拆分后微服務(wù)間仍然沒有達到解耦的目標，那么還不如不進行微服務(wù)化改造。

對于緊耦合的原因本身又體現(xiàn)在兩點。

其一是微服務(wù)劃分不合理，本來不應(yīng)該拆分為2個微服務(wù)的你偏要去拆分，拆分后發(fā)現(xiàn)兩個微服務(wù)間大量接口交互調(diào)用，自己給自己找麻煩。

其二是前期的微服務(wù)治理管控工作不到位，特別是對于微服務(wù)暴露的API接口的使用約束和標準規(guī)范等。在一個大的微服務(wù)框架下，所有的微服務(wù)共享一個服務(wù)注冊中心，該微服務(wù)模塊暴露的API接口完全可以被其它微服務(wù)模塊訪問和消費使用，也就是說微服務(wù)間的API接口訪問和使用完全不受控，那么后續(xù)多個微服務(wù)間自然導(dǎo)致緊耦合的問題。

APM或服務(wù)鏈監(jiān)控是否能解決服務(wù)治理問題?

再次強調(diào)下，APM或服務(wù)鏈監(jiān)控可以幫助你改善和優(yōu)化性能問題，服務(wù)調(diào)用不合理問題。但是這個已經(jīng)是事后補償操作，任何事情應(yīng)該是需求和設(shè)計驅(qū)動，在一開始就避免問題，而不是出現(xiàn)了問題再變更和優(yōu)化。

很多人觀點是反正后續(xù)可以通過鏈路監(jiān)控查看到服務(wù)鏈路調(diào)用關(guān)系和性能損耗等，那么在設(shè)計和開發(fā)階段，我API接口隨意調(diào)用也無所謂，這個是很錯誤的一個認識。包括很多人在實踐微服務(wù)的時候又同時配合Scrum敏捷研發(fā)，導(dǎo)致微服務(wù)整個建設(shè)中完全沒有架構(gòu)設(shè)計工作，這本身又是一個給后期管控運維帶來巨大的地雷的地方。

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

高可用，高擴展和可運維

首先要認識到微服務(wù)架構(gòu)下的高可用性設(shè)計往往比傳統(tǒng)單體架構(gòu)的高可用更加困難和復(fù)雜。前面談到了拆分微服務(wù)的理由在于性能和可擴展性，以及業(yè)務(wù)能力上的解耦。

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

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