微服务理论的一个基石，那就是服务治理。

什么是服务治理呢？可以自我提问一下，Dubbo或者是Netflix的服务治理是怎么做的呢？

服务治理，这个词听起来非常的高大上，但实际上它是一个非常简单的理论。三两句话就能把这个微服务的服务治理跟大家讲明白。不过，另一方面，即使你是一个有过Spring Cloud这些框架使用经验的开发小伙伴，那你也未必了解服务治理，因为服务治理是微服务框架背后的一个流程，平常在工作当中会使用微服框架调用微服务，但可能并没有去花心思了解这个微服务框架，背后是怎么来运作。

本文就从服务治理来入手，看一下微服务的生命周期。

首先，我们先拿一个简单的微服务调用，跟大家举一个例子。

一个用户发起了一个服务调用请求，这个请求首先被路由到微服务的网关层。这个网关并不是指反向代理层，而是更往下层的一个业务层网关，我们可以把它理解成像spring cloud的gateway、zuul这类的微服务网关。网关会把用户请求路由到一个订单服务的服务集群当中，用户在系统里下了一个订单，那订单里面包含买了什么商品？那又要从订单微服务发几个调用，从商品服务当中获取这个商品的信息，锁定库存。

看着只是简单地发起一个远程调用，但它背后发生了什么呢？现在问题来了，这个订单服务是如何知道商品服务都有哪些可用的服务器列表的呢？

有个前提，订单到商品之间的这个访问请求，不会经过网关的转发，是订单服务直接发起请求到商品服务的。这个点对点之间，两个服务集群之间，它们是怎么互相知道对方有哪些服务器的呢，服务器地址是多少呢？它们是否是处于一个可用状态的呢？这是第一个问题。

第二个问题，假设我们现在做双十一的大促活动，这个商品服务有点扛不住压力。我想要对这个商品服务的服务集群做一个弹性的扩容肉缩容，有可能往集群当中加入新的服务器，也有可能去下线掉一台服务器。那在商品服务集群当中，这个服务器增加和删除操作，如何反映到订单微服务呢？订单微服务怎么知道哪些是新加入的商品服务的服务器，哪些商品服务的服务器已经被下线掉了呢？如果这些服务器的当前可用状态，没有同步到订单微服务那里，那订单微服务发起的远程调用，就可能是失败的。

处理这两个问题了，还有一个问题，如果商品微服务出现了一些网络故障，导致服务不可用，或者说发生了像outMemory这样的内存泄露异常，导致服务器宕机了，那这些服务器的信息，如何同步给订单服务？

以上的这三个问题，如果你能轻松地解决掉，那你就不用再往下看了，你已经算是玩转了服务治理，就是这么简单。

服务治理其实是核心概念，用一句话，它就是指，如何去维护一个当前可用的服务器的列表。那维护在哪里？那不管，反正要有这么一个地方来维护它，同时，这个列表要能反映出各个服务的当前状态，也就是服务器的下线、上线、增加、删除，都需要体现在这个服务列表上面，这就是服务治理。

接下来，我们再回到上面的问题上来。这个可用服务的列表它保存在哪里？

同样，还是一个订单服务和一个商品服务，不管微服务框架用的是Spring Cloud还是Dubbo，它都有这么一个组件，这个组件叫做注册中心。

微服务的可用服务列表，就维护在这个注册中心里面。比如，现在订单服务向注册中心发起一个注册请求。那么注册中心里面就会记录下订单服务server 1、2、3这三台服务器是处一个当前可用状态。同时，商品服务也可以发送这个服务注册中心请求，把自己的可用的服务器列表注册到注册中心里边。在订单服务里面，当它要发起一个调用之前，它要去跑一个定时的任务，这个定时任务做什么呢？它从注册中心里面获取所有的商品服务的可用服务器列表。这样的话，订单服务每一台服务器就知道应该向哪一台商品服务器来发送请求，发起一个服务调用了。

在这个过程当中，服务之前还会牵扯到一些负载均衡的策略。

简单地看，服务治理就是简单的三步走，注册服务，发现服务，然后发起调用。但是，事情可远不像大家想得这么简单。前面提到过，系统各个服务器都是有可能发生一些异常情况，也可能是是集群当中添加了服务器，也可能是删除服务器，那么，怎么做才能同步给注册中心呢？

我们接下来看一个非常完整的微服务的生命周期地图。

这次用服务生命周期中的行话，来跟大家描述一下。

第一个步骤，注册服务，它是整个服务治理当中的第一环。微服务将自己的服务器名称，IP与端口，以及当前的系统时间戳，还有微服务的服务名称等，一股脑的全部注册到注册中心里面。早来早注册，晚来晚注册，我注册完了，你再注册。这样一来，订单服务和商品服务都在服务注册中心当中存在了。

第二步，服务发现。各个微服务需要从注册中心，把已经注册的服务列表，给拉取到本地。这一个步骤，行话叫做服务发现。你看，换了一个叫法，这个逼格就立马上来了。服务发现，就是把服务注册中心中，各个微服务传上去的所有信息，一股脑的同步到各个服务的本地。在这里，也跟大家提个醒，现在主流的微服框架一般都是基于Client做服务发现的。也就是说，我的具体的client端，比如订单服务，它主动地从注册中心中，把服务列表信息给拉下来，而不是被动地等注册中心把信息推送给它。那为什么这样做？大家可以思考一下，后面会专门写个文章给大家解释一下。

当拿到了这个商品服务器的地址，一台服务器就可以发起一个服务调用了。那订单服务和商品服务之间打了一个照面，发起了一次调用，两次调用，三次调用都没问题。那如何才能知道这商品服务可以在以后一直不出故障呢？就要靠一个叫做服务续约和服务心跳的机制了。商品服务每隔一段时间，比如说15秒，20秒，商品服务会向注册中心发送一个心跳包（heart beat package）。这个心跳包实际上就是商品服务主动去上报自己的状态。

商品服务觉得自己状态还很好，我还能继续喝，就上报这种状态，注册中心就履行服务续约，把商品服务保留在服务列表中。当商品服务喝断片了，商品服务没有在固定时间内发送信息（心跳包）到服务注册中心，这种情况下，服务注册中心就会去做一个动作，叫做服务剔除。它会每隔一段时间跑一个批处理，这个批处理就会去查看你过去一段特定的时间内，比如说一分钟内，都没有收到服务的心跳包。那么这种情况，注册中心就会将商品服务，从自己的服务列表当中把它给删除掉，这就是服务剔除。

通常来讲，各种注册中心都会有一个开关，可以去手动地来控制服务剔除功能的开启和关闭。对于某些注册中心，它还有一些高级版的功能，比方说，你在短时间内服务剔除所踢下线的服务，达到了一个特定的比例，比如说80%的服务，都在过去一分钟之内被服务剔除掉了，当然这是属于一个非常极端的情况。注册中心看这个架势一看就不对啊，这会不会因为短暂的网络抖动导致服务暂时不可用呢？注册中心想，那我可不能把所有服务都踢下去。这种情况下，有些服务注册中心就会开启一个服务自保功能。一旦服务自保功能开启，服务剔除这个功能就会被暂时地关闭。

以上是一个被动踢出操作步骤，其实还可以做一个主动的剔除，服务自己把自己下线掉。下线指令由商品服务自己主动发起，并且发送到注册中心，告诉注册中心，您好，请把我下线掉。这是一个主动下线的操作，注册中心收到请求，就将商品服务从自己的服务列表当中删除掉。

这五个步骤就是微服务服务治理的全景图，它们共同构建了微服务的全生命周期。

看到这里，是不是感觉服务治理就是一个非常简单的概念！