在過去的幾年裏，微服務一直是IT界的熱門話題。ZDNet認爲微服務是一項“值得關注的技術”，而軟件設計諮詢公司ThoughtWorks 已經宣佈，微服務架構作爲一種編程模型正呈現上升趨勢。新聞媒體界正在逐漸認可微服務架構，這個現象可能會讓一些架構師和IT主管感到擔心，他們害怕自己會錯過下一個令人興奮的趨勢。
許多人認爲微服務是一種規範性的架構，一個企業假定必須採用微服務架構的話，那麼必須以一種特定的方式進行（例如Netflix），否則就無法實現。然而，對於許多企業來說，以特定方式採用微服務是不可行的，並且可能會導致失敗。對於那些具備特定結構和文化的企業來說，由於各種規章制度、技術和文化的限制，純粹的微服務架構也就不再適用了。在企業的需求與這種純粹的微服務架構不兼容的情況下，如果企業在微服務領域仍然遵循一個過於規範的方法，那麼它將註定失敗。
擁有大量遺留系統的大型企業的需求與年輕公司的有所不同，企業文化可能就不適合採用純粹的微服務架構了。一些企業，特別是在高度管制的行業中，與Netflix或Spotify相比，具有不同的安全性或合規性需求，純粹的微服務架構也就不可行了。
實際上，企業需要從實用的角度出發，以一種對企業有意義的方式，嘗試適應微服務架構。畢竟並不是每個企業都必須是Netflix或Spotify。企業可以採用與自身文化、目標和組織架構相適應的微服務架構。微服務架構有多種設計模式，企業可以根據自身的需求來選擇這些模式，而不是將微服務作爲一種單一的方法（這將違背體系結構的要點）。對於企業而言，沒有必要同時採用微服務的每一個模式，只需要採用對自身企業有意義的、實用的一種模式即可。
1987年，廚師費朗·阿德里聽到了富有開創性的一句話“創造力意味着不抄襲”。這個簡單、不言而喻的說法在烹飪界掀起了一場重大運動。同樣地，關於微服務，我們可以說“微服務不是一個整體”。
實際上，微服務模式最初是作爲一個整體應用的替代品而創建的，它本質上應該是非整體的：容易更改，粒度小，可擴展。這也意味着微服務不僅僅是一個東西。相反，我們假定微服務是一類分組的、相關的模式，它們共享同一組目標。這類似於數據庫系統；它們都有相似的特點——通常具有不同的優先級，如可擴展性或可維護性。然而，它們之間的具體情況差別很大。例如，RDBMSes、NoSQL存儲、時間序列數據庫和大數據存儲等都有一個相似之處——它們提供了存儲和查詢數據的能力——但它們各自權衡的具體情況卻並不一樣。
在接下來的幾篇文章中，我們將重點介紹幾種廣泛實踐過的微服務模式。在實踐中，這些模式都有各自獨特的優勢，不能說哪個更好哪個更壞，而需要權衡輕重緩急，選擇一種折衷方案。這些模式都遵循微服務體系結構的特點：速度、可伸縮性、內聚性，差異之處在於實現方式有所不同。甚至可以說，其中一些模式是“過程中的步驟”，它們使得體系結構具備微服務的特點。它們自身傾向於產生可預測的失敗條件，從而鼓勵以這種模式工作的團隊尋找替代方案，做出更困難的權衡，然後在不斷增長的經驗中發展成一種不同的、更專業的模式。
微服務體系結構就是這樣形成的。它開始於一個概念方法和一組特點，這些特點導致了第一次架構迭代，然後快速迭代到更專業（許多人認爲是更“極端”）的模式。這不是壞事。正在實施或適應這些早期模式的企業並沒有做什麼倒退的事情，而是將其當前狀態改進到可以清楚地看到採取下一步的好處的階段。這是微服務架構非常“真實”的一種方式，它們遵循人類學習的模式。實施者都是人類，至少現在都是，他們需要通過個人經驗來學習更具體的模式和權衡的價值，而不是盲目地跟隨任何特定的文本或博客文章。
微服務架構應該是逐漸進化得來的，因爲它產生於對軟件系統快速更新，以及在多次迭代過程中改進系統的需求。在大多數企業中，從一開始就實現微服務體系結構是相對罕見的（許多人認爲這樣做是一種反模式）。因此，基於成熟度、需求和時機，通常會有一個體繫結構、模式和技術的延續性。這個延續性的其中一些是由團隊吸收更改的能力驅動的，另一些依賴於設置啓用的基礎設施，還有一些依賴於組織變革和團隊重組，例如DevOps實踐。能夠專注於當前可以做的事情，同時使團隊不斷向更高效的狀態發展，這是微服務體系結構的關鍵優勢之一。
微服務架構有六種常用的設計模式，這些模式可以讓企業更加容易採用微服務體系結構。這些模式中的每一個都不是通用的模式；相反，每個企業都可以權衡，在特定的場景中採用特定的設計模式。我們希望實現特定模式的用戶將此作爲參考，按照這些模式來規劃其體系結構，而不是試圖過度應用任何單一模式，從而打破折衷方案。理想狀態是使用這些模式的混合來設計和實現一個微服務體系結構，而不是選擇一個模式並向其遷移。
這些模式不存在哪個更好哪個更壞，在特定任務中都有各自獨特的優勢。在描述每個模式時，我們應該弄清楚要解決的問題是什麼。
最後一點需要強調的是，微服務架構並不適合每個用例。例如，如果一個企業嚴重依賴於ERP應用程序，並且不打算替換它，那麼對這個企業來說，微服務可能並不適合。然而，對於企業而言，它的部分業務肯定能夠通過速度、規模和凝聚力這些特性來獲益，那麼在這些領域就應該尋找機會利用微服務架構。
微服務模式並不特別適用於任何一種規模或類型的組織。事實上，狀態管理的模式往往對大型、快速發展的公司更有用。但是，對於有適當需求並且願意正確平衡其體系結構需求的企業或者公司，這些模式都是適用的。換句話說，“停在哪裏”完全取決於你要解決的問題，而不是通過這些模式的任何線性進展。
接下來的文章將分別爲你詳細介紹微服務架構的六種常用設計模式。敬請關注。