多场景推进 服务网格在联通的落地实践(下)
随着以容器为核心的新一代应用承接平台的崛起,微服务正焕发出新的生命力。
经过长期的技术研究开发与应用实践,联通软研院最终确定了以服务网格(Service Mesh)为微服务的演进方向。上一期我们了解了联通服务网格的发展历程及应用变迁,本期我们将从未来规划的层面,更加深入地剖析服务网格的发展潜力。
推进微服务,未来服务网格产品的规划
如今,服务网格产品已经具备了流量治理、安全、可观测性、实例管理四个方面的能力。未来服务网格产品化也将继续紧跟 Istio 社区动态,持续迭代微服务相关能力,适配业务微服务场景,让服务网格能够更多业务场景落地。面向未来,联通将落地几个初步构想。
服务网格性能优化—单跳方案
由于服务网格技术中边车 Sidecar 用于业务的流量,其带来的延迟,一直是业务特别关心的,也是服务网格未来能否被被业务方所接受的关键因素。
目前社区的方案为业务所有的进(Inbound)和出(Outbound)流量都会被边车 Sidecar 拦截,该方式称为双跳方案。社区双跳方案往往性能差,无法在超大规模环境下落地。
通过分析发现在流量拦截机制中 Inbound 流量非必要,因此可以考虑将减少 Sidecar 非必要 Inbound 流量拦截,该方式称为单跳方案。该方案对比双跳方案,能够显著减少 Sidecar 带来的时延。
服务网格性能优化—eBPF 方案
通过引入内核 BPF 中 socketmap 和 redirect 机制(提供了一种特殊的 map 类型即 socketmap,可以来做 socket redirection),绕开 TCP/IP 协议栈,降低边车 Sidecar 层面带来的时延。
扩展性优化—Fallback 机制
服务网格中典型的代理模式是通过 Sidecar 来进行请求拦截处理,实现微服务的能力。而在实际的实践中,业务往往对增加的 Sidecar 的稳定性有很高的要求,尽管可以尽可能保障 Sidecar 的稳定,但仍无法打消业务的顾虑。
因此提供直连模式,能够保障业务能够在极端故障情况下,实现请求不经过 Sidecar 拦截处理,而是交由业务来处理流量,即使 Sidecar 存在的情况下。
Fallback 机制能够有效保障业务的可靠性,能够实现代理模式和直连模式自由切换。
扩展性优化—按需下发
通过分析社区『全量下发』的方案,发现在规模化的场景中,往往会出现瓶颈问题。主要体现在 XDS 的全量推送和频繁低效变更。
因此设计『按需下发』的方案,即下发的 XDS 数据一定是 Sidecar 所需要的,避免非必要的冗余数据和无效变更,提升服务网格的整体性能,满足规模化落地场景的需要。这里的『按需下发』主要是要收集微服务调用的依赖关系,会通过手动和程序自动收集的方式来收集。
治理能力优化—国产化
考虑到的业务会运行在各类国产化环境中,因此也会将服务网格整个技术体系兼容不同的国产化环境。在芯片层面需要兼容 X86、ARM 和 PPC,在操作系统上需要兼容统信 UOS 和麒麟。
服务网格带来的价值收益
无论是业内还是落地服务网格的感受,都能体会到基于云原生服务网格给业务带来的收益价值,那么,服务网格能带来什么样的价值收益?
微服务技术栈统一
通过服务网格『技术设施下沉』 的思路,实现了现有的 RPC 框架和星舟框架技术栈统一。一方面能够节省不同微服务框架的运维人力,另一方面能够实现微服务功能的统一。
目前基于 RPC 框架和星舟框架的业务应用,可以实现『零改造业务代码』达到迁移到服务网格的目的。
技术架构云原生化
基于 K8s 和 Istio 构建的微服务架构,正在逐步替换已有的 Mesos 和 Marathon 架构,K8s 和 Istio 的技术架构是业界主流的云原生架构,后续也将紧跟社区,共同发展。
支持多开发语言
服务网格能够天然支持多种开发语言的服务治理。无需针对多种开发语言维护多套微服务技术体系,明显节省人力成本。
非侵入式接入监控
基于现有的业务现状,实现了业务真正的『非侵入式』接入服务网格,同时实现了边车 Sidecar 监控数据和业务内部方法级别监控数据的打通,达到服务网格上的监控能力不低于业务现有监控能力的目的。
服务治理体验提升
通过 UI 化的服务治理方式替换原有手动配置服务治理项的方式,大大提升了用户使用服务治理功能的体验。同时也极大缩短了业务服务治理周期。目前联通所有试点项目已完成了测试环境迁移的验证,其表现符合预期,部分试点业务已经向生产上线并平稳运行。在未来,联通将有更多的业务会逐步向服务网格的技术架构迁移。基于优异的云原生实践场景,联通软研院和百度智能云将携手在服务网格领域做更深入的联合研发和技术探索,共同实现服务网格技术在平稳落地,加快业务向云原生化转型,加速释放业务的核心价值!
文/联通:温怀湘 百度:刘超
评论