一種新的架構，在本地單體應用上運作子產品化程式，在部署後變為分布式微服務架構。
單體應用和微服務哪種更好的争論一直是一個讨論熱度居高不下的問題。
根據不同的人和經驗，每次都會得到不同的答案。在大多數情況下，它往往取決于諸多因素，例如公司的規模，服務的流量以及所提供的産品。
實際上，兩種方法都有其優缺點。但是，如果你能同時擁有豈不兩全其美，這就是Google的新開源架構旨在為你提供的，讓我們來仔細看看！
什麼是Service Weaver？
Service Weaver 由Google編寫的一個架構，目前處于早期開發階段。它是開源的，這意味着任何人都可以使用和貢獻。該架構目前僅支援Go語言，但如果成功，該方法可以複制到任何語言中。
它是用于建構分布式應用程式的架構，其獨特之處在于它在本地作為子產品化單體應用運作，但一旦部署，就會以分布式微服務架構運作。
什麼是子產品化單體應用？
對于不熟悉的人來說，子產品化單體應用是一種體系結構，其中整個應用程式都寫成一個單獨的應用程式，在一個單一的代碼庫中。子產品化方面意味着單體應用被分成單獨的元件，并且在不同元件之間有幹淨明确的接口。
這裡是一個例子：
這是一個子產品化單體應用的示例，使用Mermaid建立。
在這個單體應用中，有三個元件：訂單、支付和運輸。每個元件實作單體應用的一個特定部分，關鍵在于每個元件的大部分都是私有的，并且元件之間的任何通信都是通過明确定義的接口進行的。
這使得每個元件的内部可以進行更改和更新，而不會影響任何其他元件，假設接口未更改或破壞。
當多個團隊在單體應用上工作時，這确實有助于在團隊之間設定明确的邊界，并使每個元件獨立于其他任何元件發展，同時在元件之間顯示明确的依賴關系。
每當你的單體應用被部署時，它都被部署為一個單一的應用程式，每個單體應用的執行個體都運作一個單一的程序。例如，如果你要部署到AWS，每個單體應用的執行個體都将作為一個程序運作在EC2執行個體上。
Service Weaver與典型的子產品化單體應用有哪些不同？
現在我們了解了什麼是子產品化單體應用，接下來我們可以看看Service Weaver與建構标準子產品化單體應用的架構有何不同。
在開發應用程式時，它實際上看起來與上面的示例相同。使用Service Weaver建構應用程式時，您需要在單個代碼庫中建構元件。如上所述，每個元件定義了一個清晰的接口，以便在不同的元件之間進行通信。
Service Weaver和傳統的子產品化單體應用之間的差別在于部署方式。使用Service Weaver建構的應用程式在部署時，不是将所有元件運作在同一台機器上的一個大程序。
相反，每個元件都作為一個獨立的微服務進行部署。這非常巧妙，因為您既可以獲得将所有代碼放在單個代碼庫中并進行友善的本地開發的好處，又可以獲得運作分布式架構的好處，其中您可以根據需要縮放每個元件，例如記憶體，CPU和執行個體數量等。
很聰明，對吧？讓我們看看Service Weaver是如何實作這一點的！
Service Weaver是如何工作的？
正如前面提到的，Service Weaver目前完全使用Go編寫。在建構應用程式時，每個元件都必須被定義為接口。可以将其視為定義給定元件的公共API，列出其他元件可以使用的方法。例如，一個反轉字元串的元件可能如下所示：
type Reverser interface {
Reverse(context.Context, string) (string, error)
}
其他需要對字元串進行反轉的元件可以調用這個反轉器元件，反轉字元串的内部實作被封裝在反轉器元件中。
然後，您可以按照通常的方式建構您的元件，通過需要時進行方法調用。您可以完全在本地建構和測試它，而Service Weaver會處理元件之間的互動，将它們視為本地方法調用。
到目前為止，與任何其他架構或單體應用程式沒有差別。
但是，一旦部署并作為單獨的微服務運作，元件之間的調用就不再可以在本地進行。相反，Service Weaver将在元件之間進行遠端過程調用RPC。
不過，不需要過于深入了解，Service Weaver使用Protocol Buffers對傳遞的資料進行序列化和反序列化。您不需要擔心這些細節，因為所有這些都發生在幕後。您不需要擔心在微服務之間進行網絡調用，或者調用是否在本地或遠端進行。
就您的代碼而言，您可以按照自己的方式編寫代碼，架構會為您處理是在本地還是在遠端進行調用。在上面的反轉器示例中，您的代碼隻需調用反轉器的Reverse方法，而您的代碼無需關心該調用是在本地還是在遠端進行。
使用 Service Weaver 組合微服務
我發現圖表有助于了解的一個例子，這是Google解釋了這些不同部分如何組合在一起的圖表：
Service Weaver 的架構。圖檔來源：Google。
我們還沒有談到 Service Weaver 架構的多功能性。傳統微服務的一個缺點是，你經常會遇到接口過于頻繁的問題。畢竟，沒有人能預見架構的演變方向。
然後，你不得不忍受增加的延遲和更高的網絡調用失敗率，或者花時間将這兩個微服務合并起來。
使用 Service Weaver，這個問題得到了解決。如果你檢視上面的圖表，你會發現有四個子產品被定義了。當部署為微服務時，你會注意到 A 和 B 住在一起，C 和 D 是他們自己的微服務。
使用 Service Weaver，你可以自由地定義元件在哪裡部署。你可以選擇讓多個元件一起運作在單個微服務中，或者将所有元件都部署為單獨的微服務。如果你的應用程式演變到兩個元件變得過于頻繁，并且作為單獨的微服務運作，你可以輕松地将它們合并，而不需要改變代碼，并在 Service Weaver 中快速更改配置。
雲部署選項
你可能會想知道在哪裡可以部署Service Weaver應用程式。由于它是由Google編寫的，你可能期望唯一的部署選項是Google Cloud，它确實與GCP內建良好。
然而，它支援任何雲環境，例如AWS或Azure。它使用TOML檔案來定義配置，我一直覺得很容易使用。這裡有另一張來自Google的圖表，解釋了不同環境下的工作方式：
Service Weaver 部署。圖檔來源：Google Service Weaver 部署。圖檔來源：Google
這個展示了如何建構你的應用程式和其元件，然後有一系列選項來運作該應用程式。你可以使用 go run . 在本地運作它，或使用 weaver gke deploy 部署到雲中。
目前，部署似乎是針對 Kubernetes 的，但未來是否會出現其他部署選項尚不清楚。我會認為在幕後，他們會大量利用 Kubernetes，以實作元件之間的通信。
開始使用Service Weaver
這就是我對Service Weaver的初步介紹，如果你想要嘗試一下，Service Weaver有自己的網站，你可以在這裡找到它。
網站包括了架構的架構、安裝過程，當然也有hello world例子的快速入門教程。
從我的角度來看，這是一個非常有趣的方法，解決了在單體架構和微服務之間做決策時遇到的許多問題。它是否能夠達到這個目标，還有待觀察，但我很期待看到Service Weaver的發展！