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

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

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

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

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

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

因此我們將招投標(biāo)作為一個(gè)獨(dú)立的子系統(tǒng)進(jìn)行建設(shè)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

高可用，高擴(kuò)展和可運(yùn)維

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

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

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