一、设计升维原则
描述：思考问题要站在更高的维度，尽可能全面，而解决问题可以降维，根据项目阶段，客观环境，选择性实施。
建议：
- 全面考虑：在设计初期，考虑系统的长期发展和扩展性，包括未来的业务增长、技术演进等。
- 逐步实施：根据项目的实际情况，逐步实现设计方案，避免一次性投入过大。
二、最小依赖原则
描述：强依赖->弱依赖->无依赖，依赖越多，风险越大，尤其是流量大、核心程度高的系统或接口。
建议：
- FMEA（失效模式与效应分析）：定期进行风险评估，识别潜在的失效点。
- 有罪推论：假设系统中的每一个组件都可能出错，设计时尽量减少对外部系统的依赖。
- 服务化：将系统拆分为多个微服务，每个服务只负责一小部分功能，减少相互之间的依赖。
三、隔离原则
描述：隔离是控制故障范围的有效手段，尤其是系统已初具规模流量。
建议：
- 代码隔离：将不同模块的代码分开，避免相互影响。
- 线程隔离：使用线程池或其他并发控制机制，隔离不同的任务。
- 进程隔离：将不同的服务部署在不同的进程中，避免一个进程的崩溃影响其他进程。
- 读写隔离：使用主从数据库分离，读写分离，提高系统的性能和稳定性。
- 数据隔离：将不同用户的数据分开存储，避免数据混杂。
四、分层原则
描述：解耦，领域、结构、代码清晰，可以有效降低混乱导致的bug出现概率，提升可维护性。
建议：
- 架构分层：不管是面向数据库编程的三层架构，还是面向领域驱动设计的四层架构，核心思想把代码圈定在合理的范围，避免的藕合导致的凌乱，提高代码的可维护性，降低迭代变更代码的复杂度，避免故障发生。
- 微服务架构：将系统拆分为多个小的服务，每个服务负责一部分功能，降低耦合度。
- API 层：提供统一的 API 接口，隐藏内部实现细节，提高系统的灵活性和可扩展性。
五、冗余原则
描述：通过对物理设施、网络、应用、容器、存储、缓存等冗余设计，降低单点故障对服务连续性和稳定性的影响。
建议：
- 多机房部署：在不同的机房部署相同的系统，实现地理冗余。
- 负载均衡：使用负载均衡器分发请求，避免单点故障。
- 备份与恢复：定期备份数据，设计灾难恢复计划。
- 双活架构：实现主备切换，确保系统在某个节点故障时仍能正常运行。
六、过载保护原则
描述：或手动或自动通过限流、熔断、降级等手段，保障核心服务可用，把影响降到最低。
建议：
- 限流：使用令牌桶、漏桶算法等技术限制请求速率，防止系统过载。
- 熔断：当某个服务不可用时，立即停止对该服务的调用，避免雪崩效应。
- 降级：在系统压力过大时，关闭非核心功能，确保核心服务的可用性。
七、可观测原则
描述：搭建可感（发现问题）、可控（诊断问题）、可恢复（恢复问题）。
建议：
- 日志监控：记录系统运行日志，实时监控系统状态。
- 性能监控：使用 APM（Application Performance Management）工具监控系统性能。
- 告警系统：设置合理的告警阈值，及时发现和处理问题。
- 故障演练：定期进行故障演练，提高系统的应对能力。
八、平衡原则
描述：高可用每多一个动作，都会显著增加系统研发投入和资源的成本，比如单元化。
建议：
- 成本效益分析：在设计高可用方案时，权衡成本和收益，避免过度设计。
- 渐进式优化：根据系统的实际需求和预算，逐步优化高可用性。
- 灵活调整：根据业务发展和市场变化，灵活调整高可用策略。
通过遵循这些原则，可以设计出更加健壮、可靠的高可用系统，确保在各种情况下都能提供稳定的服务。
