认识微服务
单体架构
不适合大型复杂项目
微服务架构
将单体结构的各个功能模块拆分为多个独立的项目
拆取的独立项目分别开发，在部署的时候也要分别去编译打包，分别去部署，不同的模块部署在不同的服务器上，对外提供不同的功能，相当于每个模块都是一个小的服务，即微服务。
另外还需要做到数据库的数据隔离，每个服务有各自的数据库，互不影响
好处：单体架构在编译部署时要花费大量的时间，微服务拆分开之后，打包编译的速度非常快
坏处：复杂度提升，运维成本变高
SpringCloud
OpenFeign
微服务的远程调用
只需定义接口，无需去实现，底层会帮我们完成跨服务的远程调用，包括服务的拉取，负载均衡，发送请求等等复杂的代码。
网关
网络的关口，负责请求路由、转发，身份校验。
类比：
网关：小区开门的老大爷
微服务：小区的各个住户
前端：相当于某人要来小区找人
检查：身份校验
告诉某某某xxx住在xxx号：路由
找不着带你过去：转发
网关（开门的大爷）就能解决微服务太多，前端不知道请求谁的问题，前端只需要知道网关的地址即可，网关根据前端的请求来判断由哪个微服务来处理请求。
判断的过程-->路由，网关将请求转发的过程-->转发
思考：微服务很多，网关如何知道每个微服务的实例ip地址和端口？
注册中心。所有微服务一经启动，都会将信息注册到注册中心，此时注册中心就会有微服务的所有信息，网关也是微服务，启动之后可以去注册中心拉取所有微服务地址。
微服务不需要暴露给前端，只需要将网关暴露给前端即可
配置路由规则
微服务的治理
服务治理包含两部分：
part1：所有微服务在启动时都应该提交自己的服务信息到nacos-->服务的注册
part2：服务的调用者去注册中心拉取服务列表进行服务的调用-->服务的发现
注册中心原理
核心用于微服务的治理-->治理过程复杂-->使用注册中心的组件Nacos
Nacos注册中心组件
服务注册
服务治理包含两部分：
part1：所有微服务在启动时都应该提交自己的服务信息到nacos-->服务的注册
服务发现
part2：服务的调用者去注册中心拉取服务列表进行服务的调用-->服务的发现
步骤1，2和服务的注册是通用的，需要单独完成服务发现的列表拉取
总结（一）
在对单体架构进行微服务的拆分过程中，发现的问题，利用微服务组件进行问题的解决。
远程调用：例如，服务拆分之后，每个服务进行单一的职责，复杂服务会出现服务之间的调用（如查询），即远程调用，使用OpenFeign进行解决。
服务治理：远程调用有很多，调用关系错综复杂，需要对微服务地址进行维护，并知道它们的健康状态，即服务的治理，使用Nacos组件进行实现。
网关：服务很多，前端不知道调用谁，引入网关进行解决。
配置管理：微服务越来越多，每个服务都有自己的配置文件，配置太多太复杂，并且配置出现变更需要重新启动服务，服务的可用性降低，使用Nacos组件进行问题解决，可以对配置进行抽取和共享，简化微服务的配置，还可以实现微服务配置的热更新，服务无需重启，提高服务的可用性
RabbitMQ
