一、微服务架构中核心模块及其使用技术总览
二、各模块详细说明
1、注册中心
该模块主要功能为 自动提供服务的注册与发现，集中式管理服务， 让 服务调用端 发现服务**，** 让服务提供端 注册服务，倘若没有注册中心，那客户端就需要维护服务端调用信息（ip、端口），另外这样操作服务调用端是无法感知服务提供端的健康状态，需要人为添加与剔除服务，维护成本高，因此需要注册中心来帮助我们来完成这些事儿。
相应技术栈对比：
注：上表AP、CP是指CAP理论
2、服务调用
该模块主要功能为负责各微服务之间的通讯， 实现服务端的远程调用，常见技术有，RestTemplate、Feign、OpenFeign。
服务调用框架对比：
3、均衡负载
该模块主要功能是负责将 请求经过一定策略均衡的分配到服务端 ，当我们的服务提供端同一个服务配置额多个实例（集群） 时，就需要负载均衡模块协助分配请求到对应服务实例，如果服务配置单个，就不要此模块，但是为了保证高可用都会配置多个实例。
常见负载均衡策略：轮询、随机、权重轮询、ip hash、根据响应时间计算、最优策略 等**。**
负载均衡模块对比：
4、服务降级、熔断（容错）
服务降级、熔断、限流是微服务架构保证高可用的得力助手，之所以出现这三兄弟，是因为我们的微服务与微服务直接相互调用，错综复杂，调用链路很长，如果微服务体系中某个服务宕机，就会造成微服务系统瘫痪，如下图：
服务降级： 在服务调用（消费）端做的一种兜底措施，当服务器处理结果不符合预期（服务响应超时、服务出错、宕机等），就把兜底的结果返回客户，以此保证服务消费方正常运行，不至于死等服务器结果，链路积压崩溃。
**服务熔断：**发生在服务提供方，包含三个状态，降级->熔断->恢复。当满足熔断条件时就会触发熔断，触发熔断首先会降级处理，返回兜底数据，然后开启熔断，熔断开启后，不管三七二十一，请求正确与否，都会在一段时间内返回兜底数据，然后尝试恢复，也就是放行请求，如果请求处理正常，就会关闭熔断。（后面章节会代码演示）
**服务限流：**服务限流是为了让服务器平稳的处理请求，也是对服务的一种保护措施，不至于把服务拖死，比如我的服务10S内最多同时处理50个请求，突然间来了100个请求，50个以外要么排队要么丢弃，同一时间内我的服务只处理50个请求，如果不做限流，100个请求压在服务端，服务器忙不过来的！就有崩溃风险。
常见主流的技术： HyStrix、Sentinel、Resilience4j（国外使用）
5、服务网关
网关是在我们的微服务基础上在封装的一层服务，网关后面是我们系统的各个微服务，负责转发前端请求到各个服务，就像公司前台一样，公司外部人员首先接触的是前台人员，再由前台人员对接公司内部人员。
一般网关主要包含三个模块：断言 （根据配置决定是否进行下一步）-> 路由匹配 -> 路由转发， 网关是微服务体系重要的环节，他能保护我们的服务不被侵害 ，同时还能做鉴权 、全局日志采集 、容错 、限流、反向代理等
目前主流技术为getway ,zuul已经跟不上时代步伐了，因为他底层采用的是servlet，servlet是一种阻塞io ，满足不了高并发场景，而且不支持任何长连接，而getway后期新秀，底层采用netty做支撑，是一种异步非阻塞io，处理请求能力远远强于 servlet。
6**、配置中心**
配置中心的存在主要是为了解决大量微服务下的公共配置 以及动态配置 问题，我们都知道，每个微服务是由springboot做支撑，每个springboot项目都会有一个application的配置文件，如果某些配置发生变化，得一个一个服务去修改，这样加大维护工作量，特别是运维老哥！ 另外每次修改配置还得重启服务，因此对动态配置也有强烈需求，基于这样的背景而产生配置中心模块。
常见配置中心技术支持有**： springCloud config，nacos。**
7**、服务总线**
服务总线，顾名思义他是为我们所有服务提供服务，在微服务体系中通常会有一些公共的消息，比如上步骤提到的动态配置，就需要服务总线的支撑，各个微服务向服务总线订阅消息，进而监听总线，当总线发生变动时，订阅的服务可以感知，然后同步更新自己，服务总线一般搭配着消息中间件，如RabbitMq（MQ）、kafka等，此外服务总线还具有定点通知某个或多个服务的功能
总之服务总线就像一个妈妈管着一群孩子一样，通过妈妈向所有孩子或者某个孩子传达消息，从而改变孩子的某些行为或功能。
常见技术支撑有： springcloud bus，nacos