如果应用的设计是无状态的,那么应用比较容易进行水平扩展。实际生产环境是:应用无状态、配置文件有状态。
访问量大,资源充足,可考虑拆分。几种主要的拆分情况:
进程内服务—>单机远程服务—>集群手动注册服务—>自动注册和发现服务—>服务的分组/隔离/路由—>服务治理(限流/黑白名单)
消息队列用来解耦一些不需要同步调用的服务,或者订阅一些自己系统关心的变化。使用消息队列可以实现服务解耦(一对多消费)、异步处理、流量削峰/缓冲等。
订单分库分表一般按照订单ID进行拆分,如果要查询某个用户的订单列表,则需要聚合多个表的数据后才能返回,这样会导致订单表的读性能很低。此时需要对订单表进行异构,异构一套用户订单表,按照用户ID进行分库分表。
另外,还需要考虑对订单数据进行归档处理,以提升服务的性能和稳定性。
如商品详情页,因为数据来源太多,影响服务稳定性的因素就非常多。因此,最好的办法就是把使用到的数据进行异构存储,形成数据闭环,基本步骤如下:
这种方式的好处是数据闭环,任何依赖系统出问题了,还是能正常工作,只是更新会有积压,但是不影响前端展示。
另外,如果一次需要多个数据,那么可以考虑使用HashTag机制把相关的数据聚合到一个实例,如在展示商品详情页时需要使用商品基本信息”p:productId:”和商品规格参数信息”d:productId:”,此时就可以使用冒号中间的productId作为数据分片的Key,这样相同productId的商品相关数据就在同一个实例。
对于兜底数据或者异常数据,不应该让其缓存,否则用户会在很长一段时间里看到这些数据。
改串行为并行。
对于高可用服务,很重要的一个设计就是降级开关,在设计降级开关时,主要依据如下思路:
限流的目的是防止恶意请求流量、恶意攻击,或者放置流量超出系统峰值。可以考虑如下思路:
原则是限制流量穿透到后端薄弱的应用层。
对于一个大型应用,切流量是非常重要的,比如多机房环境下某个机房挂了,或者某个机架挂了,或者某台服务器挂了,都需要切流量,可以使用如下手段进行切换:
版本化的目的是实现可审计、可追溯,并且可回滚。当程序或者数据出错,如果有版本化机制,那么久可以通过回滚恢复到最近一个正确的版本,比如事务回滚、代码库回滚、部署版本回滚、数据版本回滚、静态资源版本回滚等。通过回滚机制可以保证系统在某些场景下的高可用。
例如防止重复支付、重复扣减内存等。
一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果的函数。
复用流程系统,提供个性化的流程服务。
在设计交易订单系统时,会存在正向状态(待付款、待发货、已发货、完成)和逆向状态(取消、退款)等,正向状态和逆向状态应该根据系统的特征来决定要不要分离存储。状态设计时应有状态轨迹,方便用户跟踪当前订单的轨迹并记录相关日志,万一出问题时可回溯问题。
设计后台系统时,考虑效果的可预览、可反馈。
对于有些重要的后台功能需要设计审批流,比如调整价格,并对操作进行日志记录,从而保证操作可追溯、可审计。
系统发展的最初阶段就应该有文档库(设计架构、设计思想、数据字典/业务流程、现有问题),业务代码合特殊需求都要有注释。
包括代码和人员的备份。代码主要提交到代码仓库进行管理和备份,代码仓库至少应该具备多版本的功能。人员备份指的是一个系统至少应该有两名开发人员是了解的。
系统设计不仅需要考虑实现业务功能,还要保证系统高并发、高可用、高可靠等。同时还应考虑系统容量规划(流量、容量等)、SLA指定(吞吐量、响应时间、可用性、降级方案等)、监控报警(机器负载、响应时间、可用率等)、应急预案(容灾、降级、限流、隔离、切流量、可回滚等)。
出处:http://blog.csdn.net/foreverling/article/details/77917174
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞4
添加新评论0 条评论