高內聚、低耦合。
無縫的 api 整合。
為每一項服務分配唯一的資源標識。
實時流量管理。
最小化資料表，以優化載入。
通過內/外部 api，執行持續監控。
為每個微服務隔離資料的儲存。這對於限制資料的訪問和避免「服務的耦合」是非常有用的。 例如：基於使用者的分類資料，我們可以實施命令查詢的責任分離（command query responsibility segregation，cqrs）。
去中心化。設計微服務架構的首要原則是：將單體結構分解成獨立的多個實體，而這些實體就被稱為微服務。 這些微服務能夠獨立於其他的系統功能提供服務，使用者對它們採取的所有編輯、刪除、或在其他地方的使用，都不會影響到本系統的整體效能。
通過與 devops 的整合，實現持續交付。devops 的多技術互通與融合，比較適合於微服務架構。在設計微服務架構時，我們需要關注效能和系統效率的提公升，這正好契合了 devops 的更快交付出方案的理念。 相對於傳統的單體式設計，它更適合於部署性、可靠的和可擴充套件性的方案管理。
當然，相對於上述各項原則與優勢，微服務架構也有著一定的侷限性。不過好在我們擁有多種微服務的設計模式可供選擇，來實現自己的系統設計目標。下面讓我們來逐一進行討論。
高效的微服務架構必須能夠讓多個微服務實現有效的協作和同步執行。
由於會涉及到多種業務，我們有必要為終端使用者截獲輸出、並將其予以合併。
對於使用者來說，如果他們想自行合併資料，則需要具有對於系統的大量內部知識。
那麼，我們在設計微服務架構時，為了打破這種單體性，就應當根據輸出來進行資源的劃分。因此，我們利用聚合器模式，來彙總這些資料。
這種方案可以通過兩個主要元件，來呈現給終端使用者。其中的一種是帶有 api 閘道器的複合式微服務。它可以彙總資料，並將其**給使用者。
如果您需要在分解的系統中用到各種業務功能模組的話，複合式微服務應當成為您的首選。
此模式擴充套件了聚合器的設計模式。在分支模式下，您可以通過兩個獨立的（更精確地說是：互斥的）微服務鏈，來同時處理請求和響應。
這種設計模式能夠根據您的不同業務需求，為單個或多個服務鏈提供靈活性。
從每個執行服務處獲取資料，是任何應用程式的首要任務。對於微服務架構而言，從獨立的服務中提取資料，同樣非常重要。
但是，僅通過乙個使用者介面（ui），從大量的微服務中獲取使用者手中的資源資訊，並不是一件容易的事。
因此，就像企業裡的服務台那樣，我們可以在微服務架構中，用 api 閘道器來為所有的互動操作提供統一的入口。
另外，在安全方面，api 閘道器也有助於實現使用者的授權、和為合適的使用者提供相關的 api。
因此 api 閘道器作為單一的切入點，不僅能夠充當**伺服器的作用，將各種請求路由到不同的微服務那裡，還能彙總來自多個服務的輸出結果，並傳送給使用者。
它可以處理多種協議請求，並按需進行轉換（例如，實現 https 與 amqp 之間的互轉）。
效能監測是確保微服務架構成功的另乙個重要方面。它有助於衡量系統的效率，並獲悉拖慢系統的罪魁禍首。下列模式涉及到可觀測性的範疇，能夠保障微服務架構設計的魯棒性。
微服務是可以獨立地、並行地支援多種其他服務的。而且，它的例項能夠橫跨各台機器。
同時，每個服務都會根據其執**況生成乙個日誌入口。那麼我們該如何跟蹤這些大量的服務相關日誌呢？
這正是日誌聚合模式的切入點。為了防止出現混亂的局面，我們應當設定乙個可以對所有微服務例項進行日誌聚合的主服務。而且，這種集中式日誌應當具有搜尋和監控的功能。
對微服務架構的監控，是一項繁瑣、但又必要的任務。當有數百個服務同時執行時，要想在日誌庫里查明某個失敗的根本原因，那就更難了。此時，綜合監控可能會派上用場。
在您進行自動化測試時，綜合監控能夠幫助您將結果與生產環境定期進行對映和比較。一旦出現故障，使用者將及時得到相關警告。
另外，語義監控還能幫助您實現如下兩方面： 1. 監測自動化的測試案例。 2. 根據業務需求，檢測生產環境中的故障。
同時，隨著系統的負載和微服務數量的增加，對系統效能的持續監控，並跨服務發現潛在的問題，就顯得非常重要了。
我們可以通過指標服務（metric service）來收集各類資料。指標服務可以是「推式」和「拉式」兩種形式。
微服務架構的設計促進了各個服務之間的相互獨立，並避免了系統中的任何延遲。
我們知道，api 在網路連線中能夠起到基石作用。我們需要通過對 api 的定期健康檢查，來提前發現各種障礙。
例如，您可能會經常觀察到：某個微服務雖然處於啟動和和執行狀態，卻沒有能力去處理任何請求。
為了應對上述因素，我們應該確保每乙個服務在執行時，都配有乙個健康檢查的特定 api 端點。
例如：我們可以在每個服務的末尾，通過追加 http/health 的引數，以返回各個服務例項、主機、連線和演算法邏輯等方面的健康狀況。
同時，服務註冊中心需要定期呼叫健康檢查的 api 端點，以執行相關的健康掃瞄任務。
而健康檢查的內容則可以包括如下方面： * 針對特定應用的系統邏輯。 * 主機的狀態。 * 連線到其他基礎設施或任何服務例項的連線狀態。
為業務能力而改變一切
在將單體架構分解成多個微服務的過程中，我們需要根據實際情況遵循不同的設計模式。
微服務的成功應該能夠充分體現高內聚和低耦合的特點。因此各種服務需要在抽象出相似功能的基礎上，保持低耦合的狀態。那麼，我們該如何將軟體系統分解成為更小、更獨立的邏輯單元呢？
我們需要定義微服務的範圍，從而支援特定的業務能力。例如，我們可以將組織的內部架構分為技術、營銷、公關、銷售、服務和運維等不同部門，這些不同的職能部門都可以被看作是各個微服務，而組織本身就是一套系統。
因此，為了保持效率和預估增長，我們需要按照業務能力對系統進行分解，基於各種能力所產生的價值，區分不同的業務領域。
雖然我們可以按照業務能力分類出各種微服務，但是我們該如何處置那些服務中的通用類呢？在此，我們可以用需要干預的「神類（god classes）」來分解這些類。
例如，在電子商務系統中，訂單是乙個共用類，一些諸如訂單號、訂單管理、訂單退貨、訂單交付等服務都會用到它。因此針對該問題，我們引入了領域驅動設計（domain-driven design，ddd）的微服務設計原則。
在領域驅動設計中，我們使用到了各個子域。這些子域模型應當被預定好功能的範圍，即界限上下文（bounded context）。
這些界限上下文作為引數被用來建立微服務，從而克服了通用類的相關問題。
上面我們討論了對全新單體架構概念的分解，下面我們來看看如何將現有的單體系統轉換為微服務架構。在此，我們引入刀砍蔓藤的模式。
由於在 web 應用中，經常會涉及到不同域裡各個服務之間的往返呼叫，因此刀砍模式非常適用於對域的切分。
在該模式下，雖然系統會出現兩個域共用乙個相同 uri 的情況，但是一旦某個服務完成了轉換，我們就會砍掉其對應的應用程式中的現有版本。而且，此過程會一直持續下去，直到單體系統不復存在為止。
就微服務架構而言，其松耦合的特性造就了各個獨立服務的部署與擴充套件能力。
但是由於不同的服務有著不同的儲存需求，因此它們可能需要訪問那些並非儲存在本地的資料。
下面讓我們來討論一些根據不同的需求，所適合採用的主要資料庫設計模式。
在領域驅動設計的原則中，基於服務的單獨資料庫，是將整個資料庫分配給特定的微服務。
因此，我們需要按照服務來事先設計好獨享的資料庫。也就是說，任何其他的外部微服務都無法訪問，其他未分配給自己的資料庫裡的資料，除非是通過微服務的 api 閘道器方式。
如果我們只是將上述獨享資料庫模式運用到，將單體架構分解成多個微服務的場景中，那麼難免會碰到各種麻煩。
因此，我們可以在分解的過程中，對有限數量的服務採用基於服務的共享資料庫模式。
而這個數量一般會被限制在 2～3 個，否則對系統的部署、自治性和擴充套件性有所影響。
當應用的當前狀態發生變化時，我們如何才能確保架構能夠按需變更，並根據這些變更實時地產生相應的事件呢？
事件溯源（event sourcing）模式，能夠根據每個業務實體的狀態變化，順次將新的事件追加到事件列表之中。
在系統中，諸如 customer 這樣的實體會產生許多事件，因此我們可以對實體的當時狀態進行「截圖式」事件錄入，以便進一步查詢或通過自動化的狀態調整，來優化負載。
對於基於服務的資料庫模式而言，由於訪問被限制在了單個資料庫之中，因此我們很難達到各種複雜的查詢效果。那麼我們該如何實現各種基於資料庫系統的聯合查詢呢？
cqrs 模型將單個應用程式分為命令和查詢兩個部分： 1. 命令部分處理各種建立、更新和刪除之類的請求。 2. 查詢則用到了物化檢視（materialized view），而這些檢視是通過事件流來進行更新的。
同時，這些事件又是由事件溯源模式所產生，並標註了資料中的各種變化。
在我們實施微服務時，難免會在服務的呼叫上碰到問題，因此我們可以採用橫切（cross-cutting）的模式來簡化工作。
由於採用了容器技術，ip 位址往往是被動態地分配的。這就意味著 ip 位址會隨時發生改變，進而導致服務的中斷。此外，使用者需要記住每個服務的 url，而這反而倒退成了緊耦合狀態。
為了解決該問題，我們需要通過乙個登錄檔，向使用者的請求提供位置資訊。服務例項在啟動時，能夠被註冊到表中；而在關閉時，也能被登出。
此法有助於使用者找出那些可用來查詢的準確位置。此外，登錄檔通過健康檢查，能夠確保例項的可用性，進而提高系統的效能。
在微服務架構中，乙個系統裡往往有著多個微服務。如果我們因為部署、或更新版本而停止所有的服務的話，那麼長時間的停機勢必會影響整體的生產力。
因此，我們需要在設計微服務架構時，通過藍-綠部署的模式，來避免該問題。
那麼在需要進行新的部署時，我們將應用的最新版本上傳到綠色系統中，並將真實對外的路由器切換到綠色系統上，以完成更新。
雖然您不一定會在自己的微服務系統中用到上述每一種設計模式，但是這些模式都有著它們獨特的應用場景。
作為架構師，對於不同的微服務架構設計模式，您需要從應用的設計階段到生產環境的維護階段，持續進行各種評估、審計、測試和實踐。相信它們在給您帶來一致性標準的同時，也能提高您的應用的整體可靠性。
微服務設計原則
相比於單機服務與其他架構，微服務架構的主要特徵是元件化 松耦合 獨立 去中心化。主要表現在如下幾個方面 細粒度的服務分解 將專案中每個模組 每個職責拆分出來，專注做好一件事情。獨立部署執行和擴充套件 每個微服務又是乙個單獨的專案，獨立執行在自己的程序裡。它可以不依賴於其他服務進行單獨使用和靈活擴充套...
微服務軟體架構設計
在軟體內部經過綜合各種因素考量 權衡，選擇特定的技術，將系統劃分為不同的部分並使用這些部分相互分工，彼此協作，為使用者提供需要的價值 軟體架構進化考慮的因素 傳統架構 單體架構 概念優勢 挑戰微服務架構 定義使用一套小服務來開發單個應用的方式，每個服務執行在單獨的程序，一般採用輕量級的通訊機制互聯，...
架構之微服務設計 Nginx Upsync
upsync，微博開源基於nginx容器動態流量管理方案 nginx 以其超高的效能與穩定性，在業界獲得了廣泛的使用，微博的七層就大量使用了 nginx 結合 nginx 的健康檢查模組，以及動態 reload 機制，可以近乎無損的服務的公升級上線與擴容。這個時候擴容的頻次比較低，大多數情況下是有計...