间件,这些中间件虽然不是直接体现在某个功能上,但是能够用来来协调各个服务之间,以及服务层与数据层之间的关系。例如上面提到的MQ服务能够提供消息广播服务,而Cache则能够提供缓存方案,以提高系统的性能。4架构体系按照以上的技术体系结构,这里给出了4种架构体系,这4种架构分别应对不同量级的需求,下面则分别来介绍下这几种架构方案。架构方案A方案A是比较简单的一种方案,由于该方案成本低廉,运维成本则几乎为0,因此该方案是项目初期推荐选择的方案。图4给出了该方案的架构图。图4架构方案A示意图通过图4能够看出本方案是非常简单的方案,因为架构简单,使得该方案非常容易维护,成本也非常低廉,但同时,该方案也无法支撑高并发的需求。下面给出了该方案的一些参数:支撑流量上限100W机房能够选择公有云服务,例如阿里云。也能够自购主机、自选IDC机房。存在的问题:IDC网络故障、IDC提供商响应不及时。能够优化方案:搭建配置服务器,使用IP直联的形式会一定程度上减少域名带来的问题。综上所诉,在项目刚开始阶段,用户流量不是很大的情况下,该方式还是比较实用的,性价比比较高的。架构方案B随着业务的发展,流量逐步达到了单机的极限,如果并发流量超过100W的时候,方案A就无法满足需求,而方案B则在A的基础上进行了扩充,使用集群来处理高并发的业务需求。图5给出了方案B的架构图。图5架构方案B示意图能够看出,方案B在方案A的基础之上得到了有效的改善,也由以前单机nginx改为LVS提供负载均衡服务,而服务层则是以集群的形式提供强劲的性能,数据库也做了主从模式的集群化架构方案。该方案主要有以下特点:支撑并发流量3000W~2亿机房最好自购主机、自选IDC机房,并搭建LNMP集群环境。引入MongoDB解决空间索引问题。订单分配系统,则是将LBS服务,分单服务以及redis坐标数据独立出来,形成订单分配系统独立维护。
全文预览
