1.4 服务治理的区分

我们基于应用开发、测试、运维的不同阶段，对服务治理的概念做一个区分，分为开发态、测试态 和 运行态 Ops。其中运行态又分为 发布台、安全态 和 高可用。

开发态服务治理

开发态服务治理的目标是为了提升研发效率，让开发更快捷，主要功能包括：

• 服务契约：统一管理微服务的 API 定义，包含接口的方法名，参数的具体类型结构，返回值的具体类型结构，接口描述等。
• 服务调试：在微服务开发和运行时快速地对某个接口进行调试，而不需要经过手动编写测试代码，也不需要关心网络打通流程。
• 服务Mock：当某个接口尚未开发完成时，可以通过配置 Mock 此接口的请求行为，返回预设的值，使得开发时不需要依赖于下游接口开发完成。
• 开发环境隔离：通过逻辑隔离的方式，为每一个正在开发的功能特性隔离出一个独立的环境，在低成本的前提下，划分出多个完整的独立环境，使得各功能特性的开发调试不会互相影响，提升开发迭代的效率。
• 端云互联：本地开发的微服务可以快速的访问云上的服务，云上的服务也能调用到本地开发的微服务。

测试态服务治理

测试态的微服务治理的目标是为了提升测试效率，让测试更快更准更全面。

• 服务压测：微服务上线前快速发起压测，迅速了解微服务的容量是否偏离基线，确保新版的性能。
• 自动化回归：通过自动化的方式进行回归测试，自动发起测试并自动比对结果进行验证，无需人工重复测试，保障业务代码逻辑的正确性。
• 流量录制：将线上流量录制下来，自动生成测试用例进行回归测试，通过真实的请求丰富测试覆盖率，保障业务代码逻辑的正确性。
• 流量回放：将录制好的流量重新运行，验证当前的业务运行结果是否和录制好的请求的结果匹配。

运行态服务治理

运行态通常又分为3个部分：发布态，安全态，高可用。

发布态

发布态通常解决的是业务发布的时候的流量治理问题，他主要包括：

• 无损下线：确保应用在发布、停止、扩容时，所有请求都不会被影响，确保微服务下线的过程中业务无损。
• 无损上线：应用刚启动时可能会存在一些资源未初始化完成、未预热完毕的情况，无损上线功能可以确保在这个场景下不影响业务
• 金丝雀发布：满足特定流量特征的请求才会进入微服务的灰度节点，通过小流量验证微服务新版的逻辑是否符合预期。
• 全链路灰度：一个迭代的多个应用同时发布，希望经过灰度的上游流量只能达到下游的灰度节点，确保灰度流量只在灰度环境中流转。

安全态

• 服务鉴权：保护敏感微服务，确保敏感服务只能被已授权的应用发起访问。
• 漏洞防护：常见的框架常常会漏洞，通过不升级框架的方式实现漏洞的防护。
• 配置鉴权：某些配置比较敏感，不希望任何微服务都有权限访问，控制只有受限的微服务才能访问。

高可用

• 限流：针对超过阈值的流量进行限流控制，保障机器和整体业务的稳定性。
• 降级：在资源有限的情况下，针对某些不重要的请求返回预设的降级结果，把有限的资源让给重要的请求。
• 熔断：客户端访问后端服务不可用的情况下，返回固定异常或预定义的结果，避免引起业务异常，甚至雪崩。
• 离群实例摘除：在单个服务提供者节点持续不可用的情况下，在消费者侧摘除这个异常节点，保障业务的高可用。
• 同可用区优先路由：微服务多可用区部署的情况下，确保流量优先在同一个可用区内流转，降低业务的整体时延。
• 就近容灾路由：当某个可用区发生故障，可以把流量尽快的切到正常的可用区，让业务以最快速度恢复。