微服务的架构

用户发送请求。请求进入网关（gateway），统一URL地址，由网关统一分发地址（类似前端控制器），并将微服务的公共功能移入网关，如对用户的请求进行拦截过滤等一系列功能。

网关之后是业务组件（也叫业务微服务）。可以理解为拆分之后的微服务了，服务组件之间通过Fegin来进行http调用，Fegin集成Ribbon来实现客户端负载均衡。

微服务架构中，服务之间同步调用是通过Feign来实现的，那服务间的异步解耦就要通过MQ（消息中间件）来实现了。虽然我们可以通过多线程来实现异步调用，但是这种异步调用不支持持久化，可能会造成消息丢失，所以一般都集成RabbitMq或者RocketMq.。

把所有的服务组件都注册到注册中心，进而实现服务的动态调用。一般新的平台建议直接集成Nacos，Nacos除了能做注册中心来使用，也可以作为分布式配置中心来使用，比Sping Cloud Config更好使。

链路追踪与监控就是支撑微服务，
链路追踪（sleuth）:追踪请求日志，加了两个属性，轨迹id和微服务轨迹id，一个请求对应一个轨迹id，相同请求的轨迹id是相同的，同一个请求可能经过多个微服务，每个微服务的id不同，通过轨迹id下的微服务的id可以知道走了那些微服务。
服务监控（zipkin）：可视化客户端，上边的信息通过这个来查看
熔断降级：（服务保护）用的框架是sentinal,为什么要服务保护？避免服务雪崩，保证服务之间独立运行，互补影响
RocketMQ消息中间件：用在服务的异步访问，而服务的同步访问用OpenFegin

如果服务是集群的，则使用ribbon框架，因为他是负载均衡的。