[[377883]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這五大黃金原則，應(yīng)當成為一切微服務(wù)架構(gòu)的核心設(shè)計要求。請認真考量每項原則，據(jù)此建立起適合當前應(yīng)用程序的良好架構(gòu)。