作者：人月神話，新浪博客同名
簡(jiǎn)介：多年SOA規(guī)劃建設(shè)，私有云PaaS平臺(tái)架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)，長(zhǎng)期從事一線項(xiàng)目實(shí)踐
今天我準(zhǔn)備重新講解下微服務(wù)的基礎(chǔ)概念，關(guān)鍵組件和組件間關(guān)系等核心邏輯。這篇文章我會(huì)對(duì)我原來(lái)寫(xiě)過(guò)的微服務(wù)類(lèi)文章內(nèi)容進(jìn)行大量重構(gòu)，去掉里面比較技術(shù)化的內(nèi)容，而轉(zhuǎn)為一種非開(kāi)發(fā)人員也容易理解的方式來(lái)講解。
概念模型為何如此重要？
最近我思考比較多的一個(gè)詞就是概念模型，不管新知識(shí)的學(xué)習(xí)，新事物的認(rèn)知，新領(lǐng)域的快速切入還是面對(duì)新問(wèn)題的快速分析和解決，認(rèn)識(shí)和理解概念模型都是相當(dāng)重要的一個(gè)步驟。
概念模型本身是我們認(rèn)知事物核心框架和基礎(chǔ)邏輯的自我可理解的最簡(jiǎn)模型。
這里面有幾個(gè)關(guān)鍵點(diǎn)，其一是對(duì)事物形成基礎(chǔ)認(rèn)知，其二是最簡(jiǎn)和最容易模型，其三則是對(duì)我們自己最佳適用的模型。
每個(gè)人的知識(shí)積累和經(jīng)驗(yàn)不同，最適用于他們的概念模型就是不一樣的。因此對(duì)于有理論和實(shí)踐經(jīng)驗(yàn)積累的人，你可能并不需要用簡(jiǎn)單的方式闡述事物，有時(shí)候連比喻都不需要，而對(duì)于初次接觸陌生領(lǐng)域的人來(lái)說(shuō)，那么對(duì)核心邏輯的形象比喻就顯得相當(dāng)重要了。
一個(gè)事物只有在自己腦海里面形成了初步的概念模型的時(shí)候，才能夠算對(duì)該事物有了初步的認(rèn)識(shí)，接下來(lái)才談得上如何層層剝繭和分解，深入到內(nèi)部機(jī)理進(jìn)行深入了解。這和我們?cè)趯W(xué)習(xí)方法和模式里面談到一開(kāi)始的學(xué)習(xí)應(yīng)該是不求甚解是一個(gè)道理。
只有搭建了大框架，理清主脈絡(luò)，你才可能有目標(biāo)和有興趣深入。
但是實(shí)際我們?nèi)匀豢吹剑ê芏嗳藛T頭腦里面仍然是采用了SpringCLoud框架，采用了Http Rest接口服務(wù)集成或API網(wǎng)關(guān)就是微服務(wù)了。而對(duì)微服務(wù)架構(gòu)思想的本質(zhì)并沒(méi)有形成完整的理解，這些都是我們?cè)趯W(xué)習(xí)新知識(shí)，認(rèn)識(shí)新事物時(shí)候必須要避免的。
從微服務(wù)基本定義說(shuō)起
我們先看下當(dāng)前互聯(lián)網(wǎng)上對(duì)微服務(wù)的主流定義。
微服務(wù)可以在“自己的程序”中運(yùn)行，并通過(guò)“輕量級(jí)設(shè)備與HTTP型API進(jìn)行溝通”。關(guān)鍵在于該服務(wù)可以在自己的程序中運(yùn)行。通過(guò)這一點(diǎn)我們就可以將服務(wù)公開(kāi)與微服務(wù)架構(gòu)（在現(xiàn)有系統(tǒng)中分布一個(gè)API）區(qū)分開(kāi)來(lái)。在服務(wù)公開(kāi)中，許多服務(wù)都可以被內(nèi)部獨(dú)立進(jìn)程所限制。如果其中任何一個(gè)服務(wù)需要增加某種功能，那么就必須縮小進(jìn)程范圍。在微服務(wù)架構(gòu)中，只需要在特定的某種服務(wù)中增加所需功能，而不影響整體進(jìn)程。
微服務(wù)不需要像普通服務(wù)那樣成為一種獨(dú)立的功能或者獨(dú)立的資源。定義中稱(chēng)，微服務(wù)是需要與業(yè)務(wù)能力相匹配，這種說(shuō)法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設(shè)計(jì)是錯(cuò)誤的，那么，我們就必須付出很多代價(jià)。
看完上面的圖后，估計(jì)還是很難真正抓住微服務(wù)的關(guān)鍵點(diǎn)。
在我很早就談到過(guò)，在理解和認(rèn)識(shí)一個(gè)概念的時(shí)候，你一定要用和你已有的知識(shí)概念做對(duì)比，進(jìn)行差異分析，你就很容易抓住要點(diǎn)在哪里。
而要了解微服務(wù)一樣，你了解了和傳統(tǒng)單體應(yīng)用的差別，基本微服務(wù)核心就了解了。簡(jiǎn)單來(lái)說(shuō)微服務(wù)本身就是將傳統(tǒng)的單體應(yīng)用大拆小，然后通過(guò)一種輕量高效的標(biāo)準(zhǔn)接口進(jìn)行協(xié)同的架構(gòu)模式。
舉一個(gè)單體應(yīng)用到微服務(wù)的例子說(shuō)明
為了更好的解釋微服務(wù)，包括后面對(duì)微服務(wù)很多關(guān)鍵組件的解釋?zhuān)覀冃枰獪?zhǔn)備一個(gè)業(yè)務(wù)系統(tǒng)功能常見(jiàn)來(lái)進(jìn)行舉例說(shuō)明，具體的背景如下。
當(dāng)前我們準(zhǔn)備構(gòu)建一個(gè)SRM供應(yīng)商關(guān)系管理業(yè)務(wù)系統(tǒng)，這個(gè)系統(tǒng)經(jīng)過(guò)前期業(yè)務(wù)和需求分析，包括了供應(yīng)商管理，物料管理，招投標(biāo)，供應(yīng)商績(jī)效評(píng)估四個(gè)功能模塊。當(dāng)然在構(gòu)建整個(gè)系統(tǒng)的時(shí)候還有類(lèi)似底層的系統(tǒng)管理，流程引擎等技術(shù)模塊組件。
我們要構(gòu)建的SRM系統(tǒng)就是典型的單體應(yīng)用，那么我們來(lái)看這個(gè)單體應(yīng)用構(gòu)建模式轉(zhuǎn)變到微服務(wù)構(gòu)建模式后究竟帶來(lái)了哪些變化。如下圖，我們從開(kāi)發(fā)態(tài)和運(yùn)行態(tài)去分析。
從這個(gè)圖我們基本就把微服務(wù)核心的關(guān)鍵點(diǎn)看清楚了。即：
- 一個(gè)單體變多個(gè)微服務(wù)模塊，而且從數(shù)據(jù)庫(kù)到邏輯層到前端完全獨(dú)立
- 微服務(wù)模塊間通過(guò)Http Rest接口高效集成協(xié)同
- 各個(gè)微服務(wù)完全獨(dú)立部署，擴(kuò)展的時(shí)候數(shù)據(jù)庫(kù)，集群都單獨(dú)擴(kuò)展
以上實(shí)際上就是我們經(jīng)常談到的微服務(wù)區(qū)別于單體架構(gòu)最關(guān)鍵的幾個(gè)點(diǎn)。在掌握了這個(gè)核心概念后你才清楚哪些不是微服務(wù)基本特征。比如微服務(wù)必須容器化部署，沒(méi)有這個(gè)說(shuō)法，微服務(wù)也可以傳統(tǒng)方式部署。還有就是微服務(wù)開(kāi)發(fā)必須前后端分離，實(shí)際上也沒(méi)有這個(gè)說(shuō)法，前后端不分離只要微服務(wù)間完全縱向解耦就是微服務(wù)架構(gòu)。
基于SOA和中臺(tái)思想對(duì)上面拆分進(jìn)行重構(gòu)
如果按照上面的模塊拆分進(jìn)行獨(dú)立的設(shè)計(jì)，開(kāi)發(fā)和部署，完全是符合微服務(wù)架構(gòu)的思想的。但是是否符合SOA和中臺(tái)能力共享思想呢？
將數(shù)據(jù)提供和形成數(shù)據(jù)的流程分開(kāi)形成分層
我再?gòu)?qiáng)調(diào)下SOA和中臺(tái)里面的一個(gè)關(guān)鍵思想，即：
你要去找到你的核心業(yè)務(wù)能力提供，而不是馬上去關(guān)心你的能力或最終數(shù)據(jù)是如何形成的。能力最終提供屬于中臺(tái)能力，能力如何形成的可以屬于前臺(tái)應(yīng)用能力。
比如上面談到的供應(yīng)商，物料兩個(gè)微服務(wù)，我們發(fā)現(xiàn)核心就是提供可共享的供應(yīng)商和物料數(shù)據(jù)能力。但是這兩個(gè)數(shù)據(jù)如何形成的? 一方面是可以直接在后臺(tái)錄入，一個(gè)方面還是可以是供應(yīng)商自己進(jìn)行供應(yīng)商認(rèn)證申請(qǐng)，我們審核通過(guò)后進(jìn)入到供應(yīng)商庫(kù)。
那么供應(yīng)商數(shù)據(jù)本身屬于中臺(tái)能力，供應(yīng)商信息的申請(qǐng)流程可屬于前臺(tái)應(yīng)用功能。
是否嚴(yán)格的邏輯層和數(shù)據(jù)庫(kù)1對(duì)1對(duì)應(yīng)？
這個(gè)是我今天想拿出來(lái)討論的第二個(gè)問(wèn)題，即很多人在進(jìn)行微服務(wù)架構(gòu)設(shè)計(jì)的時(shí)候往往走兩個(gè)極端。或者是數(shù)據(jù)庫(kù)不拆分就一個(gè)大庫(kù)，或者就是數(shù)據(jù)庫(kù)完全按微服務(wù)1對(duì)1拆分。那么我們上層規(guī)劃的20個(gè)微服務(wù)，是否就一定有20個(gè)對(duì)應(yīng)的數(shù)據(jù)庫(kù)實(shí)例ID？
在數(shù)據(jù)庫(kù)拆分細(xì)一定帶來(lái)我們?cè)谠O(shè)計(jì)實(shí)現(xiàn)時(shí)候兩個(gè)問(wèn)題
- 其一是我們常說(shuō)的分布式事務(wù)處理問(wèn)題，有用庫(kù)拆分無(wú)法再用數(shù)據(jù)庫(kù)層事務(wù)
- 其二是原來(lái)一個(gè)關(guān)聯(lián)sql搞定的事情，全部變成了邏輯層多次服務(wù)調(diào)用后進(jìn)行服務(wù)組裝
以上兩個(gè)問(wèn)題不僅僅是帶來(lái)的開(kāi)發(fā)工作量，而且更重要的是影響到數(shù)據(jù)一致性。
正是由于這個(gè)原因，我們提出一個(gè)微服務(wù)集的概念。
微服務(wù)集的意思可以理解為邏輯層仍然按照標(biāo)準(zhǔn)的微服務(wù)要求去構(gòu)建，每個(gè)邏輯層都可以編譯可獨(dú)立部署的Jar包。但是對(duì)應(yīng)微服務(wù)集里面的多個(gè)微服務(wù)可共用一個(gè)數(shù)據(jù)庫(kù)。
而基于上面場(chǎng)景，供應(yīng)商和物料本身關(guān)聯(lián)業(yè)務(wù)場(chǎng)景相當(dāng)多，放在一個(gè)數(shù)據(jù)庫(kù)顯然是更加適合。經(jīng)過(guò)重新思考后，我們整體的邏輯架構(gòu)變化為：
基于實(shí)際業(yè)務(wù)場(chǎng)景驅(qū)動(dòng)，對(duì)微服務(wù)初步設(shè)計(jì)重構(gòu)后體現(xiàn)為兩點(diǎn)
- 其一是供應(yīng)商和物料合并為一個(gè)數(shù)據(jù)庫(kù)而不進(jìn)行拆分
- 其二是邏輯層的微服務(wù)基于復(fù)用分層思路拆分為三個(gè)微服務(wù)模塊
拆分后的三個(gè)微服務(wù)如何交互？
在完成基本的拆分后，我們來(lái)看拆分完成后的三個(gè)微服務(wù)模塊如何交互。
如果我們?nèi)匀话裇RM看成一個(gè)大的應(yīng)用，并且SRM系統(tǒng)的能力接口不需要對(duì)外暴露，不需要互聯(lián)網(wǎng)App應(yīng)用協(xié)同的時(shí)候。在這種情況下，走微服務(wù)架構(gòu)體系里面的服務(wù)注冊(cè)中心來(lái)完成接口交互。簡(jiǎn)單來(lái)說(shuō)就是微服務(wù)間的接口消費(fèi)調(diào)用是一種去中心化的架構(gòu)模式。
我們以供應(yīng)商申請(qǐng)微服務(wù)，需要在申請(qǐng)審核通過(guò)后，調(diào)用供應(yīng)商管理提供的信息導(dǎo)入API接口將數(shù)據(jù)導(dǎo)入到供應(yīng)商管理模塊中來(lái)舉例說(shuō)明。
從圖里面可以看到整個(gè)過(guò)程簡(jiǎn)單的三個(gè)關(guān)鍵步驟。
- 第一，供應(yīng)商管理將實(shí)現(xiàn)的API接口注冊(cè)到注冊(cè)中心
- 第二，申請(qǐng)模塊從注冊(cè)中心獲取接口的地址信息
- 第三，根據(jù)拿到的地址信息直接發(fā)起對(duì)接口的點(diǎn)對(duì)點(diǎn)調(diào)用
為何叫去中心化？
從上圖整個(gè)過(guò)程可以看到，整個(gè)服務(wù)調(diào)用只有獲取地址會(huì)和數(shù)據(jù)中心發(fā)生關(guān)系，實(shí)際獲取到地址后即是接口的點(diǎn)對(duì)點(diǎn)調(diào)用，這個(gè)時(shí)候接口的數(shù)據(jù)流完全不經(jīng)過(guò)注冊(cè)中心。
那么獲取地址的時(shí)候注冊(cè)中心宕機(jī)了怎么辦？
所以可以看到一般來(lái)說(shuō)，獲取的地址信息都會(huì)在本地微服務(wù)模塊緩存，后續(xù)在調(diào)用的時(shí)候如果注冊(cè)中心有故障，那么就訪問(wèn)本地緩存的地址信息。對(duì)于這點(diǎn)本身又需要稍微展開(kāi)下分兩個(gè)實(shí)現(xiàn)方式來(lái)進(jìn)一步解釋下。
其一，負(fù)載均衡的能力在注冊(cè)中心
在這種情況下，我們每次消費(fèi)接口，都必須調(diào)用注冊(cè)中心服務(wù)來(lái)獲取最終輪詢出來(lái)的目標(biāo)地址信息。只有在注冊(cè)中心不可用情況下，我們才訪問(wèn)本地緩存。
其二，負(fù)載均衡的能力在本地微服務(wù)
在這種情況下，只需要獲取注冊(cè)中心的地址信息清單，同時(shí)在地址狀態(tài)變更的時(shí)候被動(dòng)獲取注冊(cè)中心的變更消息推送。那么后續(xù)所有接口訪問(wèn)都和注冊(cè)中心無(wú)關(guān)。
微服務(wù)間交互是否一定是Http Rest接口？
多個(gè)微服務(wù)如果不對(duì)外提供能力，僅僅是內(nèi)部接口交互，那么Http Rest接口并不是必須的。比如我們常說(shuō)的Dubbo框架，可以采用更加高效的RPC接口進(jìn)行交互，而且底層還可以走TCP協(xié)議。
但是一涉及到對(duì)外能力提供，涉及到主動(dòng)網(wǎng)絡(luò)防火墻問(wèn)題時(shí)，一般只能走Http接口交互。
當(dāng)然你可以理解為，同樣一個(gè)接口實(shí)現(xiàn)，我們可以在內(nèi)部交互的時(shí)候走高效的RPC接口模式，而僅僅需要對(duì)外暴露服務(wù)能力的時(shí)候?qū)⑵浒l(fā)布為Http Rest接口。
從服務(wù)注冊(cè)中心到API網(wǎng)關(guān)
對(duì)于一個(gè)應(yīng)用里面的多個(gè)微服務(wù)需要統(tǒng)一對(duì)外暴露接口能力的時(shí)候，這個(gè)時(shí)候就涉及到OpenAPI能力開(kāi)放平臺(tái)或API網(wǎng)關(guān)，那么首先來(lái)解釋下API網(wǎng)關(guān)。
如何給API網(wǎng)關(guān)一個(gè)定義？
簡(jiǎn)單來(lái)說(shuō)API網(wǎng)關(guān)就是將所有的微服務(wù)提供的API接口服務(wù)能力全部匯聚進(jìn)來(lái)，統(tǒng)一接入進(jìn)行管理，也正是通過(guò)統(tǒng)一攔截，就可以通過(guò)網(wǎng)關(guān)實(shí)現(xiàn)對(duì)API接口的安全，日志，限流熔斷等共性需求。如果再簡(jiǎn)單說(shuō)下，通過(guò)網(wǎng)關(guān)實(shí)現(xiàn)了幾個(gè)關(guān)鍵能力。
- 內(nèi)部的微服務(wù)對(duì)外部訪問(wèn)來(lái)說(shuō)位置透明，外部應(yīng)用只需和網(wǎng)關(guān)交互
- 統(tǒng)一攔截接口服務(wù)，實(shí)現(xiàn)安全，日志，限流熔斷等需求
從這里，我們就可以看到API網(wǎng)關(guān)和傳統(tǒng)架構(gòu)里面的ESB總線是類(lèi)似的，這些關(guān)鍵能力本身也是ESB服務(wù)總線的能力，但是ESB服務(wù)總線由于要考慮遺留系統(tǒng)的接入，因此增加了類(lèi)似遺留系統(tǒng)適配，協(xié)議轉(zhuǎn)換，復(fù)雜數(shù)據(jù)映射等能力。
微服務(wù)架構(gòu)不再需要ESB，并且一定是去中心化的？
這是必須要搞清楚的一個(gè)問(wèn)題。
首先看下微服務(wù)架構(gòu)里面確實(shí)不需要傳統(tǒng)ESB，但是需要一個(gè)ESB的輕量實(shí)現(xiàn)，即我們說(shuō)的API網(wǎng)關(guān)。因?yàn)槲⒎?wù)架構(gòu)里面都是標(biāo)準(zhǔn)的Http Rest接口，不再存在復(fù)雜的遺留接口適配，復(fù)雜協(xié)議轉(zhuǎn)換等問(wèn)題。但是我們常說(shuō)的接口服務(wù)代理，統(tǒng)一的安全，日志，流控功能仍然需要。
同時(shí)微服務(wù)架構(gòu)內(nèi)部各個(gè)微服務(wù)模塊間本身是去中心化的，但是當(dāng)微服務(wù)架構(gòu)里面各個(gè)微服務(wù)需要對(duì)外提供接口服務(wù)能力給外部應(yīng)用使用時(shí)候，外部應(yīng)用和微服務(wù)間由于增加了API網(wǎng)關(guān)又變成了一個(gè)中心化的架構(gòu)。所以不要一提到微服務(wù)就去中心化，這個(gè)理解本身也是不對(duì)的。
對(duì)于API網(wǎng)關(guān)來(lái)說(shuō)，核心就是實(shí)現(xiàn)兩類(lèi)能力，一個(gè)是對(duì)API全生命周期管理能力，包括了API接口的注冊(cè)，接入，發(fā)布，測(cè)試，變更和版本管理，下線等。另外一個(gè)關(guān)鍵能力就是我們常說(shuō)的安全，日志，流控方面的能力。
而這些能力最常見(jiàn)的實(shí)現(xiàn)方式就是通過(guò)插件進(jìn)行攔截處理，如下:
如上圖，API網(wǎng)關(guān)里面的關(guān)鍵對(duì)象注意包括了接入系統(tǒng)（微服務(wù)），消費(fèi)系統(tǒng)，注冊(cè)接入的API接口，發(fā)布的Proxy API接口，在代理和原始服務(wù)間有一個(gè)路由對(duì)象。只要有這些最基本的對(duì)象就可以實(shí)現(xiàn)最簡(jiǎn)單場(chǎng)景下的服務(wù)接入。
而其它所有的擴(kuò)展可以看到都應(yīng)該基于插件式方式的擴(kuò)展，這些插件包括了安全認(rèn)證類(lèi)插件，流量控制類(lèi)插件，日志監(jiān)控類(lèi)插件，轉(zhuǎn)換類(lèi)插件。
任何一個(gè)API接口和插件之間是一種多對(duì)多的關(guān)系。即一個(gè)API接口可以被作用多個(gè)插件，同時(shí)一個(gè)插件本身又可以應(yīng)用在多個(gè)API接口上。插件本身就類(lèi)似于AOP橫切，對(duì)服務(wù)請(qǐng)求消息的輸入和輸出進(jìn)行攔截，在攔截到信息后進(jìn)行相關(guān)的安全或其他管控處理。
當(dāng)然插件本身一定會(huì)損耗性能，在實(shí)現(xiàn)的時(shí)候需要考慮對(duì)服務(wù)運(yùn)行數(shù)據(jù)，運(yùn)行統(tǒng)計(jì)數(shù)據(jù)的緩存，特別是對(duì)于流控的實(shí)時(shí)計(jì)算過(guò)程。
業(yè)務(wù)場(chǎng)景需求引入網(wǎng)關(guān)
還是基于上面的案例，供應(yīng)商申請(qǐng)流程我們希望開(kāi)發(fā)一個(gè)APP應(yīng)用給用戶自己申請(qǐng)。這個(gè)APP供應(yīng)商在公網(wǎng)就可以正常訪問(wèn)和登錄使用。
前面談到，API網(wǎng)關(guān)使用重要場(chǎng)景就是需要對(duì)外提供服務(wù)能力。這個(gè)對(duì)外可能是和外部其它系統(tǒng)集成，也可以是我們的應(yīng)用本身會(huì)開(kāi)發(fā)外部互聯(lián)網(wǎng)使用的APP。
在這個(gè)時(shí)候API網(wǎng)關(guān)引入就變成了必須。
API網(wǎng)關(guān)本身也實(shí)現(xiàn)了外部應(yīng)用和我們內(nèi)部微服務(wù)間的安全隔離，比如我們把API網(wǎng)關(guān)還可以部署到整個(gè)基礎(chǔ)設(shè)施架構(gòu)的DMZ區(qū)等。
是否可以不用API網(wǎng)關(guān)？
當(dāng)然，你也可以不用類(lèi)似Kong等API網(wǎng)關(guān)產(chǎn)品，那么這個(gè)時(shí)候我們常說(shuō)的一些共性的安全，日志，限流熔斷能力無(wú)法實(shí)現(xiàn)。但是最基本的代理路由轉(zhuǎn)發(fā)能力是必須的，因此你在前期可以使用類(lèi)似Ngnix來(lái)實(shí)現(xiàn)請(qǐng)求轉(zhuǎn)發(fā)并替代API網(wǎng)關(guān)的使用。
API網(wǎng)關(guān)的幾個(gè)關(guān)鍵功能分析
下面來(lái)看下API網(wǎng)關(guān)實(shí)現(xiàn)的幾個(gè)關(guān)鍵功能。其中附帶介紹下Kong網(wǎng)關(guān)的一些關(guān)鍵能力。
日志攔截和記錄
對(duì)于日志攔截和記錄是最常見(jiàn)的一個(gè)API網(wǎng)關(guān)功能，但是類(lèi)似開(kāi)源的API網(wǎng)關(guān)產(chǎn)品往往也僅僅是提供日志輸入接口，如果需要對(duì)日志進(jìn)行集中化存儲(chǔ)和日志查詢分析，仍然需要自己開(kāi)發(fā)相關(guān)的功能來(lái)完成。
日志攔截簡(jiǎn)單來(lái)說(shuō)三點(diǎn)
- 其一：首先是通過(guò)插件攔截到輸入和輸出消息信息
- 其二：將信息寫(xiě)入異步寫(xiě)入到消息中間件中
- 其三：通過(guò)程序從消息中間件中獲取消息，再將日志持久化到數(shù)據(jù)庫(kù)或分布式對(duì)象存儲(chǔ)
如果整個(gè)微服務(wù)里面日志產(chǎn)生量大，而且對(duì)歷史日志的查詢時(shí)間段也要求較長(zhǎng)的情況下，建議將日志存在到分布式文件存儲(chǔ)或分布式對(duì)象存儲(chǔ)中。
可以看到日志信息本身復(fù)合服務(wù)實(shí)例ID+實(shí)例報(bào)文體這種對(duì)象存儲(chǔ)結(jié)構(gòu)。
比如我們可以基于Kong網(wǎng)關(guān)的擴(kuò)展能力來(lái)自己開(kāi)發(fā)日志記錄存儲(chǔ)和查詢插件，對(duì)于Kong網(wǎng)關(guān)來(lái)說(shuō)插件的定制化開(kāi)發(fā)能力相當(dāng)強(qiáng)。
一個(gè)是sysLog在配置后可以直接將Kong產(chǎn)生的日志寫(xiě)入到應(yīng)用服務(wù)器的系統(tǒng)日志文件中。如果配置了file-log則是單獨(dú)寫(xiě)入到你指定的file文件中。對(duì)于http-log則是對(duì)于http服務(wù)請(qǐng)求，可以詳細(xì)的記錄請(qǐng)求的輸入和輸出報(bào)文信息，但是具體是記錄到哪里，需要通過(guò)config.http_endpoint配置。
安全功能
對(duì)于安全功能我們先簡(jiǎn)單談下實(shí)際需要哪些安全能力。
最常見(jiàn)的就是接口服務(wù)訪問(wèn)控制安全能力，即API網(wǎng)關(guān)暴露的一個(gè)接口，必須通過(guò)安全認(rèn)證通過(guò)后才能夠訪問(wèn)接口。供應(yīng)商信息導(dǎo)入API比如你授權(quán)給供應(yīng)商申請(qǐng)流程微服務(wù)模塊（SUP）使用。那么可以看到常見(jiàn)的一些方法。
- 其一：分配給SUP一個(gè)靜態(tài)的用戶名和密碼，調(diào)用服務(wù)的時(shí)候基于這個(gè)進(jìn)行驗(yàn)證
- 其二：對(duì)SUP系統(tǒng)的IP地址進(jìn)行配置，只有授權(quán)的IP地址能夠訪問(wèn)
但是對(duì)于方法1容易出現(xiàn)用戶名密碼泄漏或被截取；第2種方法容易出現(xiàn)IP偽造，或者對(duì)于容器云環(huán)境IP本身就是不斷動(dòng)態(tài)變化你很難去控制。
因此在這種常見(jiàn)下，我們出現(xiàn)了動(dòng)態(tài)Token安全的處理方法。
簡(jiǎn)單來(lái)說(shuō)就是你每次調(diào)用服務(wù)前，都先向API網(wǎng)關(guān)申請(qǐng)一個(gè)動(dòng)態(tài)申請(qǐng)的Token碼，然后在調(diào)用服務(wù)的時(shí)候連帶上這個(gè)token碼一起發(fā)送過(guò)去進(jìn)行校驗(yàn)，只要校驗(yàn)通過(guò)才允許訪問(wèn)服務(wù)。
當(dāng)然對(duì)于開(kāi)源各類(lèi)API網(wǎng)關(guān)產(chǎn)品基本也提供常見(jiàn)的各類(lèi)安全能力。
比如當(dāng)前網(wǎng)關(guān)提供basic-auth，key-auth、ldap-auth，hmac-auth多種認(rèn)證插件。
限流熔斷功能
對(duì)限流熔斷的理解，首先本文談到的服務(wù)限流和熔斷，和常規(guī)我們說(shuō)的限流和熔斷有區(qū)別。
具體說(shuō)明為：
- 服務(wù)限流：取消某個(gè)消費(fèi)方對(duì)某個(gè)服務(wù)的訪問(wèn)授權(quán)，只單個(gè)消費(fèi)方受影響
- 服務(wù)熔斷：直接對(duì)該服務(wù)進(jìn)行下線處理，或?qū)⒃摲?wù)狀態(tài)設(shè)置為不可用，所有消費(fèi)方受影響
其次，對(duì)于服務(wù)流控我們需要設(shè)置具體要監(jiān)控哪些指標(biāo)，注意這個(gè)指標(biāo)監(jiān)控是在單位時(shí)間里面的監(jiān)控指標(biāo)，即計(jì)算在單位時(shí)間的累計(jì)數(shù)據(jù)，當(dāng)觸發(fā)后即進(jìn)行流控。具體包括：
- 運(yùn)行次數(shù)：?jiǎn)挝粫r(shí)間里面的運(yùn)行次數(shù)累計(jì)，比如一個(gè)消費(fèi)方大并發(fā)調(diào)用，可以限流
- 業(yè)務(wù)系統(tǒng)異常次數(shù)：源服務(wù)出現(xiàn)異常的次數(shù)，也可以考慮異常占比率
- 系統(tǒng)異常：即出現(xiàn)系統(tǒng)級(jí)異常次數(shù)，本身包括Token失效，也包括ESB總線本身故障
- 報(bào)文量：即單位時(shí)間內(nèi)傳輸?shù)膱?bào)文量達(dá)到某個(gè)值，考慮是輸入+輸出報(bào)文量和的累計(jì)
對(duì)于運(yùn)行時(shí)長(zhǎng)更多是預(yù)警，而實(shí)際上直接限流和熔斷不現(xiàn)實(shí)。因此主要的流控指標(biāo)就是上面這些，基于以上指標(biāo)本身又有兩種操作，一種是限流，一種是整個(gè)服務(wù)熔斷。而實(shí)際上可以看到。
- 限流：運(yùn)行次數(shù)，Token失效，報(bào)文量
- 熔斷：業(yè)務(wù)系統(tǒng)異常，系統(tǒng)ESB本身故障異常
限流熔斷解除，最后，在還需要考慮的就是在實(shí)施了限流和熔斷后如何解除的問(wèn)題，在實(shí)際實(shí)現(xiàn)的時(shí)候，對(duì)于限流可以在規(guī)定時(shí)間后自動(dòng)解除，而對(duì)于熔斷最好還是人工恢復(fù)解除。
比如對(duì)CRM系統(tǒng)訪問(wèn)MDM的查詢供應(yīng)商服務(wù)進(jìn)行限流后，在啟動(dòng)限流后的某個(gè)時(shí)間間隔后，比如2小時(shí)后，可以自動(dòng)進(jìn)行解除。這個(gè)時(shí)間間隔可以靈活配置。
而對(duì)于類(lèi)似Kong網(wǎng)關(guān)當(dāng)前提供的限流相對(duì)來(lái)說(shuō)還是比較弱，即主要是控制某一個(gè)API接口服務(wù)在單位時(shí)間內(nèi)最多只能夠調(diào)用多少次，如果超過(guò)這個(gè)次數(shù)那么網(wǎng)關(guān)就直接拒絕訪問(wèn)并返回錯(cuò)誤提示信息。
而在前面我講限流和流量控制的時(shí)候經(jīng)常說(shuō)到，就是限流實(shí)際上一個(gè)是根據(jù)服務(wù)調(diào)用次數(shù)，一個(gè)是根據(jù)服務(wù)調(diào)用數(shù)據(jù)量，需要在這兩個(gè)方面進(jìn)行限流。而里面更加重要的反而是數(shù)據(jù)量的限流，因?yàn)榇髷?shù)據(jù)量報(bào)文往往更加容易造成內(nèi)存溢出異常。
API全生命周期管理包括了API接口的定義，API快速開(kāi)發(fā)的支持，API的注冊(cè)和接入，API模擬測(cè)試和自動(dòng)化測(cè)試，API文檔自動(dòng)生成，API版本和變更管理，API下線，API監(jiān)控運(yùn)維等一系列的功能，本部分后續(xù)單獨(dú)文章說(shuō)明。
遺漏了什么？
基于上面的例子來(lái)分析，我們整體感覺(jué)進(jìn)行微服務(wù)架構(gòu)設(shè)計(jì)和開(kāi)發(fā)并不困難。但是如果站在整體企業(yè)應(yīng)用架構(gòu)規(guī)劃視角來(lái)看，你會(huì)發(fā)現(xiàn)有內(nèi)容遺漏，即技術(shù)平臺(tái)建設(shè)。
這也是我們經(jīng)常在強(qiáng)調(diào)的，共性技術(shù)平臺(tái)能力下沉是進(jìn)行微服務(wù)開(kāi)發(fā)的基礎(chǔ)。
還是以上面的例子來(lái)進(jìn)一步分析。
四個(gè)模塊都需要用到系統(tǒng)管理和工作流引擎，那么我們?cè)谶M(jìn)行微服務(wù)拆分后，不可能在每個(gè)微服務(wù)里面還各自含有相同的4A系統(tǒng)管理和流程引擎等共性技術(shù)能力。
即共性技術(shù)能力下沉，然后共性技術(shù)服務(wù)能力給微服務(wù)使用是必須的。
對(duì)于系統(tǒng)管理和流程引擎本身也是一個(gè)或二個(gè)獨(dú)立建設(shè)的微服務(wù)。
企業(yè)要進(jìn)行微服務(wù)架構(gòu)規(guī)劃和建設(shè)，那么最基礎(chǔ)的技術(shù)平臺(tái)規(guī)劃建設(shè)，將共性技術(shù)能力從傳統(tǒng)遺留系統(tǒng)移出，作為微服務(wù)功能模塊單獨(dú)建設(shè)并能力共享，是基礎(chǔ)的基礎(chǔ)。
企業(yè)核心技術(shù)中臺(tái)能力支撐微服務(wù)
微服務(wù)架構(gòu)思想實(shí)際上是包含了平臺(tái)+應(yīng)用思想，業(yè)務(wù)組件化服務(wù)化思想，SOA和云思想，包括當(dāng)前主流的DevOps思想的一個(gè)融合，而不僅僅是簡(jiǎn)單的微服務(wù)架構(gòu)。
因此企業(yè)在轉(zhuǎn)型到微服務(wù)架構(gòu)時(shí)候必須重新規(guī)劃和建設(shè)技術(shù)中臺(tái)能力，包括前面的遺留問(wèn)題分析我們也看到共性技術(shù)能力下沉是微服務(wù)建設(shè)的基礎(chǔ)。共性技術(shù)能力下沉后，微服務(wù)才能夠只關(guān)心業(yè)務(wù)而更加輕量。
首先我們對(duì)整體規(guī)劃建設(shè)進(jìn)行拆分，主要應(yīng)該包括以下關(guān)鍵的建設(shè)任務(wù)和內(nèi)容：
底層私有云IaaS平臺(tái)建設(shè)
在建設(shè)時(shí)候可以基于IaaS資源池進(jìn)行并盡量去IOE架構(gòu)。當(dāng)前實(shí)際上對(duì)于數(shù)據(jù)庫(kù)仍然會(huì)涉及到部分的Oracle數(shù)據(jù)庫(kù)和集中存儲(chǔ)，企業(yè)在選型和規(guī)劃的時(shí)候要考慮去掉這部分潛在風(fēng)險(xiǎn)。
服務(wù)器資源可以考慮全部采用X86服務(wù)器并進(jìn)行虛擬化，提供虛擬機(jī)資源作為計(jì)算能力。
容器化PaaS平臺(tái)建設(shè)
對(duì)于PaaS平臺(tái)建設(shè)當(dāng)前可以基于輕量的Docker容器進(jìn)行，并通過(guò)Kubernetes進(jìn)行資源管理和動(dòng)態(tài)調(diào)度。而如果規(guī)劃建設(shè)DevOps支撐平臺(tái)，即在DevOps平臺(tái)建設(shè)過(guò)程中統(tǒng)一建設(shè)容器化PaaS平臺(tái)，當(dāng)然在DevOps平臺(tái)中會(huì)進(jìn)一步實(shí)現(xiàn)了持續(xù)集成和流水線作業(yè)能力，實(shí)現(xiàn)開(kāi)發(fā)，運(yùn)行和后期運(yùn)維監(jiān)控的一體化管理。
微服務(wù)開(kāi)發(fā)框架和環(huán)境
在微服務(wù)架構(gòu)實(shí)施中，還有一個(gè)重點(diǎn)就是制定微服務(wù)架構(gòu)開(kāi)發(fā)框架，標(biāo)準(zhǔn)和規(guī)范體系，以指導(dǎo)后續(xù)開(kāi)發(fā)廠商按照統(tǒng)一的標(biāo)準(zhǔn)方法、工具和流程進(jìn)行微服務(wù)組件模塊和接口服務(wù)的開(kāi)發(fā)，確保開(kāi)發(fā)標(biāo)準(zhǔn)和規(guī)范一致性，也進(jìn)一步確保了后續(xù)多個(gè)微服務(wù)模塊在集成的時(shí)候不會(huì)出現(xiàn)問(wèn)題。
把這些都談后，再轉(zhuǎn)回談需要統(tǒng)一建設(shè)的技術(shù)平臺(tái)部分：
4A平臺(tái)和系統(tǒng)管理
這個(gè)是必須建設(shè)的內(nèi)容，不僅僅是實(shí)現(xiàn)統(tǒng)一用戶，統(tǒng)一認(rèn)證和鑒權(quán)，統(tǒng)一組織，統(tǒng)一審計(jì)等內(nèi)容。在微服務(wù)架構(gòu)下，4A平臺(tái)需進(jìn)一步擴(kuò)展傳統(tǒng)業(yè)務(wù)系統(tǒng)中系統(tǒng)管理模塊的內(nèi)容，即能夠?qū)崿F(xiàn)到微服務(wù)模塊內(nèi)部的功能菜單和按鈕級(jí)的操作授權(quán)，同時(shí)能夠?qū)崿F(xiàn)靈活定義的數(shù)據(jù)級(jí)授權(quán)和配置。
公共流程平臺(tái)
這個(gè)公共流程平臺(tái)也是必須，實(shí)現(xiàn)統(tǒng)一的類(lèi)似內(nèi)部多租戶的流程引擎，實(shí)現(xiàn)流程的設(shè)計(jì)建模，運(yùn)行，監(jiān)控的全部統(tǒng)一化。各個(gè)業(yè)務(wù)組件模塊僅僅是使用流程平臺(tái)提供的能力。
技術(shù)服務(wù)平臺(tái)
這個(gè)實(shí)際涉及到消息，緩存，文件，任務(wù)，日志，通知，分布式存儲(chǔ)等諸多技術(shù)服務(wù)能力，可以根據(jù)企業(yè)需要來(lái)確定哪些要單獨(dú)實(shí)現(xiàn)為獨(dú)立的技術(shù)服務(wù)能力開(kāi)放提供。這個(gè)沒(méi)有明確的要求，但是根據(jù)實(shí)際項(xiàng)目實(shí)踐來(lái)看，類(lèi)似發(fā)送短信郵件的通知類(lèi)服務(wù)，文件存儲(chǔ)類(lèi)服務(wù)往往都是必須要規(guī)劃建設(shè)的。
監(jiān)控運(yùn)維平臺(tái)
這個(gè)平臺(tái)實(shí)際上包括了傳統(tǒng)的IT網(wǎng)管監(jiān)控，同時(shí)還包括了當(dāng)前的APM業(yè)務(wù)性能監(jiān)控兩個(gè)方面的內(nèi)容。同時(shí)兩者內(nèi)容本身又相互集成和融合。由于采用了容器化PaaS，實(shí)際上微服務(wù)開(kāi)發(fā)商對(duì)底層資源的情況并不清楚，因此更加需要這樣一個(gè)監(jiān)控運(yùn)維平臺(tái)能夠同時(shí)監(jiān)控到業(yè)務(wù)性能和資源層性能，并實(shí)時(shí)預(yù)警。
微服務(wù)架構(gòu)設(shè)計(jì)還有哪些關(guān)鍵點(diǎn)？
對(duì)于微服務(wù)架構(gòu)設(shè)計(jì)，要明白遠(yuǎn)遠(yuǎn)不是采用了類(lèi)似SpringCloud微服務(wù)開(kāi)發(fā)框架，或者說(shuō)采用了Http Rest接口服務(wù)就是微服務(wù)架構(gòu)，更加重要的還是業(yè)務(wù)能力的組件化或者叫微服務(wù)模塊化，組件能力的接口服務(wù)化。對(duì)于微服務(wù)架構(gòu)設(shè)計(jì)，可以思考的關(guān)鍵點(diǎn)如下：
基于業(yè)務(wù)交互分析劃分合理的微服務(wù)組件模塊
微服務(wù)模塊劃分是否合理將直接影響到后續(xù)微服務(wù)模塊的開(kāi)發(fā)集成和實(shí)施難度。
看到很多例子就是一個(gè)本來(lái)很小的業(yè)務(wù)系統(tǒng)居然會(huì)劃分出20多個(gè)微服務(wù)模塊，每個(gè)模塊全部采用單獨(dú)的容器部署。這個(gè)在互聯(lián)網(wǎng)應(yīng)用里面可能適合，但是在企業(yè)微服務(wù)架構(gòu)轉(zhuǎn)型里面一定不適合。
模塊劃分越細(xì)，模塊間接口交互和集成就越復(fù)雜，后續(xù)微服務(wù)的運(yùn)維管控治理就越難。
如何劃分？一個(gè)傳統(tǒng)的業(yè)務(wù)系統(tǒng)建議最多拆分為6到8個(gè)微服務(wù)組件，對(duì)于縱向流程工單驅(qū)動(dòng)型由于本身耦合小可以劃分的更細(xì)，但是其它類(lèi)似核心業(yè)務(wù)數(shù)據(jù)驅(qū)動(dòng)型都不要?jiǎng)澐痔?xì)。
面向接口開(kāi)發(fā)同時(shí)識(shí)別粗粒度的服務(wù)接口
微服務(wù)在架構(gòu)設(shè)計(jì)階段除了技術(shù)架構(gòu)外核心就是兩個(gè)事情
- 一個(gè)就是劃分微服務(wù)模塊
- 一個(gè)就是識(shí)別和定義粗粒度的微服務(wù)API接口
注意微服務(wù)模塊間的接口要提前進(jìn)行識(shí)別和定義，從頂向下面向接口開(kāi)發(fā)，這本身也是傳統(tǒng)架構(gòu)設(shè)計(jì)就遵循的原則。一定不能是一開(kāi)始不定義接口，后續(xù)各個(gè)模塊開(kāi)發(fā)到哪里了發(fā)現(xiàn)接口缺少再臨時(shí)倉(cāng)促定義，這個(gè)帶來(lái)的最大問(wèn)題就是接口粒度管理失控，后續(xù)運(yùn)維也失控，導(dǎo)致大量的接口重復(fù)定義等。
如果你是采用Http Rest接口，那么你更要了解面向資源設(shè)計(jì)和領(lǐng)域建模的概念，怎樣定義才算得上是面向資源的，而不是簡(jiǎn)單的隨便定義Http API操作。
在架構(gòu)設(shè)計(jì)階段就完成數(shù)據(jù)庫(kù)拆分設(shè)計(jì)
注意在微服務(wù)架構(gòu)設(shè)計(jì)階段一開(kāi)始就應(yīng)該完成數(shù)據(jù)庫(kù)拆分，每個(gè)微服務(wù)模塊對(duì)應(yīng)獨(dú)立的數(shù)據(jù)庫(kù)。
一定要注意微服務(wù)一定不是簡(jiǎn)單的應(yīng)用組件拆分，而是包括了后端的數(shù)據(jù)庫(kù)也有拆分，這樣才是完整意義上的微服務(wù)架構(gòu)。同時(shí)拆分后的數(shù)據(jù)庫(kù)間不應(yīng)該有交互和集成，所有的交互和集成都應(yīng)該通過(guò)應(yīng)用組件層的API接口服務(wù)進(jìn)行。只有這樣才是完整意義上的微服務(wù)架構(gòu)。
搞清微服務(wù)注冊(cè)中心和微服務(wù)網(wǎng)關(guān)的區(qū)別并按需使用
在一個(gè)完整的微服務(wù)架構(gòu)里面涉及到微服務(wù)注冊(cè)中心和微服務(wù)網(wǎng)關(guān)，務(wù)必注意到兩個(gè)組件的區(qū)別并按需使用。簡(jiǎn)單來(lái)說(shuō)就是一個(gè)微服務(wù)架構(gòu)應(yīng)用內(nèi)部所有的微服務(wù)模塊組件之間的接口交互都只需要通過(guò)注冊(cè)中心來(lái)完成即可，這種方式是性能最佳，去中心化的方式。當(dāng)一個(gè)微服務(wù)架構(gòu)應(yīng)用需要和外部交互，或者說(shuō)需要開(kāi)放能力給外部業(yè)務(wù)系統(tǒng)使用的時(shí)候才需要將API接口服務(wù)接入到微服務(wù)網(wǎng)關(guān)或API網(wǎng)關(guān)。
做好開(kāi)發(fā)團(tuán)隊(duì)劃分和微服務(wù)模塊劃分之間的匹配工作
在微服務(wù)架構(gòu)設(shè)計(jì)做好了微服務(wù)模塊劃分后，另外一個(gè)重點(diǎn)工作就是做好開(kāi)發(fā)團(tuán)隊(duì)的劃分和匹配工作。按道理這個(gè)不屬于微服務(wù)架構(gòu)設(shè)計(jì)的內(nèi)容，但是屬于整個(gè)研發(fā)過(guò)程和項(xiàng)目管理的內(nèi)容。
開(kāi)發(fā)團(tuán)隊(duì)的劃分基本要做到和微服務(wù)模塊劃分匹配，能夠完全隔離和松耦合是最好。
要明白，如果一個(gè)人負(fù)責(zé)多個(gè)微服務(wù)模塊，那我們?cè)瓉?lái)定義的微服務(wù)模塊間的接口規(guī)則，交互規(guī)則，技術(shù)標(biāo)準(zhǔn)規(guī)范很難真正做到徹底執(zhí)行。
即多個(gè)微服務(wù)模塊間協(xié)同變成一個(gè)開(kāi)發(fā)人員內(nèi)部管理的事情，那么開(kāi)發(fā)就容易怎么方便怎么來(lái)，而忽視了關(guān)鍵的架構(gòu)規(guī)則和約束。也就是到最后你會(huì)發(fā)現(xiàn)，分配給一個(gè)人負(fù)責(zé)的多個(gè)微服務(wù)模塊，本身一開(kāi)始是松耦合的設(shè)計(jì)，但是最后完全變樣為難以拆分的緊耦合關(guān)系。
面向產(chǎn)品集成和持續(xù)集成而設(shè)計(jì)
在微服務(wù)架構(gòu)設(shè)計(jì)的時(shí)候，必須要考慮到產(chǎn)品集成和持續(xù)集成。對(duì)于持續(xù)集成可以參考標(biāo)準(zhǔn)的持續(xù)集成方法，也可以參考DevOps標(biāo)準(zhǔn)過(guò)程體系以實(shí)現(xiàn)持續(xù)集成和持續(xù)交付，當(dāng)然在整個(gè)過(guò)程中可以和容器化PaaS平臺(tái)融合，進(jìn)一步實(shí)現(xiàn)持續(xù)交付過(guò)程的自動(dòng)化。
另外在整個(gè)架構(gòu)設(shè)計(jì)中的模塊劃分和接口設(shè)計(jì)的時(shí)候，還需要考慮到整個(gè)產(chǎn)品集成順序，即一個(gè)大系統(tǒng)劃分為了多個(gè)微服務(wù)模塊，他們之間的構(gòu)建順序，集成順序究竟是如何的？為了更好的實(shí)現(xiàn)產(chǎn)品集成，原則上應(yīng)該是基于完整的業(yè)務(wù)流生命周期，模塊之間更多的是由上游流程到下游流程進(jìn)行逐層集成，同時(shí)盡量要避免雙向集成導(dǎo)致后續(xù)集成測(cè)試很難進(jìn)行集成和組裝。
對(duì)于DevOps研發(fā)運(yùn)維一體化，持續(xù)集成和持續(xù)交付，以及DevOps過(guò)程支撐平臺(tái)如何和微服務(wù)架構(gòu)設(shè)計(jì)開(kāi)發(fā)，研發(fā)過(guò)程管理更好的協(xié)同，我后面會(huì)專(zhuān)門(mén)再寫(xiě)一篇文章進(jìn)行描述。
面向業(yè)務(wù)和應(yīng)用監(jiān)控運(yùn)維而設(shè)計(jì)
要注意在微服務(wù)架構(gòu)下實(shí)際上是獨(dú)立自治的微服務(wù)模塊變多，接口變多，集成關(guān)系更加復(fù)雜，這些都直接導(dǎo)致了后續(xù)業(yè)務(wù)和應(yīng)用監(jiān)控更加復(fù)雜。很多企業(yè)在進(jìn)行微服務(wù)架構(gòu)轉(zhuǎn)型的時(shí)候，由于后期的自動(dòng)化監(jiān)控運(yùn)維能力跟不上導(dǎo)致最終轉(zhuǎn)型中出現(xiàn)大量的問(wèn)題無(wú)法解決，這些也是在架構(gòu)設(shè)計(jì)時(shí)要考慮的。
即在進(jìn)行微服務(wù)架構(gòu)設(shè)計(jì)的時(shí)候，要基于DevOps的思想，將很多可監(jiān)控，可運(yùn)維需求作為關(guān)鍵的非功能性需求納入到架構(gòu)設(shè)計(jì)中，在微服務(wù)模塊間的接口服務(wù)設(shè)計(jì)的時(shí)候都需要加入這些設(shè)計(jì)原則和關(guān)鍵屬性，以方便后續(xù)進(jìn)行業(yè)務(wù)監(jiān)控和服務(wù)鏈監(jiān)控，同時(shí)在業(yè)務(wù)出現(xiàn)問(wèn)題的時(shí)候能夠快速定位。
