文章图片
这是Kitex和gRPC性能的对比 ， 我们选了两组 ， 分别是基于Thrift和Protobuf协议的对比 。 可以看到在两种方式下 ， Kitex都有比较好的性能表现 。 特别是在在TP99延迟上 ， 随着并发连接数的增大 ， Kitex表现出的优势是越来越大 。
文章图片
这是Hertz和业界一些框架的对比 ， 包括平均时延、QPS ， 以及在不同Size包的情况下的对比结果 。 这两个框架我们现在都通过开源的方式在对外提供 ， 所以欢迎各位开发者去下载使用 ， 和我们交流 ， 提供意见 。
文章图片
接下来我们看服务网格的治理 。 刚才谈到过因为本身的业务类型、业务体量 ， 所以我们在实践微服务的架构中 ， 面临着非常多挑战 ， 比如语言碎片化、服务异构、协议异构 ， 还有安全、可观测性、问题追查调用等等 。 所以我们采取了基于服务网格模式 ， 来进行整体的微服务治理 。
上图绿色方框是控制面 ， 虚框是数据面 。 我们通过服务网格将控制平面和数据平面进行了分离 ， 消除了单点故障的可能 。 比如当数据平面流量过大出现性能问题时 ， 就不会影响到控制平面的路由策略；反过来也是 ， 当控制平面策略负载过重时也不会影响数据平面的转发 。
图中每个虚框是一个pod ， 与传统的服务相比 ， 我们的服务网格是通过sidecar方式进行流量治理 ， 比如熔断、限流、超时重试、降低等 ， 把这些功能从每个服务中剥离出来形成一个代理 ， 通过这些代理实现服务间的治理 。 这样的好处是能够让每个服务只关注自己的业务逻辑 ， 不需要管全局的调度和通讯问题 ， 让开发更简单、高效 。
文章图片
当然这种ServiceMesh无侵入性的模式带来了很多便利 ， 但是实际上也带来了很多挑战 。 最大一个挑战就是额外的性能开销 ， 所以我们做了大量的工作去解决服务网格的极致性能优化 。 这样的一个优化是多个层次的：
在网络和内核层面 ， 我们用共享内存或者系统调用的方式来实现真正的zero copy 。
也会在基础库、组件架构层面的优化 ， 去除一些不必要的交互 。 甚至在编译阶段 ， 我们通过更好的全静态的编译 ， 不需要任何代码的修改 ， 就能够获得2%左右的性能提升 。
最终通过这种整体的、多层次的组合优化 ， 我们既享受到了服务网格带来的便利 ， 也保证了性能 。
推荐阅读
- 区块|面向2030：影响数据存储产业的十大应用（下）：新兴应用
- 选型|数据架构选型必读：2021上半年数据库产品技术解析
- 殊荣|蝉联殊荣！数梦工场荣获DAMA2021数据治理三项大奖
- 数据|数智安防时代 东芝硬盘助力智慧安防新赛道
- OriginOS|当硬件驱动力逐渐放缓，手机还能更快吗？
- 技术|悦鲜活高端瓶装鲜奶市占第一 科技驱动营养再升级
- 平台|数梦工场助力北京市中小企业公共服务平台用数据驱动业务创新
- 数据|中标 | 数梦工场以数字新动能助力科技优鄂
- 建设|数据赋能业务，数梦工场助力湖北省智慧应急“十四五”开局
- 市民|大数据、人工智能带来城市新变化 科技赋能深化文明成效