随着以容器为核心的新一代应用承接平台的崛起，微服务正焕发出新的生命力。
微服务究竟是什么？它经历了怎样的发展历程？又该如何用于实践？本期，我们将以中国联通微服务架构变迁为例探讨服务网格是如何在联通微服务发展史上立足的。
中国联合网络通信有限公司软件研究院（以下简称联通软研院），在微服务技术上进行了长期的技术研究开发与应用实践，收益显著。而且，由于需要支撑多种微服务架构带来的诸多困扰，经过业内的调研及评估，最终确定了以服务网格（Service Mesh）为微服务的演进方向，组建微服务研发团队，并完成中国联通服务网格 CSM（Chinaunicom Service Mesh）产品研发。
在提升网格能力及微服务治理能力上，联通软研院与百度智能云联合研发 Mesh 服务治理能力并将其融合进 CSM 产品，并借鉴百度智能云服务网格在 APP、百度地图等领域的优秀实践经验，推进 CSM 在联通的试点推广及规模化应用生产落地，持续丰富服务网格在各自业务场景下落地的经验积累。
通过服务网格技术将微服务能力下沉到『基础设施层』，实现了微服务技术栈统一、技术架构云原生化、 多语言场景下微服务能力对齐、业务非侵入式接入监控，服务治理体验大大提升。
服务网格为何物？
>> 微服务1.0阶段：
微服务业务需要主动『依赖 SDK』来实现基本的微服务能力（如熔断、负载均衡、限流等）。因此该部分微服务能力需要和业务应用捆绑在一起，并且对编程语言有强烈的依赖，举一个典型的例子，C++微服务 SDK 无法直接在 Java 业务中使用。
>> 微服务2.0阶段：
按照『基础设施』下沉的思路，微服务能力不再通过 SDK 来实现，而是通过『独立的边车 Sidecar』的思路来实现，Sidecar 作为独立的进程和业务进程分别在两个独立的容器中，各自独立，天然解决了微服务场景中多语言的依赖问题。
如上所示，由边车 Sidecar 形成的网络平面，称为『服务网格』。
联通微服务架构发展历程有何独特之处？
联通微服务架构的发展也经历了如下几个阶段：
- 阶段1：主要采用虚拟机和 RPC 框架；
- 阶段2：主要采用容器、Spring 和自研服务框架；
- 阶段3：以服务网格（Service Mesh）技术为代表，采用 K8S 和 Istio 为主的目标架构。
此外，联通确立了以服务网格作为其目标架构，因此在落地实践中除了考虑服务网格技术，还重点考虑兼容存量微服务架构的迁移。
在实践中理解联通服务网格
>> RPC 架构向服务网格迁移
通过梳理现有存量微服务业务，发现有大量的存量微服务业务采用 SDK 方式，其中 RPC 框架是一个典型的代表，其主要技术特点和业务诉求包括三点：
- 业务代码基于接口/方法编码方式；
- SDK 基于接口级别的服务发现机制；
- 业务方希望不改动现有的业务代码，实现向服务网格迁移。
结合联通业务现状以及服务网格的演进路线，与百度智能云进行了多轮研讨和论证，双方共同确立了如下迁移方案：
▲ 降低迁移成本低
考虑到业务方迁移的诉求在设计迁移方案时，保证业务『不改动业务代码』是重要诉求。通过动态代理的方式兼容业务现有接口/方法的编码方式，业务只需要添加几行注解即可实现迁移，迁移成本极大降低。
▲ 降低冗余注册数据
考虑到目前云原生技术中服务发现机制都是基于『应用级别服务发现机制』， 因此实现服务发现机制由接口级别转变为应用级别，使迁移后的架构服务发现机制更加云原生化。同时该机制的转变，能够有效减少注册中心中冗余数据，降低注册中心压力。
▲ Mesos 架构向服务网格迁移
目前部分业务微服务架构资源调用采用 mesos+marathon，服务治理采用 spring cloud，该架构主要有以下特点：
- 部分微服务治理能力通过 SDK 实现（如熔断、限流等）；
- 资源调度和负载均衡依托于 Mesos、Marathon LB 能力实现；
- 治理能力分散在多种治理组件上。
基于不改动现有业务代码的同时完成向服务网格平滑迁移，即存量应用中已迁移服务和未迁移服务之间的互访目标，经过与百度智能云的共同努力，制定了业务方满意的迁移方案。方案如下所述：
▲ 降低迁移成本低
同样，在迁移方案上，业务无需修改业务代码。通过对 SDK V1（Fat SDK）移出相关微服务能力并兼容服务网格架构，实现 SDK V2（Thin SDK），微服务能力统一在基础设施 Sidecar 上实现。考虑到现有的 Mesos中Marathon LB 的架构，通过中心级别配置规则，配置少，平滑迁移现有业务逻辑。
▲ 云原生化
通过将基础设施 Mesos 更换为 K8s 和 Istio 技术栈，使迁移后的架构更加云原生化，对齐业务主流服务网格架构。
可观测性在服务网格场景下的建设
为推进存量业务向服务网格迁移，在兼顾业务的无感迁移的同时，补齐服务网格业务与非服务网格业务可观测性的能力。
>> 实现业务真正的无侵入接入 Mesh
服务网格技术主要通过将基础设施下沉实现的无侵入性，通过将微服务相关能力在边车 Sidecar 实现，比如路由、限流、熔断等。
但唯一对业务有侵入的地方，体现在『trace header 透传』。什么是 header 透传？简而言之，业务需要在代码当中主动透传边车 Sidecar 上生成的 trace 头信息，否则会出现 trace 链路不完整。
针对大量的 Java 业务，采用 Java Agent（一种字节码增强技术）实现业务的零改造(业务无需感知 trace header 透传)，实现在字节码层面 trace header 透传。
>> 实现方法级别监控，监控数据更完整
由于服务网格技术的特殊性，因此在监控层面会有天然的劣势。这里的劣势主要体现在监控信息只能通过边车 Sidecar 来生成，而对于业务内部的方法级别的执行细节无从得知。
针对大量的 Java 业务，采用 Java Agent（一种字节码增强技术）采集业务内部的方法级别的实现细节，并协同边车 Sidecar 层面监控信息，实现从边车 Sidecar 监控到业务内部方法级别监控的完整链路。
>> 支持多种监控系统，灵活性更强
通过引入 OpenTelemetry 规范，实现数据采集端的数据协议统一。
对于 Service Mesh 体系架构中采集的监控数据，统一按照 OTLP 协议发送至 OpenTelemetry Collector（收集器）中，OpenTelemetry Collector 支持将数据对接至不同的监控系统（如 Jaeger、Skywalking 等），以此来屏蔽底层监控系统的差异性。
从传统微服务框架再到服务网格，联通的微服务技术不断向基础设备下沉，前路日益明朗，下期我们再来聊一聊未来联通对于服务网格产品的规划。
文/联通：温怀湘 百度：刘超