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

最初架构

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

优点：

①开发简单，集中式管理

②基本不会重复开发

③功能都在本地，没有分布式的管理和调用消耗

缺点：

1、效率低：开发都在同一个项目改代码，相互等待，冲突不断

2、维护难：代码功功能耦合在一起，新人不知道何从下手

3、不灵活：构建时间长，任何小修改都要重构整个项目，耗时

4、稳定性差：一个微小的问题，都可能导致整个应用挂掉

5、扩展性不够：无法满足高并发下的业务需求

 

集群模式

说明:我们使用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.分布式锁

SOA架构

SOA(Service Oriented Architecture)“面向服务的架构”：他是一种设计方法，其中包含多个服务，
服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在与操作系统进程中。各
个服务之间通过网络调用。

 说明：1.各个服务间相互调用  通过将自己现有服务注册到注册中心进行统一管理！并将自己依赖的服务通过自动发现从注册中心订阅下来 通过rabbion在客户端做负载均衡

          2.通过网关统一的将服务从注册中心订阅下来 并做统一的认证处理  外部调用 统一访问网关

          3.配置中心   各个服务都有自己单独的配置 配置的刷新和配置都要到每个服务项目进行配置增加运维的复杂性。通过配置中心统一进行配置冰注册到注册中心 各个服务启动加载自己所属配置进行初始化  配置中心还可以对敏感数据 进行加密 比如数据库链接

        需要解决的问题：单点登录 分布式事物  分布式锁 session共享  文件共享

 

随着服务增加 我们发布服务也增加了复杂度 可以通过jenkins 来对服务进行发布

微服务

2.微服务架构：其实和SOA架构类似，微服务是在SOA上做的升华，微服务架构强调的一个重点是“业
务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应
用。这些小应用之间通过服务完成交互和集成。