高并发系统技术实战经验总结

架构设计三个思维

合适即可

选择适合当前现状的，而不是追求最好的。合适也就是适应当前业务的要求是首位的，不要追求完美与过度设计。

针对合适原则，我们有几个考虑方向，人力资源、业务需求、公司资源几个角度考虑。

比如当前开发人员只有2个，那么能用单体就用单体架构，微服务都不需要用。

业务需求就是满足低频次的数据写入和读取，那么直接读数据库就好，缓存也不需要。

简单原则

依赖系统、组件越多，就越有可能某个组件出故障。

尽量减少服务调用链路 微服务架构已经不是什么新鲜事了，一次请求依赖几十个服务也不是没有可能，我们需要做的就是保证尽量少的依赖关系，模块之间的依赖关系应尽量减少，避免过多的依赖链条。

这样可以降低修改一个模块对其他模块造成的影响，提高系统的稳定性和可维护性。

在面对多种设计选择时，优先选择简单的解决方案。简单的解决方案往往更易于理解和实现，并且更不容易出错。

演化原则

唯一不变的就是变化，所有的系统，都不是一开始就是这样设计的，而是一步步演变来的。

迭代思维在架构设计中的应用可以体现在多个方面：

1. 渐进式完善系统：架构设计不必一开始就完全确定所有细节，而是可以先设计一个初步的架构，然后通过迭代不断优化和完善。

2. 快速验证想法：通过迭代，可以快速验证不同的架构想法和解决方案，从而找到最合适的方案。

3. 及时反馈和调整：迭代过程中可以及时获取用户和利益相关者的反馈，从而及时调整架构设计，保证系统的实际需求和预期一致。

系统背景

业务背景

某大型促销活动系统，展示不同的活动页面，属于CPU密集型服务，读多写少，主要提供了页面数据获取。

（针对于高并发写，有机会的话，下次再说吧。）

指标评估

系统用户数 假设注册用户1亿人。 活跃用户数 日活按照注册用户的10%，有1000w人。 目标用户数 促销活动，只针对部分用户生效，可能我们目标是覆盖到100w人。 并发用户数 100w人是我们期望覆盖的用户数量，中间会产生一些折损，而且这部分人也不会同一时间访问我们的系统。我们假设并发用户数为10w人。

因此，我们估算指标如下： 峰值QPS10w+，平均RT：200-300ms

设计思路

扩展能力

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

垂直扩展

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

水平扩展

第二类就是水平扩展方案，不用更厉害的硬件，而使用更多的服务器，来构建成一个分布式集群，以此提升整体能力。

水平扩展其实也是随着互联网应用场景必备的解决方案，因为你没法预估有多少人来访问你的系统，或者在一些促销活动时，会有多少倍的流量增加。

简单来说，假设在4c8g（