具体以电子商务网站为例， 展示web应用的架构演变过程。
这个时候是一个web项目里包含了所有的模块，一个数据库里包含了所需要的所有表，这时候网站访问量增加时，首先遇到瓶颈的是应用服务器连接数，比如tomcat连接数不能无限增加，线程数上限受进程内存大小、CPU内核数等因素影响，当线程数到达一定数时候，线程上下文的切换对性能的损耗会越来越严重，响应会变慢，通过增加web应用服务器方式的横向扩展对架构影响最小，这时候架构会变成下面这样：
这时候随着网站访问量继续增加，继续增加应用服务器数量后发现数据库成了瓶颈，而数据库的最主要的瓶颈体现在两方面：
这时，根据业务特点，如果读写比差距不大，并且对数据一致性要求不是很高的情况下，数据库可以采用主从方式进行读写分离的方案，并且引入缓存机制来抗读流量。如果读写比差距很大或者对数据一致性要求高时，就不适合用读写分离方案，需要考虑业务的垂直拆分，这时期的系统架构图如下：
这时候仍然是垂直架构，所有业务集中在一个项目里。项目维护、快速迭代问题会越来越严重，单个模块的开发都需要发布整个项目，项目稳定性也受到很大挑战，这是需要考虑业务的垂直拆分，需要将一些大的模块单独拆出来，这时候的架构图如下：
这时候为了进一步提升用户体验，加速用户的网站访问速度，会使用CDN来缓存信息，用户会访问最近的CDN节点来提升访问速度。此时的架构图如下：
随着业务量增大，一些核心系统数据库单表数量达到几千万甚至亿级，这时候对该表的数据操作效率会大大降低，并且虽然有缓存来抗读的压力，但是对于大量的写操作和一些缓存miss的流量到达一定量时，单库的负荷也会到达极限，这时候需要将表拆分，一般直接采用分库分表，因为只做分表的话，单个库的连接瓶颈仍然无法解决。分库分表后的架构如下：
随着流量的进一步增大，这时候系统仍然会有瓶颈出现，以订单系统为例：单个机房的机器是有限的，不能一直新增下去，并且基于容灾的考虑，一般采用同城双机房的方式，机房之间用专线链接，同城跨机房质检的延时在几毫秒，此时的架构图如下：
由于数据库主库只能是在一个机房，所以仍然会有一半的数据库访问是跨机房的，虽然延时只有几毫秒，但是一个调用链里的数据库访问太多后，这个延时也会积少成多。其次这个架构还是没能解决数据库连接数瓶颈问题
从上面的架构图里能看到，流量从接入层按照路由规则（比如以用户ID来路由）路由到不同单元，每个单元内都是高内聚，包含了核心系统，数据层面的分片逻辑是与接入层路有逻辑一致，也解决了数据库连接的瓶颈问题，但是一些跨单元的调用是无法避免的，同时也有些无法拆分的业务需要放在中心单元，供所有其他单元调用。
作者|顶尖架构师栈
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。