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

打印 上一主题 下一主题

主题 1028|帖子 1028|积分 3084

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?立即注册

x
架构设计三个头脑

合适即可

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

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

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

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

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

  • 及时反馈和调整:迭代过程中可以及时获取用户和长处干系者的反馈,从而及时调整架构设计,包管体系的实际需求和预期同等。
体系背景

业务背景

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

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

扩展能力

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

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

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

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

南飓风

论坛元老
这个人很懒什么都没写!
快速回复 返回顶部 返回列表