本文將探討微服務(wù)的演化架構(gòu)，介紹在建立微服務(wù)策略時要考慮的流行模式。還將通過案例分析簡要介紹如何實施這些策略。

微服務(wù)：演化架構(gòu)的性質(zhì)

架構(gòu)通常是按照據(jù)預定義的原則來創(chuàng)建的，這些原則有助于反映企業(yè)的業(yè)務(wù)策略目標。業(yè)務(wù)模式可能很少改變，但在當今環(huán)境中，企業(yè)希望建立高度可擴展的業(yè)務(wù)來應對更多的交易并為更多的客戶服務(wù)。他們需要有靈活的運營流程來快速進軍新市場，并提高現(xiàn)有市場中的創(chuàng)新能力。一些不變的共同目標催生了一組架構(gòu)原則，促使企業(yè)以進化方式搭建、設(shè)計、實現(xiàn)和運行 IT 系統(tǒng)。演化架構(gòu)的最重要原則之一是，能夠支持技術(shù)和業(yè)務(wù)領(lǐng)域的多個維度上的持續(xù)和增量變化。

軟件的傳統(tǒng)架構(gòu)元素可能很難改變。這意味著在制定決策并設(shè)計和實現(xiàn)組件后，很難更改系統(tǒng)的架構(gòu)。隨著分層架構(gòu)和實施這些架構(gòu)的模式不斷出現(xiàn)，設(shè)計系統(tǒng)的方式已發(fā)生了一些變化。圖 1 顯示了一種推動系統(tǒng)演化的典型分層架構(gòu)的示例。

圖 1 一個分層架構(gòu)示例

借助分層架構(gòu)，很容易在每層實現(xiàn)更改，而不會影響系統(tǒng)的其他部分。例如，如果想更改持久性層中的一個組件，此更改在理論上對業(yè)務(wù)和數(shù)據(jù)庫層的影響很小，對演示層沒有影響。這代表著一定程度的演化，系統(tǒng)有 4 個不斷演化的機會；4 個不同層中的每一個層都可以演化。但是，這種演化僅能在一個維度上實現(xiàn)：架構(gòu)的技術(shù)方面。

向架構(gòu)中增加業(yè)務(wù)領(lǐng)域視角后，該視角沒有演化維度。根據(jù)更改需求，在業(yè)務(wù)領(lǐng)域中實現(xiàn)更改可能很難；業(yè)務(wù)領(lǐng)域中的更改通常需要觸及系統(tǒng)的不同模塊或?qū)?。例如，通常很難對系統(tǒng)提供的服務(wù)的客戶執(zhí)行更改，包括相關(guān)信息和流。出現(xiàn)困難是因為，客戶的某些部分位于業(yè)務(wù)層，而其他部分分散在數(shù)據(jù)層、演示層和其他層。

微服務(wù)架構(gòu)在性質(zhì)上是一種演化架構(gòu)。它的典型特征之一是，每個服務(wù)形成自己的有界上下文，在操作上與系統(tǒng)中的其他所有服務(wù)都不同。從很大程度上講，該架構(gòu)的技術(shù)方面完全封裝在系統(tǒng)中的每個服務(wù)內(nèi)。您可以輕松地從系統(tǒng)中取出一個服務(wù)，放入另一個服務(wù)來取代它，而不會影響其他服務(wù)。這是由于該架構(gòu)風格中包含的高度解耦原則。因此，微服務(wù)架構(gòu)更加靈活。這種靈活性帶來了演化系統(tǒng)中每個服務(wù)的能力。

圖 2 展示一種典型微服務(wù)架構(gòu)的架構(gòu)概略圖示例。請注意，API 網(wǎng)關(guān)是微服務(wù)架構(gòu)的一種強制要求。但是，通過將 API 請求路由到合適的微服務(wù)，可以讓 API 網(wǎng)關(guān)處理不同的請求，這非常不錯。如果使用 API 網(wǎng)關(guān)，請小心設(shè)計和實現(xiàn)它，以避免服務(wù)之間的耦合。每個微服務(wù)都可以有多個微組件，這些組件可能分散在不同的層中。圖 1 展示了微服務(wù)類型。

圖 2 微服務(wù)架構(gòu)中的更多可演化維度

演化實踐和模式

擁有一種演化架構(gòu)，對構(gòu)建更靈活的業(yè)務(wù)模型很重要。本節(jié)介紹可用作演化架構(gòu)的推動力的實踐和模式。

持續(xù)集成、持續(xù)交付

持續(xù)集成 (CI) 是一種軟件開發(fā)實踐，其中軟件開發(fā)人員頻繁地（通常是每天）集成他們的工作，導致每天多次進行集成。這種首選實踐背后的思路是，盡早隔離潛在的集成問題，以解決可能發(fā)生的問題。CI 通過一種自動化流程提供支持，該流程包含構(gòu)建和測試活動，以便快速驗證每次構(gòu)建和檢測集成錯誤。因為可以更早隔離和發(fā)現(xiàn)潛在問題，所以 CI 有助于在開發(fā)期間顯著減少集成問題，最終有助于快速交付產(chǎn)品。

CI 通常與持續(xù)交付 (CD) 結(jié)合使用，后者指的是不斷將每個通過測試的良好構(gòu)建版本發(fā)布到生產(chǎn)中。通過采用 CI 和 CD，開發(fā)人員可以減少花費在修復錯誤上的時間，增加花費在開發(fā)新功能或增強現(xiàn)有功能上的精力。CI 和 CD 的采用帶來了更高業(yè)務(wù)價值的影響。

CI 和 CD 受到在開發(fā)周期的每個步驟（包括創(chuàng)建基礎(chǔ)架構(gòu)的步驟）中利用自動化的驅(qū)動。由于云技術(shù)及 CI 和 CD 工具的出現(xiàn)和日趨成熟，自動化也已演化。CI 和 CD 都在架構(gòu)的演化過程中發(fā)揮著關(guān)鍵作用。

Strangler 應用程序

Martin Fowler 在 2004 年發(fā)表的原創(chuàng)文章《Strangler 應用程序》中引入了術(shù)語 Strangler應用程序。在此模式下，一個新系統(tǒng)會捕獲并攔截對成熟應用程序的調(diào)用，將它們路由到其他處理函數(shù)，并逐步替換這些應用程序。從第一步開始重寫整個現(xiàn)有系統(tǒng)具有一定的風險；與切換(cut-over) 重寫方法相比，Strangler 應用程序方法減少了更多風險。在從整體式架構(gòu)朝微服務(wù)架構(gòu)轉(zhuǎn)變的過程中，能夠以增量方式重構(gòu)整體式應用程序。您逐步構(gòu)建一個由微服務(wù)組成的新應用程序；然后將此應用程序與該整體式應用程序一起運行。隨著時間的推移，整體式應用程序處理的功能會逐步減少，直到完全消失或成為新微服務(wù)的一部分。圖 3 描述了使用 Strangler 應用程序模式的轉(zhuǎn)變過程。

圖 3 逐步替代一個應用程序

使用 Strangler 應用程序模式，得到的架構(gòu)仍然擁有之前的整體式應用程序和新服務(wù)。該架構(gòu)還有另外兩個主要組件：

• 調(diào)度程序：此組件可用作一個請求路由器，它處理傳入請求的方法是：將與新功能對應的請求路由到新服務(wù)，將以前的請求路由到現(xiàn)有的整體式應用程序。

• IC：這些組件位于新服務(wù)、整體式應用程序或同時位于二者中。它們負責將整體式應用程序與新創(chuàng)建的服務(wù)集成。您可以不完全替換整體式應用程序的各部分；可以將它們包裝為一個記錄系統(tǒng)，讓它以一組應用編程接口 (API) 的形式存在。

演化架構(gòu)的一個原則是隨時準備處理未知情況，也就是說，對未來的發(fā)展保持前瞻性而不是預測性。在自然演化的影響下，您現(xiàn)在構(gòu)建的功能在未來會變過時并被替代。因此，這種在成熟應用程序逐步消失的過程中設(shè)計新的應用程序油然而生。

演化數(shù)據(jù)庫重構(gòu)和部署

通常，數(shù)據(jù)庫（更確切地講，數(shù)據(jù)庫中的數(shù)據(jù)）是 IT 系統(tǒng)內(nèi)最重要的資產(chǎn)。在您的系統(tǒng)演化時，還必須更改該資產(chǎn)，以便與應用程序代碼更改保持一致。這里的數(shù)據(jù)庫更改既包括數(shù)據(jù)庫結(jié)構(gòu)更改，也包括數(shù)據(jù)從舊結(jié)構(gòu)向新結(jié)構(gòu)的遷移。您甚至可能需要考慮在不同類型的數(shù)據(jù)庫之間遷移。例如，將數(shù)據(jù)庫的部分或全部內(nèi)容從關(guān)系數(shù)據(jù)庫管理系統(tǒng) (RDBMS) 轉(zhuǎn)變?yōu)?NoSQL 風格。這種情況下的數(shù)據(jù)重構(gòu)和遷移更具挑戰(zhàn)性。不幸的是，傳統(tǒng)的數(shù)據(jù)庫更新工具和流程不夠創(chuàng)新和成熟，無法趕上應用程序開發(fā)方法的快速發(fā)展節(jié)奏。這種情況可能會阻礙應用程序的快速發(fā)布。

我們需要一種受自動化支持的新型數(shù)據(jù)庫變更管理和部署方法，以便在像微服務(wù)架構(gòu)這樣的演化架構(gòu)中執(zhí)行持續(xù)更改和增量更改。本節(jié)將討論一些技術(shù)，將它們作為讓數(shù)據(jù)庫更改的演化與應用程序代碼更改更加一致的建議做法。在《重構(gòu)數(shù)據(jù)庫：演化數(shù)據(jù)庫設(shè)計》一書中，Scott Ambler 和 Promod Sadalage 介紹了在制定數(shù)據(jù)庫重構(gòu)策略時可用作指南的 13 條經(jīng)驗教訓。這些經(jīng)驗教訓為數(shù)據(jù)重構(gòu)的 3 個步驟提供了基礎(chǔ)：將大更改分解為小更改，對更改執(zhí)行版本控制，并自動化數(shù)據(jù)庫部署。

將大更改分解為小更改

如果您要執(zhí)行一項較大的數(shù)據(jù)庫更改，可將它拆分為更小的更改；讓它們成為一些小型的、可單獨測試的更改。每項更改通常是數(shù)據(jù)庫結(jié)構(gòu)更改、數(shù)據(jù)遷移和關(guān)聯(lián)的訪問代碼的組合。通過這種方式，可以快速隔離更改可能在這些小片段中產(chǎn)生的任何可能故障，隨后采取相應措施來對它們進行更正。這種分解的目的也是將數(shù)據(jù)庫更改映射到使用這些更改的應用程序功能。這有助于以增量方式持續(xù)地將更改部署到同一個敏捷流程中。

對更改執(zhí)行版本控制

要執(zhí)行版本控制，可以先根據(jù)需要組織數(shù)據(jù)庫更改腳本。確保更改腳本存儲在與應用程序源代碼相同的存儲庫中。另外，確保您擁有與代碼相同的目錄結(jié)構(gòu)和命名約定。這樣，您就可以讓數(shù)據(jù)庫更改與需要這些更改的特定版本中的特定應用程序更改保持一致。在結(jié)構(gòu)上保持一致后，在數(shù)據(jù)庫更改腳本上應用版本控制。此過程有助于簡化數(shù)據(jù)庫更改的部署，為數(shù)據(jù)庫團隊與其他團隊的協(xié)調(diào)和協(xié)作提供共同基礎(chǔ)。

自動化數(shù)據(jù)庫部署

自動化是管理和部署演化數(shù)據(jù)庫更改的關(guān)鍵。確保應用程序代碼更改與數(shù)據(jù)庫更改一致。為此，在合適的粒度水平上進行分解，重組數(shù)據(jù)庫更改腳本，并應用版本控制。完成這一步后，您就擁有了一種受自動化支持的、更支持演化的數(shù)據(jù)庫部署方法。然后，可以通過使用敏捷 CI 和 CD 實踐，采用與應用程序代碼部署類似的方式實現(xiàn)數(shù)據(jù)庫部署自動化。

演化架構(gòu)實戰(zhàn)

本節(jié)將介紹如何應用演化方法，構(gòu)建一種支持不斷更改的更靈活架構(gòu)。本節(jié)通過虛構(gòu)公司 A 的一個示例應用程序的案例分析來演示此方法。技術(shù)架構(gòu)通常受業(yè)務(wù)策略需求推動。第 1 部分'微服務(wù)'介紹了為幫助您開始為整體式應用程序構(gòu)建演化策略而需要滿足的業(yè)務(wù)需求。

以下基本步驟可作為轉(zhuǎn)型指南：

1.從產(chǎn)品數(shù)據(jù)開始實施演化策略：客戶在其網(wǎng)站上查找產(chǎn)品數(shù)據(jù)時遇到麻煩。目的是讓數(shù)據(jù)可用并采用一種更交互式的方式呈現(xiàn)它們。通過將數(shù)據(jù)遷移到 Elasticsearch 數(shù)據(jù)庫，客戶能執(zhí)行更強大的搜索。這可作為在云上構(gòu)建新微服務(wù)的起點，所以考慮將數(shù)據(jù)遷移到 NoSQL 模型，建立新索引，并部署到云環(huán)境。

2.繼續(xù)處理帳戶服務(wù)，獲取客戶的更多信息，以便個性化提供給他們的內(nèi)容。這種個性化可改善客戶體驗?？赏ㄟ^將現(xiàn)有客戶數(shù)據(jù)與社交數(shù)據(jù)相結(jié)合來滿足這一需求，實現(xiàn)一種基于 JSON 的潛在的新數(shù)據(jù)模型。

3.將部分客戶數(shù)據(jù)遷移到云。考慮一種混合云集成模式，以解決之前的數(shù)據(jù)源與新創(chuàng)建的數(shù)據(jù)源之間的數(shù)據(jù)同步問題。

4.優(yōu)化用戶界面 (UI) 層，以便更好地服務(wù)用戶。首先從支持移動平臺開始，然后使用微服務(wù)方法，根據(jù)新數(shù)據(jù)模型以增量方式更新 UI。

5.訂購是轉(zhuǎn)換和遷移的最后一步。要轉(zhuǎn)換為微服務(wù)，首先可以圍繞當前的訂購組件創(chuàng)建一組 API，以便提高靈活性和解耦程度。這使您能為未來的步驟做好準備。

逐步轉(zhuǎn)變?yōu)槟夸浄?wù)

關(guān)于公司 A 提供的產(chǎn)品的信息是該公司業(yè)務(wù)的核心數(shù)據(jù)集。讓客戶能夠以最輕松和交互的方式訪問該數(shù)據(jù)，這是架構(gòu)取得成功的關(guān)鍵因素。產(chǎn)品相關(guān)組件是啟動演化策略的不錯候選組件。得到的工件可能是一個新微服務(wù)，它在云環(huán)境中運行，以實現(xiàn)恢復和擴展能力。在此示例中，Catalog 服務(wù)是新服務(wù)的名稱。因為產(chǎn)品邏輯完全被移動到新微服務(wù)，所以數(shù)據(jù)也必須逐步遷移到同一個云平臺。這消除了新服務(wù)需要調(diào)用數(shù)據(jù)庫來填充數(shù)據(jù)時可能產(chǎn)生的任何延遲。

實現(xiàn)新目錄的技術(shù)有許多。但是，在考慮演化方法的同時，還要考慮保持整體式應用程序（基于 Java）中使用的相同技術(shù)棧，以避免同時執(zhí)行大規(guī)模更改?？梢愿鶕?jù)業(yè)務(wù)需求，根據(jù)制定架構(gòu)決策時市場上已有的特定技術(shù)的可用性和成熟度，在以后的步驟中更改技術(shù)棧。為了將服務(wù)代碼快速部署到運行時實例中，云平臺（比如 IBM Bluemix）提供了各種不同的選擇。新創(chuàng)建的 Catalog 服務(wù)的數(shù)據(jù)也可以先保存在關(guān)系數(shù)據(jù)庫管理模型中，以避免任何大的更改。

下一步是將數(shù)據(jù)遷移到更加現(xiàn)代的、輕量的 NoSQL 和 JSON 模型，以改善搜索體驗。

替代客戶和訂單組件

業(yè)務(wù)持續(xù)性對公司 A 很重要，因此必須小心完成轉(zhuǎn)型過程，在轉(zhuǎn)型過程中不得中斷服務(wù)。為了減輕系統(tǒng)宕機的風險，可以使用 Strangler 應用程序技術(shù)。

與客戶相關(guān)的業(yè)務(wù)組件和數(shù)據(jù)被分解和轉(zhuǎn)換為更善于演化的新模型，但與此同時，舊組件將繼續(xù)并行運行。流往舊客戶和組件的流量被逐漸轉(zhuǎn)移到新創(chuàng)建的服務(wù)。

以進化方式將用戶界面轉(zhuǎn)換為 UI 微服務(wù)

公司 A 的一個業(yè)務(wù)需求是擴展系統(tǒng)，以涵蓋使用移動設(shè)備的客戶。此背景下的客戶包括現(xiàn)有客戶和潛在的新客戶。為了滿足該需求，執(zhí)行了以下主要步驟，將它們作為將用戶界面轉(zhuǎn)換為微服務(wù)架構(gòu)的參考步驟：

• 更改 CustomerServiceDojo 模塊以支持移動用戶，并朝響應式設(shè)計方法更進一步。

• 通過采用了響應式設(shè)計的客戶端庫（例如 Bootstrap 和 Angular）來改善用戶體驗，讓 UI 更加模塊化且更容易更改。

• 首先將 UI 層遷移到云環(huán)境，以便更快地開發(fā)、部署和適應更改。

接下來，將介紹如何識別整體式應用程序中適合采用微服務(wù)架構(gòu)和實踐的候選者，還將介紹如何設(shè)計和重構(gòu)新組件。

識別候選功能

適合演化為微服務(wù)架構(gòu)的候選整體式應用程序，是包含會導致任何以下情形的組件的整體式應用程序：

• 由于難以維護、修改和快速產(chǎn)生成效，導致推出新服務(wù)的上市周期很長，所以您無法足夠快地部署應用程序來滿足需求。或許業(yè)務(wù)部門需要一個新功能來利用新的市場機會，或者您希望鏈接到一個新社交媒體服務(wù)。在任何一種情況下，您都無法及時構(gòu)建、測試和部署應用程序。

• 您無法應用單一部署。即使是細微的更改或增強，構(gòu)建、測試和部署它們通常也要涉及其他模塊或組件，因為同一個 .ear 或 .war 文件包內(nèi)不存在模塊和組件分離。

• 只有一種技術(shù)選擇，而且您不能利用其他企業(yè)采用的新技術(shù)、庫或技巧。這種情況可以通過多種方式來說明?；蛟S您當前的技術(shù)棧不支持您需要的功能。例如，您想自動從代碼生成文檔，或者您想鏈接到新服務(wù)，但您的系統(tǒng)或平臺中目前使用的技術(shù)沒有提供這些功能。

• 您的大型系統(tǒng)擁有以下特征：

– 內(nèi)存中包含大量數(shù)據(jù)

– 操作的 CPU 使用率很高

– 無法擴展應用程序的一部分；通常必須擴展整個應用程序

– 無法輕松地更新和維護

– 代碼依賴關(guān)系難以管理

• 由于代碼的復雜性和大規(guī)模，很難培訓新的開發(fā)人員。

轉(zhuǎn)變?yōu)槲⒎?wù)的考慮因素

在轉(zhuǎn)變?yōu)槲⒎?wù)之前，請考慮以下重要方面：

• 開發(fā)平臺的靈活性

微服務(wù)支持靈活地為工作選擇正確工具；它的思路是每個微服務(wù)都可以通過一種不同的技術(shù)（語言和數(shù)據(jù)存儲）提供支持。根據(jù)特定服務(wù)的需求，為系統(tǒng)的不同部分提供不同的數(shù)據(jù)存儲技術(shù)可能會更好一些。類似地，微服務(wù)可以使用不同的語言；這使您能為特定問題選擇首選語言，而不是遵循標準。

• 根據(jù)功能和職責進行設(shè)計

微服務(wù)實現(xiàn)了組件和職責的分離：每個微服務(wù)負責一個確定的主題。這樣，您就可以在系統(tǒng)的特定部分中應用新功能或改進，避免錯誤，以及避免損害正常工作的系統(tǒng)部分。這種方法也可用于隔離舊功能；可通過添加微服務(wù)來向整體式系統(tǒng)添加新功能。

• 輕松地重寫完整的服務(wù)

通常，微服務(wù)是容易重寫、維護和更改的小型服務(wù)，它們提供了強大的封裝模型，以及安全的重構(gòu)和重寫方式。

• 靈活地執(zhí)行更改

對于微服務(wù)，您可以根據(jù)您對系統(tǒng)和領(lǐng)域的了解加深，推遲決策及靈活地增強架構(gòu)。您可以將困難的決策（比如有關(guān)數(shù)據(jù)存儲技術(shù)的決策）推遲到絕對需要它們時。例如，一個服務(wù)提供的唯一功能是對一個數(shù)據(jù)存儲器執(zhí)行領(lǐng)域感知的瘦包裝，但要正確實現(xiàn)的最重要功能是其他服務(wù)交互的接口。

• 創(chuàng)造業(yè)務(wù)價值

業(yè)務(wù)負責人看到了微服務(wù)的好處，因為他們希望其團隊能夠快速響應新的客戶和市場需求。如果采用整體式應用程序開發(fā)方法，IT 響應很緩慢。微服務(wù)更符合業(yè)務(wù)需求，因為它們支持比整體式服務(wù)更頻繁和更快地交付。微服務(wù)使業(yè)務(wù)負責人能夠快速獲取反饋并相應地調(diào)整其投資。

其他益處如下：

– 團隊關(guān)注范圍更小，使業(yè)務(wù)負責人能夠更輕松、更有效地管理資源，例如將資源從低影響力業(yè)務(wù)區(qū)域移到更高影響力區(qū)域。

– 通過擴展單個微服務(wù)來消除瓶頸，實現(xiàn)更流暢的用戶體驗。

– 識別和消除重復服務(wù)，從而減少開發(fā)成本。

• 靈活擴展的能力

采用微服務(wù)，可擴展系統(tǒng)的不同部分；每個微服務(wù)負責特定的功能，這樣就可以實現(xiàn)更靈活的擴展。

• 安全分區(qū)

安全架構(gòu)師堅持采用分層方法來構(gòu)建系統(tǒng)，以避免讓重要代碼在 Web 服務(wù)器上運行的風險。微服務(wù)可提供分區(qū)功能，這類似于傳統(tǒng)的分層方法。業(yè)務(wù)邏輯和關(guān)鍵數(shù)據(jù)存儲可與負責呈現(xiàn) HTML 的服務(wù)分開?？蔀楦鱾€微服務(wù)之間的通信設(shè)置防火墻、加密和執(zhí)行其他保護方法。

• 團隊技能

對于微服務(wù)，團隊可以按技能或位置進行分組，避免讓不同團隊處理同一個代碼庫的相關(guān)風險或困難。

將整體式應用程序分解為微服務(wù)

本節(jié)介紹將整體式應用程序分解為微服務(wù)的技術(shù)。

設(shè)計微服務(wù)

微服務(wù)架構(gòu)的一個重要優(yōu)勢是，可自由決定對每個服務(wù)使用的技術(shù)棧和微服務(wù)大小。存在這種自由是因為，微服務(wù)架構(gòu)首先對用戶體驗有清楚的了解。

使用設(shè)計思維來限定和識別微服務(wù)

設(shè)計思維是一種構(gòu)想整體用戶體驗的流程。不再專注于一項功能，微服務(wù)專注于用戶體驗（也就是說，用戶擁有該體驗時的想法、行為和感覺）。設(shè)計思維有助于將工作范圍限定到適用的、可發(fā)布的功能單元。這種設(shè)計有助于更輕松地從功能上分解和識別微服務(wù)。設(shè)計思維包含以下概念：

• Hills

• Hills Playback

• 方案

• 用戶案例

• Epic

• 贊助用戶

• 識別微服務(wù)機會

Hills

Hill 是對您的發(fā)布時間表的業(yè)務(wù)目標的表述。Hill 定義了您希望誰使用哪些資源來如何實現(xiàn)目標。團隊通常為每個項目確定 3 個 Hill 和一個技術(shù)基礎(chǔ)。Hill 傳達領(lǐng)導者的意圖，允許團隊自行決定如何解釋和實施一種提供流暢用戶體驗的解決方案。Hill 的定義必須以用戶為目標，它必須是可度量的。在使用 Hill 時，避免使用模糊或無法量化的目標。示例 1 給出了一個示例 Hill。

示例 1 示例 Hill

Hills Playback

Hills Playback 提供團隊想要實現(xiàn)的目標的摘要。Hills Playback 設(shè)定特定發(fā)布時間段的工作范圍。Playback Zero 是團隊完成組建，并向業(yè)務(wù)贊助者提供其想要實現(xiàn)的成果的時刻。Playback 由來自跨職能團隊的參與者和嘗試執(zhí)行 Hill 的贊助用戶每周執(zhí)行一次。圖 4 展示了一個 Hills Playback 時間表。

圖 4 Hills Playback 時間表

方案

方案是一個實現(xiàn)某種體驗的工作流，它設(shè)定 Hills Playback 中使用的案例和上下文。大型方案可進一步分解為場景和產(chǎn)品用戶案例。方案獲取'現(xiàn)狀'方案并制定'目標'方案。

用戶案例

用戶案例是一個獨立的、可編碼的需求，可在一兩天內(nèi)開發(fā)完成。用戶案例是用用戶體驗來表達的，例如'作為開發(fā)人員，我想找到示例并快速將它們部署到 Bluemix，以便我可以試用它們。'

Epics

Epics 將案例分組為一種可在整個方案中多次重用的形式，以避免案例出現(xiàn)重復。

贊助用戶

贊助用戶是全程參與項目，代表項目的目標用戶的用戶。他們應該領(lǐng)導或參與 Playback。贊助用戶可以是使用包含微服務(wù)的應用程序的客戶。他們也可以是內(nèi)部開發(fā)人員，使用您開發(fā)的微服務(wù)入門工具來支持您的 DevOps 發(fā)布流程。

識別微服務(wù)機會

對于每種設(shè)計，識別一個服務(wù)在其他設(shè)計中的潛在重用機會。'Hill'中給出的 Hill 定義針對的是使用 Bluemix 的 iOS 解決方案。

根據(jù)這個 Hill 示例，您有以下需求：

• 能夠部署到 Bluemix 和其他網(wǎng)站

• 能夠作為單獨服務(wù)部署到 Bluemix

• 能夠部署到 Bluemix 微服務(wù)團隊

Deploy to Bluemix 微服務(wù)團隊負責實現(xiàn)該服務(wù)。該團隊還負責對使用該微服務(wù)的案例執(zhí)行功能和系統(tǒng)集成測試。該服務(wù)包含日志數(shù)據(jù)，用于收集使用情況信息。這有助于更好地量化微服務(wù)對業(yè)務(wù)的影響。它顯示了部署的最流行應用程序，以及在用戶部署一個示例后的用戶跟蹤信息。

選擇實現(xiàn)技術(shù)棧

因為微服務(wù)系統(tǒng)由各個作為不同進程運行的服務(wù)組成，所以我們希望任何能支持通信或消息協(xié)議的合格技術(shù)都可使用。舉例而言，通信協(xié)議可能是 HTTP 和 REST；消息協(xié)議可能是 MQ 遙測傳輸 (MQTT) 或高級消息隊列協(xié)議 (AMQP)。在選擇實現(xiàn)技術(shù)棧時，必須考慮多個方面：

• 同步還是異步

經(jīng)典技術(shù)棧（比如 Java Platform Enterprise Edition (Java EE)）會同時攔截網(wǎng)絡(luò)請求。因此，它們必須在單獨的線程中運行，才能處理多個并發(fā)請求。

異步技術(shù)棧（比如 Java Message Server (Java EE JMS)）使用事件循環(huán)來處理請求，該循環(huán)通常是單線程的，但在需要下游輸入和輸出 (I/O) 操作來處理請求時，也可以處理更多請求。

• I/O 受限還是處理器 (CPU) 受限

Node.js 等解決方案非常適合主要處理 I/O 操作的微服務(wù)。Node.js 規(guī)定在等待 I/O 請求完成的過程中不持有所有線程。但是，因為請求是在事件循環(huán)中執(zhí)行的，所以復雜的計算會給調(diào)度程序處理其他請求的能力帶來負面影響。如果微服務(wù)正在執(zhí)行長期運行的操作，那么最好執(zhí)行以下操作之一：

– 將長期運行的操作卸載到一組使用最適合 CPU 密集型工作的技術(shù)棧（例如 Java、Go 或 C）編寫的工作者線程上。

– 在具有多線程能力的技術(shù)棧中實現(xiàn)整個服務(wù)。

• 內(nèi)存和 CPU 需求

微服務(wù)是用復數(shù)形式來表達的，因為您會運行多個微服務(wù)，而不是一個。每個微服務(wù)可通過運行它的多個實例得到進一步擴展。有許多進程要處理，而且內(nèi)存和 CPU 需求是評估整個系統(tǒng)的操作成本時的重要考慮因素。從這個角度講，傳統(tǒng)的 Java EE 技術(shù)棧不太適合微服務(wù)，因為它們針對運行單個應用程序容器進行了優(yōu)化的，而不是針對多個容器。

但是，Java EE 技術(shù)棧（比如 IBM WebSphere Liberty）可緩解這一問題。同樣地，Node.js 和 Go 等技術(shù)棧是合適的技術(shù)，因為它們更輕便，而且每個實例需要的內(nèi)存和 CPU 資源更少。

在大部分系統(tǒng)中，開發(fā)人員使用 Node.js 微服務(wù)提供網(wǎng)頁，這是由于 Node.js 與在瀏覽器中運行的客戶端 JavaScript 的親和性 (affinity)。開發(fā)人員使用 CPU 友好的平臺（Java 或 Go）運行后端服務(wù)，并重用現(xiàn)有系統(tǒng)庫和工具包。但是，始終可以在新微服務(wù)中嘗試新技術(shù)棧，而不會因為高成本的返工拖累系統(tǒng)的剩余部分。

確定微服務(wù)的大小

在設(shè)計微服務(wù)系統(tǒng)時，最難處理、最不明確的任務(wù)之一就是確定各個微服務(wù)的數(shù)量和大小。對于最佳大小，并沒有嚴格的規(guī)定，但有些做法已在實際系統(tǒng)中得到檢驗。

可單獨或結(jié)合使用以下技術(shù)：

• 文件數(shù)量

可以按微服務(wù)包含的文件數(shù)量來確定系統(tǒng)中的微服務(wù)大小。這是一種不夠嚴謹?shù)拿枋觯袝r您可能想分解占用過大物理空間的微服務(wù)。大型服務(wù)很難處理，很難部署，而且啟動和停止所花的時間更長。但是請注意，不要讓它們變得太小。當微服務(wù)太小時（太小的服務(wù)通常被視為一種反模式），部署和運行這樣一個服務(wù)的資源成本會超過它的效用。盡管人們通常將微服務(wù)與 UNIX 設(shè)計精神（即做一件事就要將它做好）進行比較，但最好從較大的服務(wù)開始著手。始終可以在以后將一個服務(wù)拆分為兩個。

• 太多的職責

同時負責不同對象的服務(wù)可能需要拆分，因為它通常很難測試、維護和部署。即使所有職責都是相同類型的（例如 REST 端點），但一個服務(wù)可能有太多職責要履行。

• 服務(wù)類型

一種不錯的規(guī)則是，微服務(wù)僅做一件事，例如以下任務(wù)之一：

– 處理身份驗證

– 提供多個 REST 端點

– 提供多個網(wǎng)頁

通常，您并不想將這些不同的職責混在一起。這可能看起來與職責過多的技術(shù)無異，其實不然。它處理的是職責的質(zhì)量，而不是數(shù)量。一種反模式可能是，一個服務(wù)既提供網(wǎng)頁，也提供 REST 端點，或者用作工作者線程。

• 有界上下文分離

在現(xiàn)有系統(tǒng)被分割為微服務(wù)時，這種技術(shù)很重要。該名稱來自 Martin Fowler 提出的一種設(shè)計模式。

http:///bliki/BoundedContext.html

它表示系統(tǒng)中的各部分相對獨立，所以它們與一個服務(wù)器的鏈接較少，可轉(zhuǎn)換為微服務(wù)。如果一個微服務(wù)需要與另外 10 個微服務(wù)通信才能完成它的任務(wù)，這可能表明在整體式應用程序中的錯誤位置進行了分割。

• 團隊組織

許多微服務(wù)系統(tǒng)都是圍繞負責編寫代碼的團隊來組織的。因此，微服務(wù)沿團隊界線進行分割，以最大化團隊的獨立性。

微服務(wù)成為一種流行的架構(gòu)和組織模式的重要原因之一是，它們允許團隊在云中計劃、開發(fā)和部署系統(tǒng)功能，而無需頻繁協(xié)調(diào)。因此，我們期望微服務(wù)的數(shù)量和大小由組織和技術(shù)原理來確定。

精心設(shè)計的微服務(wù)系統(tǒng)會結(jié)合使用這些技術(shù)。這些技術(shù)需要在使用該系統(tǒng)的過程和經(jīng)驗中積累的良好判斷力。在獲得該經(jīng)驗之前，首先創(chuàng)建可能較大的微服務(wù)（更像迷你服務(wù)），直到觀察到更多適合繼續(xù)分割的'斷層線'。

備注：在逆向代理背后的精心設(shè)計的系統(tǒng)中，這種重組可以無中斷地運行。如果一個微服務(wù)提供了兩個 URL 路徑，那么兩個新的微服務(wù)可以分別提供一個路徑。微服務(wù)系統(tǒng)設(shè)計是一個持續(xù)過程，不是必須一次就完成。

重構(gòu)

重構(gòu)是一種現(xiàn)代化應用程序并獲得新結(jié)構(gòu)和新平臺所提供的資源的實踐。整體式應用程序向微服務(wù)的遷移遵循相同的路線。重構(gòu)將微服務(wù)添加到應用程序中，而不更改應用程序的用途。

本節(jié)將介紹一些將整體式應用程序重構(gòu)為微服務(wù)的技術(shù)；其中的內(nèi)容主要基于 Kyle Brown 編寫的這篇 IBM developerWorks? 文章：重構(gòu)到微服務(wù)，第 1 部分：執(zhí)行整體遷移時的考慮事項

重構(gòu)為微服務(wù)的一個原因

從一開始就使用新運行時和編程語言很耗費成本，尤其是在許多代碼都是用 Java 開發(fā)的而且仍能正常工作時。使用微服務(wù)的重構(gòu)是一種更加謹慎的方法，因為可以保持舊系統(tǒng)繼續(xù)運行，將整體式應用程序分數(shù)個部分遷移到一個更可持續(xù)的、最新的平臺。

轉(zhuǎn)變?yōu)槲⒎?wù)的策略

將整體式應用程序轉(zhuǎn)變?yōu)槲⒎?wù)可能涉及到以下策略：

• 將整個整體式應用程序轉(zhuǎn)換為微服務(wù)

從頭開始構(gòu)造基于微服務(wù)的新應用程序可能是最佳選擇。但是，因為該方法可能涉及到一次執(zhí)行太多更改，所以此方法具有一定風險，而且常常導致故障。

• 逐步重構(gòu)

該策略的基本思路是，通過將系統(tǒng)的各部分構(gòu)建為與整體式應用程序一起運行的微服務(wù)，逐步重構(gòu)整體式應用程序。隨著時間的推移，整體式應用程序提供的功能量不斷減少，直到它完全遷移到微服務(wù)。這被視為一種謹慎的策略。Martin Fowler 將這種應用程序現(xiàn)代化策略稱為 Strangler 應用程序。

此方法涉及的其他方面如下：

– 不要在整體式應用程序中添加新功能；這可能會阻止它變得更大。對于所有新功能，請使用獨立的微服務(wù)。

– 創(chuàng)建圍繞業(yè)務(wù)能力而組織的微服務(wù)，每個微服務(wù)負責一個主題。

– 整體式應用程序通常由多層組成，比如演示、業(yè)務(wù)邏輯和數(shù)據(jù)訪問層。您可以為演示層創(chuàng)建一個微服務(wù)，為業(yè)務(wù)訪問數(shù)據(jù)創(chuàng)建另一個微服務(wù)。關(guān)注點始終放在功能和業(yè)務(wù)上。

– 使用領(lǐng)域驅(qū)動設(shè)計 (DDD) 有界上下文，將一個復雜領(lǐng)域細分為多個有界上下文，并在它們之間建立映射關(guān)系，服務(wù)與上下文邊界之間存在著一種自然的關(guān)聯(lián)。

如何將 Java EE 重構(gòu)為微服務(wù)

在將 Java Platform 和 Java EE 應用程序轉(zhuǎn)換為微服務(wù)時，考慮以下重要方面：

• 重新打包應用程序（參見圖 5）

執(zhí)行以下步驟：

a. 拆分企業(yè)存檔文件 (EAR)。

不要將所有相關(guān)的 Web 存檔文件 (WAR) 打包到一個 EAR 中，而是應該將它們拆分為獨立的 WAR。如果更改應用程序上下文根來實現(xiàn)分離，這可能涉及到對代碼執(zhí)行一些細微更改，或者可能需要更改靜態(tài)內(nèi)容。

b. 應用每個服務(wù)一個容器的模式。

接下來應用每個服務(wù)一個容器的模式，將每個 WAR 部署在自己的應用服務(wù)器中，最好部署在自己的容器中（比如 Docker 容器或 Bluemix 即時運行時）。然后您可以獨立地擴展容器。

c. 獨立地構(gòu)建、部署和管理每個 WAR。

拆分它們后，您可以通過自動化的 DevOps 管道（比如 IBM DevOps Pipeline Service）獨立管理每個 WAR。這一步有助于獲得持續(xù)交付的優(yōu)勢。

圖 5 重新打包整體式應用程序

備注：有關(guān)重新打包整體式應用程序的更多信息，請訪問下面的網(wǎng)站：

https://www.ibm.com/devops/method/content/code/practice_refactor_microservices/

• 重構(gòu)整體式代碼（參見圖 6）：

重新打包后，在將部署策略細化到獨立 WAR 級別時，就可以開始尋找重構(gòu)機會：

– 前端

對于通常作為數(shù)據(jù)庫表的前端的簡單程序 servlet/JSP，創(chuàng)建一個可表示為 RESTful 服務(wù)的領(lǐng)域?qū)?。應用領(lǐng)域驅(qū)動設(shè)計來識別您的領(lǐng)域?qū)ο螅@可以幫助您識別缺少的領(lǐng)域服務(wù)層。完成構(gòu)建后，在下一階段，可以重構(gòu)現(xiàn)有的 servlet/JSP 應用程序，以便使用新服務(wù)或使用 JavaScript、HTML5 和 CSS 構(gòu)建新接口，或者將它構(gòu)建為原生移動應用程序。

HTTP 會話狀態(tài)：在這種情況下，將 HTTP 會話狀態(tài)轉(zhuǎn)移到數(shù)據(jù)庫中是一個好方法。

– SOAP 或 EJB 服務(wù)

與一個 RESTful 接口建立映射，并重新實現(xiàn) EJB 會話 bean 接口或 JAX-WS 接口作為 JAX-RS 接口。為此，您可能需要將對象表示轉(zhuǎn)換為 JSON。

– REST 或 JMS 服務(wù)

您可能已有兼容或能夠兼容微服務(wù)架構(gòu)的服務(wù)。首先將每個 REST 或簡單 JMS 服務(wù)與 WAR 的剩余部分分離，然后將每個服務(wù)部署為獨立的 WAR。在此級別上，可以復制支持性 JAR 文件；這只是一種打包風格。

圖 6 重構(gòu)整體式代碼概略圖

• 重構(gòu)整體式數(shù)據(jù)

構(gòu)建和重新打包前幾步中定義的小型服務(wù)后，下一步可能是微服務(wù)采用過程中最困難的問題。這一步將基于當前數(shù)據(jù)模型，為每個微服務(wù)創(chuàng)建一個新數(shù)據(jù)模型。

以下是要遵守的規(guī)則：

– 數(shù)據(jù)孤島（參見圖 7）

首先考慮您的代碼使用的數(shù)據(jù)庫表。如果使用的表與其他所有表獨立，或者包含一些通過關(guān)系聯(lián)接起來的表組成的孤立小島中，您可以將這些表與數(shù)據(jù)設(shè)計中的剩余部分分開。

要確定使用哪個數(shù)據(jù)庫，需要確認您想要使用的查詢類型。如果您使用的大多數(shù)查詢都是基于主鍵的簡單查詢，那么鍵值數(shù)據(jù)庫或文檔數(shù)據(jù)庫可能是最佳選擇。但是，如果有各不相同的復雜聯(lián)接（例如查詢不可預測），那么使用 SQL 可能是最佳選擇。

– 批量數(shù)據(jù)更新

如果只有少量關(guān)系，并決定將數(shù)據(jù)遷移到 NoSQL 數(shù)據(jù)庫中，則需要考慮您是否僅需要對現(xiàn)有數(shù)據(jù)庫執(zhí)行批量更新。通常，在考慮表之間的關(guān)系時，這些關(guān)系沒有考慮時間因素；它們可能并不總是需要保持最新。

在許多情況下，每隔幾小時運行一次數(shù)據(jù)轉(zhuǎn)儲和加載方法可能就足以應對許多情況。

– 對表進行去標準化

如果您與其他表有更多的關(guān)系，可以重構(gòu)（或者用數(shù)據(jù)庫管理員的話說，去標準化）您的表。

通常，使用高度標準化的模式的目的是減少重復（這可以節(jié)省空間），因為磁盤空間很昂貴。但是，磁盤空間現(xiàn)在變便宜了?，F(xiàn)在您必須優(yōu)化查詢時間；去標準化是實現(xiàn)該優(yōu)化的一種簡單方法。

圖 7 重構(gòu)整體式數(shù)據(jù)概略圖

識別并創(chuàng)建新架構(gòu)的示例

本節(jié)基于第 1 部分中小節(jié)“虛構(gòu)公司 A 的業(yè)務(wù)問題”中描述的業(yè)務(wù)案例和整體式應用程序，定義了一種新架構(gòu)。本節(jié)遵循小節(jié)中的理論，并提供了選擇每種新服務(wù)的原因和好處。

架構(gòu)：現(xiàn)有架構(gòu)

當前應用程序是一種典型的 Java 整體式應用程序，它在一個 EAR 包中定義，并在一個應用服務(wù)器內(nèi)運行。該 EAR 包包含針對應用程序的每個部分的特定組件，通常采用分層模式。當前的應用程序使用 JSF 和 Dojo 實現(xiàn)前端，使用 EJB 實現(xiàn)業(yè)務(wù)組件，使用 JPA 實現(xiàn)持久性組件和訪問（DB2? 和 SQL），如圖 9 所示。

圖 9 整體式應用程序架構(gòu)概略圖

架構(gòu)：目標架構(gòu)

新架構(gòu)基于平臺即服務(wù) (PaaS) 云環(huán)境。該架構(gòu)使用服務(wù)來提高對開發(fā)周期的控制 (DevOps)。它還使用了其他可用資源來改進新應用程序的新功能，比如數(shù)據(jù)庫、運行時、安全性、應用服務(wù)器等。它還為每個服務(wù)提供了更加獨立的擴展性。

采用逐步遷移，將 Catalog 和 Account 組件遷移到微服務(wù)，將 Order 組件保留在整體式應用程序中（參見圖 10）。

圖 10 微服務(wù)架構(gòu)概略圖

下面給出每個組件的詳細信息：

• PaaS 平臺

PaaS 提供了一個基于云的環(huán)境，其中包含為構(gòu)建和交付基于 Web 的（云）應用程序的完整生命周期提供支持所需的一切資源，而沒有購買和管理基礎(chǔ)硬件、軟件，以及執(zhí)行配置和托管的成本和復雜性。

PaaS 提供了以下好處：

– 可以更快地開發(fā)應用程序并上市。

– 可以在幾分鐘內(nèi)將新 Web 應用程序部署到云。

– 通過中間件即服務(wù)降低了復雜性。

• 安全網(wǎng)關(guān)

安全 Web 網(wǎng)關(guān)是一種安全解決方案，可阻止不安全的流量進入企業(yè)的內(nèi)部網(wǎng)絡(luò)。企業(yè)使用它保護其員工和用戶，阻止其訪問惡意 Web 流量、網(wǎng)站、病毒和惡意軟件并被其感染。安全網(wǎng)關(guān)還可以確保企業(yè)的監(jiān)管政策得以實施和遵守。在新架構(gòu)中，此組件用于與來自整體式應用程序的數(shù)據(jù)庫 SQL 集成。在新架構(gòu)中，此服務(wù)還負責確保與整體式應用程序的完整性和安全性功能集成。

• 5 種不同的應用程序

這些應用程序如下：

1. 使用 jQuery、Bootstrap 和 AngularJS 的 UI 應用程序

   創(chuàng)建了一個新的前端應用程序，該應用程序使用的技術(shù)和框架使它能在不同的設(shè)備中運行（手機、平板電腦和桌面）。使用來自微服務(wù)的 REST API 檢索必要的業(yè)務(wù)信息（帳戶、目錄和訂單）。

2. Catalog 組件對應的微服務(wù)應用程序

   負責 Catalog 組件的組件已遷移到微服務(wù)，成為一個隔離的應用程序，以實現(xiàn)更好的擴展。另外，使用靈活的技術(shù)向微服務(wù)添加了一個新搜索服務(wù)，以改進每個元素內(nèi)的搜索。該目錄使用提取、轉(zhuǎn)換和加載 (ETL) 操作進行更新，這些操作使用集成的網(wǎng)關(guān)服務(wù)從 SQL 整體式應用程序獲取數(shù)據(jù)。

3. Order 組件對應的微服務(wù)

   Order 組件保留在整體式應用程序中，但創(chuàng)建了一個微服務(wù)來從整體式應用程序中獲取訂單信息，該微服務(wù)使用了一個集成的網(wǎng)關(guān)服務(wù)。

4. Account 組件對應的微服務(wù)

   負責 Account 組件的組件已遷移到微服務(wù)，成為一個隔離的應用程序，以便實現(xiàn)更好的擴展。另外，向 Analytics 服務(wù)添加了一個新 NoSQL 數(shù)據(jù)庫，并集成了社交網(wǎng)絡(luò)。這些新功能提高了為提供新產(chǎn)品來收集信息的潛力。

5. 企業(yè)數(shù)據(jù)中心

   整體式應用程序采取的是部分遷移。在此階段，Order 功能保留在整體式應用程序中。向整體式應用程序添加一個新 API，以便提供訪問訂單信息的能力。

總結(jié)

本文探討了微服務(wù)的演化架構(gòu)，以及介紹了如何識別整體應用程序適合演化為微服務(wù)架構(gòu)。下一部分我們將介紹在將整體式應用程序演化為微服務(wù)架構(gòu)是要考慮的重要的數(shù)據(jù)庫主題。好了，學習愉快，下次再見！

出處：https://www.ibm.com/developerworks/cn/java/j-cn-java-and-microservice-5/index.html?ca=drs-