從微服務基本概念到核心元件-透過一個例項來講解和分析

觸發小時級流控permits:5是什麼意思

作者：人月神話，新浪部落格同名

簡介：多年SOA規劃建設，私有云PaaS平臺架構設計經驗，長期從事一線專案實踐

今天我準備重新講解下微服務的基礎概念，關鍵元件和元件間關係等核心邏輯。這篇文章我會對我原來寫過的微服務類文章內容進行大量重構，去掉裡面比較技術化的內容，而轉為一種非開發人員也容易理解的方式來講解。

概念模型為何如此重要？

最近我思考比較多的一個詞就是概念模型，不管新知識的學習，新事物的認知，新領域的快速切入還是面對新問題的快速分析和解決，認識和理解概念模型都是相當重要的一個步驟。

概念模型本身是

我們認知事物核心框架和基礎邏輯的自我可理解的最簡模型

。

這裡面有幾個關鍵點，

其一是對事物形成基礎認知，其二是最簡和最容易模型，其三則是對我們自己最佳適用的模型

。

每個人的知識積累和經驗不同，最適用於他們的概念模型就是不一樣的。因此對於有理論和實踐經驗積累的人，你可能並不需要用簡單的方式闡述事物，有時候連比喻都不需要，而對於初次接觸陌生領域的人來說，那麼對核心邏輯的形象比喻就顯得相當重要了。

一個事物只有在自己腦海裡面形成了初步的概念模型的時候，才能夠算對該事物有了初步的認識，接下來才談得上如何層層剝繭和分解，深入到內部機理進行深入瞭解。這和我們在學習方法和模式裡面談到一開始的學習應該是不求甚解是一個道理。

只有搭建了大框架，理清主脈絡，你才可能有目標和有興趣深入。

但是實際我們仍然看到，包括很多人員頭腦裡面仍然是採用了SpringCLoud框架，採用了Http Rest介面服務整合或API閘道器就是微服務了。而對微服務架構思想的本質並沒有形成完整的理解，這些都是我們在學習新知識，認識新事物時候必須要避免的。

從微服務基本定義說起

我們先看下當前網際網路上對微服務的主流定義。

微服務可以在“自己的程式”中執行，並透過“輕量級裝置與HTTP型API進行溝通”。關鍵在於該服務可以在自己的程式中執行。透過這一點我們就可以將服務公開與微服務架構（在現有系統中分佈一個API）區分開來。在服務公開中，許多服務都可以被內部獨立程序所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小程序範圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體程序。

微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那麼，我們就必須付出很多代價。

看完上面的圖後，估計還是很難真正抓住微服務的關鍵點。

在我很早就談到過，在理解和認識一個概念的時候，你一定要用和你已有的知識概念做對比，進行差異分析，你就很容易抓住要點在哪裡。

而要了解微服務一樣，你瞭解了和傳統單體應用的差別，基本微服務核心就瞭解了。簡單來說微服務本身就是將傳統的單體應用大拆小，然後透過一種輕量高效的標準介面進行協同的架構模式。

舉一個單體應用到微服務的例子說明

為了更好的解釋微服務，包括後面對微服務很多關鍵元件的解釋，我們需要準備一個業務系統功能常見來進行舉例說明，具體的背景如下。

當前我們準備構建一個SRM供應商關係管理業務系統，這個系統經過前期業務和需求分析，包括了供應商管理，物料管理，招投標，供應商績效評估四個功能模組。當然在構建整個系統的時候還有類似底層的系統管理，流程引擎等技術模組元件。

我們要構建的SRM系統就是典型的單體應用，那麼我們來看這個單體應用構建模式轉變到微服務構建模式後究竟帶來了哪些變化。如下圖，我們從開發態和執行態去分析。

從這個圖我們基本就把微服務核心的關鍵點看清楚了。即：

一個單體變多個微服務模組，而且從資料庫到邏輯層到前端完全獨立

微服務模組間透過Http Rest介面高效整合協同

各個微服務完全獨立部署，擴充套件的時候資料庫，叢集都單獨擴充套件

以上實際上就是我們經常談到的微服務區別於單體架構最關鍵的幾個點。在掌握了這個核心概念後你才清楚哪些不是微服務基本特徵。比如微服務必須容器化部署，沒有這個說法，微服務也可以傳統方式部署。還有就是微服務開發必須前後端分離，實際上也沒有這個說法，前後端不分離只要微服務間完全縱向解耦就是微服務架構。

基於SOA和中臺思想對上面拆分進行重構

如果按照上面的模組拆分進行獨立的設計，開發和部署，完全是符合微服務架構的思想的。但是是否符合SOA和中臺能力共享思想呢？

將資料提供和形成資料的流程分開形成分層

我再強調下SOA和中臺裡面的一個關鍵思想，即：

你要去找到你的核心業務能力提供，而不是馬上去關心你的能力或最終資料是如何形成的。能力最終提供屬於中臺能力，能力如何形成的可以屬於前臺應用能力。

比如上面談到的供應商，物料兩個微服務，我們發現核心就是提供可共享的供應商和物料資料能力。但是這兩個資料如何形成的？ 一方面是可以直接在後臺錄入，一個方面還是可以是供應商自己進行供應商認證申請，我們稽核通過後進入到供應商庫。

那麼供應商資料本身屬於中臺能力，供應商資訊的申請流程可屬於前臺應用功能。

是否嚴格的邏輯層和資料庫1對1對應？

這個是我今天想拿出來討論的第二個問題，即很多人在進行微服務架構設計的時候往往走兩個極端。或者是資料庫不拆分就一個大庫，或者就是資料庫完全按微服務1對1拆分。那麼我們上層規劃的20個微服務，是否就一定有20個對應的資料庫例項ID？

在資料庫拆分細一定帶來我們在設計實現時候兩個問題

其一是我們常說的分散式事務處理問題，有用庫拆分無法再用資料庫層事務

其二是原來一個關聯sql搞定的事情，全部變成了邏輯層多次服務呼叫後進行服務組裝

以上兩個問題不僅僅是帶來的開發工作量，而且更重要的是影響到資料一致性。

正是由於這個原因，我們提出一個

微服務集

的概念。

微服務集的意思可以理解為邏輯層仍然按照標準的微服務要求去構建，每個邏輯層都可以編譯可獨立部署的Jar包。但是對應微服務集裡面的多個微服務可共用一個數據庫。

而基於上面場景，供應商和物料本身關聯業務場景相當多，放在一個數據庫顯然是更加適合。經過重新思考後，我們整體的邏輯架構變化為：

基於實際業務場景驅動，對微服務初步設計重構後體現為兩點

其一是供應商和物料合併為一個數據庫而不進行拆分

其二是邏輯層的微服務基於複用分層思路拆分為三個微服務模組

拆分後的三個微服務如何互動？

在完成基本的拆分後，我們來看拆分完成後的三個微服務模組如何互動。

如果我們仍然把SRM看成一個大的應用，並且SRM系統的能力介面不需要對外暴露，不需要網際網路APP應用協同的時候。在這種情況下，走微服務架構體系裡面的服務註冊中心來完成介面互動。簡單來說就是微服務間的介面消費呼叫是一種去中心化的架構模式。

我們以供應商申請微服務，需要在申請稽核通過後，呼叫供應商管理提供的資訊匯入API介面將資料匯入到供應商管理模組中來舉例說明。

從圖裡面可以看到整個過程簡單的三個關鍵步驟。

第一，供應商管理將實現的API介面註冊到註冊中心

第二，申請模組從註冊中心獲取介面的地址資訊

第三，根據拿到的地址資訊直接發起對介面的點對點呼叫

為何叫去中心化？

從上圖整個過程可以看到，整個服務呼叫只有獲取地址會和資料中心發生關係，實際獲取到地址後即是介面的點對點呼叫，這個時候介面的資料流完全不經過註冊中心。

那麼獲取地址的時候註冊中心宕機了怎麼辦？

所以可以看到一般來說，獲取的地址資訊都會在本地微服務模組快取，後續在呼叫的時候如果註冊中心有故障，那麼就訪問本地快取的地址資訊。對於這點本身又需要稍微展開下分兩個實現方式來進一步解釋下。

其一，負載均衡的能力在註冊中心

在這種情況下，我們每次消費介面，都必須呼叫註冊中心服務來獲取最終輪詢出來的目標地址資訊。只有在註冊中心不可用情況下，我們才訪問本地快取。

其二，負載均衡的能力在本地微服務

在這種情況下，只需要獲取註冊中心的地址資訊清單，同時在地址狀態變更的時候被動獲取註冊中心的變更訊息推送。那麼後續所有介面訪問都和註冊中心無關。

微服務間互動是否一定是Http Rest介面？

多個微服務如果不對外提供能力，僅僅是內部介面互動，那麼Http Rest介面並不是必須的。比如我們常說的Dubbo框架，可以採用更加高效的RPC介面進行互動，而且底層還可以走TCP協議。

但是一涉及到對外能力提供，涉及到主動網路防火牆問題時，一般只能走Http介面互動。

當然你可以理解為，同樣一個介面實現，我們可以在內部互動的時候走高效的RPC介面模式，而僅僅需要對外暴露服務能力的時候將其釋出為Http Rest介面。

從服務註冊中心到API閘道器

對於一個應用裡面的多個微服務需要統一對外暴露介面能力的時候，這個時候就涉及到OpenAPI能力開放平臺或API閘道器，那麼首先來解釋下API閘道器。

如何給API閘道器一個定義？

簡單來說API閘道器就是將所有的微服務提供的API介面服務能力全部匯聚進來，統一接入進行管理，也正是透過統一攔截，就可以透過閘道器實現對API介面的安全，日誌，限流熔斷等共性需求。如果再簡單說下，透過閘道器實現了幾個關鍵能力。

內部的微服務對外部訪問來說位置透明，外部應用只需和閘道器互動

統一攔截介面服務，實現安全，日誌，限流熔斷等需求

從這裡，我們就可以看到API閘道器和傳統架構裡面的ESB匯流排是類似的，這些關鍵能力本身也是ESB服務匯流排的能力，但是ESB服務匯流排由於要考慮遺留系統的接入，因此增加了類似遺留系統適配，協議轉換，複雜資料對映等能力。

微服務架構不再需要ESB，並且一定是去中心化的？

這是必須要搞清楚的一個問題。

首先看下微服務架構裡面確實不需要傳統ESB，但是需要一個ESB的輕量實現，即我們說的API閘道器。因為微服務架構裡面都是標準的Http Rest介面，不再存在複雜的遺留介面適配，複雜協議轉換等問題。但是我們常說的介面服務代理，統一的安全，日誌，流控功能仍然需要。

同時

微服務架構內部各個微服務模組間本身是去中心化的，但是當微服務架構裡面各個微服務需要對外提供介面服務能力給外部應用使用時候，外部應用和微服務間由於增加了API閘道器又變成了一箇中心化的架構

。所以不要一提到微服務就去中心化，這個理解本身也是不對的。

對於API閘道器來說，核心就是實現兩類能力，

一個是對API全生命週期管理能力，包括了API介面的註冊，接入，釋出，測試，變更和版本管理，下線等。另外一個關鍵能力就是我們常說的安全，日誌，流控方面的能力。

而這些能力最常見的實現方式就是透過外掛進行攔截處理，如下：

如上圖，API閘道器裡面的關鍵物件注意包括了接入系統（微服務），消費系統，註冊接入的API介面，釋出的Proxy API介面，在代理和原始服務間有一個路由物件。只要有這些最基本的物件就可以實現最簡單場景下的服務接入。

而其它所有的擴充套件可以看到都應該基於外掛式方式的擴充套件，這些外掛包括了

安全認證類外掛，流量控制類外掛，日誌監控類外掛，轉換類外掛。

任何一個API介面和外掛之間是一種多對多的關係。即一個API介面可以被作用多個外掛，同時一個外掛本身又可以應用在多個API介面上。外掛本身就類似於AOP橫切，對服務請求訊息的輸入和輸出進行攔截，在攔截到資訊後進行相關的安全或其他管控處理。

當然外掛本身一定會損耗效能，在實現的時候需要考慮對服務執行資料，執行統計資料的快取，特別是對於流控的實時計算過程。

業務場景需求引入閘道器

還是基於上面的案例，供應商申請流程我們希望開發一個APP應用給使用者自己申請。這個APP供應商在公網就可以正常訪問和登入使用。

前面談到，API閘道器使用重要場景就是需要對外提供服務能力。這個對外可能是和外部其它系統整合，也可以是我們的應用本身會開發外部網際網路使用的APP。

在這個時候API閘道器引入就變成了必須。

API閘道器本身也實現了外部應用和我們內部微服務間的安全隔離，比如我們把API閘道器還可以部署到整個基礎設施架構的DMZ區等。

是否可以不用API閘道器？

當然，你也可以不用類似Kong等API閘道器產品，那麼這個時候我們常說的一些共性的安全，日誌，限流熔斷能力無法實現。但是

最基本的代理路由轉發能力是必須的，因此你在前期可以使用類似Ngnix來實現請求轉發並替代API閘道器的使用

。

API閘道器的幾個關鍵功能分析

下面來看下API閘道器實現的幾個關鍵功能。其中附帶介紹下Kong閘道器的一些關鍵能力。

日誌攔截和記錄

對於日誌攔截和記錄是最常見的一個API閘道器功能，但是類似開源的API閘道器產品往往也僅僅是提供日誌輸入介面，如果需要對日誌進行集中化儲存和日誌查詢分析，仍然需要自己開發相關的功能來完成。

日誌攔截簡單來說三點

其一：首先是透過外掛攔截到輸入和輸出訊息資訊

其二：將資訊寫入非同步寫入到訊息中介軟體中

其三：透過程式從訊息中介軟體中獲取訊息，再將日誌持久化到資料庫或分散式物件儲存

如果整個微服務裡面日誌產生量大，而且對歷史日誌的查詢時間段也要求較長的情況下，建議將日誌存在到分散式檔案儲存或分散式物件儲存中。

可以看到日誌資訊本身複合

服務例項ID+例項報文體

這種物件儲存結構。

比如我們可以基於Kong閘道器的擴充套件能力來自己開發日誌記錄儲存和查詢外掛，對於Kong閘道器來說外掛的定製化開發能力相當強。

一個是sysLog在配置後可以直接將Kong產生的日誌寫入到應用伺服器的系統日誌檔案中。如果配置了file-log則是單獨寫入到你指定的file檔案中。對於http-log則是對於http服務請求，可以詳細的記錄請求的輸入和輸出報文資訊，但是具體是記錄到哪裡，需要透過config。http_endpoint配置。

安全功能

對於安全功能我們先簡單談下實際需要哪些安全能力。

最常見的就是介面服務訪問控制安全能力，即API閘道器暴露的一個介面，必須透過安全認證通過後才能夠訪問介面。供應商資訊匯入API比如你授權給供應商申請流程微服務模組（SUP）使用。那麼可以看到常見的一些方法。

其一：分配給SUP一個靜態的使用者名稱和密碼，呼叫服務的時候基於這個進行驗證

其二：對SUP系統的IP地址進行配置，只有授權的IP地址能夠訪問

但是對於方法1容易出現使用者名稱密碼洩漏或被擷取；第2種方法容易出現IP偽造，或者對於容器雲環境IP本身就是不斷動態變化你很難去控制。

因此在這種常見下，我們出現了動態Token安全的處理方法。

簡單來說就是你每次呼叫服務前，都先向API閘道器申請一個動態申請的Token碼，然後在呼叫服務的時候連帶上這個token碼一起傳送過去進行校驗，只要校驗透過才允許訪問服務。

當然對於開源各類API閘道器產品基本也提供常見的各類安全能力。

比如當前閘道器提供basic-auth，key-auth、ldap-auth，hmac-auth多種認證外掛。

限流熔斷功能

對限流熔斷的理解，首先本文談到的服務限流和熔斷，和常規我們說的限流和熔斷有區別。

具體說明為：

服務限流：取消某個消費方對某個服務的訪問授權，只單個消費方受影響

服務熔斷：直接對該服務進行下線處理，或將該服務狀態設定為不可用，所有消費方受影響

其次，對於服務流控我們需要設定具體要監控哪些指標，注意這個指標監控是在單位時間裡面的監控指標，即計算在單位時間的累計資料，當觸發後即進行流控。具體包括：

執行次數：單位時間裡面的執行次數累計，比如一個消費方大併發呼叫，可以限流

業務系統異常次數：源服務出現異常的次數，也可以考慮異常佔比率

系統異常：即出現系統級異常次數，本身包括Token失效，也包括ESB匯流排本身故障

報文量：即單位時間內傳輸的報文量達到某個值，考慮是輸入+輸出報文量和的累計

對於執行時長更多是預警，而實際上直接限流和熔斷不現實。因此主要的流控指標就是上面這些，基於以上指標本身又有兩種操作，一種是限流，一種是整個服務熔斷。而實際上可以看到。

限流：執行次數，Token失效，報文量

熔斷：業務系統異常，系統ESB本身故障異常

限流熔斷解除，最後，在還需要考慮的就是在實施了限流和熔斷後如何解除的問題，在實際實現的時候，對於限流可以在規定時間後自動解除，而對於熔斷最好還是人工恢復解除。

比如對CRM系統訪問MDM的查詢供應商服務進行限流後，在啟動限流後的某個時間間隔後，比如2小時後，可以自動進行解除。這個時間間隔可以靈活配置。

而對於類似Kong閘道器當前提供的限流相對來說還是比較弱，即主要是控制某一個API介面服務在單位時間內最多隻能夠呼叫多少次，如果超過這個次數那麼閘道器就直接拒絕訪問並返回錯誤提示資訊。

而在前面我講限流和流量控制的時候經常說到，就是限流實際上一個是根據服務呼叫次數，一個是根據服務呼叫資料量，需要在這兩個方面進行限流。而裡面更加重要的反而是資料量的限流，因為大資料量報文往往更加容易造成記憶體溢位異常。

API全生命週期管理包括了API介面的定義，API快速開發的支援，API的註冊和接入，API模擬測試和自動化測試，API文件自動生成，API版本和變更管理，API下線，API監控運維等一系列的功能，本部分後續單獨文章說明。

遺漏了什麼？

基於上面的例子來分析，我們整體感覺進行微服務架構設計和開發並不困難。但是如果站在整體企業應用架構規劃視角來看，你會發現有內容遺漏，即技術平臺建設。

這也是我們經常在強調的，共性技術平臺能力下沉是進行微服務開發的基礎。

還是以上面的例子來進一步分析。

四個模組都需要用到系統管理和工作流引擎，那麼我們在進行微服務拆分後，不可能在每個微服務裡面還各自含有相同的4A系統管理和流程引擎等共性技術能力。

即

共性技術能力下沉，然後共性技術服務能力給微服務使用是必須的

。

對於系統管理和流程引擎本身也是一個或二個獨立建設的微服務。

企業要進行微服務架構規劃和建設，那麼最基礎的技術平臺規劃建設，將共性技術能力從傳統遺留系統移出，作為微服務功能模組單獨建設並能力共享，是基礎的基礎。

企業核心技術中臺能力支撐微服務

微服務架構思想實際上是包含了平臺+應用思想，業務元件化服務化思想，SOA和雲思想，包括當前主流的DevOps思想的一個融合，而不僅僅是簡單的微服務架構。

因此企業在轉型到微服務架構時候必須重新規劃和建設技術中臺能力，包括前面的遺留問題分析我們也看到共性技術能力下沉是微服務建設的基礎。

共性技術能力下沉後，微服務才能夠只關心業務而更加輕量。

首先我們對整體規劃建設進行拆分，主要應該包括以下關鍵的建設任務和內容：

底層私有云IaaS平臺建設

在建設時候可以基於IaaS資源池進行並儘量去IOE架構。當前實際上對於資料庫仍然會涉及到部分的Oracle資料庫和集中儲存，企業在選型和規劃的時候要考慮去掉這部分潛在風險。

伺服器資源可以考慮全部採用X86伺服器並進行虛擬化，提供虛擬機器資源作為計算能力。

容器化PaaS平臺建設

對於PaaS平臺建設當前可以基於輕量的Docker容器進行，並透過Kubernetes進行資源管理和動態排程。而如果規劃建設DevOps支撐平臺，即在DevOps平臺建設過程中統一建設容器化PaaS平臺，當然在DevOps平臺中會進一步實現了持續整合和流水線作業能力，實現開發，執行和後期運維監控的一體化管理。

微服務開發框架和環境

在微服務架構實施中，還有一個重點就是制定微服務架構開發框架，標準和規範體系，以指導後續開發廠商按照統一的標準方法、工具和流程進行微服務元件模組和介面服務的開發，確保開發標準和規範一致性，也進一步確保了後續多個微服務模組在整合的時候不會出現問題。

把這些都談後，再轉回談需要統一建設的技術平臺部分：

4A平臺和系統管理

這個是必須建設的內容，不僅僅是實現統一使用者，統一認證和鑑權，統一組織，統一審計等內容。在微服務架構下，4A平臺需進一步擴充套件傳統業務系統中系統管理模組的內容，即能夠實現到微服務模組內部的功能選單和按鈕級的操作授權，同時能夠實現靈活定義的資料級授權和配置。

公共流程平臺

這個公共流程平臺也是必須，實現統一的類似內部多租戶的流程引擎，實現流程的設計建模，執行，監控的全部統一化。各個業務元件模組僅僅是使用流程平臺提供的能力。

技術服務平臺

這個實際涉及到訊息，快取，檔案，任務，日誌，通知，分散式儲存等諸多技術服務能力，可以根據企業需要來確定哪些要單獨實現為獨立的技術服務能力開放提供。這個沒有明確的要求，但是根據實際專案實踐來看，類似傳送簡訊郵件的通知類服務，檔案儲存類服務往往都是必須要規劃建設的。

監控運維平臺

這個平臺實際上包括了傳統的IT網管監控，同時還包括了當前的APM業務效能監控兩個方面的內容。同時兩者內容本身又相互整合和融合。由於採用了容器化PaaS，實際上微服務開發商對底層資源的情況並不清楚，因此更加需要這樣一個監控運維平臺能夠同時監控到業務效能和資源層效能，並實時預警。

微服務架構設計還有哪些關鍵點？

對於微服務架構設計，要明白遠遠不是採用了類似SpringCloud微服務開發框架，或者說採用了Http Rest介面服務就是微服務架構，更加重要的還是業務能力的元件化或者叫微服務模組化，元件能力的介面服務化。對於微服務架構設計，可以思考的關鍵點如下：

基於業務互動分析劃分合理的微服務元件模組

微服務模組劃分是否合理將直接影響到後續微服務模組的開發整合和實施難度。

看到很多例子就是一個本來很小的業務系統居然會劃分出20多個微服務模組，每個模組全部採用單獨的容器部署。這個在網際網路應用裡面可能適合，但是在企業微服務架構轉型裡面一定不適合。

模組劃分越細，模組間介面互動和整合就越複雜，後續微服務的運維管控治理就越難。

如何劃分？一個傳統的業務系統建議最多拆分為6到8個微服務元件，對於縱向流程工單驅動型由於本身耦合小可以劃分的更細，但是其它類似核心業務資料驅動型都不要劃分太細。

面向介面開發同時識別粗粒度的服務介面

微服務在架構設計階段除了技術架構外核心就是兩個事情

一個就是劃分微服務模組

一個就是識別和定義粗粒度的微服務API介面

注意微服務模組間的介面要提前進行識別和定義，從頂向下面向介面開發，這本身也是傳統架構設計就遵循的原則。一定不能是一開始不定義介面，後續各個模組開發到哪裡了發現介面缺少再臨時倉促定義，這個帶來的最大問題就是介面粒度管理失控，後續運維也失控，導致大量的介面重複定義等。

如果你是採用Http Rest介面，那麼你更要了解面向資源設計和領域建模的概念，怎樣定義才算得上是面向資源的，而不是簡單的隨便定義Http API操作。

在架構設計階段就完成資料庫拆分設計

注意在微服務架構設計階段一開始就應該完成資料庫拆分，每個微服務模組對應獨立的資料庫。

一定要注意微服務一定不是簡單的應用元件拆分，而是包括了後端的資料庫也有拆分，這樣才是完整意義上的微服務架構。同時拆分後的資料庫間不應該有互動和整合，所有的互動和整合都應該透過應用元件層的API介面服務進行。只有這樣才是完整意義上的微服務架構。

搞清微服務註冊中心和微服務閘道器的區別並按需使用

在一個完整的微服務架構裡面涉及到微服務註冊中心和微服務閘道器，務必注意到兩個元件的區別並按需使用。簡單來說就是一個微服務架構應用內部所有的微服務模組元件之間的介面互動都只需要透過註冊中心來完成即可，這種方式是效能最佳，去中心化的方式。當一個微服務架構應用需要和外部互動，或者說需要開放能力給外部業務系統使用的時候才需要將API介面服務接入到微服務閘道器或API閘道器。

做好開發團隊劃分和微服務模組劃分之間的匹配工作

在微服務架構設計做好了微服務模組劃分後，另外一個重點工作就是做好開發團隊的劃分和匹配工作。按道理這個不屬於微服務架構設計的內容，但是屬於整個研發過程和專案管理的內容。

開發團隊的劃分基本要做到和微服務模組劃分匹配，能夠完全隔離和松耦合是最好。

要明白，如果一個人負責多個微服務模組，那我們原來定義的微服務模組間的介面規則，互動規則，技術標準規範很難真正做到徹底執行。

即多個微服務模組間協同變成一個開發人員內部管理的事情，那麼開發就容易怎麼方便怎麼來，而忽視了關鍵的架構規則和約束。也就是到最後你會發現，分配給一個人負責的多個微服務模組，本身一開始是松耦合的設計，但是最後完全變樣為難以拆分的緊耦合關係。

面向產品整合和持續整合而設計

在微服務架構設計的時候，必須要考慮到產品整合和持續整合。對於持續整合可以參考標準的持續整合方法，也可以參考DevOps標準過程體系以實現持續整合和持續交付，當然在整個過程中可以和容器化PaaS平臺融合，進一步實現持續交付過程的自動化。

另外在整個架構設計中的模組劃分和介面設計的時候，還需要考慮到整個產品整合順序，即一個大系統劃分為了多個微服務模組，他們之間的構建順序，整合順序究竟是如何的？為了更好的實現產品整合，原則上應該是基於完整的業務流生命週期，模組之間更多的是由上游流程到下游流程進行逐層整合，同時儘量要避免雙向整合導致後續整合測試很難進行整合和組裝。

對於DevOps研發運維一體化，持續整合和持續交付，以及DevOps過程支撐平臺如何和微服務架構設計開發，研發過程管理更好的協同，我後面會專門再寫一篇文章進行描述。

面向業務和應用監控運維而設計

要注意在微服務架構下實際上是獨立自治的微服務模組變多，介面變多，整合關係更加複雜，這些都直接導致了後續業務和應用監控更加複雜。很多企業在進行微服務架構轉型的時候，由於後期的自動化監控運維能力跟不上導致最終轉型中出現大量的問題無法解決，這些也是在架構設計時要考慮的。

即在進行微服務架構設計的時候，要基於DevOps的思想，將很多可監控，可運維需求作為關鍵的非功能性需求納入到架構設計中，在微服務模組間的介面服務設計的時候都需要加入這些設計原則和關鍵屬性，以方便後續進行業務監控和服務鏈監控，同時在業務出現問題的時候能夠快速定位。

歡迎關注

@人月聊IT

分享SOA，微服務，DevOps平臺規劃和建設。