不是所有的应用都需要Service Mesh架构

2023-04-01 16:29:58 浏览数 (2)

采访嘉宾 | 张培培

编辑 | Tina

“微服务架构”的含义在过去十年里不断演变,今天的服务网格实现已经相当复杂,第二代 Service Mesh 诞生在 Kubernetes 之后,它的代表是 lstio。在 lstio 之外,同时存在着各种层出不穷的框架,解决的却都是相同的问题。

正确的选择框架却不是件简单的事情。就像在容器编排领域,之前我们有 Kubernetes、Docker Swarm、Mesos 和 Cloud Foundry,其中一些后来逐渐被市场淘汰,没有选择 Kubernetes 的企业有可能得从头再来一次。在微服务领域,我们不希望有类似的情形出现。现在,各种框架竞争激烈,你的业务适合采用哪一个?使用微服务架构,除了 Service Mesh 还有其他选择吗?针对这些问题,我们采访了腾讯 TSF Mesh 研发及负责人张培培,他给出了一些很好的见解。

采访嘉宾:

张培培,腾讯研发高级工程师,TSF Mesh 研发及负责人,热衷于云原生和开源技术,在容器、Service Mesh、消息队列、区块链等领域拥有丰富经验,目前致力于 Service Mesh 和 Mecha 多运行的落地和推广。

InfoQ:这十年里微服务领域有哪些大的变化?

张培培: 微服务的概念最早是在 2011 年威尼斯一个的软件架构会议上被提及的,随后又有一大批的技术框架和文章涌现出来,越来越多的公司开始借鉴和使用微服务架构相关的技术,我觉得这十年微服务架构的演进分为四个重要阶段:

第一个阶段:RPC 通信,应用从单体拆分成运行于多主机的微服务,首要解决的问题就是微服务间的通信问题,这里又分为两类,一类跟语言平台绑定的框架如阿里 Dubbo、微博 Motan、腾讯 Tars,另一类跨语言平台的框架如 Thrift、gRPC。这个阶段,特别是早期版本的 RPC 框架,并没有支持太多的服务治理能力,开发人员需要在应用程序中解决服务发现、熔断重试等微服务架构所面临的问题,这就导致大量的非功能性代码耦合在业务代码中;

第二个阶段:服务治理 SDK 化,随着微服务架构在企业大规模落地,调用链路越来越复杂,微服务架构所面临的问题也越来越突出,亟需一套统一且完善的服务治理能力,而最直接的集成方式就是融合到 RPC 框架中,这个阶段比较有代表性的框架如 Dubbo、Spring Cloud,只需要少量代码和注解,即可集成各种所需的服务治理能力。而 Spring Cloud 更是对各种治理能力进行了模块化抽象如服务注册发现 Spring Cloud Eureka、服务调用负载均衡 Spring Cloud Feign、服务熔断 Spring Cloud Hystrix 等;

第三个阶段:服务治理 Sidecar 化,基于 SDK 的微服务框架,解决了治理能力统一的问题,但也带来的诸多问题,如 SDK 升级维护成本高、难以支持多语言、策略控制不统一等问题。Service Mesh 方案应运而生,服务治理能力下沉到 Sidecar,治理策略有控制面统一管理。这个阶段比较有代表性的框架如 Linkerd、Istio 等;

第四个阶段:多运行时,对于一个复杂的大型分布式系统,不管是基于 SDK 的服务治理和 Service Mesh,更多解决的是服务间通信的问题,而一个分布式应用的需求远远不止于此,还需要状态管理如 Workflow 管理、应用幂等实现、应用执行状态等等,需要绑定外部依赖如数据存储、事件驱动等,传统的方式依然是通过 SDK 集成各种分布式能力,要真正做到应用完全专注于业务逻辑,这部分分布式能力也应该下沉到 Sidecar,这就是由一位大牛 bibryam 提出的 Mecha 多运行时的思想,目前比较有代表性的框架如 Dapr。

InfoQ:在您看来,为什么服务网格越来越受欢迎?它能解决传统微服务架构的哪些痛点?

张培培: 先理解下什么是传统微服务架构,就是微服务治理能力如服务注册、发现、熔断、限流等与业务逻辑解耦,单独以 SDK 的形式提供给开发者,但服务治理和业务逻辑还是跑在一个进程中的。再看下这种传统微服务架构带来了哪些痛点:

  1. SDK 升级维护成本高,由于 SDK 耦合在业务进程中,那每次 SDK 升级必然需要绑定业务一起升级,这对于拥有成千上万的业务系统是很难接受的,而且涉及到 SDK 大版本的变更可能还会有兼容性问题;
  2. 多语言框架 SDK 维护成本高,SDK 意味着和语言绑定,那不同语言都要维护不同的 SDK 版本,所以很少有多语言的传统微服务框架,能流行起来的也就是某个语言的框架如 JAVA 系的 Spring Cloud、Dubbo,go 系的 go-micro 等;
  3. 没有统一微服务策略控制,各种治理能力控制比较分散,配置方式也比较随意;
  4. 额外组件的引入特别是注册中心带来的运维成本。

而 Servive Mesh 之所以越来越受欢迎,在提供更丰富的服务治理、安全性、可观测性等核心能力外,其从架构设计从解决了以上几个痛点,服务治理能力以 Sidecar 的模式下沉到数据面,解决了 SDK 升级及多语言的问题,由于没有 SDK 的依赖,开发人员可以选择任何开发语言,只需专注于业务逻辑的开发,无需关注服务治理,Sidecar 作为基础设施层,也可以独立升级。对于像负载均衡、熔断、限流等策略配置,由控制面统一管理和配置,并下发到数据面生效。同时,Kubernetes 已被认为是云原生时代的操作系统,越来越多的应用基于 Kubernetes 进行编排,而主流的 Service Mesh 方案像 Isitio、Linkerd 都是承载在 Kubernetes 上,那微服务的核心之一服务注册发现,就完全不需要额外引入外部注册中心,编排在 Kubernetes 上的应用会自动在 Mesh 体系中被感知。

InfoQ:像 Spring Cloud 、Zuul、Eureka、Consul... 这些涵盖了微服务体系的服务注册与发现、限流、熔断降级、负载均衡、服务配置的开发框架或服务组件,在设计理念上与 Service Mesh 存在哪些差别?

张培培: 像 Dubbo、Spring Cloud 都属于传统的微服务框架,与服务治理相关的大部分逻辑都是以 SDK 的方式耦合在具体的微服务应用之中,服务注册、服务调用、负载均衡以及服务熔断、限流等高级治理都需要引入 SDK,同时,为了整个分布式系统的正常运作,还需要额外引入注册中心、微服务网关的基础组件。对于服务治理策略的控制,支持硬编码到代码逻辑、配置文件或者远程配置中心,基本是由开发人员控制的,像熔断、限流、负载均衡等服务治理的策略配置,也比较分散。总之,传统微服务框架更多的是面向开发者,没有形成统一的微服务控制平面。

Service Mesh 被定义为用于处理服务间通信的基础设施层,其在架构设计上采用了控制面 数据面的模式,微服务的治理能力下沉到数据面,与应用进程完全解耦,以 Sidecar 模式运行,并由控制面统一控制,以 Istio 为例,控制面实时感知服务治理策略的变更并通过 xDS 协议下发到数据面。尤其,在以 Kubernetes 为代表的容器编排技术逐步成为软件运行主流基础环境的背景下,目前主流的 Service Mesh 方案都是基于 Kubernetes 进行构建,像 Istio 天然依托于 Kubernetes,注册中心、边界网关包括配置管理的基础组件,都不需要额外引入。开发人员负责将只包含纯业务逻辑的应用编排进 Kubernetes,服务治理由数据面和控制面协作完成。

InfoQ:在您看来,目前有哪些 Mesh 主流的框架,如 lstio、Linkerd?各有什么优势?

张培培: 业内 Mesh 方案较多,如 Istio、Linkerd、Consul Connect,Kuma,AWS App Mesh 和 OpenShift,而成熟度较高、社区较为活跃的无疑是 Istio 和 Linkerd。

下面来对比下 Istio 和 Linkerd 的 Mesh 方案:

首先,目前两者都已经成熟,并已被多家企业用于生产,都是控制面 数据面的架构模式,支持多集群多网络的部署模式,支持 gRPC、HTTP/2、HTTP/1.x、Websocket 和所有 TCP 流量,涵盖了流量管理、安全性、可观测性等核心功能。

其次,再看下各自的优势。

Istio:

  1. Istio 有 IBM、Google 和 Lyft 等行业领军者的支持,背景更加强大,社区也非常活跃;
  2. 统一的东西流量和南北流量管理方案;
  3. 功能相对丰富些,如熔断、延时注入等流量控制,安全方面支持基于 RABC 的访问控制。

Linkerd:

  1. Linkerd 是业界的第一款 Service Mesh 框架,轻量级,相比 Istio 复杂而灵活的配置选项,Linkerd 配置简单,且内置开箱即用的配置,安装相对容易,运维成本也较低;
  2. 控制面 namerd 支持直接对接多注册中心如 Kubernetes、ZooKeeper、Consul、etcd,Istio 虽然支持 service entry、mcp over xDS 的方式扩展除 Kubernetes 外的第三方注册中心,但需要用户自行编写组件扩展;
  3. 性能较好,根据第三方基准测试,Istio 1.6 VS Linkerd 2.7,Linkerd 快 3-5 倍;
  4. 企业支持较好,Buoyant 开发了 Linkerd OSS 版本, 提供了完整的企业级工程、支持和培训。

总结下来,Istio 社区更活跃、功能更完善,也更复杂;Linkerd 更轻量、性能更好,操作简单但也欠灵活。

InfoQ:您认为服务网格目前的局限性表现在哪些方面?

张培培:Service Mesh 让开发人员可以专注于业务逻辑的开发,无需关注服务治理,但也存在不少局限性。Istio 是目前业内最为流行的 Mesh 方案,下面就以 Istio 为例参考社区的几点总结:

  1. 复杂性增加,Service Mesh 通过 Sidecar 侵入到业务数据流的,而 Sidecar 对业务进程又是透明的,虽然业务代码简单了,但整个数据流变复杂了,一次简单的调用从两跳变为六跳,这就极大的增加了开发调试及运维的难度;
  2. 无法做到完全对应用透明,对于一些微服务框架已经集成了一些治理能力如重试机制,如果在 Sidecar 中再重试,容易引起重试风暴,还有 tracing header 的传递,也需要应用代码的参与,总之,现有的业务体系接入 Mesh,还是要充分考虑到所用的框架是否和 Mesh 有重合、冲突的地方;
  3. 对非 Kubernetes 环境支持有限,目前主流的 Service Mesh 方案像 Istio 还是比较依赖于 Kubernetes 的,对于非容器环境或者非 Kubernetes 环境,服务注册发现、策略配置管理可能需要自行扩展,Sidecar 注入也需要自行维护管理;
  4. 协议支持有限,目前主流的 Service Mesh 方案像 Istio、Linkerd 中 HTTP1.x/2.0、gRPC 才是一等公民,对于其它协议要么只局限在四层治理上,要么治理能力不全如 Dubbo、Thrift、Redis 等,这就导致一些传统的微服务框架很难直接迁移到 Service Mesh;
  5. 扩展的门槛并不低,比如扩展第三方注册中心,虽然 Istio 提供了多种标准的扩展方式如 controller 实现、Service entry 或者 mcp over xDS,但依然需要理解各种复杂的接口或定义并实现;再比如对私有协议的支持,首先你需要在 Istio 的 API 代码库中进行协议扩展,其次你需要修改 Istio 代码库来实现新的协议处理和下发,然后你还需要修改 xDS 代码库的协议,最后你还要在 Envoy 中实现相应的 Filter 来完成协议的解析和路由等功能,这过程中可能还涉及到编译问题、代码合并问题、开源升级问题;
  6. 性能损耗,由于服务调研经过了 Sidecar 代理,势必会带来性能上的损耗,目前公开的 Service Mesh 中 Envoy 造成的额外访问延时大概是 3 毫秒,这对延时极其敏感的业务会产生一定影响;
  7. 资源占用问题,考虑到开箱即用,用户不用进行过多的配置,Istio 默认下发全量的规则,仅仅几个服务,Envoy 所收到的配置信息就有将近 20w 行,可以想象,在稍大一些的集群规模,Envoy 的内存开销、Istio 的 CPU 开销、xDS 的下发时效性等问题,也会变得尤为突出;同时,Envoy 作为流量代理,是 CPU 密集型应用,随着 QPS 的增加 Envoy 的 CPU 开销也是不可忽视,在内部一个模拟业务的压测场景下,Envoy 要额外吃掉 20%-30% 的 CPU 资源。

InfoQ:为什么服务网格落地时,会是百花齐放的局面?很多企业会自己实现一套?

张培培: 究其原因还是很多公司的业务系统存在较重的历史包袱,很难推翻现有平台或框架直接替换 Service Mesh 框架,因此在实际落地时会结合当前业务场景来打造自己的 Service Mesh。

比如:不少传统公司还没有容器化改造或者全量容器化改造,更不要说接入 Kubernetes,而像 Istio 这样的 Mesh 方案是非常依赖 Kubernetes 的,那可能就需要改造 Istio,支持控制面容器化部署,支持数据面容器化部署,由于不依赖 Kubernetes,那服务注册发现、策略配置管理就需要自己整一套。

再比如,在传统微服务框架盛行的年代,很多公司基于像 Dubbo、Spring Cloud 进行开发,或者一些公司自己的微服务体系,需要平滑、逐步迁移到 Service Mesh,那必然要考虑存量业务和 Mesh 业务共存的问题,同时保证两者的互联互通,而老系统有一套甚至多套注册中心像 ZooKeeper、Consul,有完整的服务治理控制平台,那可能就要设计注册中心同步或者双注册方案。

InfoQ:企业在实施微服务 / 服务网格可能会存在哪些技术债?总结起来会由哪些情况导致?

张培培: 总结下来,有以下几个方面:

  1. 业务系统是否已经做了微服务改造,如果还是单体应用或者 SOA 体系,引入 Service Mesh 所带来的收益也并不明显,反正增加了额外的运维成本;
  2. 业务系统是否已经容器化 /Kubernetes 编排,像主流 Mesh 方案还是强依赖于 Kubernetes,虽然对非容器环境有一定支持,但如果希望能直接融入 Mesh 体系,最好先容器化
  3. 业务系统中服务间通信是否基于如 HTTP/gRPC,否则需要扩展第三方协议,上面也聊到扩展协议其实并不那么轻松;
  4. 运维体系是否完善,在大规模应用场景下,大量的应用意味着有等量的 Sidecar 需要运维,一套完善的运维系统才能保证应用及 Sidecar 在部署、灰度及升级阶段中的稳定性。

InfoQ:在微服务选型时,您认为需要一个什么样的前期的决策过程?需要哪些步骤?

张培培: 首先,捋下现有业务系统的痛点,比如,是否是单体应用微服务改造的问题,是否是传统微服务 SDK 的升级问题,是否是多语言多框架服务治理不统一的问题。再深入了解下 Service Mesh 适用场景、能力矩阵,看引入 Service Mesh 是否能真正解决自己的业务痛点。

其次,评估下上面提到的 Service Mesh 局限性是否能接受,是否能够驾驭的了 Service Mesh。

最后,如果决定引入 Service Mesh,评估下现有业务系统的迁移成本,是否有完善的开发配置基础设施如 CI/CD、统一的治理平台。

Service Mesh 解耦了开发和运维,开发简单了,但运维复杂了,如果考虑到运维成本较大或者迁移成本较大,也可以考虑下现有云厂商的 Mesh 平台托管,目前不少云平台已经解决了跨 Paas 平台、多注册中心、多框架多协议等问题,极大的降低了迁移成本。

InfoQ:未来还有哪些趋势值得关注?

张培培: 未来大家可以多关注下“Mecha”多运行时的发展。如果 Service Mesh 解决的是服务间的通信问题,解决的是网络运行时,那“Mecha”多运行时,就是 Service Mesh 的延展和升华,对分布式应用运行时所需的能力进行了抽象,对外暴露统一的分布式原语 API,并且不局限于 Sidecar 模式,甚至支持 node 模式,以适应 Iot 或者 Faas 的应用场景。

而针对不用的应用场景和架构可能又会分化出两种不同的落地实现:

  1. 微服务治理能力的多运行,可以看作是 Service Mesh 的 Mecha 实现,从目前业内 Service Mesh 的落地实践来看,并没有完全撼动传统微服务系统的地位,归根结底还是之前提到的一些局限性导致很多公司掌控不了 Service Mesh。因此依然采用像 gRPC、Spring Cloud、Dubbo 甚至自研框架,但传统微服务的痛点又依然存在,而微服务治理能力的多运行实现正好迎合了这种场景,路由、泳道、熔断、负载均衡、限流、鉴权等微服务能力高度抽象,治理能力的实现和扩展下沉到 Sidecar 或 node,同时提供统一治理接口,并支持适配各种开发框架,这里没有实际侵入应用的数据流,因此,调用链路并不复杂,性能影响很小,运维成本也很小。目前,我们内部已经孵化出一款轻量级的云原生多运行时微服务框架,支持多语言、多框架、多平台,预计在今年10月份开源,敬请期待!
  2. 分布式应用能力的多运行,对于构建一个复杂的业务系统,除了需要满足应用生命周期的管理、服务治理的需求,还需要如分布式配置、分布式锁、状态管理、事件驱动等能力,分布式应用能力的多运行就是对诸如这些能力的抽象,对应用提供统一的访问接口,这种实现方式就不过多介绍,有兴趣的可以了解下业内第一个多运行的开源实践项目 Dapr。

今日好文推荐

左耳朵耗子:从“打工人”到技术创业者,我是如何作死的

研发效能度量引发的血案

禁止热饭公司曾克扣前员工加班工资并索赔14万;腾讯再投500亿助力共同富裕;程序员被划为新生代农民工 | Q资讯

PHP没你想的那么差


InfoQ 写作平台欢迎所有热爱技术、热爱创作、热爱分享的内容创作者入驻!

还有更多超值活动等你来!

扫描下方二维码

填写申请,成为作者

开启你的创作之路吧~

点个在看少个 bug

0 人点赞