1.3.2 治理方式的改变

一个运转良好的系统是不需要治理的，只有出现问题时才需要治理。以环境问题来说，环境需要治理可能是因为受到了污染，或者生态不平衡。微服务需要治理也一样是因为要解决相应的问题。例如服务间彼此不认识，需要服务注册和服务发现；服务性能或调用出现异常，需要观察；服务的请求过载，需要进行流量管理，等等。

传统的方式是通过引入微服务框架实现治理，即引入上面提到的类库。我们还以Spring Cloud为例，它是一个强大的微服务开发框架，提供了很多具有服务治理能力的组件，具体如下。

● Eureka：服务注册与发现。

● Zuul：请求路由和网关。

● Ribbon：负载均衡。

● Hystrix：熔断、容错管理。

框架几乎可以满足我们所有的需求，但本质上它还是以类库方式运行的。和上面提到的重试的例子类似，让系统具有这些治理能力需要我们在代码或配置层面引入它们，并打包部署。要想使用这些组件需要付出一定的学习成本，同时牵扯一部分维护精力。对于引入服务治理，传统的做法是：引入功能，整合（修改代码或配置），维护。

在云原生环境下，服务治理能力会尽可能地交由基础设施去实现。例如，我们将应用容器化，并交给Kubernetes这样的编排工具去管理后，有关服务注册和发现的问题就迎刃而解了。我们会为每一个服务添加一个名为Service的对象，它会为应用自动分配一个虚拟IP地址（VIP），用来在集群内进行访问。服务之间只需要通过Service对象的名称就可以访问，服务发现由Kubernetes的DNS服务负责。同时，Service对象后面可以对接多个应用实例（Pod），配合kube-proxy实现负载均衡。这些工作都不需要对应用做任何代码层面的改动，即对应用透明。我们的关注点也会变成如何定义Service对象，如何合理选择服务的暴露方式等。

当然，弊端也会在某些情况下出现。应用部分迁移到了云端，这些交由Kubernetes集群管理的服务需要和存量系统进行交互，打通它们的访问会带来一定的技术困难，需要花费精力去解决。