如何理解微服務(wù)架構(gòu)從理想到現(xiàn)實的過程

本篇內(nèi)容介紹了“如何理解微服務(wù)架構(gòu)從理想到現(xiàn)實的過程”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

任何一個新的架構(gòu)模式或方法的出現(xiàn)，一定是傳統(tǒng)架構(gòu)模式遇到了問題。而對于單體應(yīng)用來說常說的問題主要包括了如下幾個點。

單體應(yīng)用規(guī)模太大，導(dǎo)致復(fù)雜度劇增，難以開發(fā)和管理

單體應(yīng)用開發(fā)，交付和變更周期變長，敏捷性跟不上

單體應(yīng)用本身在性能，擴展性上出現(xiàn)了問題

在軟件架構(gòu)設(shè)計里面，分而治之始終都是解決復(fù)雜性的一個關(guān)鍵思維方法。包括在傳統(tǒng)軟件架構(gòu)設(shè)計里面對于大系統(tǒng)會進行子系統(tǒng)或組件劃分，會進行接口設(shè)計，集成設(shè)計等。

架構(gòu)的核心思維仍然是：分解+集成

但是傳統(tǒng)架構(gòu)在分解的時候沒有做到單個組件的高度獨立自治和徹底解構(gòu)。這個高度獨立自治實際上要求組件或模塊從開發(fā)，設(shè)計，測試，上線運行，后期運維全生命周期都做到高度獨立；同時還要求配合的開發(fā)團隊，組織結(jié)構(gòu)設(shè)計也獨立。

也正是這個原因進一步發(fā)展出了微服務(wù)架構(gòu)。也就是說微服務(wù)架構(gòu)實際是傳統(tǒng)組件化架構(gòu)設(shè)計思想的進一步強化，強化的核心就是獨立和解耦。

微服務(wù)架構(gòu)思想的一個重點就是單體應(yīng)用的拆分。

講微服務(wù)一定會談到擴展立方體。

對于傳統(tǒng)單體應(yīng)用一般來講擴展的方法只能是X坐標(biāo)軸的通過擴展實例方式的水平擴展。而另外兩個重要的擴展一個是功能拆分，一個是數(shù)據(jù)庫拆分。

對于功能拆分實際不是新鮮東西，在很早組件化架構(gòu)設(shè)計我們就做過將不同的應(yīng)用組件部署到不同的App Server服務(wù)器上，對于應(yīng)用層你只需要考慮解決類似Session會話保存，全局配置和分發(fā)等問題即可，不會涉及到復(fù)雜的數(shù)據(jù)持久化問題。

而真正難的是在數(shù)據(jù)庫拆分。因為數(shù)據(jù)庫拆分引入了兩個大問題，其一是分布式事務(wù)問題，其二是大量操作跨庫帶來的分布式事務(wù)問題。

數(shù)據(jù)庫為何要拆分？

在單體應(yīng)用發(fā)展到一定階段后，出現(xiàn)的性能問題往往都是DB層面的難以解決。數(shù)據(jù)庫集群很難做到水平彈性擴展，即使對于類似Oracle RAC等商用集群軟件，本身也有性能擴展瓶頸。性能擴展到2到3倍后已經(jīng)無法再擴展。

因此單純從擴展實例擴展來說，后面衍生了讀寫分離集群，讀寫分離集群在應(yīng)對讀操作占比大的業(yè)務(wù)場景下實際是最佳的一種擴展方式，在這種方式下數(shù)據(jù)庫本身并沒有拆分為多個實例，不會引入前面遇到的兩個大問題。只要在數(shù)據(jù)庫上搭建一個DaaS數(shù)據(jù)庫訪問中間件，那么數(shù)據(jù)庫底層的這種拆分和變化完全可以做到對上層應(yīng)用開發(fā)透明。

當(dāng)談到這里的時候，再來回顧一下微服務(wù)的一些核心點自然就更加清楚。

微服務(wù)是傳統(tǒng)單體的拆分，而且需要做到高度獨立自治

微服務(wù)的拆分不僅僅是功能拆分，更加重要是數(shù)據(jù)庫拆分

異步和解耦是微服務(wù)架構(gòu)設(shè)計的重要指導(dǎo)思想

微服務(wù)間通過輕量高效的Http API接口交互協(xié)同

微服務(wù)實踐需要開發(fā)組織，持續(xù)集成，測試，交付方式配套支撐

場景和問題驅(qū)動

在前面談微服務(wù)的時候我就談到過，微服務(wù)架構(gòu)本身將導(dǎo)致開發(fā)，集成，運維復(fù)雜度全部增加。即使對于常說的高可用性，也僅僅是高可用性和彈性擴展能力增加，但是對于高可靠性反而是降低。

那么一個企業(yè)或團隊是什么原因?qū)嵺`微服務(wù)？僅僅是微服務(wù)是一種架構(gòu)發(fā)展趨勢，是技術(shù)熱點，是互聯(lián)網(wǎng)大廠都在用嗎？

而實際對于很多企業(yè)應(yīng)用微服務(wù)可以看到，更多是團隊里面總有一些技術(shù)狂熱份子，熱衷于新架構(gòu)，新技術(shù)，但是對于這些技術(shù)究竟解決了哪些業(yè)務(wù)場景下的問題并不關(guān)心。這直接就導(dǎo)致了大量技術(shù)在不恰當(dāng)?shù)臅r候被應(yīng)用。

并不是說微服務(wù)不好，而是說對于架構(gòu)師來說應(yīng)該基于業(yè)務(wù)，技術(shù)，團隊資源，成本等多個維度來綜合考慮究竟應(yīng)該在什么時候用什么樣的技術(shù)最合適。

類似阿里的電商平臺，一天訪問量上億，接近百萬的TPS，高峰秒級成交都幾十萬筆，這種業(yè)務(wù)場景下各個模塊拆分為獨立中心，獨立數(shù)據(jù)庫是必然。不是說什么技術(shù)先進了必須使用，而是為了滿足和支撐業(yè)務(wù)必須微服務(wù)化。

那么傳統(tǒng)企業(yè)實踐微服務(wù)就一定要思考微服務(wù)究竟能解決什么問題。如果這個問題沒有想清楚就不要輕易去搞微服務(wù)。其次就是通過其他傳統(tǒng)方式能解決的也不要輕易去理想化的實踐微服務(wù)架構(gòu)。

比如一個業(yè)務(wù)系統(tǒng)運行過程中數(shù)據(jù)庫出現(xiàn)性能瓶頸，這個時候你可以考慮的是將歷史數(shù)據(jù)進行遷移到備庫，增加備庫單據(jù)查詢能力；或者是前面談到的構(gòu)建數(shù)據(jù)庫的讀寫分離集群或者在數(shù)據(jù)庫上構(gòu)建二級索引緩存庫來解決性能問題。

再比如一些業(yè)務(wù)系統(tǒng)出現(xiàn)瓶頸，并不是常規(guī)的OLTP場景出現(xiàn)問題，而是單個業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫同時在支撐OLTP和OLAP能力。這個時候你應(yīng)該做到是將大量的查詢統(tǒng)計和數(shù)據(jù)分析功能移出，而不是對整個業(yè)務(wù)系統(tǒng)進行數(shù)據(jù)拆分。

這方面的例子還有很多，實際是想說明一點，很多業(yè)務(wù)系統(tǒng)的復(fù)雜度和性能問題遠遠沒有到必須進行功能拆分和數(shù)據(jù)庫拆分才能夠解決的地步。

微服務(wù)拆分策略

當(dāng)聊微服務(wù)拆分的時候先談下傳統(tǒng)軟件架構(gòu)設(shè)計里面的組件拆分。

對于組件拆分可以看到常規(guī)的組件拆分實際是在應(yīng)用層而沒有到具體的數(shù)據(jù)庫。這就導(dǎo)致了組件拆分后，底層數(shù)據(jù)庫仍然是一個中心點和緊耦合點。包括組件拆分后，實際架構(gòu)規(guī)劃的時候希望通過組件間通過接口調(diào)用協(xié)同的，后續(xù)在開發(fā)實現(xiàn)中往往也出現(xiàn)偏差，即常說的仍然是通過底層數(shù)據(jù)庫的關(guān)聯(lián)sql查詢等來解決問題。所以你看到情況是組件間并沒有什么接口調(diào)用，而大量的耦合都轉(zhuǎn)到底層數(shù)據(jù)庫的耦合上面。

到了微服務(wù)階段的拆分，實際上變成了兩個重要的事情，一個是數(shù)據(jù)庫的拆分，一個是基于數(shù)據(jù)庫拆分后的功能拆分。

對于拆分我前面寫過兩篇文章可以參考：

對領(lǐng)域模型和上下文邊界分析來劃分微服務(wù)的再思考

聊聊DaaS數(shù)據(jù)庫即服務(wù)和微服務(wù)下數(shù)據(jù)庫拆分

不論是采用的是傳統(tǒng)的結(jié)構(gòu)化分析方法，還是當(dāng)前類似DDD領(lǐng)域驅(qū)動建模里面的子域劃分，上下文邊界識別等。拆分的重點仍然是在數(shù)據(jù)庫拆分上面，只是DDD方法里面將其理解為核心領(lǐng)域?qū)ο蟛鸱郑I(lǐng)域?qū)ο蟛鸱殖鰜碜匀粚?yīng)的數(shù)據(jù)庫和功能都進行了拆分。

先梳理清楚邊界并進行服務(wù)拆分，再基于業(yè)務(wù)協(xié)同和業(yè)務(wù)功能實現(xiàn)來梳理和定義API接口，也就是說微服務(wù)拆分工作實際包括了三個方面的事情。

即數(shù)據(jù)庫拆分，功能拆分，API接口識別和定義。

對于微服務(wù)拆分來說，真正的困難點是在微服務(wù)拆分的顆粒度上，當(dāng)重新讀這本書的時候再次慶幸我們沒有按書里面這么理想化的方法去實踐微服務(wù)，去將微服務(wù)拆分的如此細，否則真正是思路一條。

因此在這里需要重申一個重要觀點。

微服務(wù)拆分不應(yīng)該是按標(biāo)準理論理想化的拆分到哪個顆粒度，而是應(yīng)該根據(jù)實際的業(yè)務(wù)場景和擴展性需求，開發(fā)團隊管理需求拆分到一個合適的顆粒度。

比如你現(xiàn)在做的是一個外賣訂餐系統(tǒng)，如果是類似美團APP這種規(guī)模進行細粒度的微服務(wù)拆分勢在必然。但是如果你的系統(tǒng)面對的市場僅僅是類似社區(qū)，園區(qū)等私有云部署場景。那么這個系統(tǒng)從業(yè)務(wù)場景和并發(fā)量上都沒有必要做大的微服務(wù)拆分，實際架構(gòu)上進行前后端分離，獨立緩存庫，讀寫分離基本完全可以解決問題。

因此微服務(wù)拆分到哪個程度，跟業(yè)務(wù)系統(tǒng)面對的業(yè)務(wù)場景和問題有關(guān)，而不要用標(biāo)準的類似拆分方法策略去做拆分。

類似面向?qū)ο蟮姆治鲈O(shè)計，DDD領(lǐng)域驅(qū)動和領(lǐng)域?qū)ο蠓治鲎R別，這些方法都沒有問題，這些完全可以應(yīng)用到應(yīng)用內(nèi)部，應(yīng)用內(nèi)部也需要組件化拆分，而不是說組件化后每個組件就必須拆分為獨立的高度自治的微服務(wù)。

從API接口到異步解耦

對于微服務(wù)架構(gòu)中的API接口設(shè)計，在前面我專門寫過文章來進行描述。在這里還是想重新來說明對API接口設(shè)計和暴露里面的兩個重要觀點。

對Http Rest API標(biāo)準規(guī)范的理解

要知道Rest API更多的是一種面向資源的API接口設(shè)計方法。在早期我自己也堅持一個觀點即需要安裝理想化的Rest接口設(shè)計方法來設(shè)計接口。但是當(dāng)前我更傾向于僅僅將Http API作為接口實現(xiàn)方式，是否Rest風(fēng)格并不是重點。

即在接口實現(xiàn)中完全可以將所有接口實現(xiàn)POST接口方法，而不用去區(qū)分哪些必須用GET，哪些還得用PUT方法。雖然都實現(xiàn)為POST方法后會對一些接口的在線訪問和測試帶來一些不方便，但是這個完全可以通過其它方式去解決掉。

前后端分離和大量API接口暴露

API接口本身應(yīng)該是粗粒度的，但是實際在很多項目里面看到往往將數(shù)據(jù)庫表的CRUD方法全部暴露為了API接口方法。這個一方面是領(lǐng)域?qū)ο髮拥呢氀?，一個是前后端分離導(dǎo)致原來數(shù)據(jù)訪問層的內(nèi)部API接口全部都需要通過Http API接口方式暴露。

一個內(nèi)部的IT系統(tǒng)，本身僅僅內(nèi)部局域網(wǎng)使用，只提供PC端的BS瀏覽界面也沒有對APP端的支撐需求，在這種情況下前后端分離沒有任何必要。前后端分離反而帶來了后端API接口大量暴露，前端和后端集成協(xié)同等大量問題。

在這種場景下如果IT系統(tǒng)劃分為5個微服務(wù)模塊，這5個微服務(wù)模塊之間的API接口設(shè)計和集成，才是我們真正需要去關(guān)注的問題點。

在當(dāng)前微服務(wù)架構(gòu)設(shè)計里面，微服務(wù)間的接口協(xié)同，微服務(wù)本身前后端接口協(xié)同全部混雜在一起，實際導(dǎo)致了后續(xù)整個微服務(wù)體系里面的API管控治理完全失控。

基于Saga分布式事務(wù)

前面談分布式事務(wù)的時候，更多談的是事物補償或者事務(wù)最終一致性保障，但是很多長周期的事務(wù)仍然是API接口的同步調(diào)用方式來實現(xiàn)。即當(dāng)API接口同步調(diào)用的時候，微服務(wù)間并沒有徹底解耦。要解耦必須是基于事件或消息模式的異步調(diào)用方式。

Saga即是一種異步消息事件機制下的分布式事務(wù)解決方案。Saga是由一系列的本地事務(wù)構(gòu)成。每一個本地事務(wù)在更新完數(shù)據(jù)庫之后，會發(fā)布一條消息或者一個事件來觸發(fā)Saga中的下一個本地事務(wù)的執(zhí)行。如果一個本地事務(wù)因為某些業(yè)務(wù)規(guī)則無法滿足而失敗，Saga會執(zhí)行在這個失敗的事務(wù)之前成功提交的所有事務(wù)的補償操作。

Saga的實現(xiàn)有很多種方式，其中最流行的兩種方式是：

基于事件的方式。這種方式?jīng)]有協(xié)調(diào)中心，整個模式的工作方式就像舞蹈一樣，各個舞蹈演員按照預(yù)先編排的動作和走位各自表演，最終形成一只舞蹈。

基于命令的方式。這種方式的工作形式就像一只樂隊，由一個指揮家（協(xié)調(diào)中心）來協(xié)調(diào)大家的工作。協(xié)調(diào)中心來告訴Saga的參與方應(yīng)該執(zhí)行哪一個本地事務(wù)。

當(dāng)重新來思考分布式事務(wù)的時候，再次印證我的一個觀點，即微服務(wù)拆分太細導(dǎo)致引入了很多完全沒有必要的分布式事務(wù)問題，增加了開發(fā)，集成，測試和后續(xù)監(jiān)控運維的工作量和復(fù)雜度。

比如書里面談到的一個例子，對于一個在線訂餐系統(tǒng)提交一個訂單，這個本身是一個很容易實現(xiàn)的功能，但是在微服務(wù)化后，訂單提交涉及到用戶校驗，賬戶校驗，廚房工單生成多個獨立API服務(wù)接口調(diào)用。這個就涉及到這些API接口的事件編排，同時在編排中你還需要考慮出現(xiàn)異常時候的補償回退，考慮消息執(zhí)行順序等諸多問題。

這些急劇了增加了一個功能實現(xiàn)的復(fù)雜度。當(dāng)你本身開發(fā)的系統(tǒng)就不存在海量并發(fā)和高性能需求的時候，我實在難以找到任何理由將微服務(wù)拆分的如此細，引入這么多的復(fù)雜度。

實際上以上的分布式事務(wù)場景應(yīng)該更多地應(yīng)用到大系統(tǒng)間的分布式事務(wù)協(xié)同上面，比如采購系統(tǒng)提交訂單的時候，同時涉及到工作流平臺中的工作流實例啟動，涉及到預(yù)算系統(tǒng)的預(yù)算校驗，這個時候才要分布式事務(wù)來實現(xiàn)是有必要的。

跨系統(tǒng)出現(xiàn)上面這種分布式事務(wù)處理和協(xié)同場景，這個量完全可控。但是你微服務(wù)拆分得太細，你在實現(xiàn)應(yīng)用中任何一個功能都引入上面這種分布式事務(wù)問題，基于事件的編排和補償問題，可想而知已經(jīng)不是簡單的復(fù)雜度問題，而是后期的系統(tǒng)可靠性和可運維問題。

如何徹底解耦？

前面談到了如果是CUD操作可以異步方式來實現(xiàn)解耦，那么對于查詢操作如何處理。如果一個查詢查找本身還涉及到多個微服務(wù)API接口的組合，這個時候如何實現(xiàn)解耦。

對于查詢操作一般來講都是同步操作，用戶端點擊查詢后會等待數(shù)據(jù)的返回，這個時候如果需要調(diào)用多個微服務(wù)API接口數(shù)據(jù)進行組合，那么底層某個微服務(wù)模塊如此異常，將直接導(dǎo)致整個查詢功能持續(xù)異常。

即如果存在查詢操作，那么微服務(wù)間仍然是緊耦合在一起的。我們希望的微服務(wù)間通過消息和異步來徹底解耦這個目標(biāo)并沒有達到。

當(dāng)然實際上可以考慮兩個方法來解決這個問題。

其一就是將常用數(shù)據(jù)緩存，查詢的時候直接訪問緩存庫。

其二就是將微服務(wù)底層數(shù)據(jù)庫需要共享數(shù)據(jù)進行同步，同步到一個大的共享ODS讀庫專門來提供查詢服務(wù)能力。

在一些項目的CQRS命令查詢職責(zé)分離實踐中，基本即采用的這個思路。通過這種方式來實現(xiàn)微服務(wù)間的徹底解耦。當(dāng)然也引入了另外兩個依賴點，一個就是消息中間件，一個就是緩存庫或分布式ODS讀庫。這兩個點的穩(wěn)定性就直接影響到整個系統(tǒng)的穩(wěn)定性。

采用CQRS模式最大的一個問題點就是無法實現(xiàn)命令和查詢兩部分內(nèi)容的強一致性保障，即很可能你界面上查詢到的數(shù)據(jù)不是最新的持久化數(shù)據(jù)庫里面的數(shù)據(jù)，這個本身和消息管道異步寫入的實時性又關(guān)系。

其次在使用CQRS模式的時候，有一個重要假設(shè)就是在事件和命令發(fā)出后，無特殊情況在事件接收方都必須要能夠接收事件成功處理，否則就存在大量的異常錯誤消息的異步回寫，反而增加系統(tǒng)的復(fù)雜度。

實施CQRS引入的整體復(fù)雜度，也不是一般的小項目能夠玩得起的。

同時對于CQRS框架的實施，不是簡單的設(shè)計模式和開發(fā)復(fù)雜度問題，更加重要的仍然是是否能夠接受最終一致性要求，同時在該要求下將傳統(tǒng)的同步請求下業(yè)務(wù)功能和邏輯處理機制轉(zhuǎn)變?yōu)楫惒绞录r值下的事件鏈驅(qū)動模式。要實現(xiàn)這種轉(zhuǎn)變就必須能夠拆分出獨立，自治的命令和事件，同時確保這些事件在朝后端業(yè)務(wù)功能和邏輯模塊發(fā)送的時候能夠處理成功（即該做的校驗必須提前做完）。

微服務(wù)網(wǎng)關(guān)和API網(wǎng)關(guān)

對于API網(wǎng)關(guān)也可以先參考我頭條發(fā)布過的相關(guān)文章。

于API網(wǎng)關(guān)和微服務(wù)網(wǎng)關(guān)實際實現(xiàn)的核心功能基本一致，但是要注意到微服務(wù)網(wǎng)關(guān)一般是在微服務(wù)架構(gòu)體系里面的內(nèi)容。而API網(wǎng)關(guān)一般是可以獨立在微服務(wù)架構(gòu)體系之外的內(nèi)容。

也就是說API網(wǎng)關(guān)和微服務(wù)整體框架體系更加的松耦合。

API網(wǎng)關(guān)一般具備獨立的服務(wù)注冊接入，負載均衡和路由能力，而微服務(wù)網(wǎng)關(guān)一般則是通過和服務(wù)注冊中心的集成來實現(xiàn)服務(wù)注冊發(fā)現(xiàn)，負載均衡和路由

應(yīng)用范圍的區(qū)別

在這里重新強調(diào)下，微服務(wù)網(wǎng)關(guān)和API網(wǎng)關(guān)實際在應(yīng)用范圍上有明顯的區(qū)別。即微服務(wù)網(wǎng)關(guān)一般應(yīng)用在單個微服務(wù)應(yīng)用內(nèi)部，特別是在存在前后端分離情況下。而對于API網(wǎng)關(guān)則是應(yīng)用在組織級，實現(xiàn)多個微服務(wù)應(yīng)用之間的集成和協(xié)同能力。

單個微服務(wù)應(yīng)用，完全沒有必要采用API網(wǎng)關(guān)，直接使用微服務(wù)網(wǎng)關(guān)。比如當(dāng)你采用SpringCLoud框架體系的時候，你直接采用框架里面的Zuul或SpringCLoud Gateway即可。

但是當(dāng)你在做組織級的多個微服務(wù)應(yīng)用間集成的時候，這個時候需要的脫離單個微服務(wù)框架體系的的一個外部集成中間件，因此不能和微服務(wù)框架綁定太死。其次你會看到跨應(yīng)用間的集成管控的粒度不是到微服務(wù)組件，而是要細化到一個個的API接口。因此這個時候啟用API網(wǎng)關(guān)就是必須的。

當(dāng)你在組織級啟用API網(wǎng)關(guān)的時候發(fā)現(xiàn)一個新問題。

即對于整個組織級來說，遺留系統(tǒng)和單體應(yīng)用的微服務(wù)化本身有個過程，在這個過程中一定是傳統(tǒng)架構(gòu)和微服務(wù)架構(gòu)共存。新的Rest API接口和老的SOAP接口和消息協(xié)議共存階段。而API網(wǎng)關(guān)本身對老的接口協(xié)議適配能力并不好。對于類似ESB總線來說雖然偏重，但是可以完全兼容和覆蓋API網(wǎng)關(guān)具備的能力。

因此在這種情況下API網(wǎng)關(guān)反而變得雞肋。

API網(wǎng)關(guān)是否該做類似服務(wù)編排組合的事情？

簡單來說API網(wǎng)關(guān)不應(yīng)該做這件事情，傳統(tǒng)的ESB總線往往具備這個能力，但是API網(wǎng)關(guān)不適合來承載這個能力。如果做了服務(wù)編排的事情一個是讓API網(wǎng)關(guān)本身從單純的技術(shù)中間件變成了承載業(yè)務(wù)邏輯的中間件，其次就是該能力本身也將讓API網(wǎng)關(guān)變得更加重。

因此最好的方法仍然是獨立一個微服務(wù)來實現(xiàn)服務(wù)組合和編排，發(fā)布組合后的領(lǐng)域服務(wù)或組合服務(wù)能力，這個在我前面文章專門有談到過。

API網(wǎng)關(guān)本身的中心化問題

不要簡單地認為中心化架構(gòu)就一定不好，中心化架構(gòu)本身通過集中管控和攔截的方式，可以很方便地實現(xiàn)類似API接口安全，日志，路由，流控等各種管控能力。

在談微服務(wù)管控治理的時候，中心化的API網(wǎng)關(guān)是一個重要的實現(xiàn)思路和手段，當(dāng)然在前面我也提到了整體的發(fā)展趨勢應(yīng)該ServiceMesh化，實現(xiàn)完全的去中心化架構(gòu)。這個ServiceMesh化本身又可以和DevOps，容器云等云原生技術(shù)形成一個完整的整體。

但是要意識到的點仍然是在于組織管控和標(biāo)準化推進的力度，如果在組織級很多技術(shù)標(biāo)準推進不一致，應(yīng)用系統(tǒng)改造存在前后逐步演進，那么這個時候你很難簡單的去實現(xiàn)ServiceMesh化架構(gòu)。簡單來說即是：

對于傳統(tǒng)IT架構(gòu)的逐步微服務(wù)化，本身并不適合采用ServiceMesh。

在談微服務(wù)架構(gòu)的時候，經(jīng)常有人談到完全的去中心化，但是沒有搞清楚為啥要去中心化。即使異步消息集成，消息中間件仍然是中心點。當(dāng)組織級標(biāo)準規(guī)范，技術(shù)要求不統(tǒng)一的時候，管控能力達不到時候很難完全去中心化，這個時候中心化方式反而是一個好的選擇。

最后，做下簡單總結(jié)如下：

按照理想化的微服務(wù)方法來設(shè)計和實施微服務(wù)，對于大部分傳統(tǒng)企業(yè)信息化來說不適用，同樣照搬互聯(lián)網(wǎng)微服務(wù)架構(gòu)化方法同樣不適用。企業(yè)IT架構(gòu)在微服務(wù)轉(zhuǎn)型過程中更多應(yīng)該基于業(yè)務(wù)場景和問題驅(qū)動，借鑒微服務(wù)拆分和解耦的思想，充分考慮敏捷交付，彈性擴展和性能，開發(fā)難度和資源成本投入，后期管控治理多方面的平衡。

“如何理解微服務(wù)架構(gòu)從理想到現(xiàn)實的過程”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！