共计 2656 个字符，预计需要花费 7 分钟才能阅读完成。
随着以容器为外围的新一代利用承接平台的崛起，微服务正焕发出新的生命力。
微服务到底是什么？它经验了怎么的倒退历程？又该如何用于实际？本期，咱们将以中国联通微服务架构变迁为例探讨服务网格是如何在联通微服务发展史上立足的。
中国联结网络通信有限公司软件研究院（以下简称联通软研院），在微服务技术上进行了长期的技术钻研开发与利用实际，收益显著。而且，因为须要撑持多种微服务架构带来的诸多困扰，通过业内的调研及评估，最终确定了以服务网格（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 等），以此来屏蔽底层监控零碎的差异性。
从传统微服务框架再到服务网格，联通的微服务技术一直向根底设施下沉，前路日益清朗，下期咱们再来聊一聊将来联通对于服务网格产品的布局。
文 / 联通：温怀湘 百度：刘超
