阶段一、单机构建网站
网站的初期，我们常常会在单机上跑我们所有的程序和软件。此时我们利用一个容器，如tomcat、jetty、jboos，然后直策应用JSP/servlet技能，或者利用一些开源的框架如maven+spring+struct+hibernate、maven+spring+springmvc+mybatis；末了再选择一个数据库管理系统来存储数据，如mysql、sqlserver、oracle，然后通过JDBC进行数据库的连接和操作。
把以上的所有软件都装载同一台机器上，运用跑起来了，也算是一个小系统了。此时系统结果如下：
阶段二、运用做事器与数据库分离
随着网站的上线，访问量逐步上升，做事器的负载逐步提高，在做事器还没有超载的时候，我们该当就要做好准备，提升网站的负载能力。如果我们代码层面已难以优化，在不提高单台机器的性能的情形下，增加机器是一个不错的办法，不仅可以有效地提高系统的负载能力，而且性价比高。
增加的机器用来做什么呢？此时我们可以把数据库，web做事器拆分开来，这样不仅提高了单台机器的负载能力，也提高了容灾能力。
运用做事器与数据库分开后的架构如下图所示：
阶段三、运用做事器集群
随着访问量连续增加，单台运用做事器已经无法知足需求了。在假设数据库做事器没有压力的情形下，我们可以把运用做事器从一台变成了两台乃至多台，把用户的要求分散到不同的做事器中，从而提高负载能力。多台运用做事器之间没有直接的交互，他们都是依赖数据库各自对外供应做事。著名的做故障切换的软件有keepalived，keepalived是一个类似于layer3、4、7交流机制的软件，他不是某个详细软件故障切换的专属品，而是可以适用于各种软件的一款产品。keepalived合营上ipvsadm又可以做负载均衡，可谓是神器。
我们以增加了一台运用做事器为例，增加后的系统构造图如下：
系统演化到这里，将会涌现下面四个问题：
用户的要求由谁来转发到到详细的运用做事器有什么转发的算法运用做事器如何返回用户的要求用户如果每次访问到的做事器不一样，那么如何掩护session的同等性我们来看看办理问题的方案：
第一个问题即是负载均衡的问题，一样平常有5种办理方案：
1、http重定向。HTTP重定向便是运用层的要求转发。用户的要求实在已经到了HTTP重定向负载均衡做事器，做事器根据算法哀求用户重定向，用户收到重定向要求后，再次要求真正的集群
优点：大略。缺陷：性能较差。2、DNS域名解析负载均衡。DNS域名解析负载均衡便是在用户要求DNS做事器，获取域名对应的IP地址时，DNS做事器直接给出负载均衡后的做事器IP。
优点：交给DNS，不用我们去掩护负载均衡做事器。缺陷：当一个运用做事器挂了，不能及时关照DNS，而且DNS负载均衡的掌握权在域名做事商那里，网站无法做更多的改进和更强大的管理。3、反向代理做事器。在用户的要求到达反向代理做事器时（已经到达网站机房），由反向代理做事器根据算法转发到详细的做事器。常用的apache，nginx都可以充当反向代理做事器。
优点：支配大略。缺陷：代理做事器可能成为性能的瓶颈，特殊是一次上传大文件。4、IP层负载均衡。在要求到达负载均衡器后，负载均衡器通过修正要求的目的IP地址，从而实现要求的转发，做到负载均衡。
优点：性能更好。缺陷：负载均衡器的宽带成为瓶颈。5、数据链路层负载均衡。在要求到达负载均衡器后，负载均衡器通过修正要求的mac地址，从而做到负载均衡，与IP负载均衡不一样的是，当要求访问完做事器之后，直接返回客户。而无需再经由负载均衡器。
第二个问题即是集群调度算法问题，常见的调度算法有10种：
1、rr 轮询调度算法。顾名思义，轮询分发要求。
优点：实现大略缺陷：不考虑每台做事器的处理能力2、wrr 加权调度算法。我们给每个做事器设置权值weight，负载均衡调度器根据权值调度做事器，做事器被调用的次数跟权值成正比。
优点：考虑了做事器处理能力的不同3、sh 原地址散列：提取用户IP，根据散列函数得出一个key，再根据静态映射表，查处对应的value，即目标做事器IP。过目标机器超负荷，则返回空。
4、dh 目标地址散列：同上，只是现在提取的是目标地址的IP来做哈希。
优点：以上两种算法的都能实现同一个用户访问同一个做事器。5、lc 最少连接。优先把要求转发给连接数少的做事器。
优点：使得集群中各个做事器的负载更加均匀。6、wlc 加权最少连接。在lc的根本上，为每台做事器加上权值。算法为：（活动连接数256+非活动连接数）÷权重 ，打算出来的值小的做事器优先当选择。
优点：可以根据做事器的能力分配要求。7、sed 最短期望延迟。实在sed跟wlc类似，差异是不考虑非活动连接数。算法为：（活动连接数+1)256÷权重，同样打算出来的值小的做事器优先当选择。
8、nq 永不排队。改进的sed算法。我们想一下什么情形下才能“永不排队”，那便是做事器的连接数为0的时候，那么假如有做事器连接数为0，均衡器直接把要求转发给它，无需经由sed的打算。
9、LBLC 基于局部性的最少连接。均衡器根据要求的目的IP地址，找出该IP地址最近被利用的做事器，把要求转发之，若该做事器超载，最采取最少连接数算法。
10、LBLCR 带复制的基于局部性的最少连接。均衡器根据要求的目的IP地址，找出该IP地址最近利用的“做事器组”，把稳，并不是详细某个做事器，然后采取最少连接数从该组中挑出详细的某台做事器出来，把要求转发之。若该做事器超载，那么根据最少连接数算法，在集群的非本做事器组的做事器中，找出一台做事器出来，加入本做事器组，然后把要求转发之。
第三个问题是集群模式问题，一样平常3种办理方案：
1、NAT：负载均衡器吸收用户的要求，转发给详细做事器，做事器处理完要求返回给均衡器，均衡器再重新返回给用户。
2、DR：负载均衡器吸收用户的要求，转发给详细做事器，做事器出来玩要求后直接返回给用户。须要系统支持IP Tunneling协议，难以跨平台。
3、TUN：同上，但无需IP Tunneling协议，跨平台性好，大部分系统都可以支持。
第四个问题是session问题，一样平常有4种办理方案：
1、Session Sticky。session sticky便是把同一个用户在某一个会话中的要求，都分配到固定的某一台做事器中，这样我们就不须要办理跨做事器的session问题了，常见的算法有ip_hash法，即上面提到的两种散列算法。
优点：实现大略。缺陷：运用做事看重启则session消逝。2、Session Replication。session replication便是在集群中复制session，使得每个做事器都保存有全部用户的session数据。
优点：减轻负载均衡做事器的压力，不须要要实现ip_hasp算法来转发要求。缺陷：复制时宽带开销大，访问量大的话session占用内存大且摧残浪费蹂躏。3、Session数据集中存储：session数据集中存储便是利用数据库来存储session数据，实现了session和运用做事器的解耦。
优点：比较session replication的方案，集群间对付宽带和内存的压力减少了很多。缺陷：须要掩护存储session的数据库。4、Cookie Base：cookie base便是把session存在cookie中，有浏览器来见告运用做事器我的session是什么，同样实现了session和运用做事器的解耦。
优点：实现大略，基本免掩护。缺陷：cookie长度限定，安全性低，宽带花费。值得一提的是：
nginx目前支持的负载均衡算法有wrr、sh（支持同等性哈希）、fair（本人以为可以归结为lc）。但nginx作为均衡器的话，还可以一同作为静态资源做事器。
keepalived+ipvsadm比较强大，目前支持的算法有：rr、wrr、lc、wlc、lblc、sh、dh
keepalived支持集群模式有：NAT、DR、TUN
nginx本身并没有供应session同步的办理方案，而apache则供应了session共享的支持。
好了，办理了以上的问题之后，系统的构造如下：
阶段四、数据库读写分离化
上面我们总是假设数据库负载正常，但随着访问量的的提高，数据库的负载也在逐步增大。那么可能有人立时就想到跟运用做事器一样，把数据库一份为二再负载均衡即可。
但对付数据库来说，并没有那么大略。如果我们大略的把数据库一分为二，然后对付数据库的要求，分别负载到A机器和B机器，那么显而易见会造成两台数据库数据分歧一的问题。那么对付这种情形，我们可以先考虑利用读写分离的办法。
读写分离后的数据库系统构造如下：
这个构造变革后也会带来两个问题：
主从数据库之间数据同步问题运用对付数据源的选择问题办理问题方案：我们可以利用MYSQL自带的master+slave的办法实现主从复制。
采取第三方数据库中间件，例如mycat。mycat是从cobar发展而来的，而cobar是阿里开源的数据库中间件，后来停滞开拓。mycat是海内比较好的mysql开源数据库分库分表中间件。
阶段五、用搜索引擎缓解读库的压力
数据库做读库的话，常常对模糊查找力不从心，纵然做了读写分离，这个问题还未能办理。以我们所举的交易网站为例，发布的商品存储在数据库中，用户最常利用的功能便是查找商品，尤其是根据商品的标题来查找对应的商品。对付这种需求，一样平常我们都是通过like功能来实现的，但是这种办法的代价非常大。此时我们可以利用搜索引擎的倒排索引来完成。
搜索引擎具有以下优点：
它能够大大提高查询速率。
引入搜索引擎后也会带来以下的开销：带来大量的掩护事情，我们须要自己实现索引的构建过程，设计全量/增加的构建办法来应对非实时与实时的查询需求。须要掩护搜索引擎集群搜索引擎并不能替代数据库，他办理了某些场景下的\"大众读\"大众的问题，是否引入搜索引擎，须要综合考虑全体系统的需求。
引入搜索引擎后的系统构造如下：
阶段六、用缓存缓解读库的压力
1、后台运用层和数据库层的缓存
随着访问量的增加，逐渐涌现了许多用户访问同一部分内容的情形，对付这些比较热门的内容，没必要每次都从数据库读取。我们可以利用缓存技能，例如可以利用google的开源缓存技能guava或者利用memcacahe作为运用层的缓存，也可以利用redis作为数据库层的缓存。
其余，在某些场景下，关系型数据库并不是很适宜，例如我想做一个\"大众逐日输入密码缺点次数限定\"大众的功能，思路大概是在用户登录时，如果登录缺点，则记录下该用户的IP和缺点次数，那么这个数据要放在哪里呢？如果放在内存中，那么显然会占用太大的内容；如果放在关系型数据库中，那么既要建立数据库表，还要简历对应的java bean，还要写SQL等等。
而剖析一下我们要存储的数据，无非便是类似{ip:errorNumber}这样的key:value数据。对付这种数据，我们可以用NOSQL数据库来代替传统的关系型数据库。
2、页面缓存
除了数据缓存，还有页面缓存。比如利用HTML5的localstroage或者cookie。
优点： 减轻数据库的压力大幅度提高访问速率缺陷： 须要掩护缓存做事器提高了编码的繁芜性值得一提的是：缓存集群的调度算法不同与上面提到的运用做事器和数据库。最好采取\公众同等性哈希算法\"大众，这样才能提高命中率。这个就不展开讲了，有兴趣的可以查阅干系资料。
加入缓存后的构造：
阶段七、数据库水平拆分与垂直拆分
我们的网站演进到现在，交易、商品、用户的数据都还在同一个数据库中。只管采纳了增加缓存，读写分离的办法，但随着数据库的压力连续增加，数据库的瓶颈越来越突出，此时，我们可以有数据垂直拆分和水平拆分两种选择。
7.1 数据垂直拆分垂直拆分的意思是把数据库中不同的业务数据拆分道不同的数据库中，结合现在的例子，便是把交易、商品、用户的数据分开。
优点：·办理了原来把所有业务放在一个数据库中的压力问题。可以根据业务的特点进行更多的优化缺陷：须要掩护多个数据库问题：· 须要考虑原来跨业务的事务跨数据库的join办理问题方案：我们该当在运用层只管即便避免跨数据库的事物，如果非要跨数据库，只管即便在代码中掌握。我们可以通过第三方运用来办理，如上面提到的mycat，mycat供应了丰富的跨库join方案，详情可参考mycat官方文档。垂直拆分后的构造如下：
7.2 数据水平拆分
数据水平拆分便是把同一个表中的数据拆分到两个乃至多个数据库中。产生数据水平拆分的缘故原由是某个业务的数据量或者更新量到达了单个数据库的瓶颈，这时就可以把这个表拆分到两个或更多个数据库中。
优点：· 如果我们能客服以上问题，那么我们将能够很好地对数据量及写入量增长的情形。问题：· 访问用户信息的运用系统须要办理SQL路由的问题，由于现在用户信息分在了两个数据库中，须要在进行数据操作时理解须要操作的数据在哪里。主键的处理也变得不同，例如原来自增字段，现在不能大略地连续利用了。如果须要分页，就麻烦了。办理问题方案：我们还是可以通过可以办理第三方中间件，如mycat。mycat可以通过SQL解析模块对我们的SQL进行解析，再根据我们的配置，把要求转发到详细的某个数据库。
我们可以通过UUID担保唯一或自定义ID方案来办理。
mycat也供应了丰富的分页查询方案，比如先从每个数据库做分页查询，再合并数据做一次分页查询等等。
数据水平拆分后的构造：
阶段八、运用的拆分
8.1 拆分运用
随着业务的发展，业务越来越多，运用越来越大。我们须要考虑如何避免让运用越来越臃肿。这就须要把运用拆开，从一个运用变为俩个乃至更多。
还是以我们上面的例子，我们可以把用户、商品、交易拆分开。变成\公众用户、商品\"大众和\公众用户，交易\公众两个子系统。拆分后的构造：
问题： 这样拆分后，可能会有一些相同的代码，如用户干系的代码，商品和交易都须要用户信息，以是在两个别系中都保留差不多的操浸染户信息的代码。如何担保这些代码可以复用是一个须要办理的问题。
办理问题：通过走做事化的路线来办理
8.2 走做事化的道路
为理解决上面拆分运用后所涌现的问题，我们把公共的做事拆分出来，形成一种做事化的模式，简称SOA。采取做事化之后的系统构造：·
优点：相同的代码不会散落在不同的运用中了，这些实现放在了各个做事中央，使代码得到更好的掩护。我们把对数据库的交互放在了各个做事中央，让\"大众前端\"大众的web运用更看重与浏览器交互的事情。问题： 如何进行远程的做事调用
办理方法：我们可以通过下面的引入中间件来办理
阶段九、引入中间件
随着网站的连续发展，我们的系统中可能涌现不同措辞开拓的子模块和支配在不同平台的子系统。此时我们须要一个平台来通报可靠的，与平台和措辞无关的数据，并且能够把负载均衡透明化，能在调用过程中网络调用数据并剖析之，推测出网站的访问增长率等等一系列需求，对付网站该当如何发展做出预测。
开源中间件有阿里的dubbo，可以搭配Google开源的分布式程序折衷做事zookeeper实现做事器的注册与创造。
引入中间件后的构造：
十、总结
以上的演化过程只是一个例子，并不适宜所有的网站，实际中网站演进过程与自身业务和不同碰着的问题有密切的关系，没有固定的模式。只有负责的剖析和不断地探究，才能创造适宜自己网站的架构。
出处：https://www.jianshu.com/p/dc3db4402717
