支付宝架构师眼中的高并发架构——阅读笔记04

原文链接：https://mp.weixin.qq.com/s/g0hUrgVZZ8iv3cDCxDZxpw

业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。 

高并发相关的业务，需要进行并发的测试，通过大量的数据分析评估出整个架构可以支撑的并发量。

场景中的定时领取是一个高并发的业务，像秒杀活动用户会在到点的时间涌入，DB瞬间就接受到一记暴击，hold不住就会宕机，然后影响整个业务；

 

大型网站要很好支撑高并发，这是需要长期的规划设计 

 

在初期就需要把系统进行分层，在发展过程中把核心业务进行拆分成模块单元，根据需求进行分布式部署，可以进行独立团队维护开发。

 

• • 分层

    • 将系统在横向维度上切分成几个部分，每个部门负责一部分相对简单并比较单一的职责，然后通过上层对下层的依赖和调度组成一个完整的系统

    • 比如把电商系统分成：应用层，服务层，数据层。(具体分多少个层次根据自己的业务场景)

    • 应用层：网站首页，用户中心，商品中心，购物车，红包业务，活动中心等，负责具体业务和视图展示

    • 服务层：订单服务，用户管理服务，红包服务，商品服务等，为应用层提供服务支持

    • 数据层：关系数据库，nosql数据库 等，提供数据存储查询服务

    • 分层架构是逻辑上的，在物理部署上可以部署在同一台物理机器上，但是随着网站业务的发展，必然需要对已经分层的模块分离部署，分别部署在不同的服务器上，使网站可以支撑更多用户访问

 

• • 分割

    • 在纵向方面对业务进行切分，将一块相对复杂的业务分割成不同的模块单元

    • 包装成高内聚低耦合的模块不仅有助于软件的开发维护，也便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展

    • 比如用户中心可以分割成：账户信息模块，订单模块，充值模块，提现模块，优惠券模块等

 

• 分布式

  • 分布式应用和服务,将分层或者分割后的业务分布式部署，独立的应用服务器，数据库，缓存服务器

  • 当业务达到一定用户量的时候，再进行服务器均衡负载，数据库，缓存主从集群

  • 分布式静态资源，比如：静态资源上传cdn

  • 分布式计算，比如：使用hadoop进行大数据的分布式计算

  • 分布式数据和存储,比如：各分布节点根据哈希算法或其他算法分散存储数据

 

对于用户访问集中的业务独立部署服务器，应用服务器，数据库，nosql数据库。 核心业务基本上需要搭建集群，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务， 服务器集群能够为相同的服务提供更多的并发支持，因此当有更多的用户访问时，只需要向集群中加入新的机器即可, 另外可以实现当其中的某台服务器发生故障时，可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上，因此可以提高系统的可用性

 在高并发业务中如果涉及到数据库操作，主要压力都是在数据库服务器上面，虽然使用主从分离，但是数据库操作都是在主库上操作，单台数据库服务器连接池允许的最大连接数量是有限的 

高并发业务接口多数都是进行业务数据的查询，如：商品列表，商品信息，用户信息，红包信息等，这些数据都是不会经常变化，并且持久化在数据库中

 

高并发的情况下直接连接从库做查询操作，多台从库服务器也抗不住这么大量的连接请求数（前面说过，单台数据库服务器允许的最大连接数量是有限的）

 

• SOA面向服务架构设计

• 微服务更细粒度服务化，一系列的独立的服务共同组成系统

 

使用服务化思维，将核心业务或者通用的业务功能抽离成服务独立部署，对外提供接口的方式提供功能。

 

最理想化的设计是可以把一个复杂的系统抽离成多个服务，共同组成系统的业务，优点：松耦合，高可用性，高伸缩性，易维护。

 

通过面向服务化设计，独立服务器部署，均衡负载，数据库集群，可以让服务支撑更高的并发

当高并发业务所在的服务器出现宕机的时候，需要有备用服务器进行快速的替代，在应用服务器压力大的时候可以快速添加机器到集群中，所以我们就需要有备用机器可以随时待命。 最理想的方式是可以通过自动化监控服务器资源消耗来进行报警，自动切换降级方案，自动的进行服务器替换和添加操作等，通过自动化可以减少人工的操作的成本，而且可以快速操作，避免人为操作上面的失误。

转载于:https://www.cnblogs.com/liusx/p/11040925.html