譯者 | 李睿

審校 | 重樓

在當(dāng)今快節(jié)奏的軟件開發(fā)環(huán)境中，微服務(wù)已經(jīng)成為一種流行的架構(gòu)模式。但是什么是微服務(wù)呢?簡而言之，微服務(wù)是一種將應(yīng)用程序構(gòu)建為通過輕量級協(xié)議進(jìn)行通信的松散耦合、細(xì)粒度服務(wù)的集合的方法。這種架構(gòu)風(fēng)格使企業(yè)的團(tuán)隊能夠獨(dú)立地開發(fā)和部署服務(wù)，為軟件開發(fā)過程提供靈活性和可擴(kuò)展性。

微服務(wù)背后的基本思想是將應(yīng)用程序分解為更小的、自包含的服務(wù)，每個服務(wù)負(fù)責(zé)特定的業(yè)務(wù)功能。以網(wǎng)上購物應(yīng)用程序?yàn)槔?，微服?wù)架構(gòu)允許用戶將搜索、購物車、支付和訂單歷史記錄等不同的功能識別為獨(dú)立的服務(wù)，而不是將整個應(yīng)用程序視為一個整體的實(shí)體。這些服務(wù)可以單獨(dú)開發(fā)和維護(hù)，從而促進(jìn)代碼模塊化，并增強(qiáng)整個系統(tǒng)的靈活性。

微服務(wù)的歷史

微服務(wù)是如何產(chǎn)生的呢?當(dāng)一些軟件架構(gòu)師認(rèn)識到許多公司面臨的共同挑戰(zhàn)：構(gòu)建太大而無法有效管理的系統(tǒng)時，微服務(wù)的概念得到了關(guān)注。他們意識到，超出定義邊界的系統(tǒng)在進(jìn)行更改時會產(chǎn)生獨(dú)特的問題。因此，重點(diǎn)從維護(hù)現(xiàn)有組件轉(zhuǎn)移到構(gòu)建可替換的系統(tǒng)。這種觀點(diǎn)的轉(zhuǎn)變催生了微服務(wù)方法。

微服務(wù)已經(jīng)被廣泛采用，世界各地的公司都在積極采用這種架構(gòu)風(fēng)格。擁有大規(guī)模系統(tǒng)的企業(yè)發(fā)現(xiàn)，微服務(wù)是管理復(fù)雜性和提高可擴(kuò)展性的有效解決方案。這些企業(yè)可能有數(shù)十個、數(shù)百個甚至數(shù)千個微服務(wù)和諧地協(xié)同工作。

要點(diǎn)

通過將應(yīng)用程序組織到微服務(wù)中，企業(yè)的團(tuán)隊可以獲得一些好處。首先，微服務(wù)支持獨(dú)立的發(fā)布周期。每個服務(wù)都可以自主地開發(fā)、測試和部署，從而減少依賴并實(shí)現(xiàn)更快的迭代。此外，團(tuán)隊可以更容易地利用現(xiàn)成的服務(wù)，因?yàn)槲⒎?wù)允許與外部組件無縫集成。

雖然微服務(wù)提供了許多優(yōu)勢，但它們也帶來了一些挑戰(zhàn)。仔細(xì)設(shè)計服務(wù)接口對于維護(hù)松耦合并將其視為公共API至關(guān)重要。在單個服務(wù)中擁有相同服務(wù)的多個版本或多個接口，以確保向后兼容性，并最大限度地減少對現(xiàn)有用戶的干擾，這種情況并不少見。這種方法需要縝密的計劃和對細(xì)節(jié)的關(guān)注。

微服務(wù)的另一個關(guān)鍵方面是信息隱藏的概念。每個微服務(wù)都封裝了自己的功能，并且只向外部世界公開了一個最小的、定義良好的接口。這促進(jìn)了可以獨(dú)立更改的組件和難以修改的組件之間的清晰分離。輕量級協(xié)議（例如REST API或消息傳遞隊列）的使用允許微服務(wù)在保持其內(nèi)部實(shí)現(xiàn)細(xì)節(jié)隱藏的同時進(jìn)行高效通信。

微服務(wù)的好處

微服務(wù)在軟件開發(fā)行業(yè)中越來越受歡迎，因?yàn)樗鼈兲峁┝嗽S多好處。這些優(yōu)點(diǎn)有助于實(shí)現(xiàn)更高層次的目標(biāo)，例如速度、安全性和規(guī)模。以下探討采用微服務(wù)架構(gòu)的一些關(guān)鍵優(yōu)勢：

• 更快的編譯和構(gòu)建時間：使用微服務(wù)，開發(fā)人員可以體驗(yàn)到更快的構(gòu)建和編譯時間，這顯著地加快了整個開發(fā)過程。
• 更快的部署、更小的可部署規(guī)模：微服務(wù)允許每個組件的單獨(dú)部署，導(dǎo)致更小的可部署規(guī)模。這意味著與單片應(yīng)用程序相比，將更改或更新部署到特定服務(wù)所需的時間更少。
• 自定義部署節(jié)奏：每個微服務(wù)都可以獨(dú)立部署，使企業(yè)能夠遵循自定義部署時間表。這種靈活性允許團(tuán)隊按照自己的節(jié)奏發(fā)布更新和特性。
• 自定義部署監(jiān)控：微服務(wù)為關(guān)鍵服務(wù)提供了細(xì)粒度監(jiān)控和額外檢查的優(yōu)勢。通過為每個微服務(wù)配置不同的監(jiān)控策略，企業(yè)可以確保最佳的性能和可靠性。
• 獨(dú)立和可配置的自動化測試：微服務(wù)允許獨(dú)立和可配置的自動化測試。這意味著可以為每個微服務(wù)執(zhí)行不同的測試，從而減少測試整個應(yīng)用程序所需的時間和精力。
• 跨語言支持：微服務(wù)架構(gòu)允許為不同的服務(wù)使用不同的技術(shù)和編程語言。這種靈活性允許開發(fā)人員選擇適合每個微服務(wù)特定需求的最佳工具和技術(shù)。
• 更簡單的API：微服務(wù)強(qiáng)調(diào)細(xì)粒度API的開發(fā)，這促進(jìn)了服務(wù)之間清晰高效的通信。定義良好的API可以更容易地集成和組合系統(tǒng)內(nèi)的不同服務(wù)。
• 水平擴(kuò)展：微服務(wù)被設(shè)計為水平擴(kuò)展，允許特定服務(wù)根據(jù)其需求獨(dú)立擴(kuò)展。這種可擴(kuò)展性方法減少了資源消耗，并實(shí)現(xiàn)了經(jīng)濟(jì)高效的可擴(kuò)展性。
• 故障隔離：微服務(wù)通過分離服務(wù)提供安全機(jī)制，防止重大系統(tǒng)故障在整個應(yīng)用程序中級聯(lián)。這種故障隔離可以確保一個服務(wù)中的故障不會影響其他服務(wù)的正常運(yùn)行。
• 可理解性：微服務(wù)由于其較小的代碼基數(shù)，有助于更好的代碼可維護(hù)性和可理解性。開發(fā)人員可以專注于特定的服務(wù)，從而在需要時更容易理解和修改代碼。
• 成本優(yōu)化：通過在低級實(shí)例上運(yùn)行不同的應(yīng)用程序組件，微服務(wù)允許企業(yè)在不影響性能的情況下優(yōu)化成本。硬件需求的靈活性為選擇經(jīng)濟(jì)有效的解決方案提供了更多的自由。
• 分布式開發(fā)：微服務(wù)促進(jìn)組件的獨(dú)立開發(fā)，這對分布式團(tuán)隊特別有利。開發(fā)人員可以處理單獨(dú)的服務(wù)，從而支持并行開發(fā)和更快的迭代周期。
• 技術(shù)自由：微服務(wù)使企業(yè)能夠更容易地采用和試驗(yàn)新技術(shù)。每個微服務(wù)都可以作為新技術(shù)的試驗(yàn)場，從而降低在單片應(yīng)用程序中采用這些技術(shù)的風(fēng)險。
• 獨(dú)立決策：開發(fā)人員可以自由地為每個微服務(wù)做出有關(guān)編程語言、庫和工具的決策。這種自主權(quán)促進(jìn)了分布式?jīng)Q策，并使開發(fā)人員能夠根據(jù)他們的特定需求選擇最佳解決方案。
• 消除不必要的依賴：微服務(wù)有助于識別和消除組件之間不需要的依賴。通過解耦服務(wù)，企業(yè)可以將某些服務(wù)的使用限制在應(yīng)用程序的特定部分，從而提高整體的模塊化和可維護(hù)性。

微服務(wù)的挑戰(zhàn)

與任何其他解決方案一樣，微服務(wù)也有其缺點(diǎn)和局限性。以下討論微服務(wù)架構(gòu)的一些缺點(diǎn)：

• 更高的資源開銷：當(dāng)一個應(yīng)用程序被分成多個組件，每個組件作為一個單獨(dú)的服務(wù)運(yùn)行時，它需要這些組件之間通過網(wǎng)絡(luò)進(jìn)行通信。這會導(dǎo)致網(wǎng)絡(luò)流量、延遲和I/O使用增加，從而導(dǎo)致更高的資源開銷。此外，單獨(dú)運(yùn)行每個組件會消耗更多的CPU和內(nèi)存資源，進(jìn)一步增加資源需求。
• 調(diào)試?yán)щy：在微服務(wù)環(huán)境中，故障排除和調(diào)試變得更具挑戰(zhàn)性。當(dāng)請求失敗時，開發(fā)人員需要訪問處理請求所涉及的多個服務(wù)的日志，以確定失敗的原因。服務(wù)的這種分布式特性使得調(diào)試更加復(fù)雜和耗時。
• 集成測試：將系統(tǒng)分解為微服務(wù)需要構(gòu)建一套全面的集成測試，以確保每個組件的兼容性和可用性。編寫和維護(hù)這些測試既耗時又耗費(fèi)資源，因?yàn)樗婕暗綔y試多個服務(wù)之間的交互。
• 一致性和事務(wù)：微服務(wù)架構(gòu)經(jīng)常導(dǎo)致數(shù)據(jù)分散在整個系統(tǒng)中。雖然這種分離有助于解耦和獨(dú)立性，但它使維護(hù)一致性和執(zhí)行需要跨多個服務(wù)進(jìn)行原子更改的事務(wù)操作變得具有挑戰(zhàn)性。
• 分歧：微服務(wù)架構(gòu)中的不同服務(wù)可能使用不同版本的庫，包括不兼容或過時的庫。依賴關(guān)系的分歧使得執(zhí)行系統(tǒng)升級和解決問題（包括軟件漏洞修復(fù)）變得困難。
• 技術(shù)債務(wù)可解決性：在每個組件由不同團(tuán)隊擁有的分布式系統(tǒng)中，解決技術(shù)債務(wù)變得更具挑戰(zhàn)性?？缍鄠€團(tuán)隊協(xié)調(diào)和確定債務(wù)解決的優(yōu)先級可能既復(fù)雜又耗時。
• 可觀察性：在微服務(wù)架構(gòu)中管理多個應(yīng)用程序在收集和利用系統(tǒng)事件、日志、跟蹤和指標(biāo)方面引入了額外的復(fù)雜性。確保適當(dāng)?shù)目捎^測性，需要從所有應(yīng)用程序收集信號并使其可用于分析，這可能是一項重要的工作。
• 可能的重復(fù)和重疊功能：在分布式開發(fā)環(huán)境中，多個組件執(zhí)行相似的角色并不罕見。需要在系統(tǒng)內(nèi)設(shè)置清晰的邊界，以避免重復(fù)，并確保組件具有良好定義的職責(zé)。
• 所有權(quán)和責(zé)任：由于不同的團(tuán)隊維護(hù)和開發(fā)獨(dú)立的組件，這使得定義明確的所有權(quán)合同變得至關(guān)重要。所有權(quán)定義了與開發(fā)請求、安全性、支持問題和維護(hù)工作相關(guān)的責(zé)任。

什么時候應(yīng)該使用微服務(wù)

微服務(wù)架構(gòu)在各種場景下都能很好地工作：

• 多個獨(dú)立工作的開發(fā)人員：企業(yè)經(jīng)常采用微服務(wù)，以允許更多的開發(fā)人員在同一個系統(tǒng)上工作，而不會產(chǎn)生沖突。通過適當(dāng)?shù)募軜?gòu)和組織邊界，微服務(wù)支持獨(dú)立工作并減少交付爭用。
• 可擴(kuò)展性和增長：快速增長的公司，尤其是那些規(guī)模達(dá)到100人以上的公司，會發(fā)現(xiàn)使用一個一致性強(qiáng)的微服務(wù)架構(gòu)更容易適應(yīng)增長。根據(jù)需要擴(kuò)大或縮小服務(wù)的能力提供了對系統(tǒng)可擴(kuò)展性的經(jīng)濟(jì)有效的控制。
• 軟件即服務(wù)(SaaS)應(yīng)用：微服務(wù)非常適合需要全天候運(yùn)行和頻繁更新的SaaS應(yīng)用。微服務(wù)的獨(dú)立發(fā)布能力簡化了變更的推出，并且可以根據(jù)需求進(jìn)行擴(kuò)展。
• 云平臺兼容性：微服務(wù)可以有效地與云平臺協(xié)同工作，充分利用各種可用的服務(wù)和部署機(jī)制。用戶可以根據(jù)特定需求選擇最合適的云服務(wù)，例如將一些服務(wù)部署為功能，將其他服務(wù)部署為托管虛擬機(jī)，以及將一些服務(wù)部署在托管平臺即服務(wù)(PaaS)平臺上。
• 面向未來變化的靈活性：微服務(wù)架構(gòu)為系統(tǒng)演化提供了靈活性。雖然這是有代價的，但它允許用戶為未來的更改保留選擇，并輕松采用新技術(shù)或方法。

微服務(wù)小貼士

以下是一些關(guān)鍵的建議：

• 不要太早引入微服務(wù)：如果產(chǎn)品仍然定義松散，或者可能會發(fā)生重大變化，最好避免過早使用微服務(wù)架構(gòu)。在開發(fā)的早期階段，可能會有許多更改，從單一應(yīng)用程序開始，然后隨著定義清晰的業(yè)務(wù)功能和邊界而逐漸將其拆分，這樣可以減少不必要的工作，并在組件之間建立適當(dāng)?shù)慕涌凇?
• 不搞一刀切：每個公司都是獨(dú)一無二的，采用微服務(wù)的決定應(yīng)該考慮團(tuán)隊規(guī)模、分布和地理等因素。小型的本地團(tuán)隊可能會發(fā)現(xiàn)采用單一應(yīng)用程序就足夠了，而地理上分散的團(tuán)隊則可以從多個微服務(wù)的靈活性中受益。
• 針對故障的設(shè)計：在微服務(wù)架構(gòu)中，組件之間存在大量交互，通常是通過遠(yuǎn)程調(diào)用和事件。這增加了失敗的可能性，例如網(wǎng)絡(luò)超時或客戶端錯誤。在構(gòu)建系統(tǒng)時要考慮故障場景，并計劃不同的處理方法。
• 投資自動化：擁有更多獨(dú)立的組件，嚴(yán)格的檢查和自動化成為確保服務(wù)之間穩(wěn)定集成的必要條件。投資于可靠的自動化對于實(shí)現(xiàn)高度的可靠性和安全的變更部署至關(guān)重要。
• 避免分層：雖然根據(jù)組織結(jié)構(gòu)拆分應(yīng)用程序似乎很方便，但這并不總是最好的方法。與其相反，應(yīng)該定義清晰的領(lǐng)域和業(yè)務(wù)功能，圍繞這些領(lǐng)域和業(yè)務(wù)功能構(gòu)建代碼，并關(guān)注組件如何相互交互。這種方法可能需要更多的努力，但是在系統(tǒng)組成和靈活性方面的回報是值得的。
• 投資集成測試：對微服務(wù)之間的集成進(jìn)行全面的自動化測試是必不可少的。確保各種服務(wù)無縫地協(xié)同工作。
• 考慮向后兼容性：保持更改向后兼容以確保安全部署非常重要。版本控制等技術(shù)可以在引入新特性時幫助管理兼容性。

例子

微服務(wù)提供的靈活性、可擴(kuò)展性和模塊化使它們成為構(gòu)建大型復(fù)雜系統(tǒng)的熱門選擇。以下是微服務(wù)在不同行業(yè)中應(yīng)用的幾個例子：

• Netflix：Netflix使用微服務(wù)架構(gòu)構(gòu)建了自己的流媒體平臺。每個組件(如用戶管理、推薦引擎和視頻流)都作為單獨(dú)的微服務(wù)實(shí)現(xiàn)。這使他們能夠獨(dú)立地擴(kuò)展系統(tǒng)的不同部分，并快速適應(yīng)不斷變化的需求。
• 優(yōu)步：優(yōu)步的平臺建立在微服務(wù)的基礎(chǔ)上，可以處理各種功能，例如用戶管理、乘車預(yù)約、實(shí)時跟蹤、支付處理和司機(jī)調(diào)度。微服務(wù)使它們能夠處理高流量、分配工作負(fù)載和快速引入新特性。
• Airbnb：Airbnb利用微服務(wù)為其住宿預(yù)訂平臺提供動力。不同的微服務(wù)處理屬性列表、搜索和過濾、預(yù)訂、支付和消息傳遞等功能。微服務(wù)允許Airbnb有效地擴(kuò)展其系統(tǒng)，并提供無縫的預(yù)訂體驗(yàn)。
• Spotify：Spotify采用微服務(wù)為數(shù)百萬用戶提供個性化的音樂流媒體服務(wù)。它們使用微服務(wù)來實(shí)現(xiàn)用戶認(rèn)證、音樂推薦、播放列表管理和音頻播放等功能。這種模塊化架構(gòu)幫助他們快速迭代，并為用戶提供個性化的體驗(yàn)。
• 亞馬遜：亞馬遜的電子商務(wù)平臺嚴(yán)重依賴微服務(wù)。每個服務(wù)處理特定的功能，例如產(chǎn)品目錄、庫存管理、支付處理、客戶評論和訂單履行。微服務(wù)使亞馬遜能夠擴(kuò)展其平臺，處理高流量，并提供無縫的購物體驗(yàn)。

結(jié)論

微服務(wù)提供靈活性、可擴(kuò)展性和獨(dú)立開發(fā)，使它們成為各種情況下有價值的架構(gòu)。但是，企業(yè)有必要評估自己的具體情況，并將其與微服務(wù)帶來的好處和挑戰(zhàn)相結(jié)合，以確定微服務(wù)是否適合自己的應(yīng)用程序。

原文標(biāo)題：Microservices Decoded: Unraveling the Benefits, Challenges, and Best Practices for APIs，作者：Piyush Tripathi