大型网站架构的演进最开始都是由小及大慢慢演变过来的，任何一个好的架构都不是设计出来了，是颠末业务成长迭代而来的，这个不雅概念我是附和的。对付网站架构技术非常有兴趣，一直连续存眷学习架构技术，本次想通过大型网站技术成长历程，分解大型网站技术架构模式，深入分析大型互联网架构设计。这篇文章我们只存眷架构的演变历程。

通过电商业务为例，该系统的成果有用户模块【用户注册和打点】、商品模块【商品展示和打点】、交易模块【创建交易和打点】。通过图例分析一个最初从单台LAMP怎么成长到复杂的漫衍架构体系。

线上系统高可用参考指标：

2、架构演变历程 2.1. 第一阶段【单机构建网站】

网站措施用到的开源框架如maven+spring+struct+hibernate、maven+spring+springmvc+mybatis；网站初期，我们经常会用单机跑所有的措施和软件。凡是由app server 和DB server构成，如tomcat和mysq；最后通过JDBC进行数据库的连接和操纵。

一般5万pv到30万pv访谒量，，结合内核参数调优、web应用性能参数调优、数据库调优，根基上能够不变的运行。

2.2. 第二阶段【应用处事器与数据库疏散】

跟着网站的成长当访谒量逐渐增大，处事器的负载慢慢提高，系统的压力越来越大，响应速度越来越慢，这个时候对照明显的是数据库和应用互相影响，应用出问题了，数据库也很容易呈现问题，而数据库出问题的时候，应用也容易出问题。在处事器还没有超载的时候，我们应该提前做好筹备，提升网站的负载能力。假如我们代码层面已难以优化，在不提高单台机器的性能的情况下，将应用和数据库从物理上疏散，增加机器是一个不错的方法，不只可以有效地提高系统的负载能力，而且性价比高。此时我们可以把数据库、web处事器拆分隔来，这样不只提高了单台机器的负载能力，也提高了容灾能力。

跟着用户量的增大、对带宽需求的增大、对CPU措置惩罚惩罚能力的增大；不敷以融合所有用户的需求了，或者网站业务量的需求了。此处很少也不应该直接就对它做负载均衡式的扩展，因为数据同步很麻。所以我们架构扩展，不会上来就直接做负载均衡式的每一组组件当做一个整体来进行扩展，而是成果上切割 。这个时候技术上没有什么新的要求，但你发明确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。

2.3. 第三阶段【应用处事器负载均衡】

跟着访谒量继续增加，单台应用处事器已经无法满足需求了。假设数据库处事器没有压力，我们可以把应用处事器从一台酿成了两台甚至多台，把用户的请求分手到差此外处事器中，从而提高负载能力。此时我们应该选择一款合适的负载均衡产品，一般来讲keepalived共同上ipvsadm做负载均衡，可谓是神器。这一阶段是需要掌握更多根本常识的关键节点。以下可以使用DNS解析对用户请求做负载均衡：

需要注意：负载均衡产品的选择、负载均衡算法的选择、用户session连结的问题、应用占用资源的角度选择合理的处事器配置。
解决方案：按照以下技术特性选择适合业务的产品、技术。例如nginx+keepalived一台处事器、apache+tomcat一台处事器、mysql一台处事器。

三种负载均衡器的优错误谬误说明如下：摘自（互联网）
LVS的长处：
1、抗负载能力强、事情在第4层仅作分发之用，没有流量的孕育产生，这个特点也决定了它在负载均衡软件里的性能最强的；无流量，同时保证了均衡器IO的性能不会受到大流量的影响；
2、事情不变，自身有完整的双机热备方案，如LVS+Keepalived和LVS+Heartbeat；
3、应用范畴对照广，可以对所有应用做负载均衡；
4、配置性对照低，这是一个错误谬误也是一个长处，因为没有可太多配置的对象，所以并不需要太多接触，大大减少了酬报堕落的几率；
LVS的错误谬误：
1、软件自己不撑持正则措置惩罚惩罚，不能做消息疏散，这就凸显了Nginx/HAProxy+Keepalived的优势。
2、如果网站应用对照复杂，LVS/DR+Keepalived就对照庞大了，出格是后面有Windows Server应用的机器，实施及配置还有维护过程就对照麻烦，相对而言，Nginx/HAProxy+Keepalived就简单多了。