面向服务 n SOA面向服务架构设计 n 微服务更细粒度服务化,一系列的独立的服务共同组成系统 使用服务化思维,将核心业务或者通用的业务功能抽离成服务独立部署,对外提供接口的方式提供功能。 最理想化的设计是可以把一个复杂的系统抽离成多个服务,共同组成系统的业务,优点:松耦合,高可用性,高伸缩性,易维护。 通过面向服务化设计,独立服务器部署,均衡负载,数据库集群,可以让服务支撑更高的并发 n 服务例子: n 用户行为跟踪记录统计 n 说明: n 通过上报应用模块,操作事件,事件对象,等数据,记录用户的操作行为 n 比如:记录用户在某个商品模块,点击了某一件商品,或者浏览了某一件商品 n 背景: n 由于服务需要记录用户的各种操作行为,并且可以重复上报,准备接入服务的业务又是核心业务的用户行为跟踪,所以请求量很大,高峰期会产生大量并发请求。 n 架构: n nodejs WEB应用服务器均衡负载 n redis主从集群 n mysql主 n nodejs+express+ejs+redis+mysql n 服务端采用nodejs,nodejs是单进程(PM2根据cpu核数开启多个工作进程),采用事件驱动机制,适合I/O密集型业务,处理高并发能力强 n 业务设计: n 并发量大,所以不能直接入库,采用:异步同步数据,消息队列 n 请求接口上报数据,接口将上报数据push到redis的list队列中 n nodejs写入库脚本,循环pop redis list数据,将数据存储入库,并进行相关统计Update,无数据时sleep几秒 n 因为数据量会比较大,上报的数据表按天命名存储 n 接口: n 上报数据接口 n 统计查询接口 n 上线跟进: n 服务业务基本正常 n 每天的上报表有上千万的数据 冗余,自动化 当高并发业务所在的服务器出现宕机的时候,需要有备用服务器进行快速的替代,在应用服务器压力大的时候可以快速添加机器到集群中,所以我们就需要有备用机器可以随时待命。 最理想的方式是可以通过自动化监控服务器资源消耗来进行报警,自动切换降级方案,自动的进行服务器替换和添加操作等,通过自动化可以减少人工的操作的成本,而且可以快速操作,避免人为操作上面的失误。 n 冗余 n 数据库备份 n 备用服务器 n 自动化 n 自动化监控 n 自动化报警 n 自动化降级 通过GitLab事件,我们应该反思,做了备份数据并不代表就万无一失了,我们需要保证高可用性,首先备份是否正常进行,备份数据是否可用,需要我们进行定期的检查,或者自动化监控, 还有包括如何避免人为上的操作失误问题。(不过事件中gitlab的开放性姿态,积极的处理方式还是值得学习的) 总结 高并发架构是一个不断衍变的过程,冰洞三尺非一日之寒,长城筑成非一日之功 。打好基础架构方便以后的拓展,这点很重要。 转自:https://mp.weixin.qq.com/s/g0hUrgVZZ8iv3cDCxDZxpw |
|