【金秋打卡】第8天 构建微服务设计架构知识体系--架构的设计原则

课程名称：海量数据高并发场景，构建Go+ES8企业级搜索微服务

课程章节：5-2

课程讲师：少林码僧

课程内容：

★架构设计原则

• 避免过度设计

  • 避免超过实际需求

  • 提升可扩展性，要在业务量还小，刚上线的时候就

  • 缩短实现周期节省成本（快速交付）

• 为什么要避免过度设计

1. 1. 实现成本和维护成本都高，弹性差限制了可扩展性

   2. 脱离当前阶段的实际需求，多数过度设计都是为以后的业务做准备，但是和当前需求差距甚远，浪费大量的人力成本和硬件资源

   3. 影响发布计划，高成本低收益            
      

• 优先使用成熟的技术

1. 1. 没有经过充分验证的技术会踩坑

   2. 学习成本高，实施周期长，解决问题更困难

   3. 应当以求稳、求快、求低成本为目标
      

• 可扩展原则

  • 可扩展性的本质

    • 表象是应对不断变化的业务

    • 设计合理的模块关系来控制系统的复杂度
      

  • AKF扩展立方体

    • X轴：水平扩展，通过复制实例，负载均衡分配流量，分摊整体压力；适用于产品的初期阶段，架构简单，实施速度快，研发成本低，但是对于有状态的服务来说不太适用，比如mysql主从服务就是有状态的

    • Y轴：根据服务或资源扩展，也是微服务架构演进的思想;适用于业务逻辑复杂，团队规模打的场景；故障的隔离性好、部署快、沟通效率高，实现成本也高。

    • Z轴：根据查询或者计算结果进行拆分；适用于大型分布式系统，有并发的压力，X轴和Y轴扩展都难以解决的问题;扩展性强，架构复杂，实现成本高，通常要保持一致性。
      

    • 
      

• 高可用设计原则

1. 1. 首先要明确一点，系统的故障不是概率性事件，要重视起来

   2. 故障发生前，要考虑如何避免。比如，验收压测，服务器资源评估，多层验收

   3. 故障发生时，要考虑怎么做故障转移：故障发生时候，可对服务进行禁用、限流、熔断，其本质就是争取故障解决时间，同时又不至于服务彻底崩溃。要优先保证核心服务不崩溃，对出问题的服务器进行隔离、镜像保存事故状态。

   4. 故障发生后，需要做好复盘总结。故障总结会并非推锅批斗会。

   5. 可回滚，确定一个安全的版本，并能快速回滚到该位置，但是要通知上下游的依赖方，必要时会一起回滚

   6. 可禁用，要给功能做“开关”，必要时能在不发版的情况下，快速对功能做出限制

   7. 限流，如果是由于高流量导致的系统问题，要在问题解决钱，对服务进行限流，保持最低的服务状态

   8. 降级，系统出问题的时候，要保证系统核心服务的可用，非核心系统可用暂时做一些限流的操作，比如秒杀活动时，大量的流量涌入对核心的mysql集群造成巨大压力，偏偏这时候缓存redis出现一些问题，就要对秒杀活动所在的服务进行降级，对用户返回一些友好的提示，避免核心mysql服务挂掉，从而全局崩溃

   9. 熔断。在通过远程数据交互的时候，某一服务出现了响应时间过长甚至崩溃，在一定积累后，要对该服务标记为熔断，不再调用该服务，直到该服务正常后，再进行调用。比如5秒20次调用失败，就会启动熔断机制。
      

• 隔离

  • 控制故障影响范围，减少服务之间的影响
    

• 自动化驱动原则

  • 70%的生产事故源于部署变更

  • 几乎任何重复性工作都应该自动化

课程收获:

学习微服务设计架构的一些原则，主要提倡在不影响功能的情况下，架构应该越简单越好，架构应该是可扩展性强，可以不断演化来适应不同时期的要求。