一種新的框架，在本地單體應(yīng)用上運(yùn)行模塊化程序漱牵，在部署后變?yōu)榉植际轿⒎?wù)架構(gòu)夺蛇。
單體應(yīng)用和微服務(wù)哪種更好的爭(zhēng)論一直是一個(gè)討論熱度居高不下的問(wèn)題。
根據(jù)不同的人和經(jīng)驗(yàn)酣胀，每次都會(huì)得到不同的答案刁赦。在大多數(shù)情況下娶聘，它往往取決于諸多因素，例如公司的規(guī)模甚脉，服務(wù)的流量以及所提供的產(chǎn)品丸升。
實(shí)際上，兩種方法都有其優(yōu)缺點(diǎn)宦焦。但是发钝，如果你能同時(shí)擁有豈不兩全其美顿涣，這就是Google的新開(kāi)源框架旨在為你提供的波闹，讓我們來(lái)仔細(xì)看看！
什么是Service Weaver涛碑？
Service Weaver 由Google編寫(xiě)的一個(gè)框架精堕，目前處于早期開(kāi)發(fā)階段。它是開(kāi)源的蒲障，這意味著任何人都可以使用和貢獻(xiàn)歹篓。該框架目前僅支持Go語(yǔ)言，但如果成功揉阎，該方法可以復(fù)制到任何語(yǔ)言中庄撮。
它是用于構(gòu)建分布式應(yīng)用程序的框架，其獨(dú)特之處在于它在本地作為模塊化單體應(yīng)用運(yùn)行毙籽，但一旦部署洞斯，就會(huì)以分布式微服務(wù)架構(gòu)運(yùn)行。
什么是模塊化單體應(yīng)用坑赡？
對(duì)于不熟悉的人來(lái)說(shuō)烙如，模塊化單體應(yīng)用是一種體系結(jié)構(gòu)，其中整個(gè)應(yīng)用程序都寫(xiě)成一個(gè)單獨(dú)的應(yīng)用程序毅否，在一個(gè)單一的代碼庫(kù)中亚铁。模塊化方面意味著單體應(yīng)用被分成單獨(dú)的組件，并且在不同組件之間有干凈明確的接口螟加。
這里是一個(gè)例子：
在這個(gè)單體應(yīng)用中捆探，有三個(gè)組件：訂單然爆、支付和運(yùn)輸。每個(gè)組件實(shí)現(xiàn)單體應(yīng)用的一個(gè)特定部分徐许，關(guān)鍵在于每個(gè)組件的大部分都是私有的施蜜，并且組件之間的任何通信都是通過(guò)明確定義的接口進(jìn)行的。
這使得每個(gè)組件的內(nèi)部可以進(jìn)行更改和更新雌隅，而不會(huì)影響任何其他組件翻默，假設(shè)接口未更改或破壞缸沃。
當(dāng)多個(gè)團(tuán)隊(duì)在單體應(yīng)用上工作時(shí)，這確實(shí)有助于在團(tuán)隊(duì)之間設(shè)定明確的邊界修械，并使每個(gè)組件獨(dú)立于其他任何組件發(fā)展趾牧，同時(shí)在組件之間顯示明確的依賴關(guān)系。
每當(dāng)你的單體應(yīng)用被部署時(shí)肯污，它都被部署為一個(gè)單一的應(yīng)用程序翘单，每個(gè)單體應(yīng)用的實(shí)例都運(yùn)行一個(gè)單一的進(jìn)程。例如蹦渣，如果你要部署到AWS哄芜，每個(gè)單體應(yīng)用的實(shí)例都將作為一個(gè)進(jìn)程運(yùn)行在EC2實(shí)例上。
Service Weaver與典型的模塊化單體應(yīng)用有哪些不同柬唯？
現(xiàn)在我們了解了什么是模塊化單體應(yīng)用认臊，接下來(lái)我們可以看看Service Weaver與構(gòu)建標(biāo)準(zhǔn)模塊化單體應(yīng)用的框架有何不同。
在開(kāi)發(fā)應(yīng)用程序時(shí)锄奢，它實(shí)際上看起來(lái)與上面的示例相同失晴。使用Service Weaver構(gòu)建應(yīng)用程序時(shí)，您需要在單個(gè)代碼庫(kù)中構(gòu)建組件拘央。如上所述涂屁，每個(gè)組件定義了一個(gè)清晰的接口，以便在不同的組件之間進(jìn)行通信灰伟。
Service Weaver和傳統(tǒng)的模塊化單體應(yīng)用之間的區(qū)別在于部署方式拆又。使用Service Weaver構(gòu)建的應(yīng)用程序在部署時(shí)，不是將所有組件運(yùn)行在同一臺(tái)機(jī)器上的一個(gè)大進(jìn)程袱箱。
相反遏乔，每個(gè)組件都作為一個(gè)獨(dú)立的微服務(wù)進(jìn)行部署。這非常巧妙发笔，因?yàn)槟瓤梢垣@得將所有代碼放在單個(gè)代碼庫(kù)中并進(jìn)行方便的本地開(kāi)發(fā)的好處盟萨，又可以獲得運(yùn)行分布式架構(gòu)的好處，其中您可以根據(jù)需要縮放每個(gè)組件了讨，例如內(nèi)存捻激，CPU和實(shí)例數(shù)量等。
很聰明前计，對(duì)吧胞谭？讓我們看看Service Weaver是如何實(shí)現(xiàn)這一點(diǎn)的！
Service Weaver是如何工作的男杈？
正如前面提到的丈屹，Service Weaver目前完全使用Go編寫(xiě)。在構(gòu)建應(yīng)用程序時(shí)，每個(gè)組件都必須被定義為接口旺垒〔士猓可以將其視為定義給定組件的公共API，列出其他組件可以使用的方法先蒋。例如骇钦，一個(gè)反轉(zhuǎn)字符串的組件可能如下所示：
type Reverser interface {
Reverse(context.Context, string) (string, error)
}
其他需要對(duì)字符串進(jìn)行反轉(zhuǎn)的組件可以調(diào)用這個(gè)反轉(zhuǎn)器組件，反轉(zhuǎn)字符串的內(nèi)部實(shí)現(xiàn)被封裝在反轉(zhuǎn)器組件中竞漾。
然后眯搭，您可以按照通常的方式構(gòu)建您的組件，通過(guò)需要時(shí)進(jìn)行方法調(diào)用业岁。您可以完全在本地構(gòu)建和測(cè)試它鳞仙，而Service Weaver會(huì)處理組件之間的交互，將它們視為本地方法調(diào)用叨襟。
到目前為止繁扎，與任何其他框架或單體應(yīng)用程序沒(méi)有區(qū)別幔荒。
但是糊闽，一旦部署并作為單獨(dú)的微服務(wù)運(yùn)行，組件之間的調(diào)用就不再可以在本地進(jìn)行爹梁。相反右犹，Service Weaver將在組件之間進(jìn)行遠(yuǎn)程過(guò)程調(diào)用RPC。
不過(guò)姚垃，不需要過(guò)于深入了解念链，Service Weaver使用Protocol Buffers對(duì)傳遞的數(shù)據(jù)進(jìn)行序列化和反序列化。您不需要擔(dān)心這些細(xì)節(jié)积糯，因?yàn)樗羞@些都發(fā)生在幕后掂墓。您不需要擔(dān)心在微服務(wù)之間進(jìn)行網(wǎng)絡(luò)調(diào)用，或者調(diào)用是否在本地或遠(yuǎn)程進(jìn)行看成。
就您的代碼而言君编，您可以按照自己的方式編寫(xiě)代碼，框架會(huì)為您處理是在本地還是在遠(yuǎn)程進(jìn)行調(diào)用川慌。在上面的反轉(zhuǎn)器示例中吃嘿，您的代碼只需調(diào)用反轉(zhuǎn)器的Reverse方法，而您的代碼無(wú)需關(guān)心該調(diào)用是在本地還是在遠(yuǎn)程進(jìn)行梦重。
使用 Service Weaver 組合微服務(wù)
我發(fā)現(xiàn)圖表有助于理解的一個(gè)例子兑燥，這是Google解釋了這些不同部分如何組合在一起的圖表：
我們還沒(méi)有談到 Service Weaver 框架的多功能性降瞳。傳統(tǒng)微服務(wù)的一個(gè)缺點(diǎn)是，你經(jīng)常會(huì)遇到接口過(guò)于頻繁的問(wèn)題蚓胸。畢竟挣饥，沒(méi)有人能預(yù)見(jiàn)架構(gòu)的演變方向斗塘。
然后，你不得不忍受增加的延遲和更高的網(wǎng)絡(luò)調(diào)用失敗率亮靴，或者花時(shí)間將這兩個(gè)微服務(wù)合并起來(lái)馍盟。
使用 Service Weaver，這個(gè)問(wèn)題得到了解決茧吊。如果你查看上面的圖表贞岭，你會(huì)發(fā)現(xiàn)有四個(gè)模塊被定義了。當(dāng)部署為微服務(wù)時(shí)搓侄，你會(huì)注意到 A 和 B 住在一起瞄桨，C 和 D 是他們自己的微服務(wù)。
使用 Service Weaver讶踪，你可以自由地定義組件在哪里部署芯侥。你可以選擇讓多個(gè)組件一起運(yùn)行在單個(gè)微服務(wù)中，或者將所有組件都部署為單獨(dú)的微服務(wù)乳讥。如果你的應(yīng)用程序演變到兩個(gè)組件變得過(guò)于頻繁柱查，并且作為單獨(dú)的微服務(wù)運(yùn)行，你可以輕松地將它們合并云石，而不需要改變代碼唉工，并在 Service Weaver 中快速更改配置。
云部署選項(xiàng)
你可能會(huì)想知道在哪里可以部署Service Weaver應(yīng)用程序汹忠。由于它是由Google編寫(xiě)的淋硝，你可能期望唯一的部署選項(xiàng)是Google Cloud，它確實(shí)與GCP集成良好宽菜。
然而谣膳，它支持任何云環(huán)境，例如AWS或Azure铅乡。它使用TOML文件來(lái)定義配置继谚，我一直覺(jué)得很容易使用。這里有另一張來(lái)自Google的圖表隆判，解釋了不同環(huán)境下的工作方式：
這個(gè)展示了如何構(gòu)建你的應(yīng)用程序和其組件，然后有一系列選項(xiàng)來(lái)運(yùn)行該應(yīng)用程序侨嘀。你可以使用 go run . 在本地運(yùn)行它臭挽，或使用 weaver gke deploy 部署到云中。
目前咬腕，部署似乎是針對(duì) Kubernetes 的欢峰，但未來(lái)是否會(huì)出現(xiàn)其他部署選項(xiàng)尚不清楚。我會(huì)認(rèn)為在幕后，他們會(huì)大量利用 Kubernetes纽帖，以實(shí)現(xiàn)組件之間的通信宠漩。
開(kāi)始使用Service Weaver
這就是我對(duì)Service Weaver的初步介紹，如果你想要嘗試一下懊直，Service Weaver有自己的網(wǎng)站扒吁，你可以在這里找到它。
網(wǎng)站包括了框架的架構(gòu)室囊、安裝過(guò)程雕崩，當(dāng)然也有hello world例子的快速入門(mén)教程。
從我的角度來(lái)看融撞，這是一個(gè)非常有趣的方法盼铁，解決了在單體架構(gòu)和微服務(wù)之間做決策時(shí)遇到的許多問(wèn)題。它是否能夠達(dá)到這個(gè)目標(biāo)尝偎，還有待觀察，但我很期待看到Service Weaver的發(fā)展肤寝！
文章來(lái)源：Service Weaver: A Framework From Google For Balancing Monoliths and Microservices
