分布式架构（一）架构变迁

分布式架构（一）架构变迁

写在前面

虽然你们都了解过从单体应用到分布式架构应用，但本文是从另外一个角度出发，主要是架构的每一次变迁都涉及到技术的升级换代，在现在的互联网时代想立足你真的应该懂的这里边的每一个技术栈，每一个技术都不是凭空出来的，都是在必定的业务背景下催生的。

单体应用

早期的单体应用，全部的就没有模块的划分，全部代码部署到一个war包，就像下边这样：

固然这是古董级的架构了，但它也是一种架构，并且这种架构也持续了好久。

缺点：
http明文传输
存在单点问题，可用性不高
不适用与高并发、数据量大的场景

7层负载应用

随着业务发展，请求量愈来愈大，单机的web服务器服务能力达到瓶颈。
所说的瓶颈：
单机的线程数（链接数）
内存不足，用户的session也有可能成为瓶颈
响应速度变慢。

咱们能够加大web服务器的cpu、内存等纵向拓展它的能力,但纵向拓展就是有个问题，太贵了，因而就是用免费的nginx在7层使用负载算法，对进行流量进行分流。

nginx的层的在7层使用proxy_pass来作负载，负载算法常见的以下：

轮训算法
随机算法
加权算法
ip hash算法
最小链接数算法

nginx的配置传递门：

每一个算法都有本身的优缺点和本身的使用场景。

缺点：session共享问题

解决方案：

方案	原理	缺点
session stick	根据用户属性（好比uid）进行hash，特定的用户每次访问服务器都访问到同一台机器	若是某台机器宕机了，hash到该机器的用户获取不到session
session 复制	tomcat经过简单的配置，经过网络将各台机器相互复制	每台机器要存储全部的用户session信息，消耗带宽，浪费空间
session 独立存储	将session第三方独立，好比存储memcached或者redis	session信息须要走网络去获取和更新

session独立存储是目前的主流。

业务拆分