点击上方 Java后端，选择 设为星标
优质文章，及时送达
作者：小M的博客
链接：cnblogs.com/xiaoMzjm/p/5223799.html
我们以javaweb为例，来搭建一个简单的电商系统，看看这个系统可以如何一步步演变。
该系统具备的功能：
-
用户模块：
用户注册和管理
-
商品模块：
商品展示和管理
-
交易模块：
创建交易和管理
阶段一、单机构建网站
网站的初期，我们经常会在单机上跑我们所有的程序和软件。此时我们使用一个容器，如tomcat、jetty、jboos，然后直接使用JSP/servlet技术，或者使用一些开源的框架如maven+spring+struct+hibernate、maven+spring+springmvc+mybatis；最后再选择一个数据库管理系统来存储数据，如mysql、sqlserver、oracle，然后通过JDBC进行数据库的连接和操作。
把以上的所有软件都装载同一台机器上，应用跑起来了，也算是一个小系统了。此时系统结果如下：
我把 架构 相关的文章整理成了 PDF ，关注微信公众号 Java后端 回复 666 下载。
阶段二、应用服务器与数据库分离
增加的机器用来做什么呢？此时我们可以把数据库，web服务器拆分开来，这样不仅提高了单台机器的负载能力，也提高了容灾能力。
应用服务器与数据库分开后的架构如下图所示：
阶段三、应用服务器集群
我们以增加了一台应用服务器为例，增加后的系统结构图如下：
-
用户的请求由谁来转发到到具体的应用服务器
-
有什么转发的算法
-
应用服务器如何返回用户的请求
-
用户如果每次访问到的服务器不一样，那么如何维护session的一致性
1、http重定向。HTTP重定向就是应用层的请求转发。用户的请求其实已经到了HTTP重定向负载均衡服务器，服务器根据算法要求用户重定向，用户收到重定向请求后，再次请求真正的集群
缺点：性能较差。
DNS域名解析负载均衡
。DNS域名解析负载均衡就是在用户请求DNS服务器，获取域名对应的IP地址时，DNS服务器直接给出负载均衡后的服务器IP。
反向代理服务器
。在用户的请求到达反向代理服务器时（已经到达网站机房），由反向代理服务器根据算法转发到具体的服务器。常用的apache，nginx都可以充当反向代理服务器。
优点：部署简单。
缺点：代理服务器可能成为性能的瓶颈，特别是一次上传大文件。
IP层负载均衡
。在请求到达负载均衡器后，负载均衡器通过修改请求的目的IP地址，从而实现请求的转发，做到负载均衡。
缺点：负载均衡器的宽带成为瓶颈。
数据链路层负载均衡
。在请求到达负载均衡器后，负载均衡器通过修改请求的mac地址，从而做到负载均衡，与IP负载均衡不一样的是，当请求访问完服务器之后，直接返回客户。而无需再经过负载均衡器。
2、第二个问题即是集群调度算法问题，常见的调度算法有10种。
rr 轮询调度算法
。顾名思义，轮询分发请求。
缺点：不考虑每台服务器的处理能力
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种解决方案：
Session Sticky
。session sticky就是把同一个用户在某一个会话中的请求，都分配到固定的某一台服务器中，这样我们就不需要解决跨服务器的session问题了，常见的算法有ip_hash法，即上面提到的两种散列算法。
Session Replication
。session replication就是在集群中复制session，使得每个服务器都保存有全部用户的session数据。
3、Session数据集中存储：session数据集中存储就是利用数据库来存储session数据，实现了session和应用服务器的解耦。
优点：相比session replication的方案，集群间对于宽带和内存的压力减少了很多。
4、Cookie Base：cookie base就是把session存在cookie中，有浏览器来告诉应用服务器我的session是什么，同样实现了session和应用服务器的解耦。
：
系统的结构如下
：
阶段四、数据库读写分离化
读写分离后的数据库系统结构如下：
1. 我们可以使用MYSQL自带的master+slave的方式实现主从复制。
mycat是从cobar发展而来的，而cobar是阿里开源的数据库中间件，后来停止开发。
：
引入搜索引擎后也会带来以下的开销：
-
带来大量的维护工作，我们需要自己实现索引的构建过程，设计全量/增加的构建方式来应对非实时与实时的查询需求。
-
需要维护搜索引擎集群
搜索引擎并不能替代数据库，他解决了某些场景下的“读”的问题，是否引入搜索引擎，需要综合考虑整个系统的需求。引入搜索引擎后的系统结构如下：
另外，在某些场景下，关系型数据库并不是很适合，例如我想做一个“每日输入密码错误次数限制”的功能，思路大概是在用户登录时，如果登录错误，则记录下该用户的IP和错误次数，那么这个数据要放在哪里呢？假如放在内存中，那么显然会占用太大的内容；假如放在关系型数据库中，那么既要建立数据库表，还要简历对应的java bean，还要写SQL等等。而分析一下我们要存储的数据，无非就是类似{ip:errorNumber}这样的key:value数据。对于这种数据，我们可以用NOSQL数据库来代替传统的关系型数据库。
2、页面缓存
-
需要维护缓存服务器
-
提高了编码的复杂性
：
加入缓存后的结构：
阶段七、数据库水平拆分与垂直拆分
-
解决了原来把所有业务放在一个数据库中的压力问题。
-
可以根据业务的特点进行更多的优化
-
需要维护多个数据库
-
需要考虑原来跨业务的事务
-
跨数据库的join
-
我们应该在应用层尽量避免跨数据库的事物，如果非要跨数据库，尽量在代码中控制。
-
我们可以通过第三方应用来解决，如上面提到的mycat，mycat提供了丰富的跨库join方案，详情可参考mycat官方文档。
-
如果我们能客服以上问题，那么我们将能够很好地对数据量及写入量增长的情况。
：
1. 访问用户信息的应用系统需要解决SQL路由的问题，因为现在用户信息分在了两个数据库中，需要在进行数据操作时了解需要操作的数据在哪里。
2. 主键的处理也变得不同，例如原来自增字段，现在不能简单地继续使用了。
3. 如果需要分页，就麻烦了。
1. 我们还是可以通过可以解决第三方中间件，如mycat。 mycat可以通过SQL解析模块对我们的SQL进行解析，再根据我们的配置，把请求转发到具体的某个数据库。
2. 我们可以通过UUID保证唯一或自定义ID方案来解决。
3. mycat也提供了丰富的分页查询方案，比如先从每个数据库做分页查询，再合并数据做一次分页查询等等。
：
这样拆分后，可能会有一些相同的代码，如用户相关的代码，商品和交易都需要用户信息，所以在两个系统中都保留差不多的操作用户信息的代码。
为了解决上面拆分应用后所出现的问题，我们把公共的服务拆分出来，形成一种服务化的模式，简称SOA。
优点：
-
相同的代码不会散落在不同的应用中了，这些实现放在了各个服务中心，使代码得到更好的维护。
-
我们把对数据库的交互放在了各个服务中心，让”前端“的web应用更注重与浏览器交互的工作。
：
随着网站的继续发展，我们的系统中可能出现不同语言开发的子模块和部署在不同平台的子系统。此时我们需要一个平台来传递可靠的，与平台和语言无关的数据，并且能够把负载均衡透明化，能在调用过程中收集调用数据并分析之，推测出网站的访问增长率等等一系列需求，对于网站应该如何成长做出预测。开源消息中间件有阿里的dubbo，可以搭配Google开源的分布式程序协调服务zookeeper实现服务器的注册与发现。
十、总结
如果看到这里，说明你喜欢这篇文章，请 转发、点赞。同时 标星（置顶）本公众号可以第一时间接受到博文推送。
推荐阅读
1. MySQL 大表优化方案
2. Spring Boot+RabbitMQ 实现延迟消息
3. 面试官问：List 如何一边遍历，一边删除？
4. 浅析 VO、DTO、DO、PO 的概念
《Java技术栈学习手册》
，覆盖了Java技术、面试题精选、Spring全家桶、Nginx、SSM、微服务、数据库、数据结构、架构等等。
获取方式：点“ 在看，关注公众号 Java后端 并回复 777 领取，更多内容陆续奉上。
喜欢文章，点个在看 
本文分享自微信公众号 - Java后端（web_resource）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
相关文章
