微服务发展的另一个形态? 来看看Google的新框架Service Weaver怎么解决微服务的顽疾

677 阅读3分钟

前些天在Hacker News周报(up主:Koala聊开源)上看到了个Google开源的Golang新框架---Service Weaver.(Service Weaver)

它是旨在解决微服务开发迭代过程中的一系列让人头疼又费精力的问题, 让开发人员能在开发微服务应用的时候, 享受像开发单体应用一样的体验. 初一看这不是退化么, 但是看完官方博客后, 顿时对这个框架感兴趣了.

下面是我个人看完官方介绍博客后总结的几个点, 相信你和我一样看完后也会对这个微服务的下一个形态感兴趣的.

在Weaver的博客中A Quick Introduction to Service Weaver, Weaver对目前微服务开发中遇到的一些问题提出了自己的改进方案

  1. 微服务开发更新版本时, 经常因为各个微服务的版本不同而导致的更新失败,而且测试还需要测试不同微服务的不同版本之间的各种组合

Weaver: 代码都属于同一个项目, 所以不同的Component都是在同一个版本的管理下, 天然解决了需要考虑不同版本的组合和测试问题

  1. 微服务不好拆分, 应怎么拆是很让人头痛的问题, 因为可能分的太细太多了或者要考虑到方便后续扩展

Weaver: 把微服务抽象为Component, 更加接近传统的软件开发思想(模块化, 封装, 高内聚低耦合), 减少精神内耗

  1. 微服务开发测试需要复杂的环境,比如安装各种工具甚至还需要云原生的运行环境, 复现bug前, 光是让项目运行起来就很花费精力

Weaver: 用Weaver写的项目可以直接用go run .像单体应用一样运行, 快速定位代码的bug(而不是云环境的bug), 当然也可以像微服务一样把不同Component部署在不同机器上运行, 或者同个机器的多个不同进程上运行, 可以用go test 来直接跑单元测试. 官方还提供了weavertest包,让你写端到端(end to end)的测试用例时像写单元测试一样简单。

components.svg

  1. 由于网络和rpc协议的原因, 导致调用运行速度缓慢

Weaver: 实现了一套自己的负载均衡, 资源自动缩放, 序列化和RPC协议, 避免了解决版本问题所需的开销. 下面是官方博客中, Weaver对比传统微服务应用的性能和开销比较结果:

We found out that Service Weaver improves application latency by 15x and reduces VM costs by 9x when compared to a typical microservices solution built on top of gRPC and protocol buffers.

  1. 不同微服务可能有不同的各自独立的CI/CD管线, 也会有各自不同的部署配置项文件, 加大了持续集成交付流程建设的难度。

Weaver: 框架内集成了云服务部署的功能, 只需要几行的配置项就能实现原来需要几十行配置项才能云服务部署的效果, 而且因为Component都在同一个项目所以只需一套CI/CD, 而且配置文件用同一个.

  1. 微服务开发中需要考量如何对接云服务的API/监控/指标等等, 不同云服务商这些方面又有差异

Weaver: 同上, Weaver还提供用于日志记录、指标和跟踪的库。会自动集成到部署应用程序的环境中。如果我们在 Google Cloud 上部署应用程序,日志会自动导出到 Google Cloud Logging,指标会自动导出到 Google Cloud Monitoring,跟踪会上传到 Google Cloud Tracing。

欢迎同样对这个新框架感兴趣的人和我私信, 一起探讨Golang技术呀~