微服務(wù)的輝煌與困境

長(zhǎng)期以來(lái)，微服務(wù)被認(rèn)為是云原生服務(wù)應(yīng)用程序架構(gòu)的事實(shí)標(biāo)準(zhǔn) ，在過(guò)去的十年中，微服務(wù)架構(gòu)風(fēng)靡全球，成為了眾多企業(yè)構(gòu)建應(yīng)用程序的首選架構(gòu)。它將大型應(yīng)用程序拆分為多個(gè)小型、獨(dú)立的服務(wù)，每個(gè)服務(wù)都可以獨(dú)立開(kāi)發(fā)、部署和擴(kuò)展，這種高靈活性、可擴(kuò)展性和可維護(hù)性的特性，讓它在云原生時(shí)代大放異彩。

許多知名企業(yè)，如 Uber、Netflix 等，都采用了微服務(wù)架構(gòu)，并取得了顯著的業(yè)務(wù)成果。以 Uber 為例，在 2012-2013 年，它主要擁有兩個(gè)單體服務(wù)，隨著業(yè)務(wù)的增長(zhǎng)，遇到了可用性風(fēng)險(xiǎn)高、部署困難、缺乏關(guān)注點(diǎn)分離和執(zhí)行效率低下等問(wèn)題。于是，Uber 采用了微服務(wù)架構(gòu)，使得系統(tǒng)變得更加靈活，團(tuán)隊(duì)更加獨(dú)立，系統(tǒng)可靠性提高，關(guān)注點(diǎn)分離更加清晰，職責(zé)更加明確，開(kāi)發(fā)人員速度也得到了提升。

然而，隨著時(shí)間的推移和業(yè)務(wù)的不斷發(fā)展，微服務(wù)架構(gòu)的一些問(wèn)題也逐漸暴露出來(lái)。對(duì)于 Uber 來(lái)說(shuō)，微服務(wù)架構(gòu)也帶來(lái)了新的挑戰(zhàn)。隨著公司規(guī)模的擴(kuò)大，從 100 名工程師發(fā)展到 1000 名工程師，系統(tǒng)復(fù)雜性不斷升高。使用微服務(wù)架構(gòu)，用單體代碼庫(kù)換取黑盒功能，這些黑盒功能隨時(shí)可能改變，并且很容易導(dǎo)致意外的行為。工程師必須對(duì)多個(gè)團(tuán)隊(duì)的多個(gè)服務(wù)進(jìn)行檢查，以調(diào)查問(wèn)題的根本原因，理解服務(wù)之間的依賴關(guān)系變得相當(dāng)困難，依賴的第 n 個(gè)服務(wù)的延遲峰值可能會(huì)導(dǎo)致上游問(wèn)題的級(jí)聯(lián)，調(diào)試變得困難。

辦公管理軟件公司 Managed by Q 也有類似的經(jīng)歷。他們的應(yīng)用程序原本是一個(gè)部署在 ECS 上的 Django 單體，為了趕上現(xiàn)代化開(kāi)發(fā)實(shí)踐的步伐，轉(zhuǎn)向微服務(wù)架構(gòu)。但很快發(fā)現(xiàn)，每多一個(gè)新服務(wù)，就會(huì)增加一些基礎(chǔ)設(shè)施，開(kāi)發(fā)一個(gè)跨多個(gè)服務(wù)的功能需要做更多的工作。結(jié)果，在轉(zhuǎn)向微服務(wù)兩年之后，他們開(kāi)始合并微服務(wù)，一些微服務(wù)被合到了單體中，其他的則合并成較大的服務(wù)。

從這些案例可以看出，微服務(wù)架構(gòu)并非完美無(wú)缺。當(dāng)企業(yè)規(guī)模不斷擴(kuò)大，業(yè)務(wù)復(fù)雜度不斷增加時(shí)，微服務(wù)架構(gòu)的維護(hù)成本、管理難度以及性能問(wèn)題等都可能成為制約企業(yè)發(fā)展的因素。這也引發(fā)了業(yè)界對(duì)于微服務(wù)架構(gòu)的反思：微服務(wù)，是否已經(jīng)過(guò)時(shí)？

谷歌的新探索：打破傳統(tǒng)，邁向新范式

面對(duì)微服務(wù)架構(gòu)的困境，谷歌率先做出了新的探索。今年 6 月，一群谷歌員工（由谷歌軟件工程師 Michael Whittaker 領(lǐng)導(dǎo)）發(fā)表了一篇名為 “Towards Modern Development of Cloud Applications” 的論文 ，對(duì)當(dāng)下的微服務(wù)架構(gòu)提出了挑戰(zhàn)。

論文指出，從架構(gòu)上講，微服務(wù)本身存在問(wèn)題，它將邏輯邊界（如何編寫(xiě)代碼）與物理邊界（如何部署代碼）混為一談 。這一觀點(diǎn)切中了微服務(wù)架構(gòu)的要害，也引發(fā)了業(yè)界的廣泛關(guān)注。

基于這樣的認(rèn)識(shí)，谷歌的工程師們提出了一種堪稱 “微服務(wù) 2.0” 的方法。該方法鼓勵(lì)開(kāi)發(fā)人員編寫(xiě)分為邏輯組件的單片應(yīng)用程序，將物理分布和執(zhí)行模塊化單片的挑戰(zhàn)推遲到運(yùn)行時(shí)，并且原子部署應(yīng)用程序。簡(jiǎn)單來(lái)說(shuō)，就是將應(yīng)用程序構(gòu)建為邏輯整體，但將其交給自動(dòng)化運(yùn)行時(shí)，后者可以根據(jù)應(yīng)用程序所需的內(nèi)容和可用的內(nèi)容來(lái)決定在哪里運(yùn)行工作負(fù)載。

為了實(shí)現(xiàn)這一方法，谷歌還推出了 Service Weaver 框架。這是一個(gè)用于編寫(xiě)、部署和管理分布式應(yīng)用程序的編程框架，開(kāi)發(fā)者可以在機(jī)器上本地運(yùn)行、測(cè)試和調(diào)試 Service Weaver 應(yīng)用程序，然后使用單個(gè)命令將該應(yīng)用程序部署到云中。

通過(guò)這種新的方法和框架，谷歌取得了顯著的成果�；谛绿岢龅慕Y(jié)構(gòu)，他們能夠?qū)⑾到y(tǒng)的延遲降低 15 倍，成本降低 9 倍 。這一成果無(wú)疑是令人矚目的，也為云應(yīng)用開(kāi)發(fā)帶來(lái)了新的思路和方向。

新架構(gòu)的獨(dú)特之處：模塊化單體的魅力

谷歌提出的這種新架構(gòu)，被稱為 “模塊化單體” ，它既不是傳統(tǒng)的單體架構(gòu)，也不是純粹的微服務(wù)架構(gòu)，而是一種融合了兩者優(yōu)點(diǎn)的創(chuàng)新架構(gòu)。

在這種架構(gòu)中，應(yīng)用程序被構(gòu)建為一個(gè)邏輯整體，就像單體架構(gòu)一樣，代碼集中管理，便于開(kāi)發(fā)和維護(hù)。但與單體架構(gòu)不同的是，它又被分成了多個(gè)獨(dú)立的組件，每個(gè)組件都有自己的職責(zé)和功能，組件之間通過(guò)明確定義的接口進(jìn)行通信，這又具備了微服務(wù)架構(gòu)的靈活性和可擴(kuò)展性。

以一個(gè)電商系統(tǒng)為例，在傳統(tǒng)的單體架構(gòu)中，訂單管理、商品管理、用戶管理等功能模塊都緊密耦合在一起，牽一發(fā)而動(dòng)全身，任何一個(gè)小的改動(dòng)都可能影響整個(gè)系統(tǒng)的穩(wěn)定性。而在微服務(wù)架構(gòu)中，這些功能模塊被拆分成一個(gè)個(gè)獨(dú)立的服務(wù)，雖然提高了靈活性和可擴(kuò)展性，但也帶來(lái)了服務(wù)間通信復(fù)雜、管理難度大等問(wèn)題。

而模塊化單體架構(gòu)則很好地平衡了兩者的優(yōu)缺點(diǎn)。在這個(gè)電商系統(tǒng)中，訂單管理、商品管理、用戶管理等功能模塊可以作為獨(dú)立的組件存在，它們之間通過(guò)接口進(jìn)行通信。當(dāng)需要對(duì)訂單管理組件進(jìn)行升級(jí)或修改時(shí)，只要接口不變，就不會(huì)影響到其他組件的正常運(yùn)行。同時(shí)，由于這些組件都在同一個(gè)代碼庫(kù)中，開(kāi)發(fā)人員可以更方便地進(jìn)行代碼的管理和維護(hù)。

在谷歌推出的 Service Weaver 框架中，組件是一個(gè)非常獨(dú)特且核心的概念。一個(gè)應(yīng)用會(huì)包含多個(gè)組件，并且每一個(gè)組件都是一個(gè) Go 的 interface。例如，在一個(gè)簡(jiǎn)單的字符串處理應(yīng)用中，可能會(huì)有一個(gè) Reverser 組件，它的定義如下：

// Reverser component. type Reverser interface { Reverse(context.Context, string) (string, error) }

上述代碼定義了一個(gè) Reverser 接口，其中包含一個(gè) Reverse 方法，用于反轉(zhuǎn)字符串。而這個(gè)接口的實(shí)現(xiàn)可以是這樣：

// Implementation of the Reverser component. type reverser struct { weaver.Implements[Reverser] } func (r *reverser) Reverse(_ context.Context, s string) (string, error) { runes := []rune(s) n := len(runes) for i := 0; i < n/2; i++ { runes[i], runes[n-i-1] = runes[n-i-1], runes[i] } return string(runes), nil }

在實(shí)際使用中，我們可以通過(guò)weaver.Get()來(lái)獲取一個(gè)組件的實(shí)例。比如：

func main() { // 初始化相關(guān)上下文等 root := weaver.Init(context.Background()) // 獲取Reverser組件的實(shí)例 reverser, err := weaver.Get[Reverser](root) if err!= nil { log.Fatal(err) } // 調(diào)用Reverse方法反轉(zhuǎn)字符串 reversed, err := reverser.Reverse(context.Background(), "Hello, Weaver") if err!= nil { // 處理錯(cuò)誤 } fmt.Println(reversed) }

從組件的概念和使用方式可以看出，它和依賴注入中的 IOC 容器有著異曲同工之妙。在依賴注入中，我們也是先定義一個(gè)接口，然后實(shí)現(xiàn)這個(gè)接口，最后從 IOC 容器中獲取這個(gè)接口的實(shí)例，以此來(lái)實(shí)現(xiàn)依賴解耦，簡(jiǎn)化對(duì)象創(chuàng)建流程。在 Service Weaver 框架中，通過(guò)組件的方式，同樣達(dá)到了這樣的效果，讓代碼的結(jié)構(gòu)更加清晰，可維護(hù)性和可擴(kuò)展性更強(qiáng)。

微服務(wù)與新架構(gòu)的對(duì)比：優(yōu)勢(shì)與局限的碰撞

為了更清晰地了解谷歌提出的新架構(gòu)的優(yōu)勢(shì)，我們不妨將它與傳統(tǒng)的微服務(wù)架構(gòu)進(jìn)行一番對(duì)比。在性能、開(kāi)發(fā)運(yùn)維復(fù)雜度、成本等多個(gè)關(guān)鍵維度上，兩者展現(xiàn)出了截然不同的特點(diǎn)。

性能表現(xiàn)：網(wǎng)絡(luò)通信的挑戰(zhàn)與突破

在性能方面，微服務(wù)架構(gòu)存在著一些先天的不足。由于微服務(wù)之間通過(guò)網(wǎng)絡(luò)進(jìn)行通信，序列化數(shù)據(jù)并通過(guò)網(wǎng)絡(luò)發(fā)送數(shù)據(jù)的開(kāi)銷(xiāo)越來(lái)越成為瓶頸。當(dāng)應(yīng)用程序變得足夠復(fù)雜，微服務(wù)數(shù)量眾多時(shí)，這些開(kāi)銷(xiāo)會(huì)顯著增加，導(dǎo)致系統(tǒng)性能下降，延遲升高 。

相比之下，谷歌的模塊化單體架構(gòu)則在性能上展現(xiàn)出了明顯的優(yōu)勢(shì)。由于應(yīng)用程序被構(gòu)建為一個(gè)邏輯整體，減少了服務(wù)間的網(wǎng)絡(luò)通信次數(shù)，從而降低了延遲。根據(jù)谷歌的實(shí)驗(yàn)結(jié)果，基于新架構(gòu)的原型應(yīng)用最多可減少延遲 15 倍 ，這一數(shù)據(jù)充分證明了新架構(gòu)在性能提升上的巨大潛力。

開(kāi)發(fā)運(yùn)維復(fù)雜度：分工與協(xié)作的權(quán)衡

從開(kāi)發(fā)和運(yùn)維的復(fù)雜度來(lái)看，微服務(wù)架構(gòu)雖然將應(yīng)用程序拆分成多個(gè)小型服務(wù)，使得每個(gè)服務(wù)可以獨(dú)立開(kāi)發(fā)、部署和擴(kuò)展，提高了開(kāi)發(fā)的靈活性，但也帶來(lái)了管理上的挑戰(zhàn)。開(kāi)發(fā)人員需要管理多個(gè)服務(wù)的生命周期，協(xié)調(diào)不同服務(wù)之間的接口和依賴關(guān)系，這無(wú)疑增加了開(kāi)發(fā)的難度和成本。同時(shí)，運(yùn)維團(tuán)隊(duì)也需要面對(duì)多個(gè)服務(wù)的部署、監(jiān)控和維護(hù)工作，運(yùn)維復(fù)雜度大幅提升。

而模塊化單體架構(gòu)則在一定程度上簡(jiǎn)化了開(kāi)發(fā)和運(yùn)維的流程。開(kāi)發(fā)人員可以將應(yīng)用程序作為一個(gè)整體進(jìn)行開(kāi)發(fā)和測(cè)試，減少了服務(wù)間協(xié)調(diào)的工作量。在運(yùn)維方面，由于應(yīng)用程序是原子部署的，避免了不同版本之間的交互問(wèn)題，降低了運(yùn)維的風(fēng)險(xiǎn)和難度。此外，自動(dòng)化運(yùn)行時(shí)的引入，使得系統(tǒng)能夠根據(jù)應(yīng)用程序的需求自動(dòng)分配資源，進(jìn)一步提高了運(yùn)維的效率。

成本考量：資源利用與經(jīng)濟(jì)賬的計(jì)算

成本也是衡量架構(gòu)優(yōu)劣的重要因素。在微服務(wù)架構(gòu)中，由于每個(gè)服務(wù)都需要獨(dú)立的資源支持，包括服務(wù)器、內(nèi)存、網(wǎng)絡(luò)帶寬等，隨著服務(wù)數(shù)量的增加，資源的消耗也會(huì)大幅上升，從而導(dǎo)致成本的增加。

谷歌的新架構(gòu)在成本控制上表現(xiàn)出色。通過(guò)將應(yīng)用程序作為一個(gè)邏輯整體進(jìn)行部署，減少了資源的浪費(fèi)，提高了資源的利用率。同時(shí)，由于新架構(gòu)能夠降低系統(tǒng)的延遲，提高性能，使得同樣的硬件資源能夠支持更多的業(yè)務(wù)量，從而間接降低了成本。根據(jù)谷歌的實(shí)驗(yàn)，新架構(gòu)最多可將成本降低 9 倍 ，這對(duì)于企業(yè)來(lái)說(shuō)，無(wú)疑具有巨大的吸引力。

行業(yè)的回響：變革中的思考與展望

谷歌的這一探索，無(wú)疑在行業(yè)內(nèi)引起了巨大的回響。它讓人們開(kāi)始重新審視微服務(wù)架構(gòu)的地位，也為其他企業(yè)在架構(gòu)選擇上提供了新的思路。

其實(shí)，并非只有谷歌一家企業(yè)對(duì)微服務(wù)架構(gòu)產(chǎn)生了質(zhì)疑并做出改變。亞馬遜 Prime Video 團(tuán)隊(duì)就曾發(fā)布案例研究，稱他們決定放棄無(wú)服務(wù)器、微服務(wù)架構(gòu)，改用單體架構(gòu) 。這一舉措為他們節(jié)省了 90% 的運(yùn)營(yíng)成本，并簡(jiǎn)化了系統(tǒng)。亞馬遜 Prime Video 的視頻質(zhì)量分析（VQA）團(tuán)隊(duì)最初使用一組分布式組件來(lái)監(jiān)控視頻流，這些組件由 AWS Step Functions 和 AWS Lambda 編排。但在實(shí)際運(yùn)行中，他們發(fā)現(xiàn)這些組件的擴(kuò)展性存在問(wèn)題，成本也過(guò)高。于是，團(tuán)隊(duì)將所有組件轉(zhuǎn)移到一個(gè)進(jìn)程中，托管在亞馬遜彈性計(jì)算云（Amazon EC2）和亞馬遜彈性容器服務(wù)（Amazon ECS）上，采用單體架構(gòu)，成功降低了成本，提升了系統(tǒng)的伸縮能力。

這些案例表明，在架構(gòu)選擇上，并沒(méi)有一種放之四海而皆準(zhǔn)的方案。企業(yè)需要根據(jù)自身的業(yè)務(wù)特點(diǎn)、發(fā)展階段以及技術(shù)實(shí)力等因素，綜合考慮選擇最適合自己的架構(gòu)。

當(dāng)然，新架構(gòu)的推廣和應(yīng)用也并非一帆風(fēng)順。從開(kāi)發(fā)人員的角度來(lái)看，習(xí)慣了微服務(wù)架構(gòu)的開(kāi)發(fā)模式，要轉(zhuǎn)變觀念接受新的架構(gòu)范式，需要一定的時(shí)間和學(xué)習(xí)成本。而且，新架構(gòu)往往需要新的技術(shù)棧和工具支持，這也對(duì)開(kāi)發(fā)人員的技術(shù)能力提出了更高的要求。

從技術(shù)生態(tài)的角度來(lái)看，目前的軟件開(kāi)發(fā)生態(tài)大多是基于微服務(wù)架構(gòu)構(gòu)建的，新架構(gòu)的出現(xiàn)可能會(huì)面臨與現(xiàn)有技術(shù)生態(tài)不兼容的問(wèn)題。例如，一些針對(duì)微服務(wù)架構(gòu)的監(jiān)控工具、服務(wù)治理框架等，在新架構(gòu)下可能無(wú)法直接使用，需要進(jìn)行相應(yīng)的調(diào)整和適配。

盡管面臨諸多挑戰(zhàn)，但新架構(gòu)的出現(xiàn)無(wú)疑為軟件開(kāi)發(fā)的未來(lái)發(fā)展指明了方向。隨著技術(shù)的不斷進(jìn)步和實(shí)踐的不斷積累，我們有理由相信，新架構(gòu)將逐漸完善，并在未來(lái)的軟件開(kāi)發(fā)中發(fā)揮重要作用。在未來(lái)，或許會(huì)出現(xiàn)更多融合創(chuàng)新的架構(gòu)模式，它們將充分汲取各種架構(gòu)的優(yōu)點(diǎn)，為企業(yè)的數(shù)字化轉(zhuǎn)型提供更強(qiáng)大的技術(shù)支持。