AWS-用于在 AWS 上进行构建的工具

Service Mesh

实践情况

1. POD容器实例10万+，应用数百

特点

多语言支持
应用无感知的升级
流量控制
RPC协议支持
可观测性

性能

CPU 增加8%，均值2%

内存 平均多15M

演示 0.2ms，多5%

Sidecar

只解析请求头，不解析body

优化

SDK优化需要全链路升级

Sicdcar升级可移无感知

问题与挑战

内存优化

报文解析产生大量临时对象 => 通过unsage.pointer直接对报文进行处理，避免产生临时的无用对象

延迟优化

路由缓存：秒级缓存

CPU优化

多个包拼装成一次syscall调用

序列化优化

使用types:Any 替换 types:Struct类型

延时lazy解析

原生Istio=500负载，SOFAMesh=10000万级

运维

SOFA双模微服务

微服务+servicemesh

流量、升降级、。。。

SOFA服务注册中心

        servicemesh控制平面

VM、POD

如何打通两个体系

打通SDK与sidecar

以MCP和xDS/UDPA为基础，融合控制平面和传统注册中心/配置中心

注册中心 -> 通过MCP介入到控制平面（Pilot）

加强SDK -> SDK通过xDS/UDPA介入到控制平面

各种SDK ->  控制中心

sidecar ->  控制中心  <- 各种注册中心

落地

痛点

1. 是否要多语言支持
2. SDK类库升级困难

云原生 通信标准化

Service Mesh

DB Mesh

Msg Mesh

Mesh化是云原生落地关键

Mesh服务于serverless

双模

注册中心 -> MCP通用协议插件 -> 控制平面

SDK call 注册中心 call 控制平面

静态编译

我们内部的 Node 系统大量采用 Serverless 架构，并对启动速度进行了优化，目前平均在4s 左右，正在往进入1秒内优化。但是Java应用就很痛苦，普通 Java 应用的启动时间大约在 30s 到 1min之内。虽然Serverless很美好，但是Java应用却因为启动速度问题，很难用到这个架构红利。我们采用了 JVM 的 SVM 技术将应用进行静态编译，实现了一个正常启动时间在60秒钟左右的应用优化到 4 秒左右，当然这个是在牺牲掉反射等一些动态性换回来的，同时为了能够尽量不让应用改，还改了很多中间件的SDK ，以减少这方面适配对应用带来的影响。当这个黑科技能完美支持1秒以内，整个Java技术生态就可以平滑的迁移过来，应用场景会更加的扩大。但这个需要挺长一个周期，而且也需要社区更多人参与进来，一起做开源类库的反动态性的改造。所以，我们利用我们应用容器的类隔离性来支持多个模块或者同一个模块的不同版本在一个 Java 运行时里跑，互不干扰，并且可以模拟 Serverless 下的快速冷启动和快速扩缩容。

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 wshten@gmail.com