服务治理主要涉及到

  • 服务关键程度
  • 服务依赖关系
  • 服务发现


服务关键程度和服务的依赖关系

我们先看看服务关键程度和服务的依赖关系。
关于服务关键程度，主要是要我们梳理和定义服务的重要程度。这不是使用技术可以完成的，它需要细致地管理对业务的理解，才能定义出架构中各个服务的重要程度。

然后，我们还要梳理出服务间的依赖关系，这点也非常重要。我们常说，“没有依赖，就没有伤害”。这句话的意思就是说，服务间的依赖是一件很易碎的事。依赖越多，依赖越复杂，我们的系统就越易碎。因为依赖关系就像“铁锁连环”一样，一个服务的问题很容易出现一条链上的问题。因此，传统的 SOA 希望通过 ESB 来解决服务间的依赖关系，这也是为什么微服务中希望服务间是没有依赖的，而让上层或是前端业务来整合这些个后台服务。

但是要真正做到服务无依赖，我认为还是比较有困难的，总是会有一些公有服务会被依赖。我们只能是降低服务依赖的深度和广度，从而让管理更为简单和简洁。在这一点上，以 Spring Boot 为首的微服务开发框架就开了一个好头。

微服务是服务依赖最优解的上限(没有依赖)，而服务依赖的下限是千万不要有依赖环。
如果系统架构中有服务依赖环，那么表明你的架构设计是错误的。循环依赖有很多的副作用，最大的问题是这是一种极强的耦合，会导致服务部署相当复杂和难解，而且会导致无穷尽的递归故障和一些你意想不到的问题。解决服务依赖环的方案一般是，依赖倒置的设计模式。在分布式架构上，你可以使用一个第三方的服务来解决这个事。比如，通过订阅或发布消息到一个消息中间件，或是把其中的依赖关系抽到一个第三方的服务中，然后由这个第三方的服务来调用这些原本循环依赖的服务。

服务的依赖关系是可以通过技术的手段来发现的，这其中，Zipkin是一个很不错的服务调用跟踪系统，它是通过 Google Dapper这篇论文来实现的。这个工具可以帮你梳理服务的依赖关系，以及了解各个服务的性能。在梳理完服务的重要程度和服务依赖关系之后，我们就相当于知道了整个架构的全局。就好像我们得到了一张城市地图，在这张地图上可以看到城市的关键设施，以及城市的主干道。再加上相关的监控，我们就可以看到城市各条道路上的工作和拥堵情况。这对于我们整个分布式架构是非常非常关键的。

参考：https://xie.infoq.cn/article/fd415110fbefe11b12b1d127f

服务状态和生命周期的管理

有了上面这张地图后，我们还需要有一个服务发现的中间件，这个中间件是非常非常关键的。因为这个“架构城市”是非常动态的，有的服务会新加进来，有的会离开，有的会增加更多的实例，有的会减少，有的服务在维护过程中（发布、伸缩等），所以我们需要有一个服务注册中心，来知道这么几个事。

整个架构中有多少种服务？
这些服务的版本是什么样的？
每个服务的实例数有多少个，它们的状态是什么样的?
每个服务的状态是什么样的？是在部署中，运行中，故障中，升级中，还是在回滚中，伸缩中，或者是在下线中……
这个服务注册中心有点像我们系统运维同学说的 CMDB 这样的东西，它也是非常之关键的，因为没有它，我们将无法知道这些服务运作的状态和情况。有了这些服务的状态和运行情况之后，你就需要对这些服务的生命周期进行管理了。服务的生命周期通常会有以下几个状态：

  • Provision，代表在供应一个新的服务；
  • Ready，表示启动成功了；
  • Run，表示通过了服务健康检查；
  • Update，表示在升级中；
  • Rollback，表示在回滚中；
  • Scale，表示正在伸缩中（可以有 Scale-in 和 Scale-out 两种）；
  • Destroy，表示在销毁中；Failed，表示失败状态。