[[377883]]

 微服務架構的正常運轉，離不開一組精心構建、且能夠高效協(xié)同運作的獨立組件。正是模塊化組件間的相互依存，構建起規(guī)模更大的應用程序本體。

但在實際開發(fā)中，在微服務分解成最基礎的單元時，確保微服務以最基本的方式運作絕非易事。如果做不到這一點，應用程序的整體效用根本無法實現。不要因為設計錯誤而拒絕微服務架構，牢記以下五項黃金設計原則，你的微服務架構將擁有強大的組件支持。

第一，專注處理一個問題。邁進微服務的第一步，就是為服務設定唯一的問題。例如，我們假定一家汽車貿易組織希望構建一款應用程序，借此將潛在的買家與賣家聯(lián)系起來。以此為基礎，將有專門的微服務組件處理汽車交易中的買、賣或者轉售等操作，任何服務除此之外再無其他用途。

付款環(huán)節(jié)正是設計中的另一個重點組件。雖然這兩項微服務可以相互結合并使用，但這些服務并不會融合起來。每個元素負責處理不同任務，而且始終能夠獨立起效。

第二，具備離散屬性。微服務在執(zhí)行工作時所需要的全部邏輯及數據都存在于自身內部，而且與其他微服務組件完全隔離。

雖然微服務往往也需要自身配置才能讓各內部組件正常運行，但是這種配置不會對其他微服務的配置產生影響。只有牢牢把持這項設計原則，開發(fā)人員才能根據實際負載需求隨時完成各項服務的規(guī)模伸縮。

第三，帶有自身數據。微服務不僅應帶有自身數據，這些數據還應獨立于其他微服務組件之外。在某些情況下，微服務甚至可能擁有自己的數據庫。在其他場景中，微服務可能與其他服務共享同一套數據庫，但仍在該數據庫中擁有自己所對應的唯一數據庫表。

通常來講，開發(fā)人員會使用共享數據庫以降低成本，但這明顯違反了微服務架構的設計原則。

開發(fā)人員往往需要在設計中同時考慮到數據的獨立性與冗余性。每項微服務自帶數據的設計方式可能在應用層級上引發(fā)數據重復，但開發(fā)者們開始逐漸接受微服務設計模式必然引發(fā)數據冗余這一基本事實。

要了解不同微服務之間的數據重復問題，最直觀的示例莫過于存儲在不同在電子商務平臺手中的客戶數據。具體來說，同一用戶很可能分別注冊了Amazon與沃爾瑪，因此兩個網站都掌握著該用戶的一套數據。但由于兩個網站保持離散且隔離性極佳，因此除非擁有明確的數據訪問授權，否則二者都意識到該用戶的數據也存在于另一網站之上。

第四，具備可傳遞性。所謂微服務的可傳遞性，代表著我們可以將其“打包”至部署單元，例如容器鏡像或者無服務器函數當中，并隨時通過CI/CD流程部署到給定的目標中。

舉例來說，開發(fā)人員可以輕松將可傳遞微服務部署至Google Cloud這類云服務商。萬一需要將其部署至其他云平臺，開發(fā)者則可隨時將同一項微服務傳遞至AWS。

第五，具備臨時性。微服務的臨時性，意味著我們可以隨時將其銷毀，而后立即將服務恢復至最近的已知狀態(tài)。

容器的臨時性質不僅決定了當前容器發(fā)生離線后、應用程序狀態(tài)的管理方式，同時也將影響到活動線程的管理思路甚至是活動線程的具體設計，確保代碼不存在基于線程的依賴項。

這五大黃金原則，應當成為一切微服務架構的核心設計要求。請認真考量每項原則，據此建立起適合當前應用程序的良好架構。