Istio从入门到精通—— 服务治理的形态

服务治理的形态

  通常认为，服务治理的演变至少经过了以下三种形态。

一、第1种形态：治理逻辑和业务代码耦合

  在微服务化的过程中，服务拆分后，基本的业务连通都成了问题。如下图

  服务调用方的微服务怎么找到对端的服务实例？怎么选择一个对端实例发出请求，等等，都需要业务开发者写代码来实现。

  这种方式简单，对外部依赖少，但存在大量重复的代码。微服务越多，重复的代码越多，维护便越难。而且，业务代码和治理逻辑耦合导致维护困难，不管是对治理逻辑的全局升级，还是对局部业务的升级，都要修改同一段代码。

二、第2种形态：治理逻辑和业务代码解释

  在解决第 1 种形态的问题时，我们很容易想到的方案，是把治理的公共逻辑抽象成一个公共库，让所有微服务都使用这个公共库；还可以把这些公共库构成一个通用的开发框架 SDK，使用这种 SDK 开发的业务代码天然包括这些治理能力，如下图：

  SDK 模式虽然在代码上解耦了业务和治理逻辑，但业务代码和 SDK 还要在一起编译，业务代码和治理逻辑还在一个进程内。这就导致业务代码必须和 SDK 基于同一种语言，即语言绑定，例如 Spring Cloud 等大部分治理框架都基于 Java，因此也只适用于 Java 开发的服务。

  另外，SDK 自身升级会导致基于这个 SDK 开发的所有业务代码重新编译、测试和上线。这时，即使业务逻辑没有改变，也要求用户的每个服务都升级，导致额外的工作量增加和上线变更的业务风险，这对用户来说很不方便。

  此外，SDK 对开发人员来说有较高的学习门槛，虽然各种 SDK 都声明开箱即用，但如果只是因为需要治理逻辑，就让开发人员放弃自己熟悉的内容去学习一套新的语言和开发框架，大概率会让其难以接受。

三、第3种形态：治理逻辑和业务进程解耦

  为了解决 SDK 模式耦合的问题，我们需要进一步解耦，把治理逻辑彻底从用户的业务进程中剥离出来，形成如下图所示：

  显然，在这种形态下，用户的业务代码和治理逻辑都以独立的进程存在，两者的代码和运行都无耦合。该方式与开发语言无关，开发者可以自己选择开发语言和开发框架，对一个应用中的多个服务甚至可以使用不同的语言开发。

  另外，业务代码和治理逻辑的升级也互相独立，对治理逻辑的升级在理论上完全不影响业务代码，在业务没有变化时，无须重新编译和升级。

  在对已存在的系统进行服务治理时，只需将其部署在运行了这些应用代理的平台上，无须对原服务做任何修改。在对老系统进行微服务化改造时，采用这种方式可以渐进式改造，微服务化的和未微服务化的服务可以互相访问，并且应用统一的治理策略。