注：本文為我最近閱讀《微服務(wù)架構(gòu)設(shè)計(jì)模式》的一點(diǎn)感悟，我不準(zhǔn)備詳細(xì)去寫對該書的讀書筆記記錄，而是結(jié)合我們自己所做的一些微服務(wù)架構(gòu)實(shí)踐情況做一些總結(jié)和復(fù)盤。

從單體應(yīng)用到微服務(wù)

[[384910]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

場景和問題驅(qū)動(dòng)

[[384911]]

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

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

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

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

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

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

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

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

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

微服務(wù)拆分策略

[[384912]]

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

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

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

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

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

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

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

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

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

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

因此在這里需要重申一個(gè)重要觀點(diǎn)。

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

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

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

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

從API接口到異步解耦

[[384913]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如何徹底解耦？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

即對于整個(gè)組織級來說，遺留系統(tǒng)和單體應(yīng)用的微服務(wù)化本身有個(gè)過程，在這個(gè)過程中一定是傳統(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總線往往具備這個(gè)能力，但是API網(wǎng)關(guān)不適合來承載這個(gè)能力。如果做了服務(wù)編排的事情一個(gè)是讓API網(wǎng)關(guān)本身從單純的技術(shù)中間件變成了承載業(yè)務(wù)邏輯的中間件，其次就是該能力本身也將讓API網(wǎng)關(guān)變得更加重。

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

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

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

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

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

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

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

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

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

來源：

https://www.toutiao.com/i6925193987997696516/