在近期舉辦的QCon倫敦大會上，Tammer Saleh在一場演講中描述了他在微服務方面遇到的一些常見的反模式以及對應的解決方案。他表示，一體性應用的主要問題在于應用難以擴展，但更重要的問題在于團隊也難以擴展。因此，選擇微服務的主要原因是團隊方面的因素。

對于小型應用和小型團隊來說，一體性的應用沒有任何問題，但隨著應用的規模不斷增長，以及開發者團隊的膨脹，他們已無法在同一個代碼庫中進行合作。選擇微服務能夠讓我們以適合自己的方式應用康威定律。

Saleh表示，微服務的構建是一項非常復雜的工作，只要在某個方面沒做好，就有可能走到錯誤的方向上。在他看來，最常見的錯誤就是在起初階段就企圖實現微服務。他強調說，對于任何一種系統，起初都應該盡可能選擇簡單的方式，只有當團隊或業務有需要時，再開始逐步地遷移至更復雜的解決方案上。他提到，對于一個公司來說，最重要的是快速進入市場賺錢，而不是去探索有趣的架構模式。他給出的方案是在起初階段選擇一體性方式，等到有必要時再進行提煉。他還指出，微服務為開發過程施加了持續的負擔。

當訪問量達到高峰時，必須維護足夠數量的服務器，以應對峰值時的負載。但隨著訪問量與服務器數量的提高，數據庫最終會達到過載狀態。一種方案是通過隊列分擔這種負載，隊列基本上就是一種緩沖，以緩解過高的訪問量。為此，通信需要轉變為異步方式，而這樣一來，由于請求與響應的生命周期被打破，客戶端將不得不處理異步的響應，使得整個應用的復雜度再度提高。但在Saleh看來，這一步是必不可少的，否則組織將不得不在計算資源上投入過多的金錢。

從運維的角度來說，如果某些服務嘗試連接某個特定的服務，而后者又無法響應，這將成為一個嚴重的問題。由于大量的請求不斷涌入，因此很難對已產生故障的服務進行故障診斷與修復工作。如果成百上千的其他服務仍然在向該服務發送請求，就可能會導致各種各樣的問題。有一種解決方案是使用斷路器，它能夠使請求無法達到發生故障的服務。在正常工作情況下，斷路器允許所有的訪問通過，而一旦它發現了某個故障，就會阻止對它繼續訪問。等到出故障的服務能夠再次響應，訪問才能夠繼續通過斷路器。

隨著微服務的興起，也出現了一系列新的測試模式。一種常見的模式是模擬某個待測試服務所調用的各種服務，測試某個服務的團隊將不再與所調用的服務進行通信，而是為這些服務編寫模擬對象。這最終意味著每個團隊都需要為其所調用的服務編寫自己的模擬對象，由此可能會產生大量的額外工作。按Saleh的經驗來看，一種通用的解決方案是讓每個團隊為其負責的服務編寫一個通用的模擬對象，這樣一來，每個服務都只對應一個模擬對象。作為對這種方案的一種改進，他進一步提議讓每個團隊為服務編寫特定于語言的客戶端，讓調用該服務的其他服務使用這個客戶端。客戶端將處理與服務之間的實際通信，它本身也可以提供模擬對象。在Saleh看來，這種方式的優點在于每個服務對于所用的協議具有完整的控制，并且能夠在必要時進行改動。他同時相信，這種方式是一種更易用的接口。

在2015年的一篇博客文章中，Stefan Tilkov反對在起初階段總是以一體性方式設計應用的思想。他認為對于足夠復雜的系統來說，從一開始就應該考慮將其設計為多個獨立的子系統。

在今年早些時候，Ben Christensen在一場報告中談到了使用由服務團隊編寫的客戶端庫，并將其作為訪問該服務唯一的正式途徑的風險。

QCon的參會者已經可以下載Saleh的報告內容了。而不久之后，InfoQ的讀者也可以欣賞到Saleh的講座內容。

查看英文原文：Anti-Patterns Working with Microservices