1.4 服务治理的区分
我们基于应用开发、测试、运维的不同阶段,对服务治理的概念做一个区分,分为开发态、测试态 和 运行态 Ops。其中运行态又分为 发布台、安全态 和 高可用。
开发态服务治理
开发态服务治理的目标是为了提升研发效率,让开发更快捷,主要功能包括:
- 服务契约:统一管理微服务的 API 定义,包含接口的方法名,参数的具体类型结构,返回值的具体类型结构,接口描述等。
- 服务调试:在微服务开发和运行时快速地对某个接口进行调试,而不需要经过手动编写测试代码,也不需要关心网络打通流程。
- 服务Mock:当某个接口尚未开发完成时,可以通过配置 Mock 此接口的请求行为,返回预设的值,使得开发时不需要依赖于下游接口开发完成。
- 开发环境隔离:通过逻辑隔离的方式,为每一个正在开发的功能特性隔离出一个独立的环境,在低成本的前提下,划分出多个完整的独立环境,使得各功能特性的开发调试不会互相影响,提升开发迭代的效率。
- 端云互联:本地开发的微服务可以快速的访问云上的服务,云上的服务也能调用到本地开发的微服务。
测试态服务治理
测试态的微服务治理的目标是为了提升测试效率,让测试更快更准更全面。
- 服务压测:微服务上线前快速发起压测,迅速了解微服务的容量是否偏离基线,确保新版的性能。
- 自动化回归:通过自动化的方式进行回归测试,自动发起测试并自动比对结果进行验证,无需人工重复测试,保障业务代码逻辑的正确性。
- 流量录制:将线上流量录制下来,自动生成测试用例进行回归测试,通过真实的请求丰富测试覆盖率,保障业务代码逻辑的正确性。
- 流量回放:将录制好的流量重新运行,验证当前的业务运行结果是否和录制好的请求的结果匹配。
运行态服务治理
运行态通常又分为3个部分:发布态,安全态,高可用。
发布态
发布态通常解决的是业务发布的时候的流量治理问题,他主要包括:
- 无损下线:确保应用在发布、停止、扩容时,所有请求都不会被影响,确保微服务下线的过程中业务无损。
- 无损上线:应用刚启动时可能会存在一些资源未初始化完成、未预热完毕的情况,无损上线功能可以确保在这个场景下不影响业务
- 金丝雀发布:满足特定流量特征的请求才会进入微服务的灰度节点,通过小流量验证微服务新版的逻辑是否符合预期。
- 全链路灰度:一个迭代的多个应用同时发布,希望经过灰度的上游流量只能达到下游的灰度节点,确保灰度流量只在灰度环境中流转。
安全态
- 服务鉴权:保护敏感微服务,确保敏感服务只能被已授权的应用发起访问。
- 漏洞防护:常见的框架常常会漏洞,通过不升级框架的方式实现漏洞的防护。
- 配置鉴权:某些配置比较敏感,不希望任何微服务都有权限访问,控制只有受限的微服务才能访问。
高可用
- 限流:针对超过阈值的流量进行限流控制,保障机器和整体业务的稳定性。
- 降级:在资源有限的情况下,针对某些不重要的请求返回预设的降级结果,把有限的资源让给重要的请求。
- 熔断:客户端访问后端服务不可用的情况下,返回固定异常或预定义的结果,避免引起业务异常,甚至雪崩。
- 离群实例摘除:在单个服务提供者节点持续不可用的情况下,在消费者侧摘除这个异常节点,保障业务的高可用。
- 同可用区优先路由:微服务多可用区部署的情况下,确保流量优先在同一个可用区内流转,降低业务的整体时延。
- 就近容灾路由:当某个可用区发生故障,可以把流量尽快的切到正常的可用区,让业务以最快速度恢复。