【51CTO.com原創(chuàng)稿件】想必你已知道了微服務(wù)及其工作原理，現(xiàn)在是時候探討如向微服務(wù)轉(zhuǎn)變這個關(guān)鍵話題了。

為什么要向微服務(wù)轉(zhuǎn)變

整體式（monolithic）應(yīng)用程序很龐大（代碼行數(shù)方面）、很復(fù)雜（功能依賴和數(shù)據(jù)等方面），為跨地區(qū)的成千上萬用戶提供服務(wù)，需要多個開發(fā)人員和 IT 工程師。

整體式應(yīng)用程序可能類似下圖：

圖 1：整體式應(yīng)用程序的基本結(jié)構(gòu)

有時，即使具有所有這些特點，應(yīng)用程序最初也可能順暢運(yùn)行，可能在應(yīng)用程序可擴(kuò)展性或性能方面不會遇到挑戰(zhàn)。但用著用著會出現(xiàn)問題，問題因應(yīng)用程序而異。

比如對于云或 Web 應(yīng)用程序而言，由于更多用戶使用服務(wù)，你可能遇到可擴(kuò)展性問題，或者由于更長的構(gòu)建時間和回歸測試，定期發(fā)布新的更新可能變得成本高、難度大。

如圖 2 所示，整體式應(yīng)用程序的用戶或開發(fā)人員可能遇到右邊列出的一個或多個問題。

圖 2：整體式應(yīng)用程序的潛在問題

這時遷移到微服務(wù)可能聽起來不僅僅是時髦的想法，更像是大救星。應(yīng)用程序的遷移會類似圖 3 所示：

圖 3：從整體式應(yīng)用程序向微服務(wù)轉(zhuǎn)變

那么，如何進(jìn)行這種轉(zhuǎn)變？有兩種可能的場景：

• 創(chuàng)建全新的應(yīng)用程序。
• 轉(zhuǎn)換或遷移已經(jīng)存在的整體式應(yīng)用程序。

后一種場景的可能性大得多，但無論目前的情況如何，都有必要了解這兩種場景的來龍去脈。

使用微服務(wù)創(chuàng)建新應(yīng)用程序

我還沒有看到很多從頭開始構(gòu)建基于微服務(wù)的應(yīng)用程序的真實場景。通常，應(yīng)用程序已部署到位，我搞過的大多數(shù)應(yīng)用程序更多是從整體式架構(gòu)向微服務(wù)架構(gòu)轉(zhuǎn)變。

在這種情況下，架構(gòu)師和開發(fā)人員的意圖一直是重用一些現(xiàn)有的實現(xiàn)。但由于技能在市場上非常普遍、一些成功的實現(xiàn)發(fā)布，我們會看到從頭開始構(gòu)建基于微服務(wù)的應(yīng)用程序的更多例子，因此當(dāng)然有必要探究這種場景。

假設(shè)你已摸清了所有需求，準(zhǔn)備好處理要構(gòu)建的應(yīng)用程序的架構(gòu)設(shè)計。你在入手時需要考慮許多常見的***實踐，這些實踐在下面各節(jié)中有介紹。

組織準(zhǔn)備

你要問自己的***個問題是，貴組織是否準(zhǔn)備好向微服務(wù)轉(zhuǎn)變。

這意味著貴組織的各個部門現(xiàn)在需要從以下方面對軟件的構(gòu)建和發(fā)布進(jìn)行不同的思考：

• 團(tuán)隊結(jié)構(gòu)。整體式應(yīng)用程序團(tuán)隊（如果有的話）需要分解成幾個知道微服務(wù)***實踐或受到培訓(xùn)的小規(guī)模高績效團(tuán)隊。

如圖 3 所示，新系統(tǒng)將包含一組獨立服務(wù)，每個服務(wù)負(fù)責(zé)提供特定服務(wù)。這是微服務(wù)模式的一大優(yōu)勢：減少了通信開銷，包括多場不間斷會議。

團(tuán)隊?wèi)?yīng)按照所要解決的業(yè)務(wù)問題或領(lǐng)域加以組織。然后，溝通變?yōu)榍枚ㄒ裱囊惶讟?biāo)準(zhǔn)/協(xié)議，那樣這些微服務(wù)就能彼此協(xié)作。

• 每個團(tuán)隊必須準(zhǔn)備獨立于其他團(tuán)隊運(yùn)作。它們的規(guī)模應(yīng)相當(dāng)于標(biāo)準(zhǔn)的 Scrum 團(tuán)隊，否則溝通會再次成為問題。執(zhí)行是關(guān)鍵，每個團(tuán)隊都應(yīng)能夠滿足不斷變化的業(yè)務(wù)要求。
• 工具和培訓(xùn)。一個關(guān)鍵要求是組織準(zhǔn)備投入于新工具和人員培訓(xùn)的情況。在大多數(shù)情況下，現(xiàn)有的工具和流程需要停用，采用一套新的。

這需要投入大量資本，致力于招聘擁有新技能的人員，并重新培訓(xùn)現(xiàn)有工作人員。從長遠(yuǎn)來看，如果采用微服務(wù)的決定是正確的，組織會看到成本節(jié)省，因而收回投入。

基于服務(wù)的方法

與整體式應(yīng)用程序不同，若是微服務(wù)，你需要采用自我維持的基于服務(wù)的方法。

應(yīng)用程序好比是一組松散耦合的服務(wù)，這些服務(wù)相互通信以提供完整的應(yīng)用程序功能。

應(yīng)將每項服務(wù)視為有其生命周期的獨立服務(wù)，可由獨立團(tuán)隊開發(fā)和維護(hù)。這些團(tuán)隊要從各種技術(shù)中進(jìn)行選擇，包括最適合其服務(wù)要求的語言或數(shù)據(jù)庫。

比如針對電子商務(wù)站點，團(tuán)隊要編寫一個完全獨立的使用內(nèi)存數(shù)據(jù)庫的服務(wù)，比如購物車微服務(wù)，以及使用關(guān)系數(shù)據(jù)庫的另一項服務(wù)，比如訂購微服務(wù)。

實際應(yīng)用程序可能將微服務(wù)用于基本功能，比如身份驗證、帳戶、用戶注冊和通知，業(yè)務(wù)邏輯封裝在 API 網(wǎng)關(guān)中，API 網(wǎng)關(guān)基于客戶端和外部請求調(diào)用這些微服務(wù)。

提醒一下：微服務(wù)可能是一個開發(fā)人員實現(xiàn)的小服務(wù)，也可能是需要多個開發(fā)人員的復(fù)雜服務(wù)。就微服務(wù)而言，大小無關(guān)緊要；它完全依賴服務(wù)要提供的一項功能。

此時必須考慮的其他方面是擴(kuò)展、性能和安全。擴(kuò)展要求可能不一樣，應(yīng)在每個微服務(wù)層面根據(jù)需要來提供。應(yīng)在所有層面考慮安全，包括靜態(tài)數(shù)據(jù)、進(jìn)程間通信和傳輸中數(shù)據(jù)等。

進(jìn)程間（服務(wù)到服務(wù)）通信

必須考慮的關(guān)鍵方面是安全和通信協(xié)議。異步通信是***選擇，因為它可確保所有請求正常運(yùn)行，不會長時間占用資源。

使用 RabbitMQ 等消息總線可能有利于這種通信。它很簡單，可以擴(kuò)展到每秒數(shù)十萬條消息。

為防止消息傳遞系統(tǒng)在發(fā)生故障后成為單一故障點，必須正確設(shè)計消息傳遞總線以實現(xiàn)高可用性。其他選項包括另一種輕量級消息傳遞平臺 ActiveMQ。

安全是該階段的關(guān)鍵。除了選擇正確的通信協(xié)議外，可使用 AppDynamics 之類的行業(yè)標(biāo)準(zhǔn)工具來監(jiān)控和衡量進(jìn)程間通信。須自動向安全團(tuán)隊報告任何異常情況。

若有數(shù)千個微服務(wù)，處理一切確實變得復(fù)雜起來。后面會解釋如何借助發(fā)現(xiàn)服務(wù)和 API 網(wǎng)關(guān)解決此類問題。

技術(shù)選擇

向微服務(wù)轉(zhuǎn)變的***優(yōu)勢是讓你可以選擇。每個團(tuán)隊可以獨立選擇最適合特定微服務(wù)的語言、技術(shù)和數(shù)據(jù)庫等。

若采用整體式方法，團(tuán)隊通常沒有這樣的靈活性，因此確保你沒有忽視并錯過該機(jī)會。

即使團(tuán)隊在處理多個微服務(wù)，也要將每個微服務(wù)視為獨立的服務(wù)并進(jìn)行分析。

為每個微服務(wù)選擇技術(shù)時，必須牢記可擴(kuò)展性、部署、構(gòu)建時間、集成和插件可操作性等。

如果是數(shù)據(jù)較少但訪問較快的微服務(wù)，內(nèi)存數(shù)據(jù)庫可能最合適，而其他微服務(wù)可能使用同樣的關(guān)系數(shù)據(jù)庫或 NoSQL 數(shù)據(jù)庫。

實現(xiàn)

實現(xiàn)是關(guān)鍵階段，這時候所有培訓(xùn)和***實踐知識派得上用場。

要記住的幾個關(guān)鍵方面包括：

• 獨立性。每個微服務(wù)都應(yīng)高度自主，有自己的生命周期并以此進(jìn)行處理。它的開發(fā)和維護(hù)不需要依賴其他微服務(wù)。
• 源代碼控制。必須部署適當(dāng)?shù)陌姹究刂葡到y(tǒng)，每個微服務(wù)要遵循標(biāo)準(zhǔn)。統(tǒng)一代碼庫也很有幫助，因為它可以確保所有團(tuán)隊使用相同的源代碼控制。

它有助于代碼審查等各個方面，便于在一個地方訪問所有代碼。長遠(yuǎn)來看，有必要對所有服務(wù)實行同樣的源代碼控制。

• 環(huán)境。所有不同的環(huán)境（如開發(fā)、測試、模擬和生產(chǎn)等階段）必須得到適當(dāng)?shù)谋Ｗo(hù)和自動化。這里的自動化包括構(gòu)建過程。

那樣，可以根據(jù)需要集成代碼，大多每天進(jìn)行。有幾種工具可用，不過 Jenkins 廣泛使用。Jenkins 是一種開源工具，有助于軟件構(gòu)建和發(fā)布過程實現(xiàn)自動化，包括持續(xù)集成和持續(xù)交付（CI/CD）。

• 故障安全。軟件故障不可避免。須在微服務(wù)開發(fā)中解決好下游服務(wù)的故障處理問題。其他服務(wù)的故障必須是隱形的，好讓用戶看不到故障。

這包括管理服務(wù)響應(yīng)時間（超時）、處理下游服務(wù)的 API 更改以及限制自動重試次數(shù)。

使用微服務(wù)時，別害怕通過使用復(fù)制粘貼來重用代碼，但這么做要有限制。

這可能導(dǎo)致代碼重復(fù)，但這勝過使用最終耦合服務(wù)的共享代碼。微服務(wù)中，你需要的是去耦，不是緊耦合。

比如說，你將編寫代碼以使用服務(wù)的輸出響應(yīng)。每次從任何客戶端調(diào)用相同的服務(wù)時，你可以復(fù)制此代碼。

重用代碼的另一種方法是創(chuàng)建公共庫。多個客戶端可以使用相同的庫，但隨后每個客戶端應(yīng)負(fù)責(zé)維護(hù)其庫。

如果你創(chuàng)建太多的庫，每個客戶端維護(hù)不同的版本，有時變得困難重重。這種情況下，你要包含相同庫的多個版本，由于向后兼容性和類似問題，構(gòu)建過程可能變得困難。

只要你可以控制客戶端的庫和版本數(shù)量，并對它們實行嚴(yán)格的流程，可以采用任何一種方式，這就看你的需要了。這肯定有助于避免大量的代碼重復(fù)。

鑒于微服務(wù)數(shù)量龐大，調(diào)試問題可能會變得困難，因此你需要在此階段進(jìn)行某種檢測。

***實踐之一是使用唯一的請求 ID 標(biāo)記每個請求，并記錄每個請求。這個唯一的 ID 標(biāo)識始發(fā)請求，應(yīng)由每個服務(wù)傳遞給任何下游請求。

看到問題后，你可以通過日志清楚地回溯并找出有問題的服務(wù)。如果你建立集中式日志記錄系統(tǒng)，該解決方案最有效。

所有服務(wù)都應(yīng)以標(biāo)準(zhǔn)化格式將所有消息記錄到此共享系統(tǒng)，以便團(tuán)隊可以根據(jù)需要從一個地方（從基礎(chǔ)設(shè)施到應(yīng)用程序）重放事件。用于集中式日志的共享庫值得研究。

市面上有幾種很理想的日志管理和聚合工具，比如 ELK（Elasticsearch、Logstas和Kibana）以及 Splunk。

部署

自動化是部署過程中的關(guān)鍵。沒有它，微服務(wù)模式幾乎不可能成功。可能有成百上千的微服務(wù)，對于敏捷交付而言，自動化必不可少。

設(shè)想部署數(shù)千個微服務(wù)并維護(hù)。其中一個微服務(wù)發(fā)生故障后會發(fā)生什么？怎么知道哪臺機(jī)器有足夠的資源來運(yùn)行你的微服務(wù)？

若沒有落實自動化，應(yīng)對這種情況變得非常復(fù)雜。Kubernetes 和 Docker Swarm 等各種工具可用于自動化部署過程。

操作

整個過程的操作部分也需要自動化。這里談?wù)摰耐瑯邮浅砂偕锨У奈⒎?wù)，組織能力需要足夠成熟才能處理這種復(fù)雜程度。

你需要一個支持系統(tǒng)，包括以下方面：

• 從基礎(chǔ)設(shè)施、應(yīng)用程序 API 到***一英里性能，全部都要加以監(jiān)控，并實施具有適當(dāng)閾值的自動警報。考慮構(gòu)建問題出現(xiàn)后彈出數(shù)據(jù)和警報的實時儀表板。
• 按需可擴(kuò)展性。若使用微服務(wù)，擴(kuò)展是最簡單的任務(wù)。配置你想要擴(kuò)展的微服務(wù)的另一個實例，將它放在現(xiàn)有的負(fù)載均衡器后面就行。

但在規(guī)模化環(huán)境中，這也需要實現(xiàn)自動化。只需設(shè)置一個整數(shù)值，告訴想要為特定微服務(wù)運(yùn)行的實例數(shù)量。

• API 公開。在大多數(shù)情況下應(yīng)該對外公開 API 以供外部用戶使用。***使用邊緣服務(wù)器來完成這項任務(wù)，該服務(wù)器可以處理所有外部請求。

它可以使用 API 網(wǎng)關(guān)和發(fā)現(xiàn)服務(wù)來完成任務(wù)，你可以針對每種設(shè)備類型（比如移動設(shè)備或瀏覽器）或用例使用一臺邊緣服務(wù)器。Netflix 開發(fā)的一款開源應(yīng)用軟件 Zuul 可用于此功能及其他功能。

• 斷路器。向故障服務(wù)發(fā)送請求毫無意義。因此可以構(gòu)建斷路器（circuit breaker），跟蹤針對每個服務(wù)的每個請求的成功或故障。若出現(xiàn)多個故障，應(yīng)阻止對該特定服務(wù)的所有請求一段指定的時間（即斷開電路）。

指定時間過后，應(yīng)進(jìn)行另一次嘗試，依此類推。一旦響應(yīng)成功，重新連接電路。這應(yīng)該在服務(wù)實例層面進(jìn)行。Netflix 的 Hystrix 提供了開源斷路器實現(xiàn)。

將整體式應(yīng)用程序遷移到微服務(wù)

雖然構(gòu)建基于微服務(wù)的新應(yīng)用程序的大多數(shù)***實踐也適用于遷離現(xiàn)有的整體式應(yīng)用程序，但如果遵循另外一些準(zhǔn)則，可使遷移更簡單、更高效。

雖然將整個整體式應(yīng)用程序轉(zhuǎn)換成完全基于微服務(wù)的應(yīng)用程序聽起來可能很正確，但將每項功能轉(zhuǎn)換成微服務(wù)可能并不高效，在一些情況下可能成本很高。

畢竟，你到頭來要從頭開始編寫應(yīng)用程序。正確的遷移方式可能需要逐步進(jìn)行，如圖 4 所示：

圖 4：基本的遷移步驟，從整體式應(yīng)用程序到微服務(wù)

下一個問題是：目前的整體式應(yīng)用程序從何處入手？如果應(yīng)用程序確實很舊，進(jìn)行分解很耗時、難度大，從頭開始可能更好。

在可以快速禁用部分代碼、技術(shù)架構(gòu)并不完全過時的其他情況下，***先將組件重新構(gòu)建為微服務(wù)，并換掉舊代碼。

微服務(wù)標(biāo)準(zhǔn)

那么問題變成了哪些組件應(yīng)該先遷移或甚至要不要遷移。這讓我想到了所謂的“微服務(wù)標(biāo)準(zhǔn)”，這概述了選擇應(yīng)遷移到微服務(wù)的功能并確定優(yōu)先級的可行方法之一。

它們是你制定的一套規(guī)則，根據(jù)組織當(dāng)時的要求，決定將現(xiàn)有整體式應(yīng)用程序的組件轉(zhuǎn)換成微服務(wù)是否適合。

這時機(jī)在這里很重要，因為組織的要求可能不斷變化，你可能要回過頭來，將更多組件轉(zhuǎn)換成微服務(wù)。

換句話說，由于要求變化，整體式應(yīng)用程序的額外組件可能適合轉(zhuǎn)換。以下是轉(zhuǎn)換過程中被視為微服務(wù)標(biāo)準(zhǔn)的幾個***實踐：

①你需要確定哪些功能頻繁使用

先將頻繁使用的服務(wù)或應(yīng)用程序功能轉(zhuǎn)換成微服務(wù)。記住：微服務(wù)只執(zhí)行一個明確定義的服務(wù)。牢記這個原則，相應(yīng)地劃分應(yīng)用程序。

②可能存在性能不佳的組件，其他替代方案隨時可用

可能有開源插件，或者你可能想從頭開始構(gòu)建服務(wù)。應(yīng)牢記的要點之一是微服務(wù)的邊界。

只要你設(shè)計的微服務(wù)只做一件事，就很好。確定邊界常常很難，你會發(fā)現(xiàn)實踐一下會更容易。

查看微服務(wù)邊界的另一種方法是，應(yīng)該幾周內(nèi)就能重寫整個微服務(wù)，而不是花幾個月來重寫服務(wù)。

③更好的技術(shù)替代方案或多語言編程

針對特定領(lǐng)域的語言可用于幫助解決問題域（problem domain）。這尤其適用于過去你收到許多改進(jìn)請求，預(yù)計將來會繼續(xù)如此的組件。

如果你不僅認(rèn)為可以使用市面上的新語言或功能簡化這種組件的實現(xiàn)，將來的維護(hù)和更新還會變得更容易，現(xiàn)在正是應(yīng)對這種變化的時候。

在其他情況下，你可能發(fā)現(xiàn)另一種語言提供的并發(fā)抽象比目前使用的語言更容易。

可以將新語言用于特定的微服務(wù)，而應(yīng)用程序的其余部分仍然使用不同的語言。

同樣，你可能希望一些微服務(wù)非常快，可能決定用 C 語言編寫以獲得***效益，而不是用另一種高級語言編寫。說到底是要利用這種靈活性。

④存儲替代方案或多語言持久性

大數(shù)據(jù)大行其道，如果使用 NoSQL 數(shù)據(jù)庫而不是關(guān)系數(shù)據(jù)庫，應(yīng)用程序的一些組件可能會提供價值。

如果應(yīng)用程序中的任何此類組件可得益于該替代方案，可能正是改用 NoSQL 的時候。

這些是你應(yīng)該為整體式應(yīng)用程序中的每個服務(wù)或功能而考慮的關(guān)鍵方面，你需要先注重這幾項的轉(zhuǎn)換。一旦你從高優(yōu)先級的部分獲得了價值，隨后可以運(yùn)用其他規(guī)則。

⑤修改請求

任何軟件生命周期中要跟蹤的一個重要方面是新的改進(jìn)請求或更改。由于構(gòu)建和部署時間，更改請求數(shù)量更多的功能可能適用于微服務(wù)。

分離這類服務(wù)可以縮短構(gòu)建和部署時間，因為你不必構(gòu)建整個應(yīng)用程序，只需更改微服務(wù)，這還可以為應(yīng)用程序的其余部分提高可用性時間。

⑥應(yīng)用程序的某些部分總是增加部署的復(fù)雜性

在整體式應(yīng)用程序中，即使某項功能未加變動，你仍得完成整個構(gòu)建和部署過程。

如果存在這種情況，劃分這些組件并用微服務(wù)取代大有助益，這樣可以為整體式應(yīng)用程序的其余部分縮短總的部署時間。

⑦輔助服務(wù)

在大多數(shù)應(yīng)用程序中，核心或主要的服務(wù)依賴一些輔助服務(wù)。沒有這類輔助功能，可能會影響核心服務(wù)的可用性。

比如在求助臺應(yīng)用程序中，工單依賴產(chǎn)品目錄服務(wù)。如果產(chǎn)品目錄服務(wù)不可用，用戶無法提交工單。

如果存在這種情況，應(yīng)將輔助服務(wù)轉(zhuǎn)換成微服務(wù)，并確保高可用性，以便它們可以更好地服務(wù)于核心服務(wù)。（這些又叫斷路器服務(wù)。）

視應(yīng)用程序而定，這些標(biāo)準(zhǔn)可能需要將大多數(shù)服務(wù)轉(zhuǎn)換成微服務(wù)，目的是簡化轉(zhuǎn)換過程，那樣你可以確定優(yōu)先級，并為遷移到基于微服務(wù)的架構(gòu)制定路線圖。

為服務(wù)重新設(shè)計架構(gòu)

一旦確定了要遷移的轉(zhuǎn)換成微服務(wù)的功能，可以遵循前面所述的***實踐，開始為已選擇的服務(wù)重新設(shè)計架構(gòu)。

以下是需要牢記的幾個方面：

• 微服務(wù)定義。為每個功能定義適當(dāng)?shù)奈⒎?wù)，應(yīng)包括通信機(jī)制（API）和技術(shù)定義等。

考慮現(xiàn)有功能使用的數(shù)據(jù)，或針對微服務(wù)相應(yīng)地創(chuàng)建和規(guī)劃數(shù)據(jù)策略。如果該功能在 Oracle 之類的密集數(shù)據(jù)庫上，遷移到 MySQL 是否有意義？

確定你將如何管理數(shù)據(jù)關(guān)系。***，將每個微服務(wù)作為單獨的應(yīng)用程序來運(yùn)行。

• 重構(gòu)代碼。如果你未改變編程語言，可以重用一些代碼。考慮存儲/數(shù)據(jù)庫層：共享 vs 專用，內(nèi)存中 vs 外部。

目的在于除非需要，否則不添加新功能，而是重新打包現(xiàn)有代碼并公開所需的 API。

• 開始編碼之前，確定源代碼控制和版本控制機(jī)制，并確保遵循這些標(biāo)準(zhǔn)。每個微服務(wù)都是單獨的一項，作為單獨的應(yīng)用程序來部署。
• 數(shù)據(jù)遷移。如果你決定創(chuàng)建新數(shù)據(jù)庫，還要遷移舊數(shù)據(jù)。這通常通過編寫簡單的 SQL 腳本來完成，具體取決于你的源代碼和目的地。
• 整體式代碼。最初將現(xiàn)有代碼留在整體式應(yīng)用程序中，以防萬一要回滾。你可以更新其余代碼以使用新的微服務(wù)，或者劃分應(yīng)用程序流量（如果可能），同時使用整體式版本和微服務(wù)版本。

這讓你有機(jī)會測試和關(guān)注性能。一旦有信心，你可以將所有流量遷移到微服務(wù)，禁用或刪除舊代碼。

• 獨立地構(gòu)建、部署和管理。要獨立構(gòu)建和部署每個微服務(wù)。推出新版本的微服務(wù)時，可以再次劃分舊版本和新版本之間的流量。

這意味著你可能在生產(chǎn)環(huán)境中運(yùn)行相同微服務(wù)的兩個或更多版本。一些用戶流量可以路由到新的微服務(wù)版本，確保服務(wù)正常運(yùn)行、性能良好。

如果新版本未在***狀態(tài)下運(yùn)行，很容易將所有流量回滾到先前版本，并將新版本退回給開發(fā)團(tuán)隊。這里的關(guān)鍵是建立可重復(fù)的自動化部署流程，竭力實現(xiàn)持續(xù)交付。

• 刪除舊代碼。只有在確認(rèn)一切已正確遷移并按預(yù)期運(yùn)行后，才能刪除臨時代碼，并從舊存儲位置刪除數(shù)據(jù)。務(wù)必在此過程中做好備份。

微服務(wù)的混合方法

開發(fā)人員編寫全新的應(yīng)用程序時，可以直接遵循微服務(wù)架構(gòu)原則和藍(lán)圖來構(gòu)建應(yīng)用軟件。開發(fā)人員有時遵循微服務(wù)和整體式應(yīng)用程序的混合方法。

在這種情況下，他們可以將應(yīng)用程序的部分組件開發(fā)成微服務(wù)，其余部分基于某些標(biāo)準(zhǔn)遵循標(biāo)準(zhǔn)的 SOA/MVC 實踐。

其想法是，并非應(yīng)用程序的所有組件都可以轉(zhuǎn)換成微服務(wù)。微服務(wù)提供了很大的靈活性，但這種靈活性要付出一些代價。

混合方法旨在兼顧靈活性和成本這兩方面，以后可以根據(jù)需要從整體式應(yīng)用程序獲取組件、轉(zhuǎn)換成微服務(wù)。關(guān)鍵是在這個轉(zhuǎn)變期間牢記這兩種方法以及微服務(wù)標(biāo)準(zhǔn)。

福利來啦

你覺得單體架構(gòu)遷移到微服務(wù)架構(gòu)還有哪些關(guān)鍵點？掃描下方二維碼，關(guān)注51CTO技術(shù)棧公眾號。歡迎在技術(shù)棧微信公眾號留言探討。小編將選出留言最精彩的 5 名網(wǎng)友，送出《Spring 5開發(fā)大全》圖書一本~活動截止時間 1 月 11 日十二時整，特別鳴謝北京大學(xué)出版社為本次活動提供的圖書贊助。等不及送書的小伙伴，可以點擊閱讀原文直接購買。

書籍簡介

本書力求全面介紹 Spring 框架，涵蓋了 Spring 核心、測試、數(shù)據(jù)訪問、 Web 開發(fā)、響應(yīng)式編程、系統(tǒng)集成及微服務(wù)等方面在內(nèi)的共 26 章的內(nèi)容，可以說是 Spring 技術(shù)的“百科全書”。同時，本書基于 Spring 5 版本來編寫，除了涉及 Spring 5 版本的新特性外，還介紹了 REST 服務(wù)、響應(yīng)式 Web 開發(fā)、微服務(wù)設(shè)計、Spring Boot、Spring Cloud 等方面的前瞻技術(shù)。而且除了講解 Spring 的理論知識外，還在每個知識點上輔以大量的代碼案例，使理論可以聯(lián)系實際，具備更強(qiáng)的可操作性。 

本書主要面向的是 Java 開發(fā)者，以及對以 Spring 為核心的 Java EE 開發(fā)感興趣的計算機(jī)專業(yè)的學(xué)生、軟件開發(fā)人員和系統(tǒng)架構(gòu)師。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】