一种新的框架，在本地单体应用上运行模块化程序，在部署后变为分布式微服务架构。
单体应用和微服务哪种更好的争论一直是一个讨论热度居高不下的问题。
根据不同的人和经验，每次都会得到不同的答案。在大多数情况下，它往往取决于诸多因素，例如公司的规模，服务的流量以及所提供的产品。
实际上，两种方法都有其优缺点。但是，如果你能同时拥有岂不两全其美，这就是Google的新开源框架旨在为你提供的，让我们来仔细看看！
什么是Service Weaver？
Service Weaver 由Google编写的一个框架，目前处于早期开发阶段。它是开源的，这意味着任何人都可以使用和贡献。该框架目前仅支持Go语言，但如果成功，该方法可以复制到任何语言中。
它是用于构建分布式应用程序的框架，其独特之处在于它在本地作为模块化单体应用运行，但一旦部署，就会以分布式微服务架构运行。
什么是模块化单体应用？
对于不熟悉的人来说，模块化单体应用是一种体系结构，其中整个应用程序都写成一个单独的应用程序，在一个单一的代码库中。模块化方面意味着单体应用被分成单独的组件，并且在不同组件之间有干净明确的接口。
这里是一个例子：
在这个单体应用中，有三个组件：订单、支付和运输。每个组件实现单体应用的一个特定部分，关键在于每个组件的大部分都是私有的，并且组件之间的任何通信都是通过明确定义的接口进行的。
这使得每个组件的内部可以进行更改和更新，而不会影响任何其他组件，假设接口未更改或破坏。
当多个团队在单体应用上工作时，这确实有助于在团队之间设定明确的边界，并使每个组件独立于其他任何组件发展，同时在组件之间显示明确的依赖关系。
每当你的单体应用被部署时，它都被部署为一个单一的应用程序，每个单体应用的实例都运行一个单一的进程。例如，如果你要部署到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 框架的多功能性。传统微服务的一个缺点是，你经常会遇到接口过于频繁的问题。毕竟，没有人能预见架构的演变方向。
然后，你不得不忍受增加的延迟和更高的网络调用失败率，或者花时间将这两个微服务合并起来。
使用 Service Weaver，这个问题得到了解决。如果你查看上面的图表，你会发现有四个模块被定义了。当部署为微服务时，你会注意到 A 和 B 住在一起，C 和 D 是他们自己的微服务。
使用 Service Weaver，你可以自由地定义组件在哪里部署。你可以选择让多个组件一起运行在单个微服务中，或者将所有组件都部署为单独的微服务。如果你的应用程序演变到两个组件变得过于频繁，并且作为单独的微服务运行，你可以轻松地将它们合并，而不需要改变代码，并在 Service Weaver 中快速更改配置。
云部署选项
你可能会想知道在哪里可以部署Service Weaver应用程序。由于它是由Google编写的，你可能期望唯一的部署选项是Google Cloud，它确实与GCP集成良好。
然而，它支持任何云环境，例如AWS或Azure。它使用TOML文件来定义配置，我一直觉得很容易使用。这里有另一张来自Google的图表，解释了不同环境下的工作方式：
这个展示了如何构建你的应用程序和其组件，然后有一系列选项来运行该应用程序。你可以使用 go run . 在本地运行它，或使用 weaver gke deploy 部署到云中。
目前，部署似乎是针对 Kubernetes 的，但未来是否会出现其他部署选项尚不清楚。我会认为在幕后，他们会大量利用 Kubernetes，以实现组件之间的通信。
开始使用Service Weaver
这就是我对Service Weaver的初步介绍，如果你想要尝试一下，Service Weaver有自己的网站，你可以在这里找到它。
网站包括了框架的架构、安装过程，当然也有hello world例子的快速入门教程。
从我的角度来看，这是一个非常有趣的方法，解决了在单体架构和微服务之间做决策时遇到的许多问题。它是否能够达到这个目标，还有待观察，但我很期待看到Service Weaver的发展！
文章来源：Service Weaver: A Framework From Google For Balancing Monoliths and Microservices
