【百度云原生导读】2020年联通集团确定了以 Kubernetes（以下简称K8s）为资源调度平台的架构演进路线，与之相对的应用微服务架构也需基于 K8s。中国联合网络通信有限公司软件研究院（以下简称 联通软研院）在微服务技术进行了长期的技术研究开发与应用实践。期间，收获了微服务为联通生产建设带来的红利，也因需要支撑多种微服务架构带来很多困扰，经过业内的调研及评估，最终确定了以服务网格（Service Mesh）为微服务的演进方向，组建微服务研发团队，并完成中国联通服务网格 CSM（Chinaunicom Service Mesh）产品研发。

2021年联通软研院持续迭代服务网格 CSM 产品，为进一步提升网格能力及微服务治理能力，与百度联合研发 Mesh 服务治理能力并将其融合进 CSM  产品，并借鉴百度服务网格在百度 APP、百度地图等优秀实践经验，推进 CSM 在联通试点推广及规模化应用生产落地，在实现了双方的共赢的同时，完成了服务网格在各自业务场景下落地的经验积累。

通过服务网格技术将微服务能力下沉到 『基础设施层』，实现了微服务技术栈统一、技术架构云原生化、 多语言场景下微服务能力对齐、业务非侵入式接入监控、服务治理体验大大提升。

 

1. 什么是服务网格

 

 

微服务1.0阶段：微服务业务需要主动依赖 SDK 来实现基本的微服务能力（如熔断、负载均衡、限流等）。因此该部分微服务能力需要和业务应用捆绑在一起，并且对编程语言有强烈的依赖（一个典型的例子C++微服务 SDK 无法直接在 Java 业务中使用）。

 

微服务2.0阶段：按照基础设施下沉的思路，微服务能力不再通过 SDK 来实现，而是通过独立的边车 Sidecar 的思路来实现，Sidecar 作为独立的进程和业务进程分别在两个独立的容器中，各自独立，其天然解决了微服务场景中多语言的依赖问题。

 

 

如上所示，由边车 Sidecar 形成的网络平面，称为『服务网格』。

 

2. 联通软研院微服务架构发展历程

 

 

目前微服务架构的发展也经历了如下几个阶段：

 

• 阶段1：以天宫1.0技术为代表，主要采用虚拟机和 RPC 框架。

• 阶段2：以天宫2.0、3.0技术为代表，主要采用容器、Spring 和自研服务框架。

• 阶段3：以服务网格（Service Mesh）技术为代表，采用 K8S 和 Istio 为主的目标架构。

 

联通软研院确立了以服务网格作为其目标架构，因此在落地实践中除了考虑服务网格技术，还重点考虑兼容存量微服务架构的迁移。

 

3. 落地实践

 

3.1  RPC 架构向服务网格迁移

 

 

通过梳理现有存量微服务业务，发现有大量的存量微服务业务采用 SDK 方式，其中 RPC 框架是一个典型的代表。通过梳理发现现有 RPC 框架的主要技术特点和业务诉求如下：

 

1. 业务代码基于接口/方法编码方式。

2. SDK 基于接口级别的服务发现机制。

3. 业务方希望不改动现有的业务代码，实现向服务网格迁移。

 

结合联通软研院业务现状以及服务网格的演进路线，与百度进行了多轮研讨和论证，双方共同确立了最终的迁移方案。迁移方案如下所述：

 

降低迁移成本低

 

考虑到业务方迁移的诉求（即不希望改动业务代码），因此在设计迁移方案时，重点保证业务不改动业务代码。通过动态代理的方式兼容业务现有接口/方法的编码方式，业务只需要添加几行注解即可实现迁移，迁移成本大大降低。

 

降低冗余注册数据

 

考虑到目前云原生技术中服务发现机制都是基于应用级别服务发现机制， 因此实现服务发现机制由接口级别转变为应用级别，使迁移后的架构服务发现机制更加云原生化。同时该机制的转变，能够有效减少注册中心中冗余数据，降低注册中心压力。

 

3.2  Mesos 架构向服务网格迁移

 

 

目前部分业务微服务架构资源调用采用 Mesos+Marathon，服务治理采用 Spring Cloud，该架构主要有以下特点：

 

• 部分微服务治理能力通过 SDK 实现（如熔断、限流等）

• 资源调度和负载均衡依托于 Mesos、Marathon LB 能力实现

• 治理能力分散在多种治理组件上

 

基于不改动现有业务代码的同时完成向服务网格平滑迁移（即存量应用中已迁移服务和未迁移服务之间的互访）目标，经过与百度的共同努力，制定了业务方满意的迁移方案。方案如下所述：

 

降低迁移成本低

 

同样，在迁移方案上，业务无需修改业务代码。通过对SDK V1（Fat SDK）移出相关微服务能力并兼容服务网格架构，实现 SDK V2（Thin SDK），微服务能力统一在基础设施 Sidecar 上实现。考虑到现有的 Mesos 中 Marathon LB 的架构，通过中心级别配置规则，配置少，平滑迁移现有业务逻辑。

 

云原生化

 

通过将基础设施 Mesos 更换为 K8s 和 Istio 技术栈，使迁移后的架构更加云原生化，对齐业务主流服务网格架构。

 

3.3  可观测性在服务网格场景下建设

 

 

为推进存量业务向服务网格迁移，在兼顾业务的无感迁移的同时，补齐服务网格业务与非服务网格业务可观测性的能力。

 

实现业务真正的无侵入接入 Mesh

 

服务网格技术主要通过将基础设施下沉实现的无侵入性，通过将微服务相关能力（如路由、限流、熔断等）在边车 Sidecar 实现。

 

但唯一对业务有侵入的地方，体现在 trace header 透传，如下引用了 Istio官 网关于trace header 透传的内容：

 

Although Istio proxies are able to automatically send spans, they need some hints to tie together the entire trace. Applications need to propagate the appropriate HTTP headers so that when the proxies send span information, the spans can be correlated correctly into a single trace.

 

因此对于业务来讲并不是完全无侵入，业务方可能会问，什么是 header 透传？简而言之，业务需要在代码当中主动透传边车 Sidecar 上生成的 trace 头信息，否则会出现trace 链路不完整。

 

针对大量的 Java 业务，采用Java Agent（一种字节码增强技术）实现业务的零改造(业务无需感知 trace header 透传)，实现在字节码层面 trace header 透传。

 

实现方法级别监控，监控数据更完整

 

由于服务网格技术的特殊性（微服务能力统一由边车 Sidecar 实现），因此在监控层面会有天然的劣势。这里的劣势主要体现在监控信息只能通过边车 Sidecar 来生成，而对于业务内部的方法级别的执行细节无从得知。

 

针对大量的 Java 业务，采用Java Agent（一种字节码增强技术）采集业务内部的方法级别的实现细节，并协同边车 Sidecar 层面监控信息，实现从边车 Sidecar 监控到业务内部方法级别监控的完整链路。

 

支持多种监控系统，灵活性更强

 

通过引入 OpenTelemetry 规范，实现数据采集端的数据协议统一。

 

对于 Service Mesh 体系架构中采集的监控数据，统一按照 OTLP 协议发送至OpenTelemetry Collector（收集器）中，OpenTelemetry Collector 支持将数据对接至不同的监控系统（如Jaeger、Skywalking等），以此来屏蔽底层监控系统的差异性。

 

4. 未来服务网格产品的规划

 

 

如上所示，服务网格产品已经具备了流量治理、安全、可观测性、实例管理四个方面的能力。未来服务网格产品化也继续紧跟 Istio 社区动态，持续迭代微服务相关能力，适配业务微服务场景，让服务网格能够更多业务场景落地。重点将围绕着网格性能、治理能力和扩展能力进行迭代优化。以下为未来落地的初步构想：

 

4.1 服务网格性能优化 - 单跳方案

 

 

由于服务网格技术中边车 Sidecar 用于业务的流量，其带来的延迟，一直是业务特别关心的，也是服务网格未来能否被被业务方所接受的关键因素。

 

目前社区的方案为业务所有的进（Inbound）和出（Outbound）流量都会被边车 Sidecar 拦截，该方式称为双跳方案。社区双跳方案往往性能差，无法在超大规模环境下落地。

 

通过分析发现在流量拦截机制中 Inbound 流量非必要，因此可以考虑将减少 Sidecar 非必要 Inbound 流量拦截，该方式称为单跳方案。该方案对比双跳方案，能够显著减少Sidecar带来的时延。

 

4.2 服务网格性能优化 - eBPF 方案

 

通过引入内核 BPF 中 socketmap 和 redirect 机制（提供了一种特殊的 map 类型即 socketmap，可以来做 socket redirection），绕开 TCP/IP 协议栈，降低边车 Sidecar 层面带来的时延。

 

4.3 扩展性优化-Fallback 机制

 

服务网格中典型的代理模式是通过 Sidecar 来进行请求拦截处理，实现微服务的能力。而在实际的实践中，业务往往对增加的 Sidecar 的稳定性有很高的要求，尽管可以尽可能保障 Sidecar 的稳定，但仍无法打消业务的顾虑。

 

因此提供直连模式，能够保障业务能够在极端故障情况下，实现请求不经过 Sidecar 拦截处理，而是交由业务来处理流量，即使 Sidecar 存在的情况下。

 

Fallback 机制能够有效保障业务的可靠性，能够实现代理模式和直连模式自由切换。

 

4.4 扩展性优化-按需下发

 

 

通过分析社区『全量下发』的方案，发现在规模化的场景中，往往会出现瓶颈问题。主要体现在 XDS 的全量推送和频繁低效变更。

 

因此设计『按需下发』的方案，即下发的 XDS数据一定是 Sidecar 所需要的，避免非必要的冗余数据和无效变更，提升服务网格的整体性能，满足规模化落地场景的需要。这里的『按需下发』主要是要收集微服务调用的依赖关系，会通过手动和程序自动收集的方式来收集。

 

4.5 治理能力优化-国产化

 

 

考虑到的业务会运行在各类国产化环境中，因此也会将服务网格整个技术体系兼容不同的国产化环境。在芯片层面需要兼容X86、ARM和PPC，在操作系统上需要兼容统信UOS 和麒麟。

 

5. 价值收益

 

无论是业内还是落地服务网格的感受，都能体会到基于云原生服务网格给业务带来的收益价值，下面将分享一下服务网格带来的价值收益。

 

微服务技术栈统一

 

通过服务网格技术设施下沉的思路，实现了微服务技术栈统一。一方面能能够节省不同微服务框架的运维人力，另一方面能够实现微服务功能的统一。

 

目前基于现有RPC服务框架的业务应用，可以实现零改造业务代码，达到迁移到服务网格的目的。

 

技术架构云原生化

 

基于 K8s 和 Istio 构建的微服务架构，正在逐步替换已有的 Mesos 和 Marathon 架构，K8s 和 Istio 的技术架构是业界主流的云原生架构，后续也将紧跟社区，共同发展。

 

支持多开发语言

 

服务网格能够天然支持多种开发语言的服务治理。无需针对多种开发语言维护多套微服务技术体系，明显节省人力成本。

 

非侵入式接入监控

 

基于现有的业务现状，实现了业务真正的非侵入式接入服务网格，同时实现了边车Sidecar监控数据和业务内部方法级别监控数据的打通，达到服务网格上的监控能力不低于业务现有监控能力的目的。

 

服务治理体验提升

 

通过UI化的服务治理方式替换原有手动配置服务治理项的方式，大大提升了用户使用服务治理功能的体验。同时也极大缩短了业务服务治理周期。

 

6. 展望

 

目前所有试点项目已完成了测试环境迁移的验证，其表现符合预期，部分试点业务已经向生产上线并平稳运行。未来将有更多的业务会逐步向服务网格的技术架构迁移。基于优异的云原生实践场景，联通软研院和百度将携手在服务网格领域做更深入的联合研发和技术探索，共同实现服务网格技术平稳落地，加快业务向云原生化转型，加速释放业务的核心价值。

 

---

 

作者：联通软件研究院-温怀湘

百度-刘超

 

---

 

进群！聊聊服务网格

扫码添加小助手即可申请加入，一定要备注：名字-公司/学校-地区，根据格式备注，才能通过且邀请进群。

了解更多微服务、云原生技术的相关信息，请关注我们的微信公众号【百度云原生】！