作者：小M\
起源：https://cnblogs.com/xiaoMzjm/...
前言
咱们以javaweb为例，来搭建一个简略的电商零碎，看看这个零碎能够如何一步步演变。
该零碎具备的性能：
- 用户模块：用户注册和治理
- 商品模块：商品展现和治理
- 交易模块：创立交易和治理
阶段一、单机构建网站
网站的初期，咱们常常会在单机上跑咱们所有的程序和软件。此时咱们应用一个容器，如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的一致性
咱们来看看解决问题的计划 ：
1、第一个问题即是负载平衡的问题，个别有5种解决方案：
1、http重定向 。HTTP重定向就是应用层的申请转发。用户的申请其实曾经到了HTTP重定向负载平衡服务器，服务器依据算法要求用户重定向，用户收到重定向申请后，再次申请真正的集群
长处：简略。
毛病：性能较差。
2、DNS域名解析负载平衡 。DNS域名解析负载平衡就是在用户申请DNS服务器，获取域名对应的IP地址时，DNS服务器间接给出负载平衡后的服务器IP。
长处：交给DNS，不必咱们去保护负载平衡服务器。
毛病：当一个应用服务器挂了，不能及时告诉DNS，而且DNS负载平衡的控制权在域名服务商那里，网站无奈做更多的改善和更弱小的治理。
3、反向代理服务器 。在用户的申请达到反向代理服务器时（曾经达到网站机房），由反向代理服务器依据算法转发到具体的服务器。罕用的apache，nginx都能够充当反向代理服务器。
长处：部署简略。
毛病：代理服务器可能成为性能的瓶颈，特地是一次上传大文件。
4、IP层负载平衡 。在申请达到负载均衡器后，负载均衡器通过批改申请的目标IP地址，从而实现申请的转发，做到负载平衡。
长处：性能更好。
毛病：负载均衡器的宽带成为瓶颈。
5、数据链路层负载平衡 。在申请达到负载均衡器后，负载均衡器通过批改申请的mac地址，从而做到负载平衡，与IP负载平衡不一样的是，当申请拜访完服务器之后，间接返回客户。而无需再通过负载均衡器。
2、第二个问题即是集群调度算法问题，常见的调度算法有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、第三个问题是集群模式问题，个别3种解决方案：
1、NAT ：负载均衡器接管用户的申请，转发给具体服务器，服务器解决完申请返回给均衡器，均衡器再从新返回给用户。
2、DR ：负载均衡器接管用户的申请，转发给具体服务器，服务器进去玩申请后间接返回给用户。须要零碎反对IP Tunneling协定，难以跨平台。
3、TUN ：同上，但无需IP Tunneling协定，跨平台性好，大部分零碎都能够反对。
4、第四个问题是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实现服务器的注册与发现。
引入消息中间件后的构造：
十、总结
以上的演变过程只是一个例子，并不适宜所有的网站，理论中网站演进过程与本身业务和不同遇到的问题有亲密的关系，没有固定的模式。只有认真的剖析和一直地探索，能力发现适宜本人网站的架构。
近期热文举荐：
1.1,000+ 道 Java面试题及答案整顿(2022最新版)
2.劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4.别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！
5.《Java开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞+转发哦！