最初架构
说明：最初我们架构是垂直的 所有功能都在一个项目里面 随着业务和用户的增长 原来一台服务器已经不能支撑现有的请求数 这个时候我们就需要部署多台服务器
集群模式
说明:我们使用nginx做代理服务器 将请求 根据权重分摊请求到对应的服务器 以及容错 ！通过nginx做代理服务器的好处不仅仅能够支持更大的并发数!而且还能在我们某台服务器发生故障的时候不会导致系统瘫痪
我们可以根据并发数适当的增加服务器数量 （但是需要注意的是:我们的nginx也是一台服务器 也会遇到瓶颈 只是内部实现机制与我们的tomcat等服务器不一样 可以支持更多的并发数！还有一个是数据库。虽然我们服务器并发能能够通过增加服务器通过nginx来进行负载均衡的转发请求 但是我们数据库也会遇到瓶颈 这个时候就需要涉及到数据库集群）
需要解决的问题：1.session 共享 2.文件上传 3.缓存共享
1.session共享 主要是解决身份认证 我们传统登录时用户登录成功将会话信息保存session 然后像客户端写入一个cookie cookie的值就是对应会话的key(浏览器每次发起请求都会将cookie传到服务端 我们在服务端根据身份认证的key 在服务器找是否存在 如果存在 则认为是认证成功 没有则登录失败) 当我们从server1 登录 成功 nginx后面将请求负载到server2 按照我们前面的方式 通过cookie是找不到登录信息的。解决方式 就是登录的时候将身份信息保存到第三方缓存 比如redis 而不是存在服务器内存
2.文件上传 如果我们文件保存到服务器的话 上传负载到server1 下载 负载到server2 则会找不到文件 我们可以通过自己搭建文件服务器 或者购买第三方文件存储中心 七牛或者青云
3.缓存共享 跟上面其实是一致的 如果将缓存存储到server1 第二次请求负载到server2 拿不到缓存 所以也是通过redis解决
4.分布式锁
分布式架构
说明:上面的架构 当我们nginx到达瓶颈之后单纯的增加服务器已经不能解决问题了。这个时候就可以通过拆分系统的粒度 将原来的垂直系统 拆分成各个子系统 每个子系统又可以单独部署集群+nginx
需要解决的问题：
1.单点登录
2.session共享
3.文件上传
4.缓存共享
5.分布式锁(redis SETNX 或者开源封装好的redisson)
6.分布式事物 当我们将原来的垂直应用拆分成一个个独立的子系统 系统之间需要交互 访问数据库不在一个会话里面或者不是同一个库 就会涉及到分布式事物(多个系统之间的交互如何保证一致性)
7.运维方面带来的难度 因为各个子系统间相互调用都是静态链接不利于维护 对外暴露接口的开发工作 以及各个子系统对外暴露服务的接口认证重复开发
基于微服务架构
说明：1.各个服务间相互调用 通过将自己现有服务注册到注册中心进行统一管理！并将自己依赖的服务通过自动发现从注册中心订阅下来 通过rabbion在客户端做负载均衡
2.通过网关统一的将服务从注册中心订阅下来 并做统一的认证处理 外部调用 统一访问网关
3.配置中心 各个服务都有自己单独的配置 配置的刷新和配置都要到每个服务项目进行配置增加运维的复杂性。通过配置中心统一进行配置冰注册到注册中心 各个服务启动加载自己所属配置进行初始化 配置中心还可以对敏感数据 进行加密 比如数据库链接
需要解决的问题：单点登录 分布式事物 分布式锁 session共享 文件共享
随着服务增加 我们发布服务也增加了复杂度 可以通过jenkins 来对服务进行发布
