从2023年北京站全球架构师峰会看云原生发展趋势

Serverless、ServiceMesh是2023年全球架构师峰会（北京站）出现频率最高的词，本篇将从这两个方面分享笔者参会了解到的一些信息。

参与此次会这后，我更坚信我们云原生项目所走的方向的正确性，以及预测到未来需要解决的难题。

Serverless（无服务器架构）

Serverless是一种无服务器架构。由于Serverless是从函数计算（FaaS）发展起来的，因此一提到Serverless我们总会先入为主想到函数计算。其实发展到现在，不仅仅是函数计算才能做到Serverless，在线微服务也可以做到Serverless。Serverless能够帮助开发者忘记服务器的存在，做到随着负载自动弹性扩缩容。

来自字节跳动阔鑫讲师分享的《Serverless容灾和多集群扩展实践》，介绍了字节内部自研的基于K8s的云原生Serverless解决方案-ByteFaaS产品的整体架构，并分享在字节内部支撑一些非核心业务落地遇到的在性能、稳定性和扩展性方面的挑战。

ByteFaaS提供多种Serverless计算形态，包含函数计算（FaaS）、在线微服务(FaaS Native)、轻量级运行时（FaaS Worker）。 函数计算：类似aws的lambda产品。

在线微服务：字节内部的HTTP微服务、gRPC微服务。

轻量级运行时：我理解的是一些轻量的计算任务，任务输出的数据存在在边缘节点上，最终通过数据同步方案达到数据的最终一致性。

在性能方面遇到的挑战即是Serverless架构下微服务/函数从0到1的扩容，或是突增流量时快速扩容微服务/函数的冷启动问题。在多语言生态以及在线微服务场景，ByteFaaS的解决方案是：

1. 利用Pod资源池化技术加快冷启动速度。
2. 根据旁路指标提前扩容，例如基于消息队列的消费延迟指标、基于CPU/内存/QPS等指标。
3. 支持用户自定义时间窗口扩容。

这些方案也不是什么创新的方案，各大云厂商早就提供的能力。

解决冷启动性能问题的另一个方向是“去冷启动”：离线服务优化。ByteFaaS控制面包含流量调度、路由管理。在线流量走FaaS Gateway流量调度网关；离线流量走消息队列消费，通过消费离线流量拉起FaaS计算。离线队列消费者和网关依赖路由管理模块将流量调度给正确的函数/微服务实例。 来自微软马腾讲师分享的《基于Serverless+消息队列的跨区域数据准实时同步的方案》，列举了基于Serverless+消息队列、使用ETL工具、自己写代码实现、使用数据库自带的同步能力等几种方案的对比。其中强调了基于Serverless+消息队列的方案体现了Serverless的成本优势，且能达到准实时。这里也再次提到Serverless冷启动的问题，但并没有提供冷启动的解决方案，而是通过至少保持一个函数实例始终运行的方案“去冷启动”（即“热启动”）。

ServiceMesh（服务网格）

与Serverless一样，一谈到ServiceMesh，我们总会想到Istio、Envoy这些ServiceMesh的代表技术。ServiceMesh是处理微服务间通信的基础设施层，翻译为服务网格。其实就是一种网络代理服务。Sidecar是ServiceMesh在K8s下的部署形式。

我们平时说ServiceMesh更多是指ServiceMesh架构，指服务间通信采用ServiceMesh的一种架构。所以只要满足应用不需要依赖实现了跨进程通信的sdk，以及网络代理以Sidecar方式部署，就是符合ServiceMesh架构的。

将服务间的通信实现下沉到ServiceMesh，能够处理异构语言通信问题，以及统一处理复杂调用拓扑下的服务治理问题。应用服务可以仅依赖一个轻量的sdk或是不需要依赖sdk，就能实现跨进程调用。

百度云原生架构师陈谭分享的《Service Mesh在百度大规模落地实践》，大概介绍他们落地的Istio管理东西向流量、Envoy管理南北向流量、xDS配置下发的ServiceMesh实践。

由于当前的Sidecar架构存在延迟高，百度也未在对请求耗时敏感的业务落地，未来展望是探索通过eBPF来解决延迟的问题。

也指出Sidecar存在升级难的痛苦，因为整个升级的过程是需要先停止旧的pod再启动新的pod。百度目前也没有比较好的解决方案。

最后提到ServiceMesh不会是微服务架构演进的终极方向，百度未来也会探索Serverless方向。

来自陌陌的袁世超讲师分享的《云原生微服务架构落地实践》，讲述了陌陌在2016年以后落地ServiceMesh的架构演进历程。

陌陌的Moa架构诞生于国内微服务框架刚刚兴起的时候，dubbo刚刚开源。也是自研实现了moa协议，一种基于pb的二进制协议。基于Redis实现MomoKeeper注册中心，并为历史php项目提供全量服务发现拉取的能力。同时，监控、分布式链路追踪、日志方面也是采用自研。

当技术发展到16年的时候，大数据和其它部门开始需要提供一些能力接口给业务调用，这个时候就存在异构语言之间的通信问题。例如gRPC如何与Moa RPC互相调用问题。

Moa的解决方案是通过引入代理服务解决，但不是网关的形式，而是一种Agent的形式。所以陌陌早期其实已经在走Mesh化了。

另外陌陌也分享了一些与普遍存在的痛点，就是Java SDK升级缓慢问题，推业务升级困难的问题，以及SDK版本碎片化严重的问题。

为了解决这些问题，引入ServiceMesh，将治理逻辑下沉到Sidecar代理。但考虑到技术栈问题，并不是业界主流的Mesh方案，而是通过使用Java开发Agent的Sidecar方式。SDK将只剩下比较轻量的一层协议的封装。

另外笔者也跟陌陌的分享人简单交流了下，主要是关心两个问题：一是mesh化后会提升内存方面的资源消耗，原因主要是java写的Agent很耗内存；二是mesh后的请求时延有所增加问题，只是没要到一份对比数据。因为时延问题，陌陌还有百分之三十的服务没升到mesh。

关于Java耗内存问题，在《AI与数据融合的基础设施技术展望》会议上，来自蚂蚁技术研究院院长，也吐槽了Java计算慢、耗内存的问题，蚂蚁还基于c++重写了原本Java写的Spark的核心RDD。

Mesh化最难的点，就是要求业务服务去改代码配合完成。这需要较多的投入，否则难以实现。陌陌的成功，除了业务部门的支持，另一个因素也与中间件都是自研的有关，能够很好的统一抽象出一个比较轻量的api sdk。

与百度的ServiceMesh对比，百度的ServiceMesh是主流的Mesh方案，存在Sidecar升级不平滑问题，而陌陌是非主流Mesh方案，通过只更新Agent进程而不需要重建容器，绕过了这个问题。

云原生我们当前做什么以及后面做什么

云原生是什么？

云原生是一种基于云的基础之上的软件架构思想。“云”是指私有云、公有云和混合云，“原生”就是指土生土长的意思，是指应用在一开始就是基于云架构设计的。

云原生我们做什么？

云原生和Serverless是我们公司今年主推的项目之一。

首先中间件需要云原生，改中间件本身架构为面向云的架构，或是通过Operator作为交付载体让中间件能够上云。

然后就是提供PaaS（平台工程），在混合云（亚马逊、阿里云、私有云、华为云等）之上提供应用交付平台，屏蔽底层基础设施，实现持续交付，即基础设施代码化，部署代码化。

基础设施代码化，免去一些运维沟通工作，降低开发者部署应用需要了解的运维知识，让开发者只需要关注开发这件事。而部署代码化，将原本文档化、人工部署转变为代码化和自动部署。

在PaaS之上，实现GitOps理念，让IaC、DaC也能实现版本化，支持环境的快速迁移和复制，为业务实现应用的异地多活提供支持。

云原生之后做什么？

云原生之后就是Serverless的实现，面向混合云提供的Serverless底座，为在线微服务实现按需自动扩缩容，实现按需付费，然后不断优化策略。

Serverless之后做什么？

未来，在Serverless之后，我们还要解决SDK版本碎片化严重和推升级困难的问题，也为迎合多语言这个发展趋势，可以去尝试从ServiceMesh这个方向寻找方案。

而在组件下沉到ServiceMesh之后，中间件就可以在异地多活方向为业务提供更多的支持。当然也需要解决ServiceMesh带来的一些问题。