京东云服务网格的落地实践-京东云开发者社区

近几年，随着容器技术和微服务的快速发展，其生态也在不断完善，更多的企业采用微服务架构进行开发，并逐步转向云原生方式。而纵观每个与容器相关的大会，都会包括服务网格的相关议题。那么，服务网格究竟是什么？企业可以通过服务网格带来哪些好处？企业应该怎样部署服务网格？

服务网格的由来及发展

在企业系统开发过程中，一个大型系统通常由多种语言实现，并且系统服务数量较多，因此就需要进行服务治理。但由于各语言成熟度不一样，开发者想把整个系统的所有服务统一治理就相对比较困难。此外，传统服务治理框架对业务应用有耦合，业务开发时需要应用治理框架的SDK，因此在升级时就会困难。

一种新的微服务框架服务网格（Service Mesh）出现在大众视野。服务网格具有语言无关、框架无关的特性，因此受到了很多企业的青睐，而服务网格也逐渐变得火热。

服务网格位于企业IT架构的中间层，底层是基础设施，上层是业务应用，主要负责应用程序可靠通信及服务治理功能，包括服务注册发现、负载均衡、熔断限流、观测监控、调用链等。开发者只需要关注业务逻辑的实现，并在系统运行时掌握系统实时状态，当出现问题时可以快速定位并进行解决，从而提高整体开发效率。

虽然服务网格的优势很明显，但是仍处于初级阶段，目前只有技术实力较强的厂商进行尝试，而中小企业涉猎的很少，毕竟网格技术发展相对还不成熟，并且成功平滑迁移到服务网格架构的案例还不多。而大型企业使用服务网格，也是看系统架构和应用场景。如果企业仍是传统单体架构，就没必要引入服务网格，因为服务网格适合中大型微服务架构或云原生环境中使用。例如，业务逻辑比较复杂，系统被设计成多语言实现的微服务架构，服务数量比较多，服务之间互相调用，没有服务治理功能时很难理清它们之间的调用关系。这种情况下就可以使用服务网格解决多语言统一治理的问题，并且可以使用服务依赖拓扑、调用链等功能查看服务之间的相互调用关系，还可以获得业务和治理功能解耦的额外收益。

服务网格的落地方式

服务网格的优势以及带来的好处这么多，那么企业该如何落地服务网格呢？如果是有研发实力的企业，可以选择自研网格。不过，目前，业界有很多开源的服务网格框架，例如istio、linkerd2、kuma、nginMesh、maesh等，企业可以依托于开源框架，快速进入到服务网格领域。

如果使用开源框架，应该如何实现呢？使用开源框架时，有四个步骤可以参考。首先，企业需要对比各个框架的优劣势，以及企业自己的环境，从而确定使用的框架。第二步，在开发之前，还要根据实际环境、资源情况和限制条件设计架构。第三步，就需要制作服务平滑迁移到服务网格的方案，将网格方案与现有IT系统进行更好的融合。最后，要给相关人员进行多角度的技术培训，以保证使用者对网格的能力、限制、用法等方面有了准确的认知。

企业在落地服务网格时，最重要的还是技术选型问题。如果开源框架无法满足企业业务需求，并且有一定的研发实力，企业可以选择自研，但是自研时还需要考虑兼容业界的标准接口，才能后续更好的利用社区新成果。而研发实力不强的企业可以直接选择主流的开源框架进行扩展开发，或者系统已经在云端则可以直接选择云端的服务网格产品，但是开源框架还是存在一些问题，例如迁移服务进网格时会遇到平滑迁移不断流的问题，业务出现问题时网格降级等问题，企业都是需要额外注意的。

京东云的服务网格之路

京东云内部有数千个服务，业务复杂，并且服务由多种语言实现，包括Golang、Nodejs、Java、C/C++等。因此，服务间的互相调用，服务间的依赖关系和调用链就需要统一管理。此外，京东各个业务部门开发功能时总会遇到重复的业务治理相关工作，浪费开发资源，降低开发效率。因此，服务网格恰好能够解决京东云的服务治理问题，解决多语言统一治理的问题，并且在中间层实现所有服务的治理功能，对业务代码也是无耦合的。

京东云的服务有些是运行在物理机和虚拟环境中，有些是运行在K8s环境，如果要进行统一治理，就要兼顾两种环境的服务。因此，京东云选择了较成熟的istio框架，虽然istio框架对非K8s环境支持还不成熟，但是依托京东云强大的自研能力，最终实现两种环境的统一治理。

京东云内部服务网格的落地是分阶段进行的。首先对非K8s环境的控制面服务入手，因为控制面需要灵活的分流并且对时延要求没那么苛刻，毕竟引入代理会或多或少增大一些时延和资源消耗。然后再拉通非K8s环境中的物理机、虚机部署的服务进行统一治理。最后是拉通K8s环境中的服务。

京东云内部服务网格落地方案

在非K8s环境中实施服务网格的难点还是有很多的。首先要明白istio的主要工作原理。istio原生是部署在K8s平台上的，在非K8s平台上就会有很多移植对接工作，比如pilot如何从依赖的底层平台获取服务和实例信息，如何下发给数据面代理envoy；如何扩展pilot并对接到京东云内部部署平台；如何开发mixer插件进行安全token认证等等。在整个数据流转过程中，在非K8s平台如何部署代理envoy并保证稳定运行；业务流如何被拦截到代理，出了问题如何降级，这些都是要考虑的问题。

此外，还要考虑应用如何平滑迁移进网格，不能有业务流量损失，万一在迁移过程中出现问题，还要能迅速回滚。最后，在非K8s环境中整个服务网格系统的版本升级相对于K8s环境来说也是一个不小的挑战。由于istio处于高速发展阶段，代码变动比较大，有些接口还不稳定，在新版本中会有一些重要特性和重大bug的解决以及性能优化。

京东云服务网格的收益

在istio框架中原生包含了众多服务治理功能，比如流量治理、服务注册与发现、负载均衡、健康检查、调用链、观测、安全等等，这些功能也给京东云带来了众多便利。

首先，可以使用流量治理功能实现更细粒度的流量控制，比如按HTTP Header、Host进行分流，或者进行灰度发布、蓝绿部署、滚动发布等。

其次，是实现了服务的统一安全治理，因为使用mixer开发了插件，服务在访问时会自动带上token，被访问服务只要在页面上打开安全认证开关即可实现对访问请求进行token认证的效果。

最后，通过网格提升对服务的观测能力。网格让所有服务都有统一的一份基线的日志、监控和调用链（自身再按需进一步扩充）。以调用链为例，在微服务系统中很多服务之间互相调用，层次比较深时不容易定位。使用调用链可以直观快速的定位到问题所在服务，减少问题定位时间，提高开发效率。调用链还提供了服务依赖图谱，可以用来分析服务之间的相关依赖关系，对梳理整个系统架构提供全局视角。

京东云服务网格的未来规划

对于京东云服务网格的未来发展，我们会打通K8s和非K8s平台，让两种平台的容器、虚机、物理机都可以统一到一套系统。此外，京东云还会优化网格和非网格两种微服务的相互调用过程的性能和易用性。

同时，我们也希望可以将京东云服务网格的经验进行抽象总结，形成云上给云客户提供的“云服务网格”产品。