认识微服务

单体架构

不适合大型复杂项目

微服务架构

将单体结构的各个功能模块拆分为多个独立的项目

拆取的独立项目分别开发，在部署的时候也要分别去编译打包，分别去部署，不同的模块部署在不同的服务器上，对外提供不同的功能，相当于每个模块都是一个小的服务，即微服务。

另外还需要做到数据库的数据隔离，每个服务有各自的数据库，互不影响

好处：单体架构在编译部署时要花费大量的时间，微服务拆分开之后，打包编译的速度非常快

坏处：复杂度提升，运维成本变高

SpringCloud

OpenFeign

微服务的远程调用

只需定义接口，无需去实现，底层会帮我们完成跨服务的远程调用，包括服务的拉取，负载均衡，发送请求等等复杂的代码。

网关

网络的关口，负责请求路由、转发，身份校验。

类比：

网关：小区开门的老大爷

微服务：小区的各个住户

前端：相当于某人要来小区找人

检查：身份校验

告诉某某某xxx住在xxx号：路由

找不着带你过去：转发

小区可以看成是微服务的集群，小区的住户看成各个微服务

网关（开门的大爷）就能解决微服务太多，前端不知道请求谁的问题，前端只需要知道网关的地址即可，网关根据前端的请求来判断由哪个微服务来处理请求。

判断的过程-->路由，网关将请求转发的过程-->转发

思考：微服务很多，网关如何知道每个微服务的实例ip地址和端口？

注册中心。所有微服务一经启动，都会将信息注册到注册中心，此时注册中心就会有微服务的所有信息，网关也是微服务，启动之后可以去注册中心拉取所有微服务地址。

微服务不需要暴露给前端，只需要将网关暴露给前端即可

配置路由规则

微服务的治理

服务治理包含两部分：

part1：所有微服务在启动时都应该提交自己的服务信息到nacos-->服务的注册

part2：服务的调用者去注册中心拉取服务列表进行服务的调用-->服务的发现

注册中心原理

核心用于微服务的治理-->治理过程复杂-->使用注册中心的组件Nacos

Nacos注册中心组件

服务注册

服务治理包含两部分：

part1：所有微服务在启动时都应该提交自己的服务信息到nacos-->服务的注册

服务发现

part2：服务的调用者去注册中心拉取服务列表进行服务的调用-->服务的发现

步骤1，2和服务的注册是通用的，需要单独完成服务发现的列表拉取

总结（一）

在对单体架构进行微服务的拆分过程中，发现的问题，利用微服务组件进行问题的解决。

远程调用：例如，服务拆分之后，每个服务进行单一的职责，复杂服务会出现服务之间的调用（如查询），即远程调用，使用OpenFeign进行解决。

服务治理：远程调用有很多，调用关系错综复杂，需要对微服务地址进行维护，并知道它们的健康状态，即服务的治理，使用Nacos组件进行实现。

网关：服务很多，前端不知道调用谁，引入网关进行解决。

配置管理：微服务越来越多，每个服务都有自己的配置文件，配置太多太复杂，并且配置出现变更需要重新启动服务，服务的可用性降低，使用Nacos组件进行问题解决，可以对配置进行抽取和共享，简化微服务的配置，还可以实现微服务配置的热更新，服务无需重启，提高服务的可用性

RabbitMQ