支付宝架构师眼中的高并发架构——3

支付宝架构师眼中的高并发架构——3

面向服务

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