六種經常使用的微服務架構設計模式 前言篇

在過去的幾年裏，微服務一直是IT界的熱門話題。ZDNet認爲微服務是一項「值得關注的技術」，而軟件設計諮詢公司ThoughtWorks 已經宣佈，微服務架構做爲一種編程模型正呈現上升趨勢。新聞媒體界正在逐漸承認微服務架構，這個現象可能會讓一些架構師和IT主管感到擔憂，他們懼怕本身會錯過下一個使人興奮的趨勢。

許多人認爲微服務是一種規範性的架構，一個企業假定必須採用微服務架構的話，那麼必須以一種特定的方式進行（例如Netflix），不然就沒法實現。然而，對於許多企業來講，以特定方式採用微服務是不可行的，而且可能會致使失敗。對於那些具有特定結構和文化的企業來講，因爲各類規章制度、技術和文化的限制，純粹的微服務架構也就再也不適用了。在企業的需求與這種純粹的微服務架構不兼容的狀況下，若是企業在微服務領域仍然遵循一個過於規範的方法，那麼它將註定失敗。

擁有大量遺留系統的大型企業的需求與年輕公司的有所不一樣，企業文化可能就不適合採用純粹的微服務架構了。一些企業，特別是在高度管制的行業中，與Netflix或Spotify相比，具備不一樣的安全性或合規性需求，純粹的微服務架構也就不可行了。

實際上，企業須要從實用的角度出發，以一種對企業有意義的方式，嘗試適應微服務架構。畢竟並非每一個企業都必須是Netflix或Spotify。企業能夠採用與自身文化、目標和組織架構相適應的微服務架構。微服務架構有多種設計模式，企業能夠根據自身的需求來選擇這些模式，而不是將微服務做爲一種單一的方法（這將違背體系結構的要點）。對於企業而言，沒有必要同時採用微服務的每個模式，只須要採用對自身企業有意義的、實用的一種模式便可。

1987年，廚師費朗·阿德里聽到了富有開創性的一句話「創造力意味着不抄襲」。這個簡單、不言而喻的說法在烹飪界掀起了一場重大運動。一樣地，關於微服務，咱們能夠說「微服務不是一個總體」。

實際上，微服務模式最初是做爲一個總體應用的替代品而建立的，它本質上應該是非總體的：容易更改，粒度小，可擴展。這也意味着微服務不只僅是一個東西。相反，咱們假定微服務是一類分組的、相關的模式，它們共享同一組目標。這相似於數據庫系統；它們都有類似的特色——一般具備不一樣的優先級，如可擴展性或可維護性。然而，它們之間的具體狀況差異很大。例如，RDBMSes、NoSQL存儲、時間序列數據庫和大數據存儲等都有一個類似之處——它們提供了存儲和查詢數據的能力——但它們各自權衡的具體狀況卻並不同。

在接下來的幾篇文章中，咱們將重點介紹幾種普遍實踐過的微服務模式。在實踐中，這些模式都有各自獨特的優點，不能說哪一個更好哪一個更壞，而須要權衡輕重緩急，選擇一種折衷方案。這些模式都遵循微服務體系結構的特色：速度、可伸縮性、內聚性，差別之處在於實現方式有所不一樣。甚至能夠說，其中一些模式是「過程當中的步驟」，它們使得體系結構具有微服務的特色。它們自身傾向於產生可預測的失敗條件，從而鼓勵以這種模式工做的團隊尋找替代方案，作出更困難的權衡，而後在不斷增加的經驗中發展成一種不一樣的、更專業的模式。

微服務體系結構就是這樣造成的。它開始於一個概念方法和一組特色，這些特色致使了第一次架構迭代，而後快速迭代到更專業（許多人認爲是更「極端」）的模式。這不是壞事。正在實施或適應這些早期模式的企業並無作什麼倒退的事情，而是將其當前狀態改進到能夠清楚地看到採起下一步的好處的階段。這是微服務架構很是「真實」的一種方式，它們遵循人類學習的模式。實施者都是人類，至少如今都是，他們須要經過我的經驗來學習更具體的模式和權衡的價值，而不是盲目地跟隨任何特定的文本或博客文章。

微服務架構應該是逐漸進化得來的，由於它產生於對軟件系統快速更新，以及在屢次迭代過程當中改進系統的需求。在大多數企業中，從一開始就實現微服務體系結構是相對罕見的（許多人認爲這樣作是一種反模式）。所以，基於成熟度、需求和時機，一般會有一個體繫結構、模式和技術的延續性。這個延續性的其中一些是由團隊吸取更改的能力驅動的，另外一些依賴於設置啓用的基礎設施，還有一些依賴於組織變革和團隊重組，例如DevOps實踐。可以專一於當前能夠作的事情，同時使團隊不斷向更高效的狀態發展，這是微服務體系結構的關鍵優點之一。

微服務架構有六種經常使用的設計模式，這些模式可讓企業更加容易採用微服務體系結構。這些模式中的每個都不是通用的模式；相反，每一個企業均可以權衡，在特定的場景中採用特定的設計模式。咱們但願實現特定模式的用戶將此做爲參考，按照這些模式來規劃其體系結構，而不是試圖過分應用任何單一模式，從而打破折衷方案。理想狀態是使用這些模式的混合來設計和實現一個微服務體系結構，而不是選擇一個模式並向其遷移。

這些模式不存在哪一個更好哪一個更壞，在特定任務中都有各自獨特的優點。在描述每一個模式時，咱們應該弄清楚要解決的問題是什麼。

最後一點須要強調的是，**微服務架構並不適合每一個用例。**例如，若是一個企業嚴重依賴於ERP應用程序，而且不打算替換它，那麼對這個企業來講，微服務可能並不適合。然而，對於企業而言，它的部分業務確定可以經過速度、規模和凝聚力這些特性來獲益，那麼在這些領域就應該尋找機會利用微服務架構。

微服務模式並不特別適用於任何一種規模或類型的組織。事實上，狀態管理的模式每每對大型、快速發展的公司更有用。可是，對於有適當需求而且願意正確平衡其體系結構需求的企業或者公司，這些模式都是適用的。換句話說，「停在哪裏」徹底取決於你要解決的問題，而不是經過這些模式的任何線性進展。

接下來的文章將分別爲你詳細介紹微服務架構的六種經常使用設計模式。敬請關注。