一、微服务架构中核心模块及其使用技术总览

二、各模块详细说明

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