Istio从入门到精通—— 服务治理的形态
服务治理的形态
通常认为,服务治理的演变至少经过了以下三种形态。
一、第1种形态:治理逻辑和业务代码耦合
在微服务化的过程中,服务拆分后,基本的业务连通都成了问题。如下图
服务调用方的微服务怎么找到对端的服务实例?怎么选择一个对端实例发出请求,等等,都需要业务开发者写代码来实现。
这种方式简单,对外部依赖少,但存在大量重复的代码。微服务越多,重复的代码越多,维护便越难。而且,业务代码和治理逻辑耦合导致维护困难,不管是对治理逻辑的全局升级,还是对局部业务的升级,都要修改同一段代码。
二、第2种形态:治理逻辑和业务代码解释
在解决第 1 种形态的问题时,我们很容易想到的方案,是把治理的公共逻辑抽象成一个公共库,让所有微服务都使用这个公共库;还可以把这些公共库构成一个通用的开发框架 SDK,使用这种 SDK 开发的业务代码天然包括这些治理能力,如下图:
SDK 模式虽然在代码上解耦了业务和治理逻辑,但业务代码和 SDK 还要在一起编译,业务代码和治理逻辑还在一个进程内。这就导致业务代码必须和 SDK 基于同一种语言,即语言绑定,例如 Spring Cloud 等大部分治理框架都基于 Java,因此也只适用于 Java 开发的服务。
另外,SDK 自身升级会导致基于这个 SDK 开发的所有业务代码重新编译、测试和上线。这时,即使业务逻辑没有改变,也要求用户的每个服务都升级,导致额外的工作量增加和上线变更的业务风险,这对用户来说很不方便。
此外,SDK 对开发人员来说有较高的学习门槛,虽然各种 SDK 都声明开箱即用,但如果只是因为需要治理逻辑,就让开发人员放弃自己熟悉的内容去学习一套新的语言和开发框架,大概率会让其难以接受。
三、第3种形态:治理逻辑和业务进程解耦
为了解决 SDK 模式耦合的问题,我们需要进一步解耦,把治理逻辑彻底从用户的业务进程中剥离出来,形成如下图所示:
显然,在这种形态下,用户的业务代码和治理逻辑都以独立的进程存在,两者的代码和运行都无耦合。该方式与开发语言无关,开发者可以自己选择开发语言和开发框架,对一个应用中的多个服务甚至可以使用不同的语言开发。
另外,业务代码和治理逻辑的升级也互相独立,对治理逻辑的升级在理论上完全不影响业务代码,在业务没有变化时,无须重新编译和升级。
在对已存在的系统进行服务治理时,只需将其部署在运行了这些应用代理的平台上,无须对原服务做任何修改。在对老系统进行微服务化改造时,采用这种方式可以渐进式改造,微服务化的和未微服务化的服务可以互相访问,并且应用统一的治理策略。