高并发体系技能实战经验总结

架构设计三个头脑

合适即可

选择得当当前现状的，而不是追求最好的。合适也就是顺应当前业务的要求是首位的，不要追求完美与过分设计。
针对合适原则，我们有几个思量方向，人力资源、业务需求、公司资源几个角度思量。
比如当前开发职员只有2个，那么能用单体就用单体架构，微服务都不需要用。
业务需求就是满足低频次的数据写入和读取，那么直接读数据库就好，缓存也不需要。
简单原则

依赖体系、组件越多，就越有可能某个组件出故障。
只管减少服务调用链路 微服务架构已经不是什么新鲜事了，一次哀求依赖几十个服务也不是没有可能，我们需要做的就是包管只管少的依赖关系，模块之间的依赖关系应只管减少，制止过多的依赖链条。
这样可以降低修改一个模块对其他模块造成的影响，进步体系的稳定性和可维护性。
在面对多种设计选择时，优先选择简单的解决方案。简单的解决方案往往更易于理解和实现，并且更不轻易堕落。
演化原则

唯一不变的就是变化，所有的体系，都不是一开始就是这样设计的，而是一步步演变来的。
迭代头脑在架构设计中的应用可以体现在多个方面：

• 渐进式完善体系：架构设计不必一开始就完全确定所有细节，而是可以先设计一个初步的架构，然后通过迭代不断优化和完善。
  
  
• 快速验证想法：通过迭代，可以快速验证不同的架构想法和解决方案，从而找到最合适的方案。
  
  
• 及时反馈和调整：迭代过程中可以及时获取用户和长处干系者的反馈，从而及时调整架构设计，包管体系的实际需求和预期同等。
  

体系背景

业务背景

某大型促销活动体系，展示不同的活动页面，属于CPU麋集型服务，读多写少，主要提供了页面数据获取。
（针对于高并发写，偶然机的话，下次再说吧。）
指标评估

体系用户数 假设注册用户1亿人。 活泼用户数 日活按照注册用户的10%，有1000w人。 目标用户数 促销活动，只针对部分用户生效，可能我们目标是覆盖到100w人。 并发用户数 100w人是我们期望覆盖的用户数目，中心会产生一些折损，而且这部分人也不会同一时间访问我们的体系。我们假设并发用户数为10w人。
因此，我们估算指标如下： 峰值QPS10w+，均匀RT：200-300ms
设计思路

扩展能力

设计思路的第一点，就是体系要具有扩展的能力，扩展又分为垂直和程度两种。
垂直扩展

一类是传统大型软件体系的技能方案，被称作垂直伸缩方案。所谓的垂直伸缩就是提升单台服务器的处置惩罚能力，比如用更多核的 CPU、更大的内存、更快的网卡、更多的磁盘构成一台服务器，从平凡服务器升级到小型机，从小型机提升到中型机，从中型机提升到大型机，从而使单台服务器的处置惩罚能力得到提升。通过这种手段提升体系的处置惩罚能力。
程度扩展

第二类就是程度扩展方案，不用更厉害的硬件，而使用更多的服务器，来构建成一个分布式集群，以此提升团体能力。
程度扩展实在也是随着互联网应用场景必备的解决方案，因为你没法预估有多少人来访问你的体系，或者在一些促销活动时，会有多少倍的流量增加。
简单来说，假设在4c8g（