网站运维人员经常会遇到一个问题，就是随着业务访问量的不断增加，需要不断调整服务器配置和数量以应对业务系统宕机，那么如何根据业务系统访问量的变化调整服务器架构呢？1.系统架构演进过程-初始阶段架构初始阶段的小系统应用、数据库、文件等资源都在一台服务器上俗称LAMP特性：应用、数据库等所有资源，和文件在一台服务器上。说明：通常服务器操作系统使用linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用Mysql，各种免费开源软件的集合和一台便宜的服务器就可以开始系统的开发。2、系统架构的演变——应用服务和数据服务的分离并没有持续多久。发现随着系统访问量再次增加，高峰期webserver机器的压力会上升到一个比较高的水平。这时候，我们开始考虑增加一个webserver。特点：应用程序、数据库和文件部署在不同的资源上。问题描述：数据量增加，单台服务器性能和存储空间不足。需要将应用与数据分离，并发处理能力和数据存储空间得到极大提升。3、系统架构的演进——使用缓存提升性能特点：将数据库中访问较为密集的一小部分数据存储在缓存服务器中，减少数据库访问次数，减轻数据库访问压力.说明：系统访问的特点遵循80/20法则，即80%的业务访问集中在20%的数据上。缓存分为本地缓存和远程分布式缓存。本地缓存访问速度更快，但缓存数据量有限。同时，与应用程序存在内存争用。4、系统架构的演进——使用应用服务器集群完成分库的工作后，数据库的压力降到一个比较低的水平，开始看访问量过上幸福生活每天翱翔。突然有一天，我发现访问系统的速度又开始变慢了。这时候先查了一下数据库，压力正常。然后查看了webserver，发现apache拦截了很多请求，应用服务器对每个请求也比较快。好像是因为请求量太大，需要排队，响应速度变慢。特点：多台服务器通过负载均衡同时对外提供服务，解决了单台服务器的处理能力和存储空间限制的问题。说明：利用集群是系统解决高并发、海量数据问题的常用方法。通过向集群中添加资源，提高系统的并发处理能力，使服务器的负载压力不再成为整个系统的瓶颈。5、系统架构的演进——数据库读写分离。在享受了一段时间系统访问量快速增长的快乐后，我发现系统又开始变慢了。这次是什么情况？查找后，发现数据库是写入更新的。这些操作中的一部分会严重争夺数据库连接资源，从而导致系统变慢。特点：多台服务器通过负载均衡同时对外提供服务，解决了单台服务器处理能力和存储空间受限的问题。说明：利用集群是系统解决高并发、海量数据问题的常用方法。通过向集群中添加资源，服务器的负载压力不再是整个系统的瓶颈。6、系统架构的演进-反向代理和CDN加速特性：CDN和反向代理用于加速系统访问。说明：为应对复杂的网络环境和不同地域用户的访问，通过CDN和反向代理加快用户访问速度，同时减轻后端服务器的负载压力。CDN和反向代理的基本原理是缓存。7、系统架构的演进——分布式文件系统和分布式数据库随着系统的不断运行，数据量开始大幅增加。这个时候发现分库之后的查询还是有点慢，于是开始按照分库的思路分表工作特点：数据库采用分布式数据库，文件系统采用分布式文件系统。说明：任何强大的单一服务器都无法满足大型系统不断增长的业务需求。随着业务的发展，数据库读写分离终将无法满足需求。需要使用分布式数据库和分布式文件系统来支持。分布式数据库是拆分系统数据库的最佳方式。只有在单表数据规模非常大的时候才会用到。数据库拆分比较常见的方式是业务分库，将不同的业务数据库部署在不同的物理服务器上。8.系统架构的演变——NoSQL和搜索引擎的使用特点：系统引入了NoSQL数据库和搜索引擎。说明：随着业务越来越复杂，对数据存储和检索的要求也越来越复杂。系统需要使用一些非关系型数据库如NoSQL和分库查询技术如搜索引擎。应用服务器通过统一的数据访问模块访问各种数据，免去了应用程序管理众多数据源的麻烦。9、系统架构演进史——业务拆分特点：系统按业务拆分改造，应用服务器按业务分工分别部署。说明：为了应对日益复杂的业务场景，通常采用分而治之的方式将整个系统业务划分为不同的产品线。应用程序之间的关系通过超链接建立，数据分发也可以通过消息队列进行。当然，更多的是通过访问同一个数据存储系统，形成一个关联的完整系统。垂直拆分：将一个大应用拆分成多个小应用。如果新业务比较独立，那就直接设计部署成一个独立的web应用系统。垂直拆分相对简单。通过业务梳理，可以剥离较少的相关业务。水平拆分：将复用的业务拆分出来，独立部署为分布式服务。新业务只需要调用这些分布式服务即可。横向拆分需要识别可复用业务，设计服务接口，规范服务依赖。10、系统架构演进史——分布式服务特点：将常用的应用模块提取出来，部署在分布式服务器上，供应用服务器以服务的方式调用，提高系统可用性调用。
