这节我们来讲讲分布式相同类型的框架和组件该如何选型。

分布式、微服务和集群的定义

首先我们得了解什么是这三种东西分别代表的是什么意思。

分布式：
分布式官方给的名词解释是 “分布式系统（distributed system）是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。”简单点说分布式就是将一个业务拆分成多个子业务，部署在多台服务器上，从而分散服务器的压力，提升吞吐量。

集群
集群跟分布式正好相反，它是将一个业务同时部署在多个服务器中，当一个服务器因某种原因宕机时，可以及时切换到另一服务器，从而实现高可用。

微服务
微服务是一种架构思想，一个大型复杂软件应用由一个或多个微服务组成，系统中各个微服务可以独立部署，互不影响，每个微服务只关注完成一个任务，而这个任务一般指的是系统中的一个业务。

总结
分布式是微服务的一种实现，而在系统中分布式和集群之间一定是搭配使用的，每个子业务之间搭配集群，从而实现高并发与高可用。

CAP原则

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。

它的精髓在于它无法同时满足一致性、可用性和分区容错性，要么CA、要么CP、要么AP，无法满足CAP。

Springcloud和Dubbo

Springcloud是Spring公司开源的微服务框架，SpirngCloud 定位为微服务架构下的一站式解决方案。而Dubbo是阿里巴巴开源的RPC框架，Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。下面有张图列出的它们之间的区别：

从中可以看出Spring Cloud 的功能很明显比 Dubbo 更加强大，涵盖面更广，而且作为 Spring 的旗舰项目，它也能够与 Spring Framework、Spring Boot、Spring Data、Spring Batch 等其他 Spring 项目完美融合，这些对于微服务而言是至关重要的。

SpringCloud生态丰富，功能完善，更像是品牌机，Dubbo则相对灵活，可定制性强，更像是组装机。

Feign和Dubbo远程调用的差异

Feign是springcloud的远程调用方式，它是基于HTTP实现的，所有的接口都是restful风格，接口规范统一，实现接口的微服务可以采用任意语言或技术开发。但受限于http协议本身的特点，请求和响应格式臃肿，其通信效率相对会差一些。

Dubbo框架默认采用Dubbo自定义通信协议，与Http协议一样底层都是TCP通信。但是Dubbo协议自定义了Java数据序列化和反序列化方式、数据传输格式，因此Dubbo在数据传输性能上会比Http协议要好一些。

相关概念：

1）Rest风格

REST是一种架构风格，指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。

Rest的风格可以完全通过HTTP协议实现，使用 HTTP 协议处理数据通信。REST架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。

因此请求和想要过程只要遵循http协议即可，更加灵活

SpringCloud中的Feign就是Rest风格的调用方式。

2）RPC
Remote Procedure Call，远程过程调用，就是像调用本地方法一样调用远程方法。
RPC一般要确定下面几件事情：

数据传输方式：多数RPC框架选择TCP作为传输协议，性能比较好。
数据传输内容：请求方需要告知需要调用的函数的名称、参数、等信息。
序列化方式：客户端和服务端交互时将参数或结果转化为字节流在网络中传输，那么数据转化为字节流的或者将字节流转换成能读取的固定格式时就需要进行序列化和反序列化
因为有序列化和反序列化的需求，因此对数据传输格式有严格要求，不如Http灵活

Dubbo协议就是RPC的典型代表。

注册中心的选型

设计或者选型一个服务注册中心，首先要考虑的就是服务注册与发现机制。纵观当下各种主流的服务注册中心解决方案，大致可归为三类：

1，应用内：
直接集成到应用中，依赖于应用自身完成服务的注册与发现，最典型的是Netflix提供的Eureka。

2，应用外：
把应用当成黑盒，通过应用外的某种机制将服务注册到注册中心，最小化对应用的侵入性，比如Airbnb的SmartStack，HashiCorp的Consul。

3，DNS
将服务注册为DNS的SRV记录，严格来说，是一种特殊的应用外注册方式，SkyDNS是其中的代表。但此种模式存在缓存缺陷。

除了基本的服务注册与发现机制，从开发和运维角度，至少还要考虑如下五个方面：

测活：服务注册之后，如何对服务进行测活以保证服务的可用性？
负载均衡：当存在多个服务提供者时，如何均衡各个提供者的负载？
集成：在服务提供端或者调用端，如何集成注册中心？
运行时依赖：引入注册中心之后，对应用的运行时环境有何影响？
可用性：如何保证注册中心本身的可用性，特别是消除单点故障？

各注册中心区别：

API网关Gateway和Zuul

1、Zuul：
使用的是阻塞式的 API，不支持长连接，比如 websockets。
底层是servlet，Zuul处理的是http请求
没有提供异步支持，流控等均由hystrix支持。
依赖包spring-cloud-starter-netflix-zuul。

2、Gateway：
底层依然是servlet，但使用了webflux，多嵌套了一层框架
依赖spring-boot-starter-webflux和/ spring-cloud-starter-gateway
提供了异步支持，提供了抽象负载均衡，提供了抽象流控，并默认实现了RedisRateLimiter。

总结

相同点：

底层都是servlet
两者均是web网关，处理的是http请求

不同点：

gateway对比zuul多依赖了spring-webflux，在spring的支持下，功能更强大，内部实现了限流、负载均衡等，扩展性也更强，但同时也限制了仅适合于Spring Cloud套件
zuul则可以扩展至其他微服务框架中，其内部没有实现限流、负载均衡等。
zuul仅支持同步
gateway支持异步。理论上gateway则更适合于提高系统吞吐量（但不一定能有更好的性能），最终性能还需要通过严密的压测来决定

下面再介绍几个springcloud的组件：

cloud中最常见的就是netflix五大组件了：

Eureka：服务治理组件，包括服务端的注册中心和客户端的服务发现机制；
Ribbon：负载均衡的服务调用组件，具有多种负载均衡调用策略；
Hystrix：服务容错组件，实现了断路器模式，为依赖服务的出错和延迟提供了容错能力；
Feign：基于Ribbon和Hystrix的声明式服务调用组件；
Zuul：API网关组件，对请求提供路由及过滤功能。

其余SpringCloud中还有：

Spring Cloud Bus
用于传播集群状态变化的消息总线，使用轻量级消息代理链接分布式系统中的节点，可以用来动态刷新集群中的服务配置。
Spring Cloud Consul
基于Hashicorp Consul的服务治理组件。
Spring Cloud Security
安全工具包，对Zuul代理中的负载均衡OAuth2客户端及登录认证进行支持。
Spring Cloud Sleuth
Spring Cloud应用程序的分布式请求链路跟踪，支持使用Zipkin、HTrace和基于日志（例如ELK）的跟踪。
Spring Cloud Stream
轻量级事件驱动微服务框架，可以使用简单的声明式模型来发送及接收消息，主要实现为Apache Kafka及RabbitMQ。
Spring Cloud Task
用于快速构建短暂、有限数据处理任务的微服务框架，用于向应用中添加功能性和非功能性的特性。
Spring Cloud Zookeeper
基于Apache Zookeeper的服务治理组件。
Spring Cloud Gateway
API网关组件，对请求提供路由及过滤功能。
Spring Cloud OpenFeign
基于Ribbon和Hystrix的声明式服务调用组件，可以动态创建基于Spring MVC注解的接口实现用于服务调用，在Spring Cloud 2.0中已经取代Feign成为了一等公民。

最后，如果觉得该篇文章对你有用，可以关注一下我的公众号。感谢各位的浏览！

分布式系统组件的选型相关推荐

关于数据仓库的架构及3大类组件工具选型
关于数据仓库的概念.原理.建设方法论,网上已经有很多内容了,也有很多的经典书籍,本文更想聊聊企业数据仓库项目上的架构和组件工具问题. 先来谈谈架构. 企业数据仓库架构关于数据仓库,有一种简单粗暴的说 ...
如何从Vant Weapp、MinUI、iView Weapp、Wux Weapp、ColorUI共5个小程序组件库选型转载
前言发展到今天,手机端组件库其实已经大同小异,熟练的程序员甚至都能背过80%的组件名称,比如toast.cell.checkbox--,来来回回就是这么些,那么,面对市面上最火的5个小程序组件库,我 ...
微服务.链路追踪概述和方案 (Cat Zipkin Skywaking，Sluth等组件对比选型)
概述为什么追踪链路 1. 单体应用过渡到微服务 2. 微服务必须导致调用熵增加 3. 单体应用中两个问题显现出来:根据日志查询问题:调用链路和调用的性能. 4. 日志问题在以后的日志方案中研 ...
RN常用UI组件技术选型
rn默认提供的控件比较基础,我们想要达到一个开箱即用的体验来构建常用app的UI,不可避免的需要用到自定义的组件库. 那么对于快速开发来说,我们选择一个不错的第三方组件库就是一件很重要的事.经过调研, ...
可视化搭建平台的地图组件和日历组件方案选型
可视化搭建平台除了需要为用户提供简单便捷的操作方式之外, 还需要提供丰富的组件支持和组件扩展, 这样才能满足更多用户的业务需求. 在 H5-dooring 创建的初期主要考虑的方向是用户使用的便捷性, ...
滴滴实时数据链路建设组件选型实践篇
写在前面随着滴滴内部技术栈的不断统一,实时相关技术组件资源的不断整合,各业务线实时数据相关开发经验的不断沉淀,基本形成了一套面向公司不同业务场景需求的最佳技术选型和具体落地方案.但同时我们也发现,大 ...
【温故而知新】分布式系统（一）
分布式系统的重要性时间:2022年12月05日作者:小蒋聊技术 [温故而知新]分布式系统(一)·分布式系统的重要性_小蒋聊技术_免费在线阅读收听下载 - 喜马拉雅手机版欢迎收听小蒋聊技术的其他类最 ...
一致性哈希算法及其在分布式系统中的应用
摘要本文将会从实际应用场景出发,介绍一致性哈希算法(Consistent Hashing)及其在分布式系统中的应用.首先本文会描述一个在日常开发中经常会遇到的问题场景,借此介绍一致性哈希算法以及这个 ...
协鑫集成的这款组件，真的很适合农光互补！
在刚刚结束的第十二届中国(济南)太阳能利用大会暨展览会上,协鑫集成重点展示了其主打的金刚系列组件,在同期举行的第五届中国光伏农业高峰论坛上,协鑫集成产品工程师周英杰就白色双玻组件在光伏农业上的应用做了 ...

分布式系统组件的选型