分布式架构（一）架构变迁
写在前面
虽然大家都了解过从单体应用到分布式架构应用，但本文是从另一个角度出发，主要是架构的每一次变迁都涉及到技术的升级换代，在如今的互联网时代想立足你真的应该懂的这里边的每个技术栈，每个技术都不是凭空出来的，都是在一定的业务背景下催生的。
单体应用
早期的单体应用，所有的就没有模块的划分，所有代码部署到一个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独立存储是目前的主流。
业务拆分