当一个单体应用改造成多个微服务之后，在请求调用过程中往往会出现更多的问题，通信过程中的每一个环节都可能出现问题。而在出现问题之后，如果不加处理，还会出现链式反应导致服务雪崩。服务治理功能就是用来处理此类问题的。

从微服务的三个角色：注册中心、服务消费者、服务提供者进行考虑：

1、注册中心如何保障稳定性
注册中心主要是负责节点状态的维护，以及相应的变更探测与通知操作。一方面，注册中心自身的稳定性是十分重要的。另一方面，我们也不能完全依赖注册中心，需要时常进行类似注册中心完全宕机后微服务如何正常运行的故障演练。

2、服务消费者如何保障稳定性
一个请求失败了，最直接影响到的是服务消费者，那么在服务消费者这边，有什么可以做的呢？
(1)超时：如果调用一个接口，但迟迟没有返回响应的时候，我们往往需要设置一个超时时间，以防自己被远程调用拖死。超时时间的设置也是有讲究的，设置的太长起的作用就小，自己被拖垮的风险就大，设置的太短又有可能误判一些正常请求，大幅提升错误率。
(2)容错机制：请求调用永远不能保证成功，那么当请求失败时候，服务消费者可以如何进行容错呢？通常容错机制分为以下这些：FailTry(失败重试)、FailOver(失败切换)、FailFast(快速失败)。另外，还有很多形形色色的容错机制，大多是基于自己的业务特性定制的，主要是在重试上做文章，例如每次重试等待时间都呈指数增长等。

3、服务提供者如何保障稳定性
限流：限流就是限制服务请求流量，服务提供者可以根据自身情况(容量)给请求设置一个阈值，当超过这个阈值后就丢弃请求，这样就保证了自身服务的正常运行。
限流更多的起到一种保障的作用，但如果服务提供者已经出现问题了，这时候该怎么办呢？
这时候就会出现两种状况。一是本身代码有bug，这时候一方面需要服务消费者做好熔断降级等操作，一方面服务提供者这边结合DevOps需要有快速回滚到上一个正确版本的能力。
更多的时候，我们可能仅仅碰到了与代码无强关联的单机故障，一个简单粗暴的办法就是自动重启。例如观察到某个接口的平均耗时超出了正常范围一定程度，就将该实例进行自动重启。当然自动重启需要有很多注意事项，例如重启时间是否放在晚上，以及自动重启引起的与上述节点摘除一样的问题，都需要考虑和处理。