微軟AzureCAT模式和實踐團隊發布了9個新的設計模式。這9個設計模式在設計和實現微服務時很有用。
下圖展示了這些模式如何運用在一個微服務架構中：
9種設計模式如下：
1. 外交官模式（Ambassador）可以用于語言無關的方式處理常見的客戶端連接任務，如監視，日志記錄，路由和安全性（如TLS）。
場景
基于云的應用需要一些特色功能，比如熔斷，路由，監測以及網絡化配置更新。通常來說更新遺留應用或給已經存在的代碼庫添加新的特性是很困難的或者是不可能的。因為這些代碼要么已經不再被開發團隊維護，要么修改起來很不容易。
網路請求需要大量穩定的關于連接，授權，和認證的配置。如果這些請求在多個應用之間使用，并且這些應用還是由多種語言和框架構建的，那么這些請求必須要針對每一個實例來配置。此外，網絡和安全相關功能可能需要一個支撐團隊來管理。在巨大的代碼庫情況下，這個團隊來更新他們不熟悉的應用代碼是很有風險的。
解決方案
將客戶端框架和庫放到一個外部的進程里面去，這個進程可以作為應用與外部服務之間的一個代理。該代理部署在與應用相同的主機環境中，允許路由控制，彈性，安全特性和避免任何與主機相關的訪問限制。也可以使用外交官模式來標準化及擴展監測功能。代理可以監控性能指標比如延遲或者資源利用率，并且監控發生在和應用一樣的主機環境中。示意圖如下：
代理獨立于應用來管理某些特色功能。更新和修改外交官（代理）不會打亂遺留應用的功能。這種模式允許由不同的專門團隊來實現和維護已經被移到外交官（代理）中去的安全，網絡或者認證等相關特性。
外交官服務可以以挎斗的形式部署，與消費應用或服務有相同的生命周期。另外，如果外交官服務被同一個主機的多個不同的進程分享，那么也可以被部署為守護進程或者Windows服務。如果消費服務被容器化，外交官服務應該在相同的主機中被創建為一個獨立的容器。
考慮點
代理增加了一些延遲開銷?？紤]以客戶端庫的形式直接被應用調用是不是更好的方式。
考慮通用化特性帶來的可能后果。比如，外交官服務處理重試，除非所有的操作都是冪等性的，否則是不安全的。
考慮能夠允許客戶端傳遞某些上下文給代理以及傳回到客戶端的機制。
考慮如何打包和部署代理。
考慮所有的客戶端是使用單一共享的實例還是每個客戶端一個實例。
什么時候使用這種模式？
適用：
需要使用多樣的語言或者框架來構建客戶端連接相關特性的共同集合時候。
需要將橫向客戶端連接相關的關注點移交給到那些基礎設施開發人員或其它專門團隊中去。
需要在遺留應用或一個很難修改的應用中支持云或集群的連接需求。
不適用：
當網絡請求的延遲非常重要時。代理會引入某些開銷，即使很少，在某些情況下也會影響應用。
當使用單一語言消費客戶端連接相關特性時候。在這種情況下，客戶端庫作為一個包分發給開發團隊可能是一個更好的選擇。
當連接相關特性無法被通用化以及需要深層次地與客戶端應用集成時候。
例子
2. 防腐層（Anti-corruption layer）介于新應用和遺留應用之間，用于確保新應用的設計不受遺留應用的限制。
場景
很多應用依賴其它系統的數據或功能。新的特性需要具有調用遺留系統的能力。特別是對于那些漸進式的遷移。
一般來說那些需要被遷移的遺留系統都有質量問題，比如過度復雜的數據結構或者過時的API接口。遺留系統使用的特性和技術與很多現代的系統差別很大。與遺留系統交互，新的應用可能需要支持過時的基礎架構，協議，數據模型，API，或者其它的不想放在現代應用里面的特性。
維護新系統和遺留系統之間的訪問，會強制新系統和一些遺留系統的API或其它語意部分粘連。當這些遺留系統的特性有質量問題時候，需要一個干凈設計的現代應用來支持這些“腐敗”。
解決方案
通過在遺留系統和現代系統之間設置一個防腐層來隔離它們。該層負責兩個系統之間的通信轉換，從而使得遺留系統繼續保持不變，同時新應用能夠避免對設計和技術方式的妥協。
防腐層包含了所有的兩個系統之間轉換邏輯。該層可以是一個在應用內部的組件，也可以是一個獨立的服務。
考慮點
可能會增加兩系統間通信延遲。
防腐層增加了額外的服務，需要管理和維護。
需要考慮防腐層如何擴展。
考慮是否需要更多的防腐層。
在與其它應用或服務有關系情況下，考慮如何管理這些防腐層。如何與監控，發布和配置流程等集成？
確保維護和監控事務和數據的一致性。
考慮防腐層是否需要處理所有的遺留和新系統之間的通信還是僅僅一部分。
考慮防腐層是否是永久的，或者當所有的遺留系統功能完成遷移時，這些防腐層是否最終要被移除。
什么時候使用？
適用：
漸進式遷移，需要維護遺留系統和新系統之間的集成。
新系統和遺留系統之間有不同的語意環境，但是還必須有交互。
不適用：
新系統和遺留系統沒有明顯的語意不同。
3. 后端服務前端（Backends for Frontends）為不同類型的客戶端（如桌面和移動設備）創建單獨的后端服務。這樣，單個后端服務就不需要處理各種客戶端類型的沖突請求。這種模式可以通過分離對特定客戶端的關注來幫助保持每個微服務的簡單性。
場景
應用剛開始只是針對桌面網絡UI。通常，需要并行地開發一個后臺服務來提供該UI所需要的特性。隨著應用的用戶數量不斷增長，需要開發移動應用，移動應用必須可以和該后臺服務交互。該后臺服務就變成了一個通用的后臺服務，既滿足桌面應用也滿足移動應用。
但是，移動設備和桌面瀏覽器區別是很大的，包括屏幕尺寸，性能以及對顯示的限制。因此，對移動應用的后臺服務的需求是有別于桌面網絡UI的。
這些區別導致了對后臺服務的競爭性需求。一般，不同的前端是由單獨的團隊負責，這就導致了在開發過程中，后臺服務成為了瓶頸。需求變更的沖突以及需要滿足所有前端的要求往往會導致需要花費更多的精力在單一部署的資源上。
當某個前端團隊要求后臺服務更改時，這些更改在被集成到后臺服務中之前，必須通過其它的前端團隊的驗證。
解決方案
每種前端創建一個對應的后臺服務。通過合理地調整每個后臺服務的行為和性能來最佳地匹配前端的需求，而不用擔心影響其它的前端體驗。
因為每個后臺服務專注于一個前端界面，該服務能夠為這個前端界面來優化。因此，該服務將會比較小，相對不復雜，以及可能比那些要滿足所有前端需求的通用的后臺服務更快。每個界面團隊有控制他們自己的后臺服務自主權，并且不需要依賴集中化的后臺服務開發團隊。這給予界面團隊很大的靈活性去選擇語言，發布節奏，工作優先級，以及集成到后臺服務里的特性。
需要考慮的點
考慮有多少個后臺服務需要部署。
如果不同的界面（比如移動客戶端）有相同的請求，考慮是否有每個界面實現一個后臺服務的必要，或者是否單一后臺服務就足夠了。
當實現這種模式時，很大可能造成不同服務之間的代碼重復問題。
面向前端的后臺服務應該只包括客戶端特定的邏輯和行為。通用的業務邏輯和其它全局特性應該由應用的其它服務來管理。
想想該模式如何反應在開發團隊的職責中。
考慮實現該模式要花費多少時間。當繼續支持現存的通用后臺服務時，構建新的后臺服務是否導致技術債。
什么時候使用？
適合：
維護共享的和通用的后臺服務需要很大的開發上的開銷。
需要根據特定的客戶端優化后臺服務。
通用后臺服務需要定制化來適應不同的界面。
用另一種語言更適合開發某種前端的后臺服務的時候。
不適合：
當界面對后臺服務產生相同或者相似的請求時候。
當只有一種前端與后臺服務交互的時候。
4. 艙壁模式（Bulkhead）隔離了每個工作負載或服務的關鍵資源，如連接池、內存和CPU。使用艙壁避免了單個工作負載（或服務）消耗掉所有資源，從而導致其他服務出現故障的場景。這種模式主要是通過防止由一個服務引起的級聯故障來增加系統的彈性。
場景
基于云的應用可能含有多種服務，每個服務有一個或多個消費者。某個服務中發生太多的失敗或者有太多的負載將會影響其它所有消費該服務的消費者。
此外，消費者可能會同時發送請求給多個服務，每個請求都會使用到資源。當消費者發送某個請求到配置錯誤的或無響應的服務上時，客戶端請求使用的資源可能不會被及時的釋放。隨著持續發送請求到該服務，這些資源可能會被耗盡。
同樣的資源耗盡問題會影響有多個消費者的服務。從某個客戶端來的大量的請求也可能會耗盡服務上的可用資源。其它的消費者就無法消費服務，從而引起級聯故障。
解決方案
根據消費者負載和可用性需求，將服務實例分成不同的組。這種設計能幫助隔離故障，允許在故障期間，為一些消費者維持服務的功能性。
消費者也能夠分區資源來保證請求某個服務所用的資源不會影響到其它請求服務所使用的資源。比如，為每個服務，給調用不同服務的消費者分配一個連接池。如果某個服務開始故障了，故障只會影響這個服務所擁有的連接池。該消費者可以繼續使用其它的服務。
該模式的好處：
從級聯故障中隔離消費者和服務。消費者或者服務發生的問題能夠被隔離在它自己的船壁中，從而防止整個系統故障。
倘若發生服務故障，允許保存一些功能。該應用的其它服務和特性會繼續工作。
允許去部署那些為不同的消費應用提供不同質量的服務。高優先級的消費者池能夠被配置去使用高優先級的服務。
下圖展示了通過連接池來調用單獨的服務的船壁結構。如果服務A故障或者有其它一些問題，服務A的連接池會被隔離，只有使用服務A的線程池的工作負載會被影響。使用服務B和C的工作負載不會被影響并且能夠繼續工作而不被中斷。
下圖展示了多個客戶端調用單個服務。每個客戶端被分配一個獨立的服務實例?？蛻舳?產生太多的請求，從而導致服務實例崩潰。因為每個服務實例是隔離的，其它的客戶端能夠繼續發送請求。
考慮點
圍繞著業務和技術上的需求來定義分區。
當劃分服務或者消費者到船壁中時，既要考慮隔離級別也要考慮開銷，性能和可管理性。
考慮船壁模式與重試，斷路器以及限流模式的結合來提供更多的復雜巧妙的故障處理。
當劃分消費者到船壁中，考慮使用進程，線程池，以及信號量。
當劃分服務到船壁中，考慮部署服務到獨立的虛擬機，容器或者進程中。容器能在資源隔離性和開銷之間提供較好的平衡。
使用異步消息通信的服務能夠從不同隊列集中隔離出來。每個隊列能夠有專屬的實例集，用來處理隊列中的消息，或者單個實例組使用某個算法來做出列和分發處理。
確定船壁的顆粒度水平。
監控每個分區的性能和SLA。
什么時候使用？
適合：
隔離那些被用來消費后臺服務集的資源，特別是，如果應用能夠提供某種程度的功能，即使當其中某個服務不響應的時候。
從普通的消費者中隔離重要的消費者。
防止應用發生級聯故障。
不適合：
項目中不能接受資源的低利用率。
沒有必要增加復雜性的時候。
5. 網關聚合（Gateway Aggregation）將對多個單獨微服務的請求聚合成單個請求，從而減少消費者和服務之間過多的請求。
場景
要完成某個單一任務，客戶端可能需要產生多個請求到不同的后臺服務上。依賴多個服務來完成一件任務的應用必須在每個請求上消耗資源。當任何新的特性或者服務加到應用中時，需要增加額外的請求、資源需求和網絡調用。客戶端和后臺服務之間的頻繁的通信能夠有害地影響應用的性能和規模。由于應用是圍繞著很多小的服務來構建，天然地存在大量的跨服務調用，所以微服務架構使這種問題更突出。
在下圖中，客戶端發送請求到每個服務（1,2,3）。每個服務處理請求并且返回響應到應用（4,5,6）。在通常有高延遲的網狀網路中，以這種方式使用獨自的請求是效率低的以及可能會導致連接中斷或未完成的請求。當每個請求可以被并行的處理時，應用必須為每個請求發送，等待以及處理數據，所有的都有獨立的連接，這增加了故障發生幾率。
解決方案
使用網關來減少客戶端和服務之間的通信量。網關接收客戶端請求，分發這些請求到不同的后臺服務上去，然后聚合結果并返回這些結果給請求的客戶端。
這種模式能夠減少應用對于后臺服務的請求數量，以及在高延遲網絡中能提高應用的性能。
在下圖中，應用發送一個請求到網關（1）。該請求包含了一系列額外的請求。網關分拆這些請求并且發送請求到相關服務（2）來處理每個請求。每個服務返回一個響應給網關（3）。網關合并這些來自于每個服務的響應到一個響應并發送該響應到應用（4）。應用產生單個請求，從網關僅僅接收到單個響應。
考慮點
網關不應該在后臺服務之間引入服務耦合。
網關應該靠近后臺服務來盡可能的減少延遲。
網關服務可能會引入單點故障。確保網關的設計滿足應用的可用性要求。
網關可能會引入瓶頸。確保網關有足夠的性能來處理負載并且能夠被擴展來滿足預期的增長。
針對網關做負載測試，確保網關沒有引入服務的級聯故障。
使用某些技術實現彈性設計，比如：船壁模式，斷路器，重試以及超時機制。
如果一個或多個服務調用耗時太長，此時超時限制以及返回部分數據是可以接受的。需要考慮應用如何處理這種情況。
使用異步I/O來確保后臺服務延遲不會在應用中引起性能問題。
使用相關ID追蹤每個獨立調用來實現分布式追蹤。
監控請求指標和響應的大小。
考慮返回緩存的數據作為處理故障的一個故障轉移策略。
考慮在網關之前放置一個聚合服務，而不是在網關中集成聚合功能。在網關中，請求聚合相對于其它服務可能會有不同的資源需求，這可能會影響網關路由和卸載的功能。
什么時候使用？
適合：
客戶端需要和不同種類的后臺服務通信來完成某個操作。
客戶端可能使用高延遲的網絡，比如網狀網絡。
不適合：
想減少客戶端和單一服務之間多個操作之間的請求數量。這種場景下，最好是使用在服務中增加一個批處理操作的方式。
客戶端和應用位于后臺服務附近并且延遲不是一個重要的因素。
6. 網關卸載（Gateway Offloading）能使每個微服務卸載共享服務功能（共同的功能抽到API網關來做），比如在API網關使用SSL認證。
場景
一些特性在多個服務之間被共同地使用，并且這些特性需要配置，管理和維護。每個應用部署都有一個共享的或特定的服務會增加管理上的開銷以及部署上的錯誤。任何針對共享特性的更新必須在所有的共享了該特性的服務之間都部署。
正確地處理安全問題（token驗證，加密，SSL認證管理）以及其它的復雜任務會需要團隊成員具有高度專業化的技能。比如，一個應用需要的一個證書必須被配置和部署到所有的應用實例上。對于每次新的部署，必須管理證書確保不過期。在每個應用部署中，任何共同的證書要過期時都必須更新，測試以及驗證。
其它的一些共同服務例如認證，授權，日志，監控或限流很難在大量部署服務之間實現和管理。為了減少開銷和故障發生的可能性，最好是合并這種類型的功能。
解決方案
卸載（轉移）一些特性到API網關中去，特別是一些交叉點例如證書管理，認證，SSL協議終止，監控，協議轉換或限流。
下圖展示了API網關終止到達的SSL連接。網關以原始請求的名義（未加密）從任一在API網關上游的HTTP服務器上請求數據。
該模式的好處：
通過移除對分布式和維護支撐資源的需求，使服務的開發簡化。相對簡單的配置有利于更容易的管理和擴展，并且使服務升級更簡單。
允許專職團隊去實現那些需要特殊專業知識的特性，比如安全。這使得核心團隊可以專注在應用功能上，而將這些特殊并且交叉的任務留給相關專家處理。
提供一些關于請求及響應的日志和監控的一致性。即使如果某個服務沒有被正確地儀表化，網關也能夠被配置并且確保監控和日志的最低水平。
考慮點
確保API網關是高可用的和對故障的彈性。通過運行多個API網關實例來避免單點故障。
確保網關是為了應用和端點容量和伸縮需求而設計。確保網關不會成為應用的瓶頸并且能夠被高效的擴展。
只卸載（轉移）那些被整個應用使用的特性，比如安全或者數據傳輸。
業務邏輯絕不能被卸載（轉移）到API網關中去。
如果需要追蹤事務，考慮為日志記錄產生相關ID。
什么時候使用？
適合：
部署應用時有相同的考慮點，比如SSL證書或者加密。
某個特性在應用部署中是通用的，并且可能有不同的資源需求，比如內存資源，存儲能力或網絡連接。
希望將某些職責比如網絡安全，限流或其它網絡邊界關注點交給特定的團隊負責。
不適合：
如果引入了服務間的耦合。
7. 網關路由（Gateway Routing）使用單個端點，將請求路由到多種多樣的微服務上，從而消費者無需管理很多分離的端點。
場景
當客戶端需要消費多個服務時，為每個服務設置一個單獨的端點以及每個端點都有客戶端消息將會很有挑戰性。比如，一個電子商務應用可能會提供很多服務例如搜索，評論，購物車，付款以及歷史訂單。每個服務有不同的API與客戶端交互，并且為了連接到服務，客戶端必須知道每個端點。如果某個服務發生更改或者更新了，客戶端必須也要更新。如果某個服務被重構成2個或更多個獨立的服務，服務和客戶端代碼都必須改動。
解決方案
在一組應用、服務或部署前面放置一個網關。使用應用7層路由來路由請求到恰當的實例上。
利用該模式，客戶端應用僅需要知道單個端點并與之通信。如果某個服務被合并了或被分解了，客戶端不一定需要更新。可以繼續向網關發送請求，僅僅是路由發生改變。
網關也能夠從客戶端抽象后臺服務，從而使得當位于網關之后的后臺服務發生改變時，客戶端調用請求始終保持簡單?？蛻舳苏埱竽軌虮宦酚傻饺我庑枰脕硖幚眍A期客戶端行為的單個服務或多個服務上去。可以新增，分解，以及重組網關后的后臺服務而無需更改客戶端。
通過管理如何將更新推出給用戶，該模式也有助于部署。當部署某個服務的新版本時，能夠與現存的版本并行地部署新版本。通過路由來控制哪個版本的服務被呈現給客戶端，這樣可以彈性地使用不同的發布策略，無論增量式，并行式，或者完整地推出更新。在新服務部署后，發現的任何問題都能夠通過更改網關的配置來迅速地恢復到原先版本，從而不會影響到客戶端。
考慮點
網關服務可能會引入單點故障。確保網關的設計滿足可用性需求。在實現時，考慮彈性和容錯能力。
網關服務可能會引入瓶頸。確保網關有足夠的性能來處理負載以及能夠很容易地線性擴展。
通過針對網關的負載測試來確保沒有引入服務的級聯故障。
網關路由是7層。網關路由能夠根據IP，端口，頭，或URL。
什么時候使用？
適合：
客戶端需要消費很多不同的能夠通過網關訪問的服務。
希望通過單個端點來簡化客戶端應用。
需要從外部可尋址的端點路由請求到內部虛擬端點上，比如暴露VM上端口給虛擬IP地址集群。
不適合：
當應用很簡單并且只使用一個或兩個服務時候。
8. 挎斗模式（Sidecar）將應用程序的輔助組件部署為單獨的容器或進程以提供隔離和封裝。
場景
應用和服務經常需要某些相關功能，比如監控、日志、配置以及網絡服務。這些外圍的任務能夠作為獨立的組成部分或服務被實現。
如果它們被緊密的集成到應用中，那么這些外圍任務能夠和應用運行在相同的進程中，對于共享資源的利用比較有效率。但是，這也意味著他們沒有很好地被隔離，并且在這些組件中任何一個發生中斷都能夠影響其它的組件或整個系統。還有，通常需要使用和父應用相同的語言來實現這些組件。從而使得組件和應用具有很緊密的相互依賴關系。
如果應用被分解成多個服務，那么每個服務可以使用不同的語言和技術來構建。盡管這增加了靈活性，同時也意味著每個組件有它自己的依賴以及需要特定語言的庫來訪問底層的平臺和任何與父應用共享的資源。此外，以獨立服務來部署這些特性會增加應用的延遲。為這些特定語言的接口管理代碼和依賴也會增加相當大的復雜性，特別是對于托管，部署和管理。
解決方案
并置一個一組內聚的任務與主應用一起，但是要將他們放在他們自己的進程或容器中，為平臺服務提供一個同種的跨語言的接口。
挎斗服務對于應用來說不是必要的部分，但是挎斗服務可以連接到應用上?？娑贩针S著父應用而變動?？娑贩罩С忠赃M程或服務形式和主應用一起部署?？娑繁桓郊拥揭粋€“摩托車”上并且每個“摩托車”都有自己的挎斗。在相同方式下，一個挎斗服務共享它父應用的生命周期。對于每個應用的實例，都會部署一個挎斗服務的實例來為其提供服務。
使用挎斗模式的好處：
在運行環境和編程語言方面，挎斗獨立于它的主要的應用，因此不需要為每種語言都開發一種挎斗。
挎斗能夠如同主應用訪問相同的資源。比如，挎斗能夠監控被挎斗服務和主應用使用的系統資源。
由于它靠近主應用，因此當互相通信時，沒有明顯的延遲。
即使那些沒有提供可擴展機制的應用，也可以使用挎斗來擴展功能，挎斗在相同主機上有自己獨立的進程或作為主應用的子容器方式附加到主應用。
挎斗模式經常與容器一起使用并且一般被稱為挎斗容器或附屬容器（sidekick container）。
考慮點
考慮用來部署服務，進程或容器的部署和打包格式。容器特別適合挎斗模式。
當設計挎斗服務時，謹慎地決定進程間通信機制。試著使用語言無關或框架無關的技術除非性能需求使此技術不現實。
在將功能封裝進挎斗之前，考慮作為單獨的服務或更傳統的守護進程更合適。
考慮功能是否可以以庫的方式實現或使用傳統的擴展機制。特定語言的庫可能會有更深級別的集成和更少的網絡延遲。
什么時候使用？
適合：
主應用使用異種的語言集和框架。挎斗服務中的組件能夠被使用不同框架和不同語言的應用消費。
遠程團隊或不同的組織擁有某個組件。
某個組件或特性必須被并置在和應用同樣的主機中。
需要某個服務共享主應用整個生命周期，但是能夠被獨立地更新。
對于特別的資源或組件，需要細顆粒度的控制。例如，可能想去限制某個特定組件的內存使用?？梢圆渴鹪摻M件為一個挎斗，從而單獨地管理主應用的內存使用。
不適合：
當進程間通信需要被優化。父應用和挎斗服務之間的通信會有一些開銷，在調用中會有顯著的延遲。對于頻繁通信的接口，這種性能的犧牲不能夠被接受。
對于一些小的應用，為每個實例部署挎斗服務的資源消耗相對于隔離的優勢是不劃算的。
當服務相對于主應用需要差異化或獨立地擴展時。如果如此，將特性部署為獨立的服務更好。
9. 絞殺者模式（Strangler）通過用新服務逐漸地替換特定的功能片段來支持漸進式遷移。
場景
隨著系統年限的增加，開發工具，服務托管技術，甚至構建系統依賴的架構都能變得日益過時。隨著新的特性和功能的加入，這些應用的復雜性會急劇的增加，使得維護或增加新特性到應用中變得非常困難。
完全地替換掉一個復雜系統將會是一個巨大的工程。通常需要漸進式地遷移到新系統，同時保持舊系統去處理那些還沒有被遷移的特性。然而，運行一個應用的兩個獨立的版本意味著客戶端需要知道特定的特性的位置。每當某個特性或服務被遷移時，需要更新客戶端來指向新的位置。
解決方案
漸進式地用新應用和服務替換特定功能片段。創建一個立面層來攔截針對后臺遺留系統的請求。該層路由請求要么到遺留系統，要么到新服務?，F存的特性能夠逐漸地遷移到新系統，而且消費者能夠繼續使用相同的接口，注意不到已發生的任何遷移。
該模式有助于最小化遷移的風險，并且隨著時間的推移分攤開發工作量。因為立面層安全地路由用戶到正確的應用上，以任何節奏給新系統增加功能都是可以的，同時保證了遺留應用繼續工作。久而久之，隨著特性都被遷移到新的系統，遺留系統最終被“絞殺”且不再需要。一旦整個過程完成后，遺留系統就能夠被安全的移除。
考慮點
考慮如何處理新系統和遺留系統都可能會使用到的服務和數據存儲。確保兩者都能夠并行地訪問這些資源。
以某種方式組織新應用和服務使它們在將來的絞殺者遷移中能夠容易地被攔截和替換。
在某些時候，當遷移完成時，絞殺者層將會要么消失，要么演化到某個遺留客戶端適配器中。
確保立面層緊跟著遷移。
確保立面層不會變成單點故障或性能瓶頸。
什么時候使用？
適合：
當漸進式遷移后臺應用到新的架構中去的時候。
不適合：
當對于后臺系統的請求不能夠被攔截時。
對于比較小的系統，當整個替換的復雜性很低的時候。
微服務的目標是通過將應用分解成小的自治的服務，這些服務能夠被獨立部署，來加速應用發布的速度。微服務架構也帶來了很多挑戰，上面這些模式能夠幫助我們應對這些挑戰。
參考文章：
