云时代架构”经典文章阅读感想十六
（支付宝架构师眼中的高并发架构）
经过这一学期的阅读，看到最多的一个名词就是高并发。
高并发高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中，如：秒杀活动，定时领取红包等。为了让业务可以流畅的运行并且给用户一个好的交互体验，我们需要根据业务场景预估达到的并发量等因素，来设计适合自己业务场景的高并发处理方案。
1.服务器架构
业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。
一个可以支持高并发的服务少不了好的服务器架构，需要有均衡负载，数据库需要主从集群，nosql缓存需要主从集群，静态文件需要上传cdn，这些都是能让业务程序流畅运行的强大后盾。
2.并发测试
高并发相关的业务，需要进行并发的测试，通过大量的数据分析评估出整个架构可以支撑的并发量。
测试高并发可以使用第三方服务器或者自己测试服务器，利用测试工具进行并发请求测试，分析测试数据得到可以支撑并发数量的评估，这个可以作为一个预警参考，俗话说知己自彼百战不殆。
第三方服务：
阿里云性能测试
并发测试工具：
Apache JMeter
Visual Studio性能负载测试
Microsoft Web Application Stress Tool
3.分层
将系统在横向维度上切分成几个部分，每个部门负责一部分相对简单并比较单一的职责，然后通过上层对下层的依赖和调度组成一个完整的系统
比如把电商系统分成：应用层，服务层，数据层。(具体分多少个层次根据自己的业务场景)
应用层：网站首页，用户中心，商品中心，购物车，红包业务，活动中心等，负责具体业务和视图展示
服务层：订单服务，用户管理服务，红包服务，商品服务等，为应用层提供服务支持
数据层：关系数据库，nosql数据库 等，提供数据存储查询服务
分层架构是逻辑上的，在物理部署上可以部署在同一台物理机器上，但是随着网站业务的发展，必然需要对已经分层的模块分离部署，分别部署在不同的服务器上，使网站可以支撑更多用户访问
4.分割
在纵向方面对业务进行切分，将一块相对复杂的业务分割成不同的模块单元
包装成高内聚低耦合的模块不仅有助于软件的开发维护，也便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展
比如用户中心可以分割成：账户信息模块，订单模块，充值模块，提现模块，优惠券模块等
5.分布式
分布式应用和服务,将分层或者分割后的业务分布式部署，独立的应用服务器，数据库，缓存服务器
当业务达到一定用户量的时候，再进行服务器均衡负载，数据库，缓存主从集群
分布式静态资源，比如：静态资源上传cdn
分布式计算，比如：使用hadoop进行大数据的分布式计算
分布式数据和存储,比如：各分布节点根据哈希算法或其他算法分散存储数据
6、集群
对于用户访问集中的业务独立部署服务器，应用服务器，数据库，nosql数据库。 核心业务基本上需要搭建集群，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务， 服务器集群能够为相同的服务提供更多的并发支持，因此当有更多的用户访问时，只需要向集群中加入新的机器即可, 另外可以实现当其中的某台服务器发生故障时，可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上，因此可以提高系统的可用性
7.异步
在高并发业务中如果涉及到数据库操作，主要压力都是在数据库服务器上面，虽然使用主从分离，但是数据库操作都是在主库上操作，单台数据库服务器连接池允许的最大连接数量是有限的
当连接数量达到最大值的时候，其他需要连接数据操作的请求就需要等待有空闲的连接，这样高并发的时候很多请求就会出现connection time out 的情况
缓存高并发业务接口多数都是进行业务数据的查询，如：商品列表，商品信息，用户信息，红包信息等，这些数据都是不会经常变化，并且持久化在数据库中
高并发的情况下直接连接从库做查询操作，多台从库服务器也抗不住这么大量的连接请求数（前面说过，单台数据库服务器允许的最大连接数量是有限的）
8.面向服务
SOA面向服务架构设计
微服务更细粒度服务化，一系列的独立的服务共同组成系统
使用服务化思维，将核心业务或者通用的业务功能抽离成服务独立部署，对外提供接口的方式提供功能。
最理想化的设计是可以把一个复杂的系统抽离成多个服务，共同组成系统的业务，优点：松耦合，高可用性，高伸缩性，易维护。
冗余，自动化
在阅读完这篇文章指后我才了解到软件架构师的强大之处，单单是解决高并发性的问题便能通过业务场景等反面进行架构设计。从8个方面进行架构设计。在今后的学习中还是应该提高对于软件工程方面的了解学习。