【51CTO.com快譯】不知您是否還記得，過(guò)去傳統(tǒng)的應(yīng)用程序往往是作為一個(gè)整體被開(kāi)發(fā)出來(lái)，然后被打包成為一個(gè)代碼包，進(jìn)而作為一個(gè)整體單元被部署的。一直以來(lái)，這種單體架構(gòu)本身和與之相關(guān)的維護(hù)極具復(fù)雜性，而且開(kāi)發(fā)與迭代速度也相當(dāng)緩慢。這些都在促進(jìn)軟件開(kāi)發(fā)企業(yè)去不斷地尋求具有可持續(xù)性、靈活性、以及易于集成的新型替代方案。

微服務(wù)架構(gòu)的出現(xiàn)打破了這樣的僵局。它代表了眾多小型、自動(dòng)化和自包含的服務(wù)的單一集合。下圖展示了系統(tǒng)如何通過(guò)一個(gè)API網(wǎng)關(guān)，去訪問(wèn)多個(gè)微服務(wù)的邏輯。

微服務(wù)架構(gòu)雖然有著諸多優(yōu)勢(shì)，但是貿(mào)然從單體架構(gòu)切換過(guò)去，可能會(huì)讓許多企業(yè)由于低估了整體的復(fù)雜性，而導(dǎo)致成本的激增，以及在研發(fā)的關(guān)鍵時(shí)刻出現(xiàn)災(zāi)難性的意外錯(cuò)誤。下面讓我們一起討論十二種值得遵循的，從單體架構(gòu)向微服務(wù)轉(zhuǎn)型的設(shè)計(jì)原則與優(yōu)秀實(shí)踐。

1. 提供單獨(dú)的數(shù)據(jù)存儲(chǔ)

在考慮遷移之前，請(qǐng)事先弄清楚將會(huì)如何根據(jù)各種微服務(wù)組件來(lái)分離數(shù)據(jù)的存儲(chǔ)。您可以通過(guò)使用諸如“命令與查詢(xún)責(zé)任隔離”（Command and Query Responsibility Segregation，CQRS，請(qǐng)參考：https://dzone.com/articles/microservices-with-cqrs-and-event-sourcing）之類(lèi)的架構(gòu)模式來(lái)實(shí)現(xiàn)，以使得數(shù)據(jù)對(duì)每一個(gè)微服務(wù)都是私有的。

如果各個(gè)服務(wù)都無(wú)法成為其數(shù)據(jù)的唯一所有者，那么就會(huì)導(dǎo)致多個(gè)服務(wù)需要訪問(wèn)同一個(gè)私有數(shù)據(jù)庫(kù)的情況，即：產(chǎn)生了耦合問(wèn)題。也就是說(shuō)，我們最好不要在微服務(wù)之間直接共享數(shù)據(jù)，而是要通過(guò)API來(lái)實(shí)現(xiàn)。

2. 建立專(zhuān)門(mén)的團(tuán)隊(duì)

微服務(wù)的主要優(yōu)勢(shì)體現(xiàn)在云原生的應(yīng)用上。這就意味著：任何更新，都需要相對(duì)快速且實(shí)時(shí)的發(fā)布。也就是說(shuō)，任何停機(jī)都會(huì)給業(yè)務(wù)造成重大的損失。因此，如果您想進(jìn)行線(xiàn)性且高效的擴(kuò)展，就需要為每個(gè)微服務(wù)分配專(zhuān)門(mén)的開(kāi)發(fā)團(tuán)隊(duì)。

不過(guò)，光靠開(kāi)發(fā)人員則很難掌控大型應(yīng)用全面的端到端方案。我們需要擁有一支專(zhuān)業(yè)的團(tuán)隊(duì)，在熟悉管理細(xì)微差別的基礎(chǔ)上，憑借轉(zhuǎn)換技術(shù)與開(kāi)發(fā)效率，進(jìn)而遵循微服務(wù)的各項(xiàng)優(yōu)秀實(shí)踐。

3. 使用自動(dòng)化進(jìn)行獨(dú)立部署

為了將單體架構(gòu)分解成為多個(gè)單獨(dú)的微服務(wù)，我們需要確保實(shí)現(xiàn)“構(gòu)建和發(fā)布”的自動(dòng)化結(jié)構(gòu)。這樣不僅可以有助于減少總體的交付時(shí)間，而且可以加快發(fā)布的速度，進(jìn)而改善部署的整個(gè)過(guò)程?？梢哉f(shuō)，有了自動(dòng)化，微服務(wù)就能夠被妥善地封裝到容器中，并能夠有效地部署到包括云端在內(nèi)的任何環(huán)境里。

4. 利用REST API的好處

開(kāi)發(fā)人員在創(chuàng)建REST（Representational State Transfer，表示性狀態(tài)傳輸）API時(shí)無(wú)需安裝任何其他的軟件與庫(kù)，因此它為微服務(wù)提供了巨大的靈活性，數(shù)據(jù)也不再綁定到任何特定的方法或資源之上。通過(guò)REST API，微服務(wù)可以處理多種類(lèi)型的調(diào)用，返回不同的數(shù)據(jù)格式，以及具有通過(guò)正確地實(shí)施超媒體，來(lái)修改結(jié)構(gòu)的能力。

5. 了解文化的轉(zhuǎn)變

對(duì)于傳統(tǒng)的開(kāi)發(fā)人員而言，他們習(xí)慣了端到端的測(cè)試環(huán)境。而隨著從單體架構(gòu)遷移過(guò)渡到基于微服務(wù)的架構(gòu)，他們必須突然從大的格局轉(zhuǎn)為關(guān)注一小部分的功能，而且管理層對(duì)此還充滿(mǎn)了期望?？梢?jiàn)，這更大程度上是文化上的轉(zhuǎn)變，而不僅僅是開(kāi)發(fā)技術(shù)上的變化。也就是說(shuō)，開(kāi)發(fā)人員需要理解和平衡公司愿景與自身工作方式的轉(zhuǎn)換。

6. 將遷移分解為多步驟

如果您過(guò)去從未處理過(guò)此類(lèi)遷移，那么請(qǐng)您做好無(wú)法一蹴而就的準(zhǔn)備。單體架構(gòu)通常會(huì)涉及一個(gè)包含有存儲(chǔ)庫(kù)、部署、監(jiān)控、以及其他復(fù)雜任務(wù)的協(xié)作網(wǎng)絡(luò)。因此，最好的方法之一就是：在暫時(shí)保留單體結(jié)構(gòu)的基礎(chǔ)上，并行開(kāi)發(fā)其他作為微服務(wù)的功能。一旦實(shí)現(xiàn)了新的服務(wù)，同時(shí)團(tuán)隊(duì)也已對(duì)新的流程有所了解，我們就可以在厘清如何將舊的架構(gòu)分解成為相關(guān)組件的基礎(chǔ)上，開(kāi)始逐一進(jìn)行遷移。

7. 在混合系統(tǒng)上構(gòu)建分離系統(tǒng)

定義不同復(fù)雜部分之間的交互作用和過(guò)程，是微服務(wù)的關(guān)鍵設(shè)計(jì)原則與優(yōu)秀實(shí)踐之一。因此，我們?cè)谶w移項(xiàng)目的初始階段，就應(yīng)當(dāng)考慮到拆分系統(tǒng)。每個(gè)拆分系統(tǒng)都應(yīng)當(dāng)對(duì)于正在構(gòu)建的架構(gòu)來(lái)說(shuō)是唯一的。我們可以通過(guò)檢查單體結(jié)構(gòu)，來(lái)持續(xù)監(jiān)控各個(gè)組件的性能，以便了解各個(gè)組件之間的差異性，以及在微服務(wù)轉(zhuǎn)換時(shí)可能出現(xiàn)的問(wèn)題。

我們可以參考如下監(jiān)視過(guò)程的工具：

• New Relic
• Datadog
• InfluxDB
• Grafana

8. 隔離運(yùn)行時(shí)（Runtime）進(jìn)程

由于我們往往針對(duì)不同的垂直細(xì)分領(lǐng)域有著不同的流程，因此我們需要在運(yùn)行時(shí)的級(jí)別上也具有一定的隔離性。例如，您可以通過(guò)某種形式的分布式計(jì)算，來(lái)分別實(shí)現(xiàn)容器化、事件架構(gòu)、各種HTTP管理方法、服務(wù)網(wǎng)格和斷路器（circuit breakers）等。

9. 將正確的技術(shù)與正確的微服務(wù)相配對(duì)

正所謂殊途同歸。也許在您的團(tuán)隊(duì)中，不同的成員會(huì)偏好使用不同的技術(shù)和編程語(yǔ)言來(lái)實(shí)現(xiàn)微服務(wù)，但是請(qǐng)盡量選用那些易于日后方便更改或替換的技術(shù)，來(lái)實(shí)現(xiàn)快速上手與直接迭代。當(dāng)然，如果您并不確定哪種技術(shù)最適合自己的項(xiàng)目，那么請(qǐng)?jiān)跊Q策過(guò)程中考慮以下方面：

• 可維護(hù)性。
• 容錯(cuò)性。
• 可擴(kuò)展性。
• 構(gòu)建成本。
• 易部署性。

10. 考慮使用域驅(qū)動(dòng)式設(shè)計(jì)（Domain-Driven Design）

域驅(qū)動(dòng)式設(shè)計(jì)在某種程度上可以被理解為：應(yīng)用于業(yè)務(wù)模型的面向?qū)ο缶幊?。作為一種設(shè)計(jì)原則，它利用實(shí)踐規(guī)則和思想來(lái)表達(dá)面向?qū)ο蟮哪Ｐ?。?jiǎn)單來(lái)說(shuō)：我們需要圍繞著自己的業(yè)務(wù)領(lǐng)域來(lái)設(shè)計(jì)微服務(wù)。例如，Netflix等平臺(tái)就是使用不同服務(wù)器上的微服務(wù)，來(lái)進(jìn)行內(nèi)容交付和相關(guān)的跟蹤服務(wù)。

11. 區(qū)分專(zhuān)用資源和按需資源

如果您的主要目標(biāo)是提供卓越的客戶(hù)體驗(yàn)，那么請(qǐng)考慮將專(zhuān)用資源和按需資源區(qū)分開(kāi)來(lái)。例如，針對(duì)某個(gè)電子商務(wù)平臺(tái)，我們可以通過(guò)構(gòu)建其微服務(wù)和云架構(gòu)，來(lái)實(shí)現(xiàn)快速且安全地在內(nèi)部平臺(tái)和云環(huán)境之間，部署并轉(zhuǎn)移不同的工作負(fù)載。這樣不僅縮短了資源的響應(yīng)時(shí)間，也使得遷移到云端的流量與資源更加直觀。

12. 治理對(duì)開(kāi)源工具的依賴(lài)

對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，使用開(kāi)源的微服務(wù)工具進(jìn)行安全性、監(jiān)控、調(diào)試、以及日志記錄，可謂“家常便飯”。但是，請(qǐng)確保不會(huì)以過(guò)分依賴(lài)某些庫(kù)和工具的方式，去干擾架構(gòu)的性能或安全性。我們可以參考如下方面，同時(shí)根據(jù)實(shí)際的開(kāi)發(fā)需求和所用到工具的類(lèi)型，來(lái)實(shí)施各種適當(dāng)?shù)慕M織策略。

• 為已批準(zhǔn)的軟件版本，建立正式的存儲(chǔ)庫(kù)。
• 了解開(kāi)源軟件的供給關(guān)系。
• 建立處理異常的治理方案。

總結(jié)

綜上所述，從單體架構(gòu)向微服務(wù)架構(gòu)轉(zhuǎn)型的確極富挑戰(zhàn)性。上述設(shè)計(jì)原則與優(yōu)秀實(shí)踐為您提供了參考的思路與方法，您可以在實(shí)際開(kāi)發(fā)與遷移過(guò)程中，根據(jù)實(shí)際情況，按需采取逐步的方法，即：先從整體系統(tǒng)中的一小部分，而且是非關(guān)鍵的部分入手，通過(guò)厘清當(dāng)前各個(gè)組件的工作原理，以及了解微服務(wù)的相關(guān)技術(shù)與文化，進(jìn)而建立逐步的遷移計(jì)劃。同時(shí)，這樣也更容易獲取利益相關(guān)者，乃至組織層面上的支持。

原文標(biāo)題：Break a Monolith to Microservices — 12 Best Practices and Design Principles，作者：Mitul Makadia

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】