课程名称：海量数据高并发场景，构建Go+ES8企业级搜索微服务
课程章节：5-2
课程讲师：少林码僧
课程内容：
★架构设计原则
避免过度设计
避免超过实际需求
提升可扩展性，要在业务量还小，刚上线的时候就
缩短实现周期节省成本（快速交付）
为什么要避免过度设计
实现成本和维护成本都高，弹性差限制了可扩展性
脱离当前阶段的实际需求，多数过度设计都是为以后的业务做准备，但是和当前需求差距甚远，浪费大量的人力成本和硬件资源
影响发布计划，高成本低收益
优先使用成熟的技术
没有经过充分验证的技术会踩坑
学习成本高，实施周期长，解决问题更困难
应当以求稳、求快、求低成本为目标
可扩展原则
可扩展性的本质
表象是应对不断变化的业务
设计合理的模块关系来控制系统的复杂度
AKF扩展立方体
X轴：水平扩展，通过复制实例，负载均衡分配流量，分摊整体压力；适用于产品的初期阶段，架构简单，实施速度快，研发成本低，但是对于有状态的服务来说不太适用，比如mysql主从服务就是有状态的
Y轴：根据服务或资源扩展，也是微服务架构演进的思想;适用于业务逻辑复杂，团队规模打的场景；故障的隔离性好、部署快、沟通效率高，实现成本也高。
Z轴：根据查询或者计算结果进行拆分；适用于大型分布式系统，有并发的压力，X轴和Y轴扩展都难以解决的问题;扩展性强，架构复杂，实现成本高，通常要保持一致性。
高可用设计原则
首先要明确一点，系统的故障不是概率性事件，要重视起来
故障发生前，要考虑如何避免。比如，验收压测，服务器资源评估，多层验收
故障发生时，要考虑怎么做故障转移：故障发生时候，可对服务进行禁用、限流、熔断，其本质就是争取故障解决时间，同时又不至于服务彻底崩溃。要优先保证核心服务不崩溃，对出问题的服务器进行隔离、镜像保存事故状态。
故障发生后，需要做好复盘总结。故障总结会并非推锅批斗会。
可回滚，确定一个安全的版本，并能快速回滚到该位置，但是要通知上下游的依赖方，必要时会一起回滚
可禁用，要给功能做“开关”，必要时能在不发版的情况下，快速对功能做出限制
限流，如果是由于高流量导致的系统问题，要在问题解决钱，对服务进行限流，保持最低的服务状态
降级，系统出问题的时候，要保证系统核心服务的可用，非核心系统可用暂时做一些限流的操作，比如秒杀活动时，大量的流量涌入对核心的mysql集群造成巨大压力，偏偏这时候缓存redis出现一些问题，就要对秒杀活动所在的服务进行降级，对用户返回一些友好的提示，避免核心mysql服务挂掉，从而全局崩溃
熔断。在通过远程数据交互的时候，某一服务出现了响应时间过长甚至崩溃，在一定积累后，要对该服务标记为熔断，不再调用该服务，直到该服务正常后，再进行调用。比如5秒20次调用失败，就会启动熔断机制。
隔离
控制故障影响范围，减少服务之间的影响
自动化驱动原则
70%的生产事故源于部署变更
几乎任何重复性工作都应该自动化
课程收获:
学习微服务设计架构的一些原则，主要提倡在不影响功能的情况下，架构应该越简单越好，架构应该是可扩展性强，可以不断演化来适应不同时期的要求。