一次事故暴露出的三个架构问题
在现代系统架构中，确保系统的高可用性和可靠性是至关重要的。本文通过一个实际案例，探讨系统架构设计中的几个关键概念：韧性（Resilience）、硬依赖（Hard Dependency）和服务降级（Service Degradation）。希望通过对这些概念的深入探讨，帮助读者更好地理解和应用这些原则，提升系统的整体稳定性和用户体验。
系统韧性指的是系统在遇到各种压力、突发事件或故障时，能够维持其功能和服务，并在受损后迅速恢复的能力。应用A在设计时没有考虑到应用K的服务可能会失败，缺乏足够的韧性。当应用K的服务不可用时，应用A应有应对措施，以确保核心功能的正常运行。服务降级（Service Degradation）
服务降级是指在系统压力过大、某些组件失效或外部依赖不可用时，通过限制或关闭某些非核心功能来保证核心服务的正常运行。在本案例中，当应用K的MFA无法发送邮件时，可以考虑进行服务降级，允许用户仅使用用户名和密码登录，暂时取消邮件验证功能。解决方案1. 减少硬依赖
为了解决硬依赖问题，系统应引入冗余和备用机制。例如，可以配置多个SMTP服务提供商，当主要的SMTP服务不可用时，自动切换到其他的备用服务。此外，MFA服务还可以考虑其他验证方式，如短信验证或基于移动应用的验证码。2. 提高系统韧性
应用A应设计为具备足够的韧性，能够应对外部依赖的失败。具体措施包括：
当应用K的MFA服务无法正常工作时，应用A可以实施服务降级策略，允许用户仅使用用户名和密码登录，暂时取消邮件验证功能。这种做法可以保证用户仍然能够访问系统的核心功能，而不会因为外部服务的不可用而完全中断。
案例介绍
应用A是一个商户管理后台，为商户提供查询交易的便利。应用A需要用户登录后才能使用。为了确保登录的安全性，应用A调用了应用K的多因素认证服务（MFA）。MFA在用户名和密码的基础上，通过邮件发送验证Token给用户，邮件使用了宇宙第一软件公司的SMTP服务。当该SMTP服务失败时，MFA无法发送邮件，导致应用A的登录失败。
- 应用K的MFA没有考虑SMTP服务失败的情况，存在硬依赖的问题。
- 应用A假设应用K的服务永远可用，没有设计足够的韧性。
- 当应用K无法发送邮件时，没有进行服务降级，导致用户无法登录。
有问题的架构
硬依赖问题（Hard Dependency）
硬依赖是指系统中某个组件必须依赖另一个特定组件，如果该组件失效，整个系统将无法正常运行。在本案例中，应用K的MFA对SMTP服务存在硬依赖，当SMTP服务失败时，MFA无法正常工作，从而导致应用A的登录失败。
系统韧性指的是系统在遇到各种压力、突发事件或故障时，能够维持其功能和服务，并在受损后迅速恢复的能力。应用A在设计时没有考虑到应用K的服务可能会失败，缺乏足够的韧性。当应用K的服务不可用时，应用A应有应对措施，以确保核心功能的正常运行。服务降级（Service Degradation）
服务降级是指在系统压力过大、某些组件失效或外部依赖不可用时，通过限制或关闭某些非核心功能来保证核心服务的正常运行。在本案例中，当应用K的MFA无法发送邮件时，可以考虑进行服务降级，允许用户仅使用用户名和密码登录，暂时取消邮件验证功能。解决方案1. 减少硬依赖
为了解决硬依赖问题，系统应引入冗余和备用机制。例如，可以配置多个SMTP服务提供商，当主要的SMTP服务不可用时，自动切换到其他的备用服务。此外，MFA服务还可以考虑其他验证方式，如短信验证或基于移动应用的验证码。2. 提高系统韧性
应用A应设计为具备足够的韧性，能够应对外部依赖的失败。具体措施包括：
- 实现服务降级机制，当外部服务不可用时，提供简化的登录方式。
- 增加故障检测与自动恢复功能，确保在发现问题时能够快速响应和处理。
- 定期进行压力测试和故障演练，验证系统在各种异常情况下的表现。
当应用K的MFA服务无法正常工作时，应用A可以实施服务降级策略，允许用户仅使用用户名和密码登录，暂时取消邮件验证功能。这种做法可以保证用户仍然能够访问系统的核心功能，而不会因为外部服务的不可用而完全中断。
优化之后的架构
结论通过本文的案例分析，我们可以看到在系统架构设计中，考虑到硬依赖、系统韧性和服务降级的重要性。这些原则不仅有助于提高系统的可靠性和可用性，还能在关键时刻为用户提供更好的体验。希望本文能为系统架构师和开发人员提供有价值的参考，帮助他们设计出更稳定和健壮的系统。----------------------------------
PS：推荐右军专栏《20年职业50个思考与洞察》