一个新的框架，在本地以模块化单体的形式运行，一旦部署，则为分布式微服务架构
转载请注明来源：janrs.com/dl08

感觉就像永远，总是在什么是更好的之间来来回回：单体还是微服务？

取决于你问谁，以及他们的经验，你每次都会得到不同的答案。但在大多数情况下，这往往取决于许多因素，如公司的规模，你需要服务的流量有多大，以及提供的产品。

在现实中，两种方法都有优点和缺点。但是，如果你能拥有两个世界的最好的东西呢？这就是谷歌新的开源框架旨在为你提供的东西，让我们仔细看看吧

什么是Service Weaver?

Service Weaver是一个框架，目前处于早期开发阶段，由Google编写。它是开源的，这意味着任何人都可以使用和贡献。该框架目前只适用于Go，但如果成功的话，该方法可以复制到任何语言。

它是一个构建分布式应用的框架，其特点是它在本地作为一个模块化的单体运行，但一旦部署，则作为一个分布式的微服务架构运行。

什么是Modular Monolith?

对于不熟悉的人来说，模块化单片机是一种架构，整个架构被写成一个单一的应用程序，在一个单一的存储库中。模块化意味着单体被分离成独立的组件，不同的组件之间有干净和清晰的接口。

这里有一个例子：

在这个单体中，有三个组件：订单、支付和运输。每个组件都实现了单体的一个特定部分，关键是每个组件的大部分都是私有的，组件之间的任何通信都是通过一个明确定义的接口。

这允许每个组件的内部被改变和更新而不影响任何其他组件，前提是接口没有被改变或破坏。

当你有多个团队在一个单体上工作时，这确实有助于在团队之间设置明确的界限，并使每个组件独立于任何其他组件而发展，组件之间显示明确的依赖关系。

无论何时你的单片机被部署，它都是作为一个单一的应用程序部署的，你的单片机的每个实例都运行一个单一的进程。例如，如果你要部署到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)
}

#

任何其他想要反转字符串的组件都可以调用这个Reverser组件，而字符串如何被反转的内部信息是私有的，包含在Reverser组件中。

然后，你可以像通常那样，通过在需要时在组件之间进行方法调用来构建你的组件。你可以完全在本地进行构建和测试，Service Weaver会处理组件之间的交互，将它们视为本地方法调用。

到目前为止，与其他框架或单体没有任何变化。

然而，一旦部署并作为独立的微服务运行，组件之间的调用就不能再本地进行。相反，Service Weaver会在组件之间进行远程程序调用（RPC）。

在不深入了解的情况下，它使用协议缓冲区来序列化和反序列化组件之间传递的数据。不过你不需要担心这个问题，因为所有这些都发生在幕后。你不需要担心在微服务之间进行网络调用，也不需要担心调用是发生在本地还是远程。

就你的代码而言，你按照你的习惯来写，框架将为你处理是在本地还是远程进行调用。在上面的Reverser例子中，你的代码只是调用Reverse，你的代码不需要关心这个调用是在本地还是远程进行的。

用Service Weaver构筑微服务

我总是发现图表有助于理解，这里是谷歌对不同部分如何结合的解释。

我们还没有触及的一件事是该框架的多功能性。传统的微服务的一个缺点是，你经常会出现非常健谈的界面。毕竟，没有人能够看到未来，看到一个架构可能随着时间的推移而演变。

然后，你要么忍受增加的延迟和更高的网络调用失败机会，要么花时间把这两个微服务结合起来。

有了Service Weaver，这个问题就得到了解决。如果你看一下上图，你会发现有4个模块被定义。当作为微服务部署时，你会发现A和B是住在一起的，而C和D是它们自己的微服务。

通过Service Weaver，你可以自由定义哪些组件被部署在哪里。你可以选择让多个组件在单个微服务中一起运行，或者将所有组件部署为独立的微服务。如果你的应用发展到两个组件变得非常健谈，并作为独立的微服务运行，你可以轻松地将它们结合起来，不需要改变代码，只需在Service Weaver中快速改变配置。

云部署选项

你可能想知道你可以将Service Weaver应用程序部署到哪里。由于它是由谷歌编写的，你可能会认为唯一的部署选择是谷歌的云，而且它当然与GCP整合得很好。

然而，它确实支持任何云，如AWS或Azure。它使用TOML文件来定义配置，我一直认为这很容易使用。下面是谷歌的另一张图，解释在不同环境下工作的情况。

这表明你是如何建立你的应用程序及其组件的，然后有一系列如何运行该应用程序的选项。你可以用go run在本地运行它。，或者用weaver gke deploy部署到云端。

目前，部署似乎是在Kubernetes上，但未来是否会有其他的部署选择，还有待观察。我认为在引擎盖下，他们正在大量利用Kubernetes来实现组件之间的通信。

开始使用Service Weaver

这就是我对Service Weaver的初步介绍，如果你很想试试，Service Weaver有自己的网站，你可以在这里找到。

它包括从框架的架构、安装，以及当然，从hello world的例子开始的一切。

在我看来，这是一个迷人的方法，在决定单体和微服务之间的时候，它解决了很多问题。它是否能实现这一目标还有待观察，但我很高兴看到Service Weaver的发展。

转载请注明来源：janrs.com/dl08

本作品采用《CC 协议》，转载必须注明作者和本文链接