阜阳市建设局网站,短视频seo营销系统,一键建站网站,5千ip的网站能赚多少钱一个新的框架#xff0c;在本地以模块化单体的形式运行#xff0c;一旦部署#xff0c;则为分布式微服务架构 转载请注明来源#xff1a;https://janrs.com/2023/03/%e8%b0%b7%e6%ad%8c%e5%8f%91%e5%b8%83%e7%bc%96%e5%86%99%e5%88%86%e5%b8%83%e5%bc%8f%e5%ba%94%e7%94%a8… 一个新的框架在本地以模块化单体的形式运行一旦部署则为分布式微服务架构 转载请注明来源https://janrs.com/2023/03/%e8%b0%b7%e6%ad%8c%e5%8f%91%e5%b8%83%e7%bc%96%e5%86%99%e5%88%86%e5%b8%83%e5%bc%8f%e5%ba%94%e7%94%a8%e7%9a%84%e6%a1%86%e6%9e%b6service-weaver/ 感觉就像永远总是在什么是更好的之间来来回回单体还是微服务
取决于你问谁以及他们的经验你每次都会得到不同的答案。但在大多数情况下这往往取决于许多因素如公司的规模你需要服务的流量有多大以及提供的产品。
在现实中两种方法都有优点和缺点。但是如果你能拥有两个世界的最好的东西呢这就是谷歌新的开源框架旨在为你提供的东西让我们仔细看看吧
什么是Service Weaver?
Service Weaver是一个框架目前处于早期开发阶段由Google编写。它是开源的这意味着任何人都可以使用和贡献。该框架目前只适用于Go但如果成功的话该方法可以复制到任何语言。
它是一个构建分布式应用的框架其特点是它在本地作为一个模块化的单体运行但一旦部署则作为一个分布式的微服务架构运行。
什么是Modular Monolith?
对于不熟悉的人来说模块化单片机是一种架构整个架构被写成一个单一的应用程序在一个单一的存储库中。模块化意味着单体被分离成独立的组件不同的组件之间有干净和清晰的接口。
这里有一个例子 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KpHRlWQu-1678154099854)(https://janrs.com/wp-content/uploads/2023/03/wervice_weaver.webp “Service Weaver”)]
在这个单体中有三个组件订单、支付和运输。每个组件都实现了单体的一个特定部分关键是每个组件的大部分都是私有的组件之间的任何通信都是通过一个明确定义的接口。
这允许每个组件的内部被改变和更新而不影响任何其他组件前提是接口没有被改变或破坏。
当你有多个团队在一个单体上工作时这确实有助于在团队之间设置明确的界限并使每个组件独立于任何其他组件而发展组件之间显示明确的依赖关系。
无论何时你的单片机被部署它都是作为一个单一的应用程序部署的你的单片机的每个实例都运行一个单一的进程。例如如果你要部署到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构筑微服务
我总是发现图表有助于理解这里是谷歌对不同部分如何结合的解释。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-w1UTh7lk-1678154099854)(https://janrs.com/wp-content/uploads/2023/03/wervice_weaver01.webp “Service Weaver”)]
我们还没有触及的一件事是该框架的多功能性。传统的微服务的一个缺点是你经常会出现非常健谈的界面。毕竟没有人能够看到未来看到一个架构可能随着时间的推移而演变。
然后你要么忍受增加的延迟和更高的网络调用失败机会要么花时间把这两个微服务结合起来。
有了Service Weaver这个问题就得到了解决。如果你看一下上图你会发现有4个模块被定义。当作为微服务部署时你会发现A和B是住在一起的而C和D是它们自己的微服务。
通过Service Weaver你可以自由定义哪些组件被部署在哪里。你可以选择让多个组件在单个微服务中一起运行或者将所有组件部署为独立的微服务。如果你的应用发展到两个组件变得非常健谈并作为独立的微服务运行你可以轻松地将它们结合起来不需要改变代码只需在Service Weaver中快速改变配置。
云部署选项
你可能想知道你可以将Service Weaver应用程序部署到哪里。由于它是由谷歌编写的你可能会认为唯一的部署选择是谷歌的云而且它当然与GCP整合得很好。
然而它确实支持任何云如AWS或Azure。它使用TOML文件来定义配置我一直认为这很容易使用。下面是谷歌的另一张图解释在不同环境下工作的情况。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ca9RZSds-1678154099855)(https://janrs.com/wp-content/uploads/2023/03/wervice_weaver02.webp “Service Weaver”)]
这表明你是如何建立你的应用程序及其组件的然后有一系列如何运行该应用程序的选项。你可以用go run在本地运行它。或者用weaver gke deploy部署到云端。
目前部署似乎是在Kubernetes上但未来是否会有其他的部署选择还有待观察。我认为在引擎盖下他们正在大量利用Kubernetes来实现组件之间的通信。
开始使用Service Weaver
这就是我对Service Weaver的初步介绍如果你很想试试Service Weaver有自己的网站你可以在这里找到。
它包括从框架的架构、安装以及当然从hello world的例子开始的一切。
在我看来这是一个迷人的方法在决定单体和微服务之间的时候它解决了很多问题。它是否能实现这一目标还有待观察但我很高兴看到Service Weaver的发展。 转载请注明来源https://janrs.com/2023/03/%e8%b0%b7%e6%ad%8c%e5%8f%91%e5%b8%83%e7%bc%96%e5%86%99%e5%88%86%e5%b8%83%e5%bc%8f%e5%ba%94%e7%94%a8%e7%9a%84%e6%a1%86%e6%9e%b6service-weaver/
