1 微服务的由来

这是一个普通的Nginx反向代理三个tomcat服务器的项目

现在产生了新的业务需求，增加了新的功能，代码更新了，自然需要重启整个项目，但是随着项目越来越大，每次重启耗费的时间越来越多，而且重启时不仅仅是客户端无法请求，服务端之间也无法进行通讯，这就会造成损失，所以要将项目按照业务进行拆分

• 项目拆分的目的

    1. 减少发布时间，不需要整个系统都重启

    2. 减少维护以及升级时的影响范围，只是影响小部分功能，不影响整个项目功能

• 项目拆分要解决的问题

    目前Nginx反向代理3台服务器，每台服务器其实都是干同样的业务，如果要拆分项目，例如将1台服务器上的业务拆分到10台服务器上分别执行，那么这3台服务器最终会产生30台服务器，这就增加了Nginx配置的压力，这个配置问题需要解决

• 解决方式

    微服务（springcloud）

2 项目架构

2.1 单体结构

一些简单的项目常用这种结构，优点很明显，缺点也很明显

优点

    - 开发简单

    - 部署简单

    - 维护简单

    - 成本低

缺点

    - 随着用户量增多，负载越来越高，负载均衡只能横向扩展

    - 业务越来越复杂之后，导致框架结构越来越复杂，需求变动改动较大，每次提交代码时都要小心翼翼，因为一个文件几千个类，害怕把别的接口的文件改了

    - 随着数据增多/业务增多，可能导致war包/jar包体积越来越大

优化方式

    - 横向增加服务器，让单台服务器变成多台机器的集群

    - 垂直拆分模块，降低耦合度

    - 数据库缓存等技术，压力也会增大，也要横向扩展

优化示意图

总结

    - 适合小型创业公司

    - 一个公司产品的最初产品，后续再重构优化

    - 适合用户量较少的项目

    - 一个单体架构的项目就足以支持公司的所有业务功能

例如：用户量只有十几人的xxx管理系统，xxxAPP内容管理系统，xxx政务系统

2.2 微服务框架

当用户量比较多时，可以使用这个框架

优点

    - 可扩展性强

    - 独立部署

    - 开发比较灵活

    - 复杂度可控

    - 每个微服务都可以有自己的数据库

    - 容错性高、高可用

    - 比较适合大型企业/大型项目

缺点

    - 故障排查困难，每次请求，都可能是一个请求链，涉及到多个微服务，每个微服务的日志可能独立存储，排查bug困难

    - 服务监控困难，每次测试都要启动一堆东西

    - 分布式的复杂性，调用其他的服务器上的服务，网络出错概率增加，延迟增高，连接超时情况增加

    - 服务的互相依赖，导致修改接口/服务其他模块报错

    - 运维成本增高

    - 服务器成本增高

总结

    - 适合成本预算充足的大型项目

    - 适合高并发的互联网项目

    - 适合用户体量较大的项目

    - 不适合小型项目

2.3 两种架构对比

一个公司的项目，除非一开始就定位为大用户量，否则都是先做单体结构，随着用户量增大才慢慢改为微服务的。

如果体量很小的项目一上来就用微服务就是给开发找事，服务器也浪费资金，还增加了运维的工作压力

不是什么项目都适合微服务的

3 微服务的注册中心

微服务的注册中心

4 微服务的远程调用

微服务的远程调用

5 微服务的配置中心

微服务的配置中心

6 微服务的网关

微服务的网关

7 微服务的限流

微服务的限流

8 微服务的中间件

8.1 说明

实际工作中需要用springcloud时，也不是一定会把所有中间件都用到，也并不需要我们一个个去搭建微服务的中间件，讲这么多只是让我们知道微服务的中间件分别是干什么的

实际开发搭建这些的是架构师，参数也不能随便乱动的，一般去到公司，application.yml里的参数都是不用改的，参数都在配置中心被统一设定好了

作为初级程序员，只需要游走于搭建好的项目中的各个业务模块，在其中写controller、service和mapper

但我们必须知道这些组件启动是有顺序的，什么服务端依赖于什么，所以以后去公司，如果是微服务项目，直接问这些组件启动顺序，让别人给你列个表就完事了

这么多中间件，无论是阿里提供的还是spring官方的，都是为了实现特定的功能（路由调用zuul、服务注册eureka、远程调用feign、负载ribbon、熔断Hystrxi、配置中心Config、限流sentinel）

如果使用了阿里提供的中间件，那么一般就要用一整套阿里提供的springcloud解决策略

8.2 微服务的中间件分类及作用

整体分类如下，具体一类可用的组件太多了，学不完，官网上列表给出了很长一串

• 注册中心：

    Eureka,Nacos,Consul,Zookeeper

    注册和发现服务，有很多注册中心可选用，无非区别就是怎么启动和怎么调用，要实现的功能都一样

• 远程调用：

    基于http的远程调用feign，集成了ribbon实现客户端负载均衡（基于随机、轮询、并发数等），还集成了Hystrxi来做服务熔断（但是sentinel也可以做）

    基于RPC协议调用Dubbo，这是另一套路线，用这个的话，整个项目就都用alibaba提供的组件就行了

• 配置中心：

    SpringCloud Config , Nacos

    集中管理配置，所有的客户端项目都需要连接配置中心服务器，其中的nacos优越点就是有一个页面

• 网关：

    Zuul网关，可以在Nginx调用时进行注册中心服务分流

    Nacos网关，也可以实现

    gateway等等

    网关可选项非常多，但是这些网关要解决的问题就是分流

• 限流：

    sentinel，实现服务降级和熔断，无非是保证服务节点的安全

9 微服务引擎MSE

百度搜索Nacos时，可以看到一个广告，进入广告页面可以看到链接到的是阿里云的MSE

这是阿里云提供的一种服务，用户花钱够买微服务的相关配置，这些配置部署在阿里云上并且已经配置完毕，用户可以直接使用，不用考虑部署和配置，需要再加更多的注册中心等微服务设施时，就再花钱即可