随着相关开源项目逐渐成熟，众多企业对 Service Mesh 跃跃欲试，其中不乏着手布局并投入实践的研发先锋，顺丰科技便是其中之一。

顺丰科技在 2016 年底向云原生架构转型，开始了容器化建设，期间基于 Mesos 和 Marathon 自研了容器管理平台 FBOX，应用实例到了 18 年数量已上万。2019 年，顺丰科技基于 K8s 打造了第二代容器管理平台 KCMP，核心应用几乎全部实现容器化，pod 实例达数万。

经过四年的发展，顺丰科技已经有了相当的容器基础。在 2020 年，顺丰科技迈入了自己云原生新的阶段：Service Mesh。

当时，困扰顺丰科技的主要有三个问题。首先，顺丰科技各业务团队前期为了满足自身的服务治理需求，选择直接使用开源产品进行拼凑，存在不少重复造轮子的情况。随着业务的快速发展，统一的服务治理标准和手段成为团队的重要需求。

其次，为了解决安全管控、标准化 SDK 以及 SDK 兼容性问题，基础设施团队需要推动业务升级。但基础框架、中间件客户端的 SDK 与业务代码耦合，存在依赖包冲突的情况，每次升级非常消耗时间和精力。

最后，传统的蓝绿灰度方案，机器资源成本高且架构复杂。从业界和顺丰科技内部调研情况看，系统变更是造成系统生产异常或故障的重要原因，因此研发团队需要对功能进行灰度测试，充分验证后才能正式发版。但顺丰科技各个部门都在自建灰度能力，但不仅资源消耗大，还难以满足各种场景的需求。

因此，顺丰科技决定利用 Service Mesh 来解决上述问题，并先从原先成本和架构复杂度相对较高的全链路灰度方案开始入手。

去年底，顺丰科技研发平台中心新组建一个专项小组来推动这个项目的发展，同时容器服务、DevOps 平台、网络安全等其他底盘团队共同配合推进。

选择合适自己的

根据顺丰科技后端高级研发工程师杨定朝介绍，Service Mesh 重构全链路灰度项目的落地主要分为三个阶段：调研、研发和适配改造。

调研是技术选型的重要环节。要做选型，就要先了解自身的需求。之前，顺丰科技同时部署了两套环境蓝绿环境，利用网关（Nginx、Kong）进行分流，但这也带来了架构复杂、运维及机器成本成倍提升、不能更好支持更多场景版本的路由等问题。

另外，顺丰科技有 1700 多套系统，拥有 Dubbo、Spring Cloud、Spring Boot 等多个技术栈，支持 Java、Golang 等多种语言。这导致团队在做安全、流控相关研发时，工作量会非常大。

因此，顺丰科技的基础需求主要集中在四方面：低成本、自动化、兼容和安全。这些需求具有一定的共性，实际上在对业内 Istio、MOSN 和 Polaris 等产品对比后，团队也发现市面上大部分产品的功能都很丰富，这些基本都可以满足。那么，如何更好地接入顺丰系统就成了产品选择的重点。

首先，顺丰科技需要更符合自身系统的编程语言。2019 年的时候，顺丰曾尝试使用了 C 的 Envoy，但顺丰的业务部门技术栈主要是 Java、容器是 Golang，虽然 C 有极致的性能，但有一定的上手难度，团队没有足够的 C 经验和相关人才储备。

其次，顺丰科技想要将一些公共服务能力沉淀到数据面上，比如将 Config Mesh、Auth Mesh, Cache Mesh、Event Mesh 等能力融合到 SIDEcar。顺丰科技内部不同的小组都有自己的标准，比如中间件团队有自己标准的 SDK，但基础架构团队时不时就要进行的升级对其非常不友好。升级不得不做，但要花费不少的人力，周期还很长。

最后，接入要让业务无感知。业务非常抗拒修改自己的程序，即使修改也不希望现有的东西有改变。但现在很多开源产品的客户端主要是 Java，两三年就有一个大的版本迭代，基础架构团队不希望因此产生兼容性问题。直接使用开源产品的后果之一就是团队要一直做适配。

基于以上考虑，团队在数据面上选择了更适合自身需求的 MOSN。MOSN 用 Go 编写，有与分布式 Runtime 融合的能力，同时衍生产品 Layotto 在向下对接了各种基础设施的同时，还向上为应用提供了各种具有分布式能力的标准 API，能够将各种通用能力下沉到 Sidecar 里。

但在治理面上，并没有一个完美适配顺丰科技的产品。

Istio 在业内算是最流行网格产品，但对顺丰科技来说，由于内部产品构建原因，没法直接使用 Istio。Istio 虽然使用事实标准的服务治理策略 xDS 协议，但 xDS 默认全量下发的方式使服务过多，一个服务的更新都会引起全量的配置下发，导致带宽占用过大，容易引起 istiod cpu 高负载，限制了 sidecar 的规模和稳定性。

另外，Istio 通过 iptables 无差别劫持所有 tcp 流量，但由于 iptables 本身机制问题，当 service 或连接过多时就会出现性能问题。另外，公司系统大部分用 ingress 或者天玑网关域名调用，要求用户修改回使用 service 方式调用，目前这种方式已经不现实。

相比之下，Polaris 对顺丰科技来说优势更明显，如流量治理策略屏蔽了底层技术栈、流量劫持支持服务网格精准拦截、支持多语言的 SDK 等。但腾讯 2021 年才将 Polaris 开源，这对顺丰来说有点晚了，因为顺丰已经形成了自己的一套技术栈。

“我们的初衷和 Polaris 很像，也是希望提供统一的治理流量界面，用户不需要关心底层的技术栈，只需接入即可使用。可惜的是，我们已经有自己对应的技术栈了，Polaris 的 SDK 流量治理技术栈与我们的不相符。”顺丰科技基础架构总工程师陈焕东说道。

但陈焕东所在的基础架构团队，在调研期间还是选择了能覆盖顺丰大部分场景的 Polaris 作为试点，抽取了 Polaris 中符合自身需求的部分能力融入到自身的服务治理平台，再根据其他需求进行适配改造。

“适配改造是非常关键的。如果开源产品不能很好地适用公司的场景，那么就不能直接拿过来使用。”陈焕东说道。就像 MOSN 即便符合顺丰的多数需求，但团队还是要在一些细节的地方做能力增强，以便满足场景需求。

现在，顺丰科技建成了 One Agent（Java 字节码增强） One Mesh（MOSN 改造后的 Polaris ）的顺丰云原生服务治理平台，即数据面选择自建的 Java Agent、MOSN 产品，控制面选择自建的 Plough Access 和改造 Polaris 产品，统一的治理面则围绕顺丰内部技术自研改造。在陈焕东看来，这是更符合顺丰科技现状的选择。

平台架构图

方案落地

目前，顺丰科技形成了以顺丰云为基础、应用为中心的顺丰云原生服务治理平台。该平台的流量负载主要围绕 xDS 协议进行，服务功能涉及熔断、降级、限流、黑白名单以及全链路灰度。而实施全链路灰度通常需要具备三要素：服务实例信息、路由能力和流量染色。

服务实例信息的 CDS、EDS，通过 controller 同步，然后交由治理面处理。治理面还负责制定路由功能和策略，各种 xDS 信息汇总后传送给 MOSN。MOSN 会带有流量染色的请求，然后将信息传递到服务集群，再做集群里面的负载均衡。

实际上，决定实施 Service Mesh 的时候，顺丰非常确定的一点就是要用统一的服务治理协议 xDS 协议。

如今，业界的治理协议不断发展，但由于没有统一标准，微服务各种产品的治理协议异常繁杂和混乱，如果要做治理面就需要不断地适配协议。“小的团队可能无所谓，但是像顺丰这样体量的公司技术栈很复杂，我们也很担心前期在一个开源产品上做了很多投入后项目突然不维护了，我们就得再考虑整体迁移改造的事情。大家都不想花费大量的精力去重复造轮子。”陈焕东说道。

陈焕东认为，现在服务网格的主流厂商都是基于 xDS 协议构建产品，只要按照这套标准，有需要时就可以轻松地切换，不会出现厂商绑定的问题。

顺丰科技内部有数万的 Pod 实例，xDS 下发效率是一个不得不考虑的问题。团队放弃了 Istio 可能导致 xDS 配置风暴的全量发送方案，沿用了 Polaris 的发布订阅模式，从 namespace 维度进行下发，既支持 namespace 全量下发，也可以订阅其他 namespace 的服务信息。另外团队也改造了 xDS 加载数据代码，保证 xDS 数据可以在 5 秒内被推送到 Sidecar 中。

在稳定性方面，团队沿用了 Polaris 精准流量匹配的能力，服务网格调用的流量才会经过 Sidecar，而调用像 Redis、Kafka、Dubbo 等时不会经过 Sidecar。同时，现在入流量拦截会导入到 Sidecar，这样在进行单个服务的压测时，不做入流量拦截也不会带来任何性能耗损。此外，基础架构团队还计划与容器团队一起试水 ebpf 方案，来进一步提升网络层性能。

安全方面，目前针对服务互调的场景，团队考虑对 Mesh 层进行 mTLS 安全认证。之前的认证体系更多是基于设备和系统的静态化体系，只涉及调用方和被调用方。认证授权小组计划结合基础架构团队，将服务、接口等的认证逻辑通过 MOSN 下沉到数据面进行处理，做到方法级流控。

带来了哪些改变

实际上，顺丰科技的 Service Mesh 探索不到半年，当初实现全链路功能的根本目标就已经达成。期间，Service Mesh 带给研发团队的改变也非常明显。

之前，研发需要做微服务框架的选型，选择各种服务治理、混沌工程和安全生产工具。现在，所有能力下沉到到 Service Mesh，业务通过流水线上订阅的方式，在使用 Spring Boot 或 Golong 应用时简单勾选监控、链路、治理等能力即可，不需要再自建和维护控制台。

还有，业务研发需要依赖中间件资源，之前要先去顺丰云申请，然后再对接各个专业组。现在希望也把这些能力直接下沉到 Sidecar 里面，通过 API 的方式暴露出来，业务需要时可以直接使用 API 市场相关的中间件接口，不必再去顺丰云申请。

除了顺丰云原生平台外，顺丰科技也把这种拿来即用的能力慢慢下沉到 IDE 插件里，本地开发中心可以直接通过插件进行部署交付，对底层基础设施基本无感知。

当然，顺丰科技的 Service Mesh 之路才刚刚开始，需要完善和改进的还有很多。比如后期团队将流量的调度和控制、中间件 API、认证授权等能力都放到了 Sidecar 里，数据面承担的职责过多，资源容易消耗过多；灰度出现问题后，数据如何恢复之类的问题并未没有得到很好地解决；团队的降级方案但还无法考虑到所有场景；个别非 HTTP 业务场景的处理还需要完善等。

顺丰云原生平台的目标是通过轻服务、分布式应用网格和应用编排三大核心产品，以及 One Id、One Agent、One Mesh、One Model、One Flow 五大技术体系，提供标准化、数字化和敏捷化的工具和场景化服务治理和运营管理体系，来持续改进业务质量。轻服务产品接入统一的、轻量协议瘦客户端即可轻松使用各种公共服务能力。应用网格产品无论在服务内外、云端或边端，所有治理能力都无感知接入，并很好地融入到场景中。

产品全景图

大规模落地之难

陈焕东坦言，随着 Service Mesh 应用体量的增大，需要考虑的事情也会越多，并不是简单“1 1=2”的问题。

目前，Service Mesh 大规模落地的方案还是不太理想。Service Mesh 落地试点之后，团队需要花大量的精力投入到 Service Mesh 性能、安全、稳定性以及与现有基础能力融合等方面。

基础设施层下沉到 Sidecar 意味着分工越来越细，那么治理面就要更加完备，引进市场上的开源产品只是解决了一些通用性的问题，和公司现有基础能力的适配，流程的整合，组织的匹配这些问题都需要一一解决。以顺丰科技为例，企业研发流程要求传递和兼容不同的流量标识，但开源产品里并没有。

各种原因都导致企业在接入 Service Mesh 时，通常要投入很大精力做二次开发，而最初可能十几个人的投入，经过一段时间后也会演变为成本问题。像顺丰云原生平台的投入也还在增加，预计到今年底小组人数将达到三四十人左右。

这也是阻碍 Service Mesh 全面落地的重要因素。对于中小企业来说，系统数量、人力资源可能没有那么多，更需要认真评估在 Service Mesh 上做投入是否划算。根据陈焕东在顺丰科技内的测算，Service Mesh 需要落地 200 系统才能使 ROI 达到平衡。陈焕东给中小企业的建议是，可以考虑“传统微服务框架 Service Mesh”的混合部署模式，等业务量上来后再慢慢迁移。

此外，有一点很重要，就是 Service Mesh 对基础设施团队是有一定要求的。像顺丰内部技术栈是 Java 为主，Go、Python 为辅，云原生技术研发和推广需要稀缺的云原生技术人才。同时顺丰内部存在不少老系统需要长期维护，这要求整个基础设施团队需要对公司现有的技术栈非常熟悉，又对云原生产品有深刻的理解。

当然在实际操作中，基础设施团队也会走一些弯路。比如很多团队更多从技术角度去开发 Service Mesh 的相关功能，并没有结合公司的业务研发习惯和治理流程，这也加大了推广的难度。

还有一些内部的系统经过长年积累，技术栈非常多，各部门的使用习惯完全不一样，要求业务研发按照某个维度进行改造并不现实。Service Mesh 使用还需要写 YAML 文件，这对非 Service Mesh 专业的业务团队来说是非常大的心智负担。诸如此类都是落地过程中存在的挑战。

总之，Service Mesh 在技术上比较依赖基础设施，组织上还需要公司各个研发部门达成共识。顺丰科技是成立了囊括各个研发部门技术骨干的技术委员会，通过这个委员会做标准化的推广和新技术的引进和落地。

杨定朝表示，团队并不是必须要实施 Service Mesh 的。Service Mesh 的使用代表着隐藏的技术底层越来越深，会增加业务研发的问题定位难度。另外，有些场景并不一定适合 Service Mesh，不恰当的使用不会得到意想中的效果。

结束语

“接入 Service Mesh，对我们云原生技术的发展有一个很好的承上启下的作用。”陈焕东表示。

目前，顺丰科技将顺丰云原生平台在内部“开源”，希望先通过“内源”的方式吸引其他业务部门一起协同共建。基础架构团队未来会以强组织管理和项目化运作两种模式展开工作。

今年下半年，顺丰科技将在 Service Mesh 研发提效方面持续投入，支持在线调测、环境隔离、低成本创新、跨集群通信、认证鉴权 Mesh、中间件 Mesh 等功能。业务连续性保障方面，Service Mesh 会聚焦在容灾多活、应用防护、混沌工程、问题排查和全域流量调度等精细化运维场景。

“我们的原则就是要先在一些业务单位试点，确实能达到业务预期、带来业务价值后，才会进行大规模推广。”陈焕东说道。面对未来的研发规划，团队上下对基础设施层带来的改变拭目以待。

采访嘉宾：

陈焕东，顺丰科技研发平台中心基础架构总工程师

杨定朝，顺丰科技研发平台中心后端高级研发工程师