微服务架构
微服务架构的最⼤好处是它可以提升开发效率和系统整体的稳定性：
- 开发和部署相对简单：单个微服务的功能可以更快地更改，因为可以独⽴部署，影响范围更
⼩，启动和调试单个微服务的时间成本相⽐于单体应⽤也⼤⼤减少。 - 横向扩展简单：根据业务的⾼峰低⾕周期快速的横向扩展⾮常简单，因为单个微服务通常很
⼩，可以随着系统整体负载的变化更快地启动和停⽌。 - 架构升级灵活：单个微服务的内部架构可以迅速升级，因为微服务之间松散耦合的，只⾯向
定义好的通讯接⼝进⾏编程。这使开发团队能够基于⾃身的技术背景和偏好灵活选择，⽽不
会直接影响其他应⽤程序、服务或团队。 - 更好的容错性：微服务之间可以实现更好的故障隔离，单个服务内的内存泄露等故障不容易
影响其他服务，相⽐单体应⽤⼀个组件故障会拖垮整个系统
微服务开发实施过程中常⻅的问题：
- 服务之间使⽤远程调⽤进⾏通讯，这⽐进程内的直接调⽤复杂很多。由于通讯链路的复杂性，
可能会出现很多不确定的问题，会出现远程调⽤不可⽤或者延迟较⾼的情况，开发⼈员需要
能够处理这些偶发问题，避免影响业务。 - 随着业务的发展，微服务之间的拓扑图开始变得复杂，排查问题变得困难，搭建完整的开发
测试环境成本也越来越⼤。 - 当功能涉及到多个微服务模块时，迭代时需要谨慎地协调多个开发团队的迭代排期，才能保
证迭代能够按时交付，达到敏捷开发的效果。
微服务治理在云原生下的挑战
微服务治理概念的区分
开发态服务治理
开发态服务治理的⽬标是为了提升研发效率，让开发更快捷，主要功能包括：
- 服务契约：业务开服能够清晰的了解应用定义了哪些接口、每个接口的参数、以及接口的业
务说明；便于开发者迅速了解应用。 - 服务调试：在微服务开发和运行时快速地对某个接口进行调试，而不需要经过手动编写测试
代码，也不需要关心网络打通流程。 - 服务 Mock：当某个接口尚未开发完成时，可以通过配置 Mock 此接口的请求行为，返回预
设的值，使得开发时不需要依赖于下游接口开发完成。 - 开发环境隔离：通过逻辑隔离的方式，为每一个正在开发的功能特性隔离出一个独立的环境，
在低成本的前提下，划分出多个完整的独立环境，使得各功能特性的开发调试不会互相影响，
提升开发迭代的效率。 - 端云互联：本地开发的微服务可以快速的访问云上的服务，云上的服务也能调用到本地开发
的微服务
测试态服务治理
测试态的微服务治理的⽬标是为了提升测试效率，让测试更快更准更全⾯。
- 服务压测：微服务上线前快速发起压测，迅速了解微服务的容量是否偏离基线，确保新版的
性能。 - ⾃动化回归：通过自动化的方式进行回归测试，自动发起测试并自动比对结果进行验证，无
需人工重复测试，保障业务代码逻辑的正确性。 - 流量录制：将线上流量录制下来，自动生成测试用例进行回归测试，通过真实的请求丰富测
试覆盖率，保障业务代码逻辑的正确性。 - 流量回放：将录制好的流量重新运行，验证当前的业务运行结果是否和录制好的请求的结果
匹配。
运⾏态服务治理
运⾏态通常⼜分为 3 个部分：发布态，安全态，⾼可⽤。
发布态
发布态通常解决的是业务发布的时候的流量治理问题，他主要包括：
- ⽆损下线：确保应用在发布、停止、扩容时，所有请求都不会被影响，确保微服务下线的过
程中业务无损。 - ⽆损上线：应用刚启动时可能会存在一些资源未初始化完成、未预热完毕的情况，无损上线
功能可以确保在这个场景下不影响业务。 - ⾦丝雀发布：满足特定流量特征的请求才会进入微服务的灰度节点，通过小流量验证微服务
新版的逻辑是否符合预期。 - 全链路灰度：一个迭代的多个应用同时发布，希望经过灰度的上游流量只能达到下游的灰度
节点，确保灰度流量只在灰度环境中流转。
安全态
- 服务鉴权：保护敏感微服务，确保敏感服务只能被已授权的应用发起访问。
- 漏洞防护：开源框架通常会陆陆续续被发现许多漏洞，整体的升级成本很高，需要通过不升
级框架的⽅式实现漏洞的防护。 - 配置鉴权：某些配置⽐较敏感，不希望任何微服务都有权限访问，控制只有受限的微服务才
能访问
⾼可⽤
- 限流：针对超过阈值的流量进行限流控制，保障机器和整体业务的稳定性。
- 降级：在资源有限的情况下，针对某些不重要的请求返回预设的降级结果，把有限的资源让
给重要的请求。 - 熔断：客户端访问后端服务不可用的情况下，返回固定异常或预定义的结果，避免引起业务
异常，甚至雪崩。 - 离群实例摘除：在单个服务提供者节点持续不可用的情况下，在消费者侧摘除这个异常节点，
保障业务的高可用。 - 同可⽤区优先路由：微服务多可用区部署的情况下，确保流量优先在同一个可用区内流转，
降低业务的整体时延。 - 就近容灾路由：当某个可⽤区发⽣故障，可以把流量尽快的切到正常的可⽤区，让业务以最
快速度恢复
若有收获，就点个赞吧
0 人点赞
