Spring Cloud-个人理解的微服务演变过程(一)

最初架构

说明：最初我们架构是垂直的所有功能都在一个项目里面随着业务和用户的增长原来一台服务器已经不能支撑现有的请求数这个时候我们就需要部署多台服务器

集群模式

说明:我们使用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 来对服务进行发布