网站排名西安,合肥网站建设策划方案,推广网站推荐,2018年网站建设培训会发言高并发原则
无状态
如果设计的应用是无状态的#xff0c;那么应用比较容易进行水平扩展。实际生产环境可能是这样的#xff1a;应用无状态#xff0c;配置文件有状态。比如#xff0c;不同的机房需要读取不同的数据源#xff0c;此时#xff0c;就需要通过配置文件或配…高并发原则
无状态
如果设计的应用是无状态的那么应用比较容易进行水平扩展。实际生产环境可能是这样的应用无状态配置文件有状态。比如不同的机房需要读取不同的数据源此时就需要通过配置文件或配置中心指定。
拆分
做一个大而全的系统还是按功能模块拆分系统这个需要根据环境进行权衡。
京东秒杀系统访问量是非常大的而且投入的资源还是蛮充足的在这种情况下就可以考虑按功能拆分系统。
拆分主要有如下几种情况
系统维度读写维度AOP维度模块维度
消息队列
消息队列是用来解耦一些不需要同步调用的服务或者订阅一些自己系统关心的变化。
使用消息队列可以实现服务解耦(一对多消费)、异步处理、流量削峰/缓冲等。
大流量缓冲
电商搞大促时系统流量会高于正常流量的几倍甚至几十倍此时就要进行一些特殊的设计来保证系统平稳度过这段时期。
扣减库存 交易订单系统
数据异构
订单分库分表一般按照订单ID进行分如果要查询某个用户的订单列表则需要聚合多个表的数据后才能返回这样会导致订单表的读性能很低。此时需要对订单表进行异构异构一套用户订单表按照用户ID进行分库分表。另外还需要考虑对历史订单数据进行归档处理以提升服务的性能和稳定性。
数据来源太多影响服务稳定性的因素就非常多了。因此最好的办法是把使用到的数据进行异构存储形成数据闭环基本步骤如下
数据异构通过如MQ机制接收数据变更然后原子化存储到合适的存储引擎如Redis或持久化KV存储。数据聚合这步是可选的数据异构的目的是把数据从多个数据源拿过来数据聚合的目的是把这些数据做个聚合这样前端就可以一个调用拿到所有数据此步骤一般存储到KV存储中。前端展示前端通过一次或少量几次调用拿到所需要的数据。
缓存银弹 并发化 如果串行获取那么需要60ms。 如果并发化获取则需要30ms,能提升一倍的性能。
高可用原则
降级
高可用服务很重要的一个设计就是降级开关在设计降级开关时主要依据如下思路
开关集中化管理通过推送机制把开关推送到各个应用 可降级的多级读服务比如服务调用降级为只读本地缓存、只读分布式缓存、只读默认降级数据 开关前置化如架构是Nginx→Tomcat,可以将开关前置到Nginx接入层 业务降级 当高并发流量来袭在电商系统大促设计时保障用户能下单、能支付是核心要求并保障数据最终一致性即可。这样就可以把一些同步调用改成异步调用优先处理高优先级数据或特殊特征的数据合理分配进入系统的流量以保障系统可用
限流
限流的目的是防止恶意请求流量、恶意攻击或者防止流量超出系统峰值。 可以考虑如下思路
恶意请求流量只访问到cache。对于穿透到后端应用的流量可以考虑使用Nginx的limit模块处理。对于恶意IP可以使用nginx deny进行屏蔽。
原则是限制流量穿透到后端薄弱的应用层。
切流量
切流量是非常重要的比如多机房环境下某个机房挂了或者某个机架挂了或者某台服务器挂了都需要切流量。
DNS:切换机房入口。HttpDNS:主要APP场景下在客户端分配好流量入口绕过运营商LocalDNS并实现更精准流量调度。LVS/HaProxy:切换故障的Nginx接入层。Nginx:切换故障的应用层。
可回滚
版本化的目的是实现可审计可追溯并且可回滚。当程序或数据出错时如果有版本化机制那么就可以通过回滚恢复到最近一个正确的版本比如事务回滚、代码库回滚、部署版本回滚、数据版本回滚、静态资源版本回滚等。通过回滚机制可保证系统某些场景下的高可用。
业务设计原则
防重设计
结算页需要考虑重复提交还有如下单扣减库存时需要防止重复扣减库存。解决方案可以考虑防重key、防重表。而有些场景如重复支付是因为有的电商网站同时支持微信支付、京东支付渠道不一样是无法防止重复支付的。但是在系统设计时需要将支付的每笔情况记录下来。
幂等设计
在交易系统中经常会用到消息而现有消息中间件基本不保证不发生重复消息的消费。因此需要业务系统在重复消息消费时进行幂等处理。还有在使用第三方支付时第三方支付会进行异步回调也要考虑做好回调的幂等处理。
流程可定义
如果接触过保险业务就会发现不同保险的理赔服务是不一样的。我们在系统设计时就设计了一套理赔流程服务。而承保流程和理赔流程是分离的在需要时进行关联从而可以复用一些理赔流程并提供个性化的理赔流程。
状态与状态机
在设计交易订单系统时会存在正向状态(待付款、待发货、已发货、完成)和逆向状态(取消、退款)等正向状态和逆向状态应该根据系统的特征来决定要不要分离存储。状态设计时应有状态轨迹方便用户跟踪当前订单的轨迹并记录相关日志万一出问题时可回溯问题。
另外还有订单状态的变迁比如待支付、已支付待发货、待收货、完成的迁移。要考虑要不要使用状态机来驱动状态的变更和后续流程节点操作尤其当状态很多的时候使用状态机能更好地控制状态迁移。
后台系统操作可反馈
很多场景都需要反馈比如修改了某些内容后想预览看看最终效果即想得到一些反馈
还有一些是在规则系统中希望看到这些规则在系统数据下的反馈。
因此在设计后台系统时需考虑效果的可预览、可反馈。
后台系统审批化
对于有些重要的后台功能需要设计审批流比如调整价格并对操作进行日志记录从而保证操作可追溯、可审计。
文档和注释
一些系统是完全没有文档、代码没有注释的完全是人传人。这将导致后来人接手很痛苦而且对有些代码是完全不敢改动的比如有些代码完全是因为业务的一些特殊情况而写的可以说没有注释是完全不懂为什么那么做的。
因此在一个系统发展的一开始就应该有文档库(设计架构、设计思想、数据字典/业务流程、现有问题),业务代码和特殊需求都要有注释。
可以使用TOGAF企业架构设计。
备份
包括代码和人员。
代码主要提交到代码仓库进行管理和备份代码仓库应该至少具备多版本的功能。
人员备份指的是一个系统至少应该有两名开发人员是了解的即使其中一名离职了也不会出现新人接手之后手忙脚乱事故频发的状况。
还有一些是“核心人员”,写着系统的核心代码被认为是“不可替代的”,这种情况也是尽可能地让他带一名兄弟一起开发核心代码(业务系统),即使离职也还是可以努力一下克服困难。
