微服务治理的思考
在分布式系统， 特别是采用微服务架构中存在诸多服务， 它们之间存在着复杂的调用和依赖关系， 我们需要一个框架对如下方面来进行统一管理
-
服务注册
服务提供方将服务注册到集中的服务注册中心 -
服务发现
管理和更新服务的状态和信息， 以供服务消费方检索并使用这些服务 -
服务诊断
记录每个服务的调用日志，并自动生成调用链， 基于调用链进行自动的故障分析支持 -
服务升降级和扩展
在服务负载上升自动扩容, 在负载过高自动降级 -
服务安全管理
对服务请求的认证, 授权检查和安全审查, 以及帐号的管理 -
服务监控
对服务在系统层面,应用层面和业务层面进行全面的监控和度量, 并根据度量数据进行自动的参数调整, 触发扩容, 熔断及报警
早在2006年时, IBM对于服务治理要点就进行了总结：
- 服务定义（服务的范围、接口和边界）
- 服务部署生命周期（各个生命周期阶段）
- 服务版本治理（包括兼容性）
- 服务迁移（启用和退役）
- 服务注册中心（依赖关系）
- 服务消息模型（规范数据模型）
- 服务监视（进行问题确定）
- 服务所有权（企业组织）
- 服务测试（重复测试）
- 服务安全（包括可接受的保护范围）
以当前流行的服务治理框架 Spring Cloud 为例, 它就包含如下机制来支持对服务的治理
- 分布式和版本控制的配置管理
- 服务注册和发现
- 服务路由
- 服务间调用
- 负载均衡
- 熔断机制
- 全局锁
- 领导者选举和集群状态管理
- 分布式消息
我比较关注的重点是度量 metrics , 在服务治理中, 基于度量的设计和实现是重中之重
- 服务注册和发现
服务活着还是死去，健康状态如何
- 微服务接口管理
既要灵活，又要稳定的，要从用量，性能，错误三方面进行度量监控
- 微服务之间的调用和依赖关系管理
对服务与其依赖服务绘制出调用和依赖关系图，做好分流，限流和断流
-
微服务的部署和配置管理
微服务的生死和更改全在一念之间，这个一念就是度量数据所引发的反应 -
微服务的智能诊断，度量, 审计和分析
日志，调用链，健康检查，安全扫描，度量仪表盘和告警系统是为微服务的保驾护航的"天眼系统"
让我们看看这些看微服务架构的演化
1） 原始的负载均衡器加微服务方案
v1
2） 增加了 API 网关和服务注册，服务发现机制
v2
3）增加了对 metrics 和 log 的收集，分析，监控，并独立出 Auth Service 和 Config Service
v3
随着 sitemesh , k8s 技术的成熟，基于公有云和企业内部的私有云，还有 v4, v5, ....
架构的演化总是随着客户需求的改变，技术的发展不断的迭代着，“任重而道远，吾将上下而求索”.
