什么是服务治理
对于程序员来说的话，把功能按照一定的设计进行开发上线之后，其实并不够，在未来的时间内，其实还需要做好功能的维护工作，而维护项目的成本远远高于开发出一个软件的成本。
- 对于功能开发起来期来说，如果前期的设计、编码等比较规范，且易维护，那么后期系统在迭代的时候维护成本就可以减少一定的成本。
对于互联网项目来说，一般提供的服务都是 7 * 24 不间断的服务。功能开发和功能维护变得更模糊。
操作系统的本质是解决软件治理问题，也就是多个软件可以在同一个物理上进行资源的操作和共享。
而服务治理的目标就是，除了软件治理外，如何保证这些如软件能够24小时不间断的提供服务。
主要的话就是如下几点 - 服务的变更：发布、升级与版本管理
- 服务的健康状况：日志、监控与报警
- 服务的故障处理：故障域与故障域案、故障排查与根本分析、过载保护与容量规划。
而从服务端整体架构看的话其实就是
服务治理通常来说包含 服务调度和流量调度。
服务关键程度和服务的依赖关系
针对于服务关键程度和服务的依赖关系，这个需要对业务系统的整体有把控力，了解主要业务流程涉及哪些系统，然后可以通过将重要的服务进行梳理出来，比如订单、支付、库存等业务可以进行抽取出来。以及对应的依赖管理，上下游关系，只有这样才可以一目了然了解各个系统之间的数据流程。
尽可能降低服务之间的依赖，可以提高系统的稳定性，因为依赖越多，复杂度越高，如果一个下游系统，全部上游系统都依赖，出现问题的话，那么就会出现多米诺骨牌效应。
并且要避免出现服务依赖成环。微服务是服务依赖最优解的上限，而服务依赖的下限是千万不要有依赖环
依赖环可能出现递归事故或者在项目发布的时候，没有办法解决兼容问题。而解决服务依赖环的关键就是依赖倒置原则，一般通过引入一个三方服务，比如消息队列等。
所以通过获取到服务整体依赖关系，就可以清楚知道如果出现故障可能影响的范围。
服务状态和生命周期的管理
对于一个分布式系统来说，服务实例可能会下线或者新增。所以我们需要一个注册中心来进行管理服务的状态。
- 整个系统有多少服务
- 服务的版本是什么
- 服务的实例数是多少
- 服务的状态，运行中，故障中，启动中，停机中等
服务生命周期包含如下
- Provision，供应一个新的服务
- Ready，启动成功
- Run，服务健康检查
- Update，升级中
- Rollback，回滚中
- Scale，伸缩中。
- Destory，销毁中
- Failed，失败
整个架构的版本管理
对于大多数公司来说，其实只是维护的一个系统的版本，而并没有维护一个上下游之间 系统的版本，比如订单系统是1.0 对应支付系统的 2.0，而如果没有整个架构的版本管理，如果出现上线问题后，那么只能通过一起回滚。而这种是非常麻烦和浪费人力。
所以最好的方式就是在系统的版本之上维护一个上一层的版本管理，这样就可以通过管理一个大的版本来进行维护系统。当出现问题时，就不需要只回滚来一部分机器而到另一部分没有回滚出现兼容问题，从而引发BUG。
资源/服务调度
服务和资源调度类似，主要有如下
- 服务状态的维持和拟合
- 服务的弹性伸缩和故障迁移
- 作业和应用调度
- 作业工作流编排
- 服务编排
小结
本篇主要介绍了服务治理和分布式系统服务调度相关的点，主要包括服务关键程度和服务依赖关系，服务的状态和服务生命周期管理以及整个架构版本的管理。
