微服务改造中，挑战最大的就是拆分之后的稳定性保障，拆分之后链路复杂、故障点众多，需要一套体系化的稳定性保障机制。
1、稳定性保障的目标
微服务稳定性保障需要从事前、事中和事后全方位进行考虑。微服务架构下，应用程序、依赖服务、网络、硬件等都有可能出现故障，稳定性设计和保障的具体目标如下。
故障预防，尽可能减少故障的产生，绝大多数稳定性问题和稳定性故障发生都有一定的诱因，并且一般是在多种拦截手段均失灵的情况下故障才会发生，如果我们在故障发生前制定完备的稳定性保障措施，可以最大限度地减少稳定性故障的发生。
故障快速定位，完全不出故障的业务是不存在的，关键是出故障时能够快速发现故障，只有及时发现，才能在最短时间内采取相应的解决措施。
故障快速止损，发生故障后第一时间要进行业务止损，恢复业务的正常运行，故障深层次的具体原因可以事后再分析和复盘解决。
2、稳定性保障的6个维度
系统故障点很多，稳定性保障就是对故障点进行管理的过程。可以从故障点管理的角度将整个稳定性设计和保障分为如下隔离、冗余、容灾容错、变更管理、时间相关故障管理与运维友好6个维度。
- 隔离
稳定性设计的第一个原则就是“隔离”，通过各种隔离机制，将核心服务之前的故障点隔离出去，保证核心服务的可用性。
隔离机制的指导原则是将变和不变、重要和非重要区分开来，变更是稳定性故障的最主要的来源，将容易发生变化的部分从核心服务和核心流程中剥离开来，减少核心部分的变更，可以保障核心系统的稳定性。隔离机制的一大手段就是解耦，通过解耦可以把核心服务和非核心服务隔离开来，同时核心服务访问非核心服务时，通过熔断、超时和重试等机制，最大限度地保障非核心服务故障不会影响整体的稳定性。
- 冗余
通过服务级别、机器级别、集群级别、机房级别等多种维度的冗余，我们可以保证：即便核心服务出问题，也可以通过相应的流量切换策略，将流量切到冗余节点上，保证业务不受影响。
为了尽量避免冗余同时失效的情况，冗余副本之间需要相互独立，完全对等，不能相互依赖，机房内副本跨交换机部署（此时一般也能保证跨机柜），如果有多机房冗余的情况，各机房独立，不能有完全相同的依赖。
- 容灾容错
稳定性设计的第三个原则是“容灾容错”，通过构建多维度的容灾容错体系，保证系统面对异常输入时，仍然能够提高稳定的输出能力。
服务可以通过降级和限流，减少突发大流量对系统的冲击，保证系统稳定输出，为了保证降级和限流操作的即时性，系统需要支持配置的动态修改和生效。
- 变更管理
绝大部分稳定性故障都是由变更引起，系统如果长时间没有任何变更，很少会有稳定性问题，因此服务稳定性保障的关键一环是严把变更这一关，保证变更质量。
针对变更，需要制定完善的变更规范，变更时严格按照规范进行，再小的变更都可能会产生稳定性隐患，因此变更时一定要加强稳定性意识，变更的每一步操作都要进行各项监控项检查，如果出现问题立即进行回滚。
- 时间相关故障管理
服务没有变更时，有一类故障很少发生并且很难发现，就是随时间变化而产生的ID越界和溢出，这类故障平常测试时很难发现，并且发生时会对整个系统产生很大的影响。
- 运维友好
为了实现运维友好的系统设计，系统需要将故障分析和定位时涉及的所有相关信息监控起来，构建完善的监控闭环，对系统层、服务层、接口层、业务层等维度进行监控收集和告警。为了减少系统的稳定性隐患，微服务架构设计中尽量遵循简单的设计原则，从业务的真实需求出发，避免纯粹从技术角度出发的高大上技术方案，如果不是业务的核心功能，必要时可以进行一定的折中和裁剪，尽量保证系统的简单和简洁性。
