一、国内外技术栈介绍
首先，我们来看看这两个技术栈在国内的流行程度，据自己了解到：
- 对于国外，Spring Cloud 基本已经统一国外的微服务体系。
- 对于国内，老的系统使用 Dubbo 较多，新的系统使用 Spring Cloud 较多。
这样说起来，仿佛 Spring Cloud 和 Dubbo 是冲突的关系？！
实际上，并不然。我们现在所使用的 Spring Cloud 技术体系，实际上是 Spring Cloud Netflix 为主，例如说：
- Netflix Eureka 注册中心
- Netflix Hystrix 熔断组件
- Netflix Ribbon 负载均衡
- Netflix Zuul 网关服务
但是，开源的世界，总是这么有趣。随着Spring Cloud Netflix 将不再开发新的组件,项目进入维护模. 目前 Alibaba 基于开源组件和多个阿里云产品组成以及Spring Cloud 对的接口，实现了一套 Spring Cloud Alibaba 技术体系，并且已经获得 Spring Cloud 的认可，目前在国内使用人数很多了。组件如下：
- Nacos 注册中心 + 配置中心，对标 Eureka 。并且，还对标了 Spring Cloud Config 。
- Sentinel 服务保障，对标 Hystrix 。
- Dubbo 服务调用( 包括负载均衡 )，对标 Ribbon + Feign 。
- Gateway 网关服务。
个人态度上，还是非常看好 Spring Cloud Alibaba 技术体系的
二、各模块详细说明
1.注册中心
该模块主要功能为 自动提供服务的注册与发现，集中式管理服务，让 服务调用端发现服务，让服务提供端注册服务，倘若没有注册中心，那客户端就需要维护服务端调用信息（ip、端口），另外这样操作服务调用端是无法感知服务提供端的健康状态，需要人为添加与剔除服务，维护成本高，因此需要注册中心来帮助我们来完成这些事儿。
CAP定理：指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可同时获得
其中：
一致性（C）：所有节点都可以访问到最新的数据
可用性（A）：每个请求都是可以得到响应的，不管请求是成功还是失败
分区容错性（P）：除了全部整体网络故障，其他故障都不能导致整个系统不可用
- CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡
- CA： 如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的
CP: 如果不要求A（可用），每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统
AP：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。
注册中心对比：
2、服务调用
该模块主要功能为负责各微服务之间的通讯， 实现服务端的远程调用，常见技术有，RestTemplate、Feign、OpenFeign。
服务调用框架对比：
RestTemplate详情调用博客
Feign、OpenFeign。详情介绍,使用的博客
3、均衡负载
该模块主要功能是负责将 请求经过一定策略均衡的分配到服务端，当我们的服务提供端同一个服务配置额多个实例（集群）时，就需要负载均衡模块协助分配请求到对应服务实例，如果服务配置单个，就不要此模块，但是为了保证高可用都会配置多个实例。
常见负载均衡策略：轮询、随机、权重轮询、ip hash、根据响应时间计算、最优策略等。
负载均衡模块对比：
4、服务降级、熔断（容错）
服务降级、熔断、限流是微服务架构保证高可用的得力助手，之所以出现这三兄弟，是因为我们的微服务与微服务直接相互调用，错综复杂，调用链路很长，如果微服务体系中某个服务宕机，就会造成微服务系统瘫痪，如下图：
服务降级： 在服务调用（消费）端做的一种兜底措施，当服务器处理结果不符合预期（服务响应超时、服务出错、宕机等），就把兜底的结果返回客户，以此保证服务消费方正常运行，不至于死等服务器结果，链路积压崩溃。
服务熔断：发生在服务提供方，包含三个状态，降级->熔断->恢复。当满足熔断条件时就会触发熔断，触发熔断首先会降级处理，返回兜底数据，然后开启熔断，熔断开启后，不管三七二十一，请求正确与否，都会在一段时间内返回兜底数据，然后尝试恢复，也就是放行请求，如果请求处理正常，就会关闭熔断。（后面章节会代码演示）
服务限流：服务限流是为了让服务器平稳的处理请求，也是对服务的一种保护措施，不至于把服务拖死，比如我的服务10S内最多同时处理50个请求，突然间来了100个请求，50个以外要么排队要么丢弃，同一时间内我的服务只处理50个请求，如果不做限流，100个请求压在服务端，服务器忙不过来的！就有崩溃风险。
常见主流的技术： HyStrix、Sentinel、Resilience4j（国外使用）
5、服务网关
网关是在我们的微服务基础上在封装的一层服务，网关后面是我们系统的各个微服务，负责转发前端请求到各个服务，就像公司前台一样，公司外部人员首先接触的是前台人员，再由前台人员对接公司内部人员。
网关的功能
- 针对所有请求进行登陆统一鉴权（登录态）、限流、缓存、日志（用户打点）。
- 可以根据不同的请求路径pattern，来进行请求的鉴权、转发、和拒绝。
- 协议转化。针对后段多种不同的协议，在网关层统一处理后以HTTP对外提供服务。
- 提供统一的错误码。
- 请求转发，并且可以基于网关实现内网与外网的隔离。Gateway(网关-Gateway - 知乎)
目前主流的网关(Gateway,与zuul)
Gateway和ZUUL介绍:网关-Gateway - 知乎
目前主流技术为getway,zuul已经跟不上时代步伐了，因为他底层采用的是servlet，servlet是一种阻塞io，满足不了高并发场景，而且不支持任何长连接，而getway后期新秀，底层采用netty做支撑，是一种异步非阻塞io，处理请求能力远远强于 servlet。
6、配置中心
配置中心的存在主要是为了解决大量微服务下的公共配置以及动态配置问题，我们都知道，每个微服务是由springboot做支撑，每个springboot项目都会有一个application的配置文件，如果某些配置发生变化，得一个一个服务去修改，这样加大维护工作量，特别是运维老哥！ 另外每次修改配置还得重启服务，因此对动态配置也有强烈需求，基于这样的背景而产生配置中心模块。
常见配置中心技术支持有： springCloud config，nacos(主流并替换个config)。
7、服务总线
服务总线，顾名思义他是为我们所有服务提供服务，在微服务体系中通常会有一些公共的消息，比如上步骤提到的动态配置，就需要服务总线的支撑，各个微服务向服务总线订阅消息，进而监听总线，当总线发生变动时，订阅的服务可以感知，然后同步更新自己，服务总线一般搭配着消息中间件，如RabbitMq（MQ）、kafka等，此外服务总线还具有定点通知某个或多个服务的功能
总之服务总线就像一个妈妈管着一群孩子一样，通过妈妈向所有孩子或者某个孩子传达消息，从而改变孩子的某些行为或功能。
常见技术支撑有： springcloud bus，nacos