本文將探討微服務(wù)的演化架構(gòu)，介紹在建立微服務(wù)策略時(shí)要考慮的流行模式。還將通過案例分析簡要介紹如何實(shí)施這些策略。
架構(gòu)通常是按照據(jù)預(yù)定義的原則來創(chuàng)建的，這些原則有助于反映企業(yè)的業(yè)務(wù)策略目標(biāo)。業(yè)務(wù)模式可能很少改變，但在當(dāng)今環(huán)境中，企業(yè)希望建立高度可擴(kuò)展的業(yè)務(wù)來應(yīng)對更多的交易并為更多的客戶服務(wù)。他們需要有靈活的運(yùn)營流程來快速進(jìn)軍新市場，并提高現(xiàn)有市場中的創(chuàng)新能力。一些不變的共同目標(biāo)催生了一組架構(gòu)原則，促使企業(yè)以進(jìn)化方式搭建、設(shè)計(jì)、實(shí)現(xiàn)和運(yùn)行 IT 系統(tǒng)。演化架構(gòu)的最重要原則之一是，能夠支持技術(shù)和業(yè)務(wù)領(lǐng)域的多個(gè)維度上的持續(xù)和增量變化。
軟件的傳統(tǒng)架構(gòu)元素可能很難改變。這意味著在制定決策并設(shè)計(jì)和實(shí)現(xiàn)組件后，很難更改系統(tǒng)的架構(gòu)。隨著分層架構(gòu)和實(shí)施這些架構(gòu)的模式不斷出現(xiàn)，設(shè)計(jì)系統(tǒng)的方式已發(fā)生了一些變化。圖 1 顯示了一種推動(dòng)系統(tǒng)演化的典型分層架構(gòu)的示例。
借助分層架構(gòu)，很容易在每層實(shí)現(xiàn)更改，而不會影響系統(tǒng)的其他部分。例如，如果想更改持久性層中的一個(gè)組件，此更改在理論上對業(yè)務(wù)和數(shù)據(jù)庫層的影響很小，對演示層沒有影響。這代表著一定程度的演化，系統(tǒng)有 4 個(gè)不斷演化的機(jī)會；4 個(gè)不同層中的每一個(gè)層都可以演化。但是，這種演化僅能在一個(gè)維度上實(shí)現(xiàn)：架構(gòu)的技術(shù)方面。
向架構(gòu)中增加業(yè)務(wù)領(lǐng)域視角后，該視角沒有演化維度。根據(jù)更改需求，在業(yè)務(wù)領(lǐng)域中實(shí)現(xiàn)更改可能很難；業(yè)務(wù)領(lǐng)域中的更改通常需要觸及系統(tǒng)的不同模塊或?qū)?。例如，通常很難對系統(tǒng)提供的服務(wù)的客戶執(zhí)行更改，包括相關(guān)信息和流。出現(xiàn)困難是因?yàn)?，客戶的某些部分位于業(yè)務(wù)層，而其他部分分散在數(shù)據(jù)層、演示層和其他層。
微服務(wù)架構(gòu)在性質(zhì)上是一種演化架構(gòu)。它的典型特征之一是，每個(gè)服務(wù)形成自己的有界上下文，在操作上與系統(tǒng)中的其他所有服務(wù)都不同。從很大程度上講，該架構(gòu)的技術(shù)方面完全封裝在系統(tǒng)中的每個(gè)服務(wù)內(nèi)。您可以輕松地從系統(tǒng)中取出一個(gè)服務(wù)，放入另一個(gè)服務(wù)來取代它，而不會影響其他服務(wù)。這是由于該架構(gòu)風(fēng)格中包含的高度解耦原則。因此，微服務(wù)架構(gòu)更加靈活。這種靈活性帶來了演化系統(tǒng)中每個(gè)服務(wù)的能力。
圖 2 展示一種典型微服務(wù)架構(gòu)的架構(gòu)概略圖示例。請注意，API 網(wǎng)關(guān)是微服務(wù)架構(gòu)的一種強(qiáng)制要求。但是，通過將 API 請求路由到合適的微服務(wù)，可以讓 API 網(wǎng)關(guān)處理不同的請求，這非常不錯(cuò)。如果使用 API 網(wǎng)關(guān)，請小心設(shè)計(jì)和實(shí)現(xiàn)它，以避免服務(wù)之間的耦合。每個(gè)微服務(wù)都可以有多個(gè)微組件，這些組件可能分散在不同的層中。圖 1 展示了微服務(wù)類型。
擁有一種演化架構(gòu)，對構(gòu)建更靈活的業(yè)務(wù)模型很重要。本節(jié)介紹可用作演化架構(gòu)的推動(dòng)力的實(shí)踐和模式。
持續(xù)集成 (CI) 是一種軟件開發(fā)實(shí)踐，其中軟件開發(fā)人員頻繁地（通常是每天）集成他們的工作，導(dǎo)致每天多次進(jìn)行集成。這種首選實(shí)踐背后的思路是，盡早隔離潛在的集成問題，以解決可能發(fā)生的問題。CI 通過一種自動(dòng)化流程提供支持，該流程包含構(gòu)建和測試活動(dòng)，以便快速驗(yàn)證每次構(gòu)建和檢測集成錯(cuò)誤。因?yàn)榭梢愿绺綦x和發(fā)現(xiàn)潛在問題，所以 CI 有助于在開發(fā)期間顯著減少集成問題，最終有助于快速交付產(chǎn)品。
CI 通常與持續(xù)交付 (CD) 結(jié)合使用，后者指的是不斷將每個(gè)通過測試的良好構(gòu)建版本發(fā)布到生產(chǎn)中。通過采用 CI 和 CD，開發(fā)人員可以減少花費(fèi)在修復(fù)錯(cuò)誤上的時(shí)間，增加花費(fèi)在開發(fā)新功能或增強(qiáng)現(xiàn)有功能上的精力。CI 和 CD 的采用帶來了更高業(yè)務(wù)價(jià)值的影響。
CI 和 CD 受到在開發(fā)周期的每個(gè)步驟（包括創(chuàng)建基礎(chǔ)架構(gòu)的步驟）中利用自動(dòng)化的驅(qū)動(dòng)。由于云技術(shù)及 CI 和 CD 工具的出現(xiàn)和日趨成熟，自動(dòng)化也已演化。CI 和 CD 都在架構(gòu)的演化過程中發(fā)揮著關(guān)鍵作用。
Martin Fowler 在 2004 年發(fā)表的原創(chuàng)文章《Strangler 應(yīng)用程序》中引入了術(shù)語 Strangler應(yīng)用程序。在此模式下，一個(gè)新系統(tǒng)會捕獲并攔截對成熟應(yīng)用程序的調(diào)用，將它們路由到其他處理函數(shù)，并逐步替換這些應(yīng)用程序。從第一步開始重寫整個(gè)現(xiàn)有系統(tǒng)具有一定的風(fēng)險(xiǎn)；與切換(cut-over) 重寫方法相比，Strangler 應(yīng)用程序方法減少了更多風(fēng)險(xiǎn)。在從整體式架構(gòu)朝微服務(wù)架構(gòu)轉(zhuǎn)變的過程中，能夠以增量方式重構(gòu)整體式應(yīng)用程序。您逐步構(gòu)建一個(gè)由微服務(wù)組成的新應(yīng)用程序；然后將此應(yīng)用程序與該整體式應(yīng)用程序一起運(yùn)行。隨著時(shí)間的推移，整體式應(yīng)用程序處理的功能會逐步減少，直到完全消失或成為新微服務(wù)的一部分。圖 3 描述了使用 Strangler 應(yīng)用程序模式的轉(zhuǎn)變過程。
使用 Strangler 應(yīng)用程序模式，得到的架構(gòu)仍然擁有之前的整體式應(yīng)用程序和新服務(wù)。該架構(gòu)還有另外兩個(gè)主要組件：
調(diào)度程序：此組件可用作一個(gè)請求路由器，它處理傳入請求的方法是：將與新功能對應(yīng)的請求路由到新服務(wù)，將以前的請求路由到現(xiàn)有的整體式應(yīng)用程序。
IC：這些組件位于新服務(wù)、整體式應(yīng)用程序或同時(shí)位于二者中。它們負(fù)責(zé)將整體式應(yīng)用程序與新創(chuàng)建的服務(wù)集成。您可以不完全替換整體式應(yīng)用程序的各部分；可以將它們包裝為一個(gè)記錄系統(tǒng)，讓它以一組應(yīng)用編程接口 (API) 的形式存在。
演化架構(gòu)的一個(gè)原則是隨時(shí)準(zhǔn)備處理未知情況，也就是說，對未來的發(fā)展保持前瞻性而不是預(yù)測性。在自然演化的影響下，您現(xiàn)在構(gòu)建的功能在未來會變過時(shí)并被替代。因此，這種在成熟應(yīng)用程序逐步消失的過程中設(shè)計(jì)新的應(yīng)用程序油然而生。
通常，數(shù)據(jù)庫（更確切地講，數(shù)據(jù)庫中的數(shù)據(jù)）是 IT 系統(tǒng)內(nèi)最重要的資產(chǎn)。在您的系統(tǒng)演化時(shí)，還必須更改該資產(chǎn)，以便與應(yīng)用程序代碼更改保持一致。這里的數(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 風(fēng)格。這種情況下的數(shù)據(jù)重構(gòu)和遷移更具挑戰(zhàn)性。不幸的是，傳統(tǒng)的數(shù)據(jù)庫更新工具和流程不夠創(chuàng)新和成熟，無法趕上應(yīng)用程序開發(fā)方法的快速發(fā)展節(jié)奏。這種情況可能會阻礙應(yīng)用程序的快速發(fā)布。
我們需要一種受自動(dòng)化支持的新型數(shù)據(jù)庫變更管理和部署方法，以便在像微服務(wù)架構(gòu)這樣的演化架構(gòu)中執(zhí)行持續(xù)更改和增量更改。本節(jié)將討論一些技術(shù)，將它們作為讓數(shù)據(jù)庫更改的演化與應(yīng)用程序代碼更改更加一致的建議做法。在《重構(gòu)數(shù)據(jù)庫：演化數(shù)據(jù)庫設(shè)計(jì)》一書中，Scott Ambler 和 Promod Sadalage 介紹了在制定數(shù)據(jù)庫重構(gòu)策略時(shí)可用作指南的 13 條經(jīng)驗(yàn)教訓(xùn)。這些經(jīng)驗(yàn)教訓(xùn)為數(shù)據(jù)重構(gòu)的 3 個(gè)步驟提供了基礎(chǔ)：將大更改分解為小更改，對更改執(zhí)行版本控制，并自動(dòng)化數(shù)據(jù)庫部署。
如果您要執(zhí)行一項(xiàng)較大的數(shù)據(jù)庫更改，可將它拆分為更小的更改；讓它們成為一些小型的、可單獨(dú)測試的更改。每項(xiàng)更改通常是數(shù)據(jù)庫結(jié)構(gòu)更改、數(shù)據(jù)遷移和關(guān)聯(lián)的訪問代碼的組合。通過這種方式，可以快速隔離更改可能在這些小片段中產(chǎn)生的任何可能故障，隨后采取相應(yīng)措施來對它們進(jìn)行更正。這種分解的目的也是將數(shù)據(jù)庫更改映射到使用這些更改的應(yīng)用程序功能。這有助于以增量方式持續(xù)地將更改部署到同一個(gè)敏捷流程中。
要執(zhí)行版本控制，可以先根據(jù)需要組織數(shù)據(jù)庫更改腳本。確保更改腳本存儲在與應(yīng)用程序源代碼相同的存儲庫中。另外，確保您擁有與代碼相同的目錄結(jié)構(gòu)和命名約定。這樣，您就可以讓數(shù)據(jù)庫更改與需要這些更改的特定版本中的特定應(yīng)用程序更改保持一致。在結(jié)構(gòu)上保持一致后，在數(shù)據(jù)庫更改腳本上應(yīng)用版本控制。此過程有助于簡化數(shù)據(jù)庫更改的部署，為數(shù)據(jù)庫團(tuán)隊(duì)與其他團(tuán)隊(duì)的協(xié)調(diào)和協(xié)作提供共同基礎(chǔ)。
自動(dòng)化是管理和部署演化數(shù)據(jù)庫更改的關(guān)鍵。確保應(yīng)用程序代碼更改與數(shù)據(jù)庫更改一致。為此，在合適的粒度水平上進(jìn)行分解，重組數(shù)據(jù)庫更改腳本，并應(yīng)用版本控制。完成這一步后，您就擁有了一種受自動(dòng)化支持的、更支持演化的數(shù)據(jù)庫部署方法。然后，可以通過使用敏捷 CI 和 CD 實(shí)踐，采用與應(yīng)用程序代碼部署類似的方式實(shí)現(xiàn)數(shù)據(jù)庫部署自動(dòng)化。
本節(jié)將介紹如何應(yīng)用演化方法，構(gòu)建一種支持不斷更改的更靈活架構(gòu)。本節(jié)通過虛構(gòu)公司 A 的一個(gè)示例應(yīng)用程序的案例分析來演示此方法。技術(shù)架構(gòu)通常受業(yè)務(wù)策略需求推動(dòng)。第 1 部分'微服務(wù)'介紹了為幫助您開始為整體式應(yīng)用程序構(gòu)建演化策略而需要滿足的業(yè)務(wù)需求。
以下基本步驟可作為轉(zhuǎn)型指南：
1.從產(chǎn)品數(shù)據(jù)開始實(shí)施演化策略：客戶在其網(wǎng)站上查找產(chǎn)品數(shù)據(jù)時(shí)遇到麻煩。目的是讓數(shù)據(jù)可用并采用一種更交互式的方式呈現(xiàn)它們。通過將數(shù)據(jù)遷移到 Elasticsearch 數(shù)據(jù)庫，客戶能執(zhí)行更強(qiáng)大的搜索。這可作為在云上構(gòu)建新微服務(wù)的起點(diǎn)，所以考慮將數(shù)據(jù)遷移到 NoSQL 模型，建立新索引，并部署到云環(huán)境。
2.繼續(xù)處理帳戶服務(wù)，獲取客戶的更多信息，以便個(gè)性化提供給他們的內(nèi)容。這種個(gè)性化可改善客戶體驗(yàn)?？赏ㄟ^將現(xiàn)有客戶數(shù)據(jù)與社交數(shù)據(jù)相結(jié)合來滿足這一需求，實(shí)現(xiàn)一種基于 JSON 的潛在的新數(shù)據(jù)模型。
3.將部分客戶數(shù)據(jù)遷移到云?？紤]一種混合云集成模式，以解決之前的數(shù)據(jù)源與新創(chuàng)建的數(shù)據(jù)源之間的數(shù)據(jù)同步問題。
4.優(yōu)化用戶界面 (UI) 層，以便更好地服務(wù)用戶。首先從支持移動(dòng)平臺開始，然后使用微服務(wù)方法，根據(jù)新數(shù)據(jù)模型以增量方式更新 UI。
5.訂購是轉(zhuǎn)換和遷移的最后一步。要轉(zhuǎn)換為微服務(wù)，首先可以圍繞當(dāng)前的訂購組件創(chuàng)建一組 API，以便提高靈活性和解耦程度。這使您能為未來的步驟做好準(zhǔn)備。
關(guān)于公司 A 提供的產(chǎn)品的信息是該公司業(yè)務(wù)的核心數(shù)據(jù)集。讓客戶能夠以最輕松和交互的方式訪問該數(shù)據(jù)，這是架構(gòu)取得成功的關(guān)鍵因素。產(chǎn)品相關(guān)組件是啟動(dòng)演化策略的不錯(cuò)候選組件。得到的工件可能是一個(gè)新微服務(wù)，它在云環(huán)境中運(yùn)行，以實(shí)現(xiàn)恢復(fù)和擴(kuò)展能力。在此示例中，Catalog 服務(wù)是新服務(wù)的名稱。因?yàn)楫a(chǎn)品邏輯完全被移動(dòng)到新微服務(wù)，所以數(shù)據(jù)也必須逐步遷移到同一個(gè)云平臺。這消除了新服務(wù)需要調(diào)用數(shù)據(jù)庫來填充數(shù)據(jù)時(shí)可能產(chǎn)生的任何延遲。
實(shí)現(xiàn)新目錄的技術(shù)有許多。但是，在考慮演化方法的同時(shí)，還要考慮保持整體式應(yīng)用程序（基于 Java）中使用的相同技術(shù)棧，以避免同時(shí)執(zhí)行大規(guī)模更改?？梢愿鶕?jù)業(yè)務(wù)需求，根據(jù)制定架構(gòu)決策時(shí)市場上已有的特定技術(shù)的可用性和成熟度，在以后的步驟中更改技術(shù)棧。為了將服務(wù)代碼快速部署到運(yùn)行時(shí)實(shí)例中，云平臺（比如 IBM Bluemix）提供了各種不同的選擇。新創(chuàng)建的 Catalog 服務(wù)的數(shù)據(jù)也可以先保存在關(guān)系數(shù)據(jù)庫管理模型中，以避免任何大的更改。
下一步是將數(shù)據(jù)遷移到更加現(xiàn)代的、輕量的 NoSQL 和 JSON 模型，以改善搜索體驗(yàn)。
業(yè)務(wù)持續(xù)性對公司 A 很重要，因此必須小心完成轉(zhuǎn)型過程，在轉(zhuǎn)型過程中不得中斷服務(wù)。為了減輕系統(tǒng)宕機(jī)的風(fēng)險(xiǎn)，可以使用 Strangler 應(yīng)用程序技術(shù)。
與客戶相關(guān)的業(yè)務(wù)組件和數(shù)據(jù)被分解和轉(zhuǎn)換為更善于演化的新模型，但與此同時(shí)，舊組件將繼續(xù)并行運(yùn)行。流往舊客戶和組件的流量被逐漸轉(zhuǎn)移到新創(chuàng)建的服務(wù)。
公司 A 的一個(gè)業(yè)務(wù)需求是擴(kuò)展系統(tǒng)，以涵蓋使用移動(dòng)設(shè)備的客戶。此背景下的客戶包括現(xiàn)有客戶和潛在的新客戶。為了滿足該需求，執(zhí)行了以下主要步驟，將它們作為將用戶界面轉(zhuǎn)換為微服務(wù)架構(gòu)的參考步驟：
更改 CustomerServiceDojo 模塊以支持移動(dòng)用戶，并朝響應(yīng)式設(shè)計(jì)方法更進(jìn)一步。
通過采用了響應(yīng)式設(shè)計(jì)的客戶端庫（例如 Bootstrap 和 Angular）來改善用戶體驗(yàn)，讓 UI 更加模塊化且更容易更改。
首先將 UI 層遷移到云環(huán)境，以便更快地開發(fā)、部署和適應(yīng)更改。
接下來，將介紹如何識別整體式應(yīng)用程序中適合采用微服務(wù)架構(gòu)和實(shí)踐的候選者，還將介紹如何設(shè)計(jì)和重構(gòu)新組件。
適合演化為微服務(wù)架構(gòu)的候選整體式應(yīng)用程序，是包含會導(dǎo)致任何以下情形的組件的整體式應(yīng)用程序：
由于難以維護(hù)、修改和快速產(chǎn)生成效，導(dǎo)致推出新服務(wù)的上市周期很長，所以您無法足夠快地部署應(yīng)用程序來滿足需求。或許業(yè)務(wù)部門需要一個(gè)新功能來利用新的市場機(jī)會，或者您希望鏈接到一個(gè)新社交媒體服務(wù)。在任何一種情況下，您都無法及時(shí)構(gòu)建、測試和部署應(yīng)用程序。
您無法應(yīng)用單一部署。即使是細(xì)微的更改或增強(qiáng)，構(gòu)建、測試和部署它們通常也要涉及其他模塊或組件，因?yàn)橥粋€(gè) .ear 或 .war 文件包內(nèi)不存在模塊和組件分離。
只有一種技術(shù)選擇，而且您不能利用其他企業(yè)采用的新技術(shù)、庫或技巧。這種情況可以通過多種方式來說明。或許您當(dāng)前的技術(shù)棧不支持您需要的功能。例如，您想自動(dòng)從代碼生成文檔，或者您想鏈接到新服務(wù)，但您的系統(tǒng)或平臺中目前使用的技術(shù)沒有提供這些功能。
您的大型系統(tǒng)擁有以下特征：
– 內(nèi)存中包含大量數(shù)據(jù)
– 操作的 CPU 使用率很高
– 無法擴(kuò)展應(yīng)用程序的一部分；通常必須擴(kuò)展整個(gè)應(yīng)用程序
– 無法輕松地更新和維護(hù)
– 代碼依賴關(guān)系難以管理
由于代碼的復(fù)雜性和大規(guī)模，很難培訓(xùn)新的開發(fā)人員。
在轉(zhuǎn)變?yōu)槲⒎?wù)之前，請考慮以下重要方面：
開發(fā)平臺的靈活性
微服務(wù)支持靈活地為工作選擇正確工具；它的思路是每個(gè)微服務(wù)都可以通過一種不同的技術(shù)（語言和數(shù)據(jù)存儲）提供支持。根據(jù)特定服務(wù)的需求，為系統(tǒng)的不同部分提供不同的數(shù)據(jù)存儲技術(shù)可能會更好一些。類似地，微服務(wù)可以使用不同的語言；這使您能為特定問題選擇首選語言，而不是遵循標(biāo)準(zhǔn)。
根據(jù)功能和職責(zé)進(jìn)行設(shè)計(jì)
微服務(wù)實(shí)現(xiàn)了組件和職責(zé)的分離：每個(gè)微服務(wù)負(fù)責(zé)一個(gè)確定的主題。這樣，您就可以在系統(tǒng)的特定部分中應(yīng)用新功能或改進(jìn)，避免錯(cuò)誤，以及避免損害正常工作的系統(tǒng)部分。這種方法也可用于隔離舊功能；可通過添加微服務(wù)來向整體式系統(tǒng)添加新功能。
輕松地重寫完整的服務(wù)
通常，微服務(wù)是容易重寫、維護(hù)和更改的小型服務(wù)，它們提供了強(qiáng)大的封裝模型，以及安全的重構(gòu)和重寫方式。
靈活地執(zhí)行更改
對于微服務(wù)，您可以根據(jù)您對系統(tǒng)和領(lǐng)域的了解加深，推遲決策及靈活地增強(qiáng)架構(gòu)。您可以將困難的決策（比如有關(guān)數(shù)據(jù)存儲技術(shù)的決策）推遲到絕對需要它們時(shí)。例如，一個(gè)服務(wù)提供的唯一功能是對一個(gè)數(shù)據(jù)存儲器執(zhí)行領(lǐng)域感知的瘦包裝，但要正確實(shí)現(xiàn)的最重要功能是其他服務(wù)交互的接口。
創(chuàng)造業(yè)務(wù)價(jià)值
業(yè)務(wù)負(fù)責(zé)人看到了微服務(wù)的好處，因?yàn)樗麄兿Ｍ鋱F(tuán)隊(duì)能夠快速響應(yīng)新的客戶和市場需求。如果采用整體式應(yīng)用程序開發(fā)方法，IT 響應(yīng)很緩慢。微服務(wù)更符合業(yè)務(wù)需求，因?yàn)樗鼈冎С直日w式服務(wù)更頻繁和更快地交付。微服務(wù)使業(yè)務(wù)負(fù)責(zé)人能夠快速獲取反饋并相應(yīng)地調(diào)整其投資。
其他益處如下：
– 團(tuán)隊(duì)關(guān)注范圍更小，使業(yè)務(wù)負(fù)責(zé)人能夠更輕松、更有效地管理資源，例如將資源從低影響力業(yè)務(wù)區(qū)域移到更高影響力區(qū)域。
– 通過擴(kuò)展單個(gè)微服務(wù)來消除瓶頸，實(shí)現(xiàn)更流暢的用戶體驗(yàn)。
– 識別和消除重復(fù)服務(wù)，從而減少開發(fā)成本。
靈活擴(kuò)展的能力
采用微服務(wù)，可擴(kuò)展系統(tǒng)的不同部分；每個(gè)微服務(wù)負(fù)責(zé)特定的功能，這樣就可以實(shí)現(xiàn)更靈活的擴(kuò)展。
安全分區(qū)
安全架構(gòu)師堅(jiān)持采用分層方法來構(gòu)建系統(tǒng)，以避免讓重要代碼在 Web 服務(wù)器上運(yùn)行的風(fēng)險(xiǎn)。微服務(wù)可提供分區(qū)功能，這類似于傳統(tǒng)的分層方法。業(yè)務(wù)邏輯和關(guān)鍵數(shù)據(jù)存儲可與負(fù)責(zé)呈現(xiàn) HTML 的服務(wù)分開?？蔀楦鱾€(gè)微服務(wù)之間的通信設(shè)置防火墻、加密和執(zhí)行其他保護(hù)方法。
團(tuán)隊(duì)技能
對于微服務(wù)，團(tuán)隊(duì)可以按技能或位置進(jìn)行分組，避免讓不同團(tuán)隊(duì)處理同一個(gè)代碼庫的相關(guān)風(fēng)險(xiǎn)或困難。
本節(jié)介紹將整體式應(yīng)用程序分解為微服務(wù)的技術(shù)。
微服務(wù)架構(gòu)的一個(gè)重要優(yōu)勢是，可自由決定對每個(gè)服務(wù)使用的技術(shù)棧和微服務(wù)大小。存在這種自由是因?yàn)?，微服?wù)架構(gòu)首先對用戶體驗(yàn)有清楚的了解。
使用設(shè)計(jì)思維來限定和識別微服務(wù)
設(shè)計(jì)思維是一種構(gòu)想整體用戶體驗(yàn)的流程。不再專注于一項(xiàng)功能，微服務(wù)專注于用戶體驗(yàn)（也就是說，用戶擁有該體驗(yàn)時(shí)的想法、行為和感覺）。設(shè)計(jì)思維有助于將工作范圍限定到適用的、可發(fā)布的功能單元。這種設(shè)計(jì)有助于更輕松地從功能上分解和識別微服務(wù)。設(shè)計(jì)思維包含以下概念：
Hills
Hills Playback
方案
用戶案例
Epic
贊助用戶
識別微服務(wù)機(jī)會
Hill 是對您的發(fā)布時(shí)間表的業(yè)務(wù)目標(biāo)的表述。Hill 定義了您希望誰使用哪些資源來如何實(shí)現(xiàn)目標(biāo)。團(tuán)隊(duì)通常為每個(gè)項(xiàng)目確定 3 個(gè) Hill 和一個(gè)技術(shù)基礎(chǔ)。Hill 傳達(dá)領(lǐng)導(dǎo)者的意圖，允許團(tuán)隊(duì)自行決定如何解釋和實(shí)施一種提供流暢用戶體驗(yàn)的解決方案。Hill 的定義必須以用戶為目標(biāo)，它必須是可度量的。在使用 Hill 時(shí)，避免使用模糊或無法量化的目標(biāo)。示例 1 給出了一個(gè)示例 Hill。
示例 1 示例 Hill
Hills Playback 提供團(tuán)隊(duì)想要實(shí)現(xiàn)的目標(biāo)的摘要。Hills Playback 設(shè)定特定發(fā)布時(shí)間段的工作范圍。Playback Zero 是團(tuán)隊(duì)完成組建，并向業(yè)務(wù)贊助者提供其想要實(shí)現(xiàn)的成果的時(shí)刻。Playback 由來自跨職能團(tuán)隊(duì)的參與者和嘗試執(zhí)行 Hill 的贊助用戶每周執(zhí)行一次。圖 4 展示了一個(gè) Hills Playback 時(shí)間表。
圖 4 Hills Playback 時(shí)間表
方案是一個(gè)實(shí)現(xiàn)某種體驗(yàn)的工作流，它設(shè)定 Hills Playback 中使用的案例和上下文。大型方案可進(jìn)一步分解為場景和產(chǎn)品用戶案例。方案獲取'現(xiàn)狀'方案并制定'目標(biāo)'方案。
用戶案例是一個(gè)獨(dú)立的、可編碼的需求，可在一兩天內(nèi)開發(fā)完成。用戶案例是用用戶體驗(yàn)來表達(dá)的，例如'作為開發(fā)人員，我想找到示例并快速將它們部署到 Bluemix，以便我可以試用它們。'
Epics 將案例分組為一種可在整個(gè)方案中多次重用的形式，以避免案例出現(xiàn)重復(fù)。
贊助用戶是全程參與項(xiàng)目，代表項(xiàng)目的目標(biāo)用戶的用戶。他們應(yīng)該領(lǐng)導(dǎo)或參與 Playback。贊助用戶可以是使用包含微服務(wù)的應(yīng)用程序的客戶。他們也可以是內(nèi)部開發(fā)人員，使用您開發(fā)的微服務(wù)入門工具來支持您的 DevOps 發(fā)布流程。
對于每種設(shè)計(jì)，識別一個(gè)服務(wù)在其他設(shè)計(jì)中的潛在重用機(jī)會。'Hill'中給出的 Hill 定義針對的是使用 Bluemix 的 iOS 解決方案。
根據(jù)這個(gè) Hill 示例，您有以下需求：
能夠部署到 Bluemix 和其他網(wǎng)站
能夠作為單獨(dú)服務(wù)部署到 Bluemix
能夠部署到 Bluemix 微服務(wù)團(tuán)隊(duì)
Deploy to Bluemix 微服務(wù)團(tuán)隊(duì)負(fù)責(zé)實(shí)現(xiàn)該服務(wù)。該團(tuán)隊(duì)還負(fù)責(zé)對使用該微服務(wù)的案例執(zhí)行功能和系統(tǒng)集成測試。該服務(wù)包含日志數(shù)據(jù)，用于收集使用情況信息。這有助于更好地量化微服務(wù)對業(yè)務(wù)的影響。它顯示了部署的最流行應(yīng)用程序，以及在用戶部署一個(gè)示例后的用戶跟蹤信息。
因?yàn)槲⒎?wù)系統(tǒng)由各個(gè)作為不同進(jìn)程運(yùn)行的服務(wù)組成，所以我們希望任何能支持通信或消息協(xié)議的合格技術(shù)都可使用。舉例而言，通信協(xié)議可能是 HTTP 和 REST；消息協(xié)議可能是 MQ 遙測傳輸 (MQTT) 或高級消息隊(duì)列協(xié)議 (AMQP)。在選擇實(shí)現(xiàn)技術(shù)棧時(shí)，必須考慮多個(gè)方面：
同步還是異步
經(jīng)典技術(shù)棧（比如 Java Platform Enterprise Edition (Java EE)）會同時(shí)攔截網(wǎng)絡(luò)請求。因此，它們必須在單獨(dú)的線程中運(yùn)行，才能處理多個(gè)并發(fā)請求。
異步技術(shù)棧（比如 Java Message Server (Java EE JMS)）使用事件循環(huán)來處理請求，該循環(huán)通常是單線程的，但在需要下游輸入和輸出 (I/O) 操作來處理請求時(shí)，也可以處理更多請求。
I/O 受限還是處理器 (CPU) 受限
Node.js 等解決方案非常適合主要處理 I/O 操作的微服務(wù)。Node.js 規(guī)定在等待 I/O 請求完成的過程中不持有所有線程。但是，因?yàn)檎埱笫窃谑录h(huán)中執(zhí)行的，所以復(fù)雜的計(jì)算會給調(diào)度程序處理其他請求的能力帶來負(fù)面影響。如果微服務(wù)正在執(zhí)行長期運(yùn)行的操作，那么最好執(zhí)行以下操作之一：
– 將長期運(yùn)行的操作卸載到一組使用最適合 CPU 密集型工作的技術(shù)棧（例如 Java、Go 或 C）編寫的工作者線程上。
– 在具有多線程能力的技術(shù)棧中實(shí)現(xiàn)整個(gè)服務(wù)。
內(nèi)存和 CPU 需求
微服務(wù)是用復(fù)數(shù)形式來表達(dá)的，因?yàn)槟鷷\(yùn)行多個(gè)微服務(wù)，而不是一個(gè)。每個(gè)微服務(wù)可通過運(yùn)行它的多個(gè)實(shí)例得到進(jìn)一步擴(kuò)展。有許多進(jìn)程要處理，而且內(nèi)存和 CPU 需求是評估整個(gè)系統(tǒng)的操作成本時(shí)的重要考慮因素。從這個(gè)角度講，傳統(tǒng)的 Java EE 技術(shù)棧不太適合微服務(wù)，因?yàn)樗鼈冡槍\(yùn)行單個(gè)應(yīng)用程序容器進(jìn)行了優(yōu)化的，而不是針對多個(gè)容器。
但是，Java EE 技術(shù)棧（比如 IBM WebSphere Liberty）可緩解這一問題。同樣地，Node.js 和 Go 等技術(shù)棧是合適的技術(shù)，因?yàn)樗鼈兏p便，而且每個(gè)實(shí)例需要的內(nèi)存和 CPU 資源更少。
在大部分系統(tǒng)中，開發(fā)人員使用 Node.js 微服務(wù)提供網(wǎng)頁，這是由于 Node.js 與在瀏覽器中運(yùn)行的客戶端 JavaScript 的親和性 (affinity)。開發(fā)人員使用 CPU 友好的平臺（Java 或 Go）運(yùn)行后端服務(wù)，并重用現(xiàn)有系統(tǒng)庫和工具包。但是，始終可以在新微服務(wù)中嘗試新技術(shù)棧，而不會因?yàn)楦叱杀镜姆倒ね侠巯到y(tǒng)的剩余部分。
在設(shè)計(jì)微服務(wù)系統(tǒng)時(shí)，最難處理、最不明確的任務(wù)之一就是確定各個(gè)微服務(wù)的數(shù)量和大小。對于最佳大小，并沒有嚴(yán)格的規(guī)定，但有些做法已在實(shí)際系統(tǒng)中得到檢驗(yàn)。
可單獨(dú)或結(jié)合使用以下技術(shù)：
文件數(shù)量
可以按微服務(wù)包含的文件數(shù)量來確定系統(tǒng)中的微服務(wù)大小。這是一種不夠嚴(yán)謹(jǐn)?shù)拿枋?，但有時(shí)您可能想分解占用過大物理空間的微服務(wù)。大型服務(wù)很難處理，很難部署，而且啟動(dòng)和停止所花的時(shí)間更長。但是請注意，不要讓它們變得太小。當(dāng)微服務(wù)太小時(shí)（太小的服務(wù)通常被視為一種反模式），部署和運(yùn)行這樣一個(gè)服務(wù)的資源成本會超過它的效用。盡管人們通常將微服務(wù)與 UNIX 設(shè)計(jì)精神（即做一件事就要將它做好）進(jìn)行比較，但最好從較大的服務(wù)開始著手。始終可以在以后將一個(gè)服務(wù)拆分為兩個(gè)。
太多的職責(zé)
同時(shí)負(fù)責(zé)不同對象的服務(wù)可能需要拆分，因?yàn)樗ǔ：茈y測試、維護(hù)和部署。即使所有職責(zé)都是相同類型的（例如 REST 端點(diǎn)），但一個(gè)服務(wù)可能有太多職責(zé)要履行。
服務(wù)類型
一種不錯(cuò)的規(guī)則是，微服務(wù)僅做一件事，例如以下任務(wù)之一：
– 處理身份驗(yàn)證
– 提供多個(gè) REST 端點(diǎn)
– 提供多個(gè)網(wǎng)頁
通常，您并不想將這些不同的職責(zé)混在一起。這可能看起來與職責(zé)過多的技術(shù)無異，其實(shí)不然。它處理的是職責(zé)的質(zhì)量，而不是數(shù)量。一種反模式可能是，一個(gè)服務(wù)既提供網(wǎng)頁，也提供 REST 端點(diǎn)，或者用作工作者線程。
有界上下文分離
在現(xiàn)有系統(tǒng)被分割為微服務(wù)時(shí)，這種技術(shù)很重要。該名稱來自 Martin Fowler 提出的一種設(shè)計(jì)模式。
http://martinfowler.com/bliki/BoundedContext.html
它表示系統(tǒng)中的各部分相對獨(dú)立，所以它們與一個(gè)服務(wù)器的鏈接較少，可轉(zhuǎn)換為微服務(wù)。如果一個(gè)微服務(wù)需要與另外 10 個(gè)微服務(wù)通信才能完成它的任務(wù)，這可能表明在整體式應(yīng)用程序中的錯(cuò)誤位置進(jìn)行了分割。
團(tuán)隊(duì)組織
許多微服務(wù)系統(tǒng)都是圍繞負(fù)責(zé)編寫代碼的團(tuán)隊(duì)來組織的。因此，微服務(wù)沿團(tuán)隊(duì)界線進(jìn)行分割，以最大化團(tuán)隊(duì)的獨(dú)立性。
微服務(wù)成為一種流行的架構(gòu)和組織模式的重要原因之一是，它們允許團(tuán)隊(duì)在云中計(jì)劃、開發(fā)和部署系統(tǒng)功能，而無需頻繁協(xié)調(diào)。因此，我們期望微服務(wù)的數(shù)量和大小由組織和技術(shù)原理來確定。
精心設(shè)計(jì)的微服務(wù)系統(tǒng)會結(jié)合使用這些技術(shù)。這些技術(shù)需要在使用該系統(tǒng)的過程和經(jīng)驗(yàn)中積累的良好判斷力。在獲得該經(jīng)驗(yàn)之前，首先創(chuàng)建可能較大的微服務(wù)（更像迷你服務(wù)），直到觀察到更多適合繼續(xù)分割的'斷層線'。
備注：在逆向代理背后的精心設(shè)計(jì)的系統(tǒng)中，這種重組可以無中斷地運(yùn)行。如果一個(gè)微服務(wù)提供了兩個(gè) URL 路徑，那么兩個(gè)新的微服務(wù)可以分別提供一個(gè)路徑。微服務(wù)系統(tǒng)設(shè)計(jì)是一個(gè)持續(xù)過程，不是必須一次就完成。
重構(gòu)是一種現(xiàn)代化應(yīng)用程序并獲得新結(jié)構(gòu)和新平臺所提供的資源的實(shí)踐。整體式應(yīng)用程序向微服務(wù)的遷移遵循相同的路線。重構(gòu)將微服務(wù)添加到應(yīng)用程序中，而不更改應(yīng)用程序的用途。
本節(jié)將介紹一些將整體式應(yīng)用程序重構(gòu)為微服務(wù)的技術(shù)；其中的內(nèi)容主要基于 Kyle Brown 編寫的這篇 IBM developerWorks? 文章：重構(gòu)到微服務(wù)，第 1 部分：執(zhí)行整體遷移時(shí)的考慮事項(xiàng)
從一開始就使用新運(yùn)行時(shí)和編程語言很耗費(fèi)成本，尤其是在許多代碼都是用 Java 開發(fā)的而且仍能正常工作時(shí)。使用微服務(wù)的重構(gòu)是一種更加謹(jǐn)慎的方法，因?yàn)榭梢员３峙f系統(tǒng)繼續(xù)運(yùn)行，將整體式應(yīng)用程序分?jǐn)?shù)個(gè)部分遷移到一個(gè)更可持續(xù)的、最新的平臺。
將整體式應(yīng)用程序轉(zhuǎn)變?yōu)槲⒎?wù)可能涉及到以下策略：
將整個(gè)整體式應(yīng)用程序轉(zhuǎn)換為微服務(wù)
從頭開始構(gòu)造基于微服務(wù)的新應(yīng)用程序可能是最佳選擇。但是，因?yàn)樵摲椒赡苌婕暗揭淮螆?zhí)行太多更改，所以此方法具有一定風(fēng)險(xiǎn)，而且常常導(dǎo)致故障。
逐步重構(gòu)
該策略的基本思路是，通過將系統(tǒng)的各部分構(gòu)建為與整體式應(yīng)用程序一起運(yùn)行的微服務(wù)，逐步重構(gòu)整體式應(yīng)用程序。隨著時(shí)間的推移，整體式應(yīng)用程序提供的功能量不斷減少，直到它完全遷移到微服務(wù)。這被視為一種謹(jǐn)慎的策略。Martin Fowler 將這種應(yīng)用程序現(xiàn)代化策略稱為 Strangler 應(yīng)用程序。
此方法涉及的其他方面如下：
– 不要在整體式應(yīng)用程序中添加新功能；這可能會阻止它變得更大。對于所有新功能，請使用獨(dú)立的微服務(wù)。
– 創(chuàng)建圍繞業(yè)務(wù)能力而組織的微服務(wù)，每個(gè)微服務(wù)負(fù)責(zé)一個(gè)主題。
– 整體式應(yīng)用程序通常由多層組成，比如演示、業(yè)務(wù)邏輯和數(shù)據(jù)訪問層。您可以為演示層創(chuàng)建一個(gè)微服務(wù)，為業(yè)務(wù)訪問數(shù)據(jù)創(chuàng)建另一個(gè)微服務(wù)。關(guān)注點(diǎn)始終放在功能和業(yè)務(wù)上。
– 使用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì) (DDD) 有界上下文，將一個(gè)復(fù)雜領(lǐng)域細(xì)分為多個(gè)有界上下文，并在它們之間建立映射關(guān)系，服務(wù)與上下文邊界之間存在著一種自然的關(guān)聯(lián)。
在將 Java Platform 和 Java EE 應(yīng)用程序轉(zhuǎn)換為微服務(wù)時(shí)，考慮以下重要方面：
重新打包應(yīng)用程序（參見圖 5）
執(zhí)行以下步驟：
a. 拆分企業(yè)存檔文件 (EAR)。
不要將所有相關(guān)的 Web 存檔文件 (WAR) 打包到一個(gè) EAR 中，而是應(yīng)該將它們拆分為獨(dú)立的 WAR。如果更改應(yīng)用程序上下文根來實(shí)現(xiàn)分離，這可能涉及到對代碼執(zhí)行一些細(xì)微更改，或者可能需要更改靜態(tài)內(nèi)容。
b. 應(yīng)用每個(gè)服務(wù)一個(gè)容器的模式。
接下來應(yīng)用每個(gè)服務(wù)一個(gè)容器的模式，將每個(gè) WAR 部署在自己的應(yīng)用服務(wù)器中，最好部署在自己的容器中（比如 Docker 容器或 Bluemix 即時(shí)運(yùn)行時(shí)）。然后您可以獨(dú)立地?cái)U(kuò)展容器。
c. 獨(dú)立地構(gòu)建、部署和管理每個(gè) WAR。
拆分它們后，您可以通過自動(dòng)化的 DevOps 管道（比如 IBM DevOps Pipeline Service）獨(dú)立管理每個(gè) WAR。這一步有助于獲得持續(xù)交付的優(yōu)勢。
圖 5 重新打包整體式應(yīng)用程序
備注：有關(guān)重新打包整體式應(yīng)用程序的更多信息，請?jiān)L問下面的網(wǎng)站：
https://www.ibm.com/devops/method/content/code/practice_refactor_microservices/
重構(gòu)整體式代碼（參見圖 6）：
重新打包后，在將部署策略細(xì)化到獨(dú)立 WAR 級別時(shí)，就可以開始尋找重構(gòu)機(jī)會：
– 前端
對于通常作為數(shù)據(jù)庫表的前端的簡單程序 servlet/JSP，創(chuàng)建一個(gè)可表示為 RESTful 服務(wù)的領(lǐng)域?qū)?。?yīng)用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)來識別您的領(lǐng)域?qū)ο?，這可以幫助您識別缺少的領(lǐng)域服務(wù)層。完成構(gòu)建后，在下一階段，可以重構(gòu)現(xiàn)有的 servlet/JSP 應(yīng)用程序，以便使用新服務(wù)或使用 JavaScript、HTML5 和 CSS 構(gòu)建新接口，或者將它構(gòu)建為原生移動(dòng)應(yīng)用程序。
HTTP 會話狀態(tài)：在這種情況下，將 HTTP 會話狀態(tài)轉(zhuǎn)移到數(shù)據(jù)庫中是一個(gè)好方法。
– SOAP 或 EJB 服務(wù)
與一個(gè) RESTful 接口建立映射，并重新實(shí)現(xiàn) EJB 會話 bean 接口或 JAX-WS 接口作為 JAX-RS 接口。為此，您可能需要將對象表示轉(zhuǎn)換為 JSON。
– REST 或 JMS 服務(wù)
您可能已有兼容或能夠兼容微服務(wù)架構(gòu)的服務(wù)。首先將每個(gè) REST 或簡單 JMS 服務(wù)與 WAR 的剩余部分分離，然后將每個(gè)服務(wù)部署為獨(dú)立的 WAR。在此級別上，可以復(fù)制支持性 JAR 文件；這只是一種打包風(fēng)格。
圖 6 重構(gòu)整體式代碼概略圖
重構(gòu)整體式數(shù)據(jù)
構(gòu)建和重新打包前幾步中定義的小型服務(wù)后，下一步可能是微服務(wù)采用過程中最困難的問題。這一步將基于當(dāng)前數(shù)據(jù)模型，為每個(gè)微服務(wù)創(chuàng)建一個(gè)新數(shù)據(jù)模型。
以下是要遵守的規(guī)則：
– 數(shù)據(jù)孤島（參見圖 7）
首先考慮您的代碼使用的數(shù)據(jù)庫表。如果使用的表與其他所有表獨(dú)立，或者包含一些通過關(guān)系聯(lián)接起來的表組成的孤立小島中，您可以將這些表與數(shù)據(jù)設(shè)計(jì)中的剩余部分分開。
要確定使用哪個(gè)數(shù)據(jù)庫，需要確認(rèn)您想要使用的查詢類型。如果您使用的大多數(shù)查詢都是基于主鍵的簡單查詢，那么鍵值數(shù)據(jù)庫或文檔數(shù)據(jù)庫可能是最佳選擇。但是，如果有各不相同的復(fù)雜聯(lián)接（例如查詢不可預(yù)測），那么使用 SQL 可能是最佳選擇。
– 批量數(shù)據(jù)更新
如果只有少量關(guān)系，并決定將數(shù)據(jù)遷移到 NoSQL 數(shù)據(jù)庫中，則需要考慮您是否僅需要對現(xiàn)有數(shù)據(jù)庫執(zhí)行批量更新。通常，在考慮表之間的關(guān)系時(shí)，這些關(guān)系沒有考慮時(shí)間因素；它們可能并不總是需要保持最新。
在許多情況下，每隔幾小時(shí)運(yùn)行一次數(shù)據(jù)轉(zhuǎn)儲和加載方法可能就足以應(yīng)對許多情況。
– 對表進(jìn)行去標(biāo)準(zhǔn)化
如果您與其他表有更多的關(guān)系，可以重構(gòu)（或者用數(shù)據(jù)庫管理員的話說，去標(biāo)準(zhǔn)化）您的表。
通常，使用高度標(biāo)準(zhǔn)化的模式的目的是減少重復(fù)（這可以節(jié)省空間），因?yàn)榇疟P空間很昂貴。但是，磁盤空間現(xiàn)在變便宜了?，F(xiàn)在您必須優(yōu)化查詢時(shí)間；去標(biāo)準(zhǔn)化是實(shí)現(xiàn)該優(yōu)化的一種簡單方法。
圖 7 重構(gòu)整體式數(shù)據(jù)概略圖
本節(jié)基于第 1 部分中小節(jié)“虛構(gòu)公司 A 的業(yè)務(wù)問題”中描述的業(yè)務(wù)案例和整體式應(yīng)用程序，定義了一種新架構(gòu)。本節(jié)遵循小節(jié)中的理論，并提供了選擇每種新服務(wù)的原因和好處。
當(dāng)前應(yīng)用程序是一種典型的 Java 整體式應(yīng)用程序，它在一個(gè) EAR 包中定義，并在一個(gè)應(yīng)用服務(wù)器內(nèi)運(yùn)行。該 EAR 包包含針對應(yīng)用程序的每個(gè)部分的特定組件，通常采用分層模式。當(dāng)前的應(yīng)用程序使用 JSF 和 Dojo 實(shí)現(xiàn)前端，使用 EJB 實(shí)現(xiàn)業(yè)務(wù)組件，使用 JPA 實(shí)現(xiàn)持久性組件和訪問（DB2? 和 SQL），如圖 9 所示。
新架構(gòu)基于平臺即服務(wù) (PaaS) 云環(huán)境。該架構(gòu)使用服務(wù)來提高對開發(fā)周期的控制 (DevOps)。它還使用了其他可用資源來改進(jìn)新應(yīng)用程序的新功能，比如數(shù)據(jù)庫、運(yùn)行時(shí)、安全性、應(yīng)用服務(wù)器等。它還為每個(gè)服務(wù)提供了更加獨(dú)立的擴(kuò)展性。
采用逐步遷移，將 Catalog 和 Account 組件遷移到微服務(wù)，將 Order 組件保留在整體式應(yīng)用程序中（參見圖 10）。
下面給出每個(gè)組件的詳細(xì)信息：
PaaS 平臺
PaaS 提供了一個(gè)基于云的環(huán)境，其中包含為構(gòu)建和交付基于 Web 的（云）應(yīng)用程序的完整生命周期提供支持所需的一切資源，而沒有購買和管理基礎(chǔ)硬件、軟件，以及執(zhí)行配置和托管的成本和復(fù)雜性。
PaaS 提供了以下好處：
– 可以更快地開發(fā)應(yīng)用程序并上市。
– 可以在幾分鐘內(nèi)將新 Web 應(yīng)用程序部署到云。
– 通過中間件即服務(wù)降低了復(fù)雜性。
安全網(wǎng)關(guān)
安全 Web 網(wǎng)關(guān)是一種安全解決方案，可阻止不安全的流量進(jìn)入企業(yè)的內(nèi)部網(wǎng)絡(luò)。企業(yè)使用它保護(hù)其員工和用戶，阻止其訪問惡意 Web 流量、網(wǎng)站、病毒和惡意軟件并被其感染。安全網(wǎng)關(guān)還可以確保企業(yè)的監(jiān)管政策得以實(shí)施和遵守。在新架構(gòu)中，此組件用于與來自整體式應(yīng)用程序的數(shù)據(jù)庫 SQL 集成。在新架構(gòu)中，此服務(wù)還負(fù)責(zé)確保與整體式應(yīng)用程序的完整性和安全性功能集成。
5 種不同的應(yīng)用程序
這些應(yīng)用程序如下：
使用 jQuery、Bootstrap 和 AngularJS 的 UI 應(yīng)用程序
創(chuàng)建了一個(gè)新的前端應(yīng)用程序，該應(yīng)用程序使用的技術(shù)和框架使它能在不同的設(shè)備中運(yùn)行（手機(jī)、平板電腦和桌面）。使用來自微服務(wù)的 REST API 檢索必要的業(yè)務(wù)信息（帳戶、目錄和訂單）。
Catalog 組件對應(yīng)的微服務(wù)應(yīng)用程序
負(fù)責(zé) Catalog 組件的組件已遷移到微服務(wù)，成為一個(gè)隔離的應(yīng)用程序，以實(shí)現(xiàn)更好的擴(kuò)展。另外，使用靈活的技術(shù)向微服務(wù)添加了一個(gè)新搜索服務(wù)，以改進(jìn)每個(gè)元素內(nèi)的搜索。該目錄使用提取、轉(zhuǎn)換和加載 (ETL) 操作進(jìn)行更新，這些操作使用集成的網(wǎng)關(guān)服務(wù)從 SQL 整體式應(yīng)用程序獲取數(shù)據(jù)。
Order 組件對應(yīng)的微服務(wù)
Order 組件保留在整體式應(yīng)用程序中，但創(chuàng)建了一個(gè)微服務(wù)來從整體式應(yīng)用程序中獲取訂單信息，該微服務(wù)使用了一個(gè)集成的網(wǎng)關(guān)服務(wù)。
Account 組件對應(yīng)的微服務(wù)
負(fù)責(zé) Account 組件的組件已遷移到微服務(wù)，成為一個(gè)隔離的應(yīng)用程序，以便實(shí)現(xiàn)更好的擴(kuò)展。另外，向 Analytics 服務(wù)添加了一個(gè)新 NoSQL 數(shù)據(jù)庫，并集成了社交網(wǎng)絡(luò)。這些新功能提高了為提供新產(chǎn)品來收集信息的潛力。
企業(yè)數(shù)據(jù)中心
整體式應(yīng)用程序采取的是部分遷移。在此階段，Order 功能保留在整體式應(yīng)用程序中。向整體式應(yīng)用程序添加一個(gè)新 API，以便提供訪問訂單信息的能力。
本文探討了微服務(wù)的演化架構(gòu)，以及介紹了如何識別整體應(yīng)用程序適合演化為微服務(wù)架構(gòu)。下一部分我們將介紹在將整體式應(yīng)用程序演化為微服務(wù)架構(gòu)是要考慮的重要的數(shù)據(jù)庫主題。好了，學(xué)習(xí)愉快，下次再見！
出處：https://www.ibm.com/developerworks/cn/java/j-cn-java-and-microservice-5/index.html?ca=drs-
