概叙
????????如上两图所示，微服务架构下，需要的组件很多，上面中也并未列全。下面将梳理一下国内微服务架构下，用到的技术栈，仅供参考。
科普文：12种常见的软件架构-CSDN博客
- 没有最好的架构，只有最适合的架构。
- 好的架构不是设计出来的，是演进变化而来的。
? ? ? ? 在前面架构介绍的文章中的两句话，也适用于微服务组件的选择。在微服务架构中，选择合适的中间件是一个重要的决策。这会影响到系统的可用性、稳定性、可扩展性和开发效率。以下是一些选择中间件的考虑因素：
系统需求：首先，你需要清楚地了解你的系统需求。这包括你的系统的规模（如用户量、请求量、数据量）、性能需求（如响应时间、吞吐量）和功能需求（如消息队列、缓存、数据库）。你选择的中间件需要能够满足这些需求。
中间件性能：你的中间件需要能够处理你的系统的负载。例如，如果你的系统需要处理大量的并发请求，那么你可能需要一个高性能的消息队列，如Kafka或RocketMQ。如果你的系统需要快速地读写数据，那么你可能需要一个高性能的缓存系统，如Redis。
中间件的稳定性和可用性：你的中间件需要是稳定和可靠的。它应该能够处理系统故障并自我恢复。此外，它应该有良好的社区支持和文档，以便在遇到问题时可以快速找到解决方案。
中间件的可扩展性：随着你的系统的增长，你的中间件需要能够轻松地扩展。这可能意味着添加更多的节点、增加存储容量或增加处理能力。
开发团队的技能和经验：你的开发团队需要能够熟练地使用你选择的中间件。这可能意味着他们需要进行培训或学习新的技术。如果你的团队已经熟悉某个中间件，那么使用这个中间件可能会更有效率。
成本：你需要考虑中间件的成本。这包括购买、部署和维护中间件的硬件和软件成本，以及开发和运维团队的人力成本。
????????在选择中间件时，你可能需要权衡这些因素。例如，一个性能优秀的中间件可能比较贵，或者需要更多的开发和运维资源。一个稳定可靠的中间件可能不具备最新的功能。因此，选择合适的中间件需要根据你的具体情况和需求进行综合考虑。
? ? ? ? 话不多说，下面开始介绍各个组件及其适用场景。
负载均衡中间件
? ? ? ? 负责均衡参考：科普文：深入理解负载均衡（四层负载均衡、七层负载均衡）_交换机聚合根据4层负载-CSDN博客
Nginx
????????比如?Nginx，Nginx（发音为?"engine-x"）是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP代理服务器。Nginx?由Igor Sysoev于2004年开发，旨在解决C10K问题（即同时处理10,000个并发连接的问题）。Nginx?因其稳定性、丰富的功能集、简单的配置文件和低资源消耗而广受欢迎。
Nginx 的用途
HTTP服务器：
Nginx?可以作为静态文件服务器，提供HTML、CSS、JavaScript和图像等静态内容的访问。反向代理：
Nginx?可以作为反向代理服务器，将客户端请求转发到后端服务器，并将响应返回给客户端。负载均衡：
Nginx?支持多种负载均衡算法，可以将请求分发到多个后端服务器，提高系统的可用性和性能。缓存：
Nginx?可以缓存后端服务器的响应，减少对后端服务器的请求，提高响应速度。SSL/TLS终结：
Nginx?可以处理SSL/TLS加密和解密，减轻后端服务器的负担。安全防护：
Nginx?可以配置各种安全策略，如访问控制、限速、防止DDoS攻击等。
Nginx 的优势
高性能：
Nginx?设计为高性能服务器，能够处理大量的并发连接，适合高流量网站。低资源消耗：
Nginx?使用异步、事件驱动的架构，相比传统的多线程服务器，资源消耗更低。高可靠性：
Nginx?设计为高可靠性服务器，支持平滑重启和升级，不影响在线服务。易于配置和扩展：
Nginx?的配置文件简洁明了，易于理解和维护。同时，Nginx?支持?？榛┱?#xff0c;可以根据需要添加新功能。社区和生态系统：
Nginx?拥有庞大的社区和丰富的生态系统，提供了大量的文档、教程和第三方模块。
Nginx 的缺点
学习曲线：虽然
Nginx?的配置文件相对简洁，但对于新手来说，仍然需要一定的学习时间来理解和掌握。动态内容支持：
Nginx?本身不支持动态内容生成，需要与后端应用服务器（如PHP-FPM、Node.js等）配合使用。?？榭?/strong>：虽然
Nginx?支持?？榛┱?#xff0c;但开发和维护第三方模块需要一定的C语言编程技能。功能限制：
Nginx?的一些高级功能（如流媒体传输）可能不如专门的软件或服务。
总的来说，Nginx?是一个高性能、低资源消耗、易于配置和扩展的HTTP和反向代理服务器，适用于各种高流量和并发连接的场景。然而，它也有一些缺点，包括学习曲线、动态内容支持和?？榭⒛讯?。在选择使用Nginx?时，需要根据具体的业务需求和技术能力进行综合考虑。
LVS (linux virtual server)
????????LVS工作在网络7层模型的传输层。
LVS（?Linux Virtual Server）?是一种在内核级别实现的4层负载均衡机制，?主要用于较大型集群环境中，?具有以下用途、?优点和缺点：?
LVS用途：?
- LVS主要工作在网络4层之上，?仅作分发之用，?没有流量的产生，?保证了均衡器IO的性能不会受到大流量的影响。?
- 它适用于对所有应用做负载均衡，?不管是http还是ssh协议都可以使用LVS。?
- LVS支持多种工作模型，?可根据业务场景使用不同的工作模式来解决生产环境请求处理问题。?
- LVS适用于需要高并发连接、?高稳定性、?低成本的大型集群环境，?特别是在对所有应用进行负载均衡的场景中表现出色
LVS优点：?
- 抗负载能力强：?LVS基于内核网络层面工作，?具有超强的承载能力和并发处理能力，?单台LVS负载均衡器可支持上万并发连接。?
- 稳定性强：?仅作分发之用，?对内存和CPU资源消耗极低，?保证了其在负载均衡软件中的性能和稳定性。?
- 成本低廉：?相比硬件负载均衡器的高成本，?LVS只需一台服务器即可免费部署使用，?性价比极高。?
- 配置简单：?LVS的配置非常简单，?仅需几行命令即可完成配置，?也可写成脚本进行管理。?
- 应用范围广：?几乎可以对所有应用做负载均衡，?包括http、?数据库、?DNS、?ftp服务等。?
- 性能卓越：?已经在多个公司使用，?可靠性非常不错，?并且是开源项目，?可以修改源代码定制自己的需求。?
LVS缺点：?
- 配置性比较低：?因为没有太多可配置的东西，?所以并不需要太多接触，?大大减少了人为出错的几率。?但这也意味着灵活性较低。?
- 不支持正则处理：?不能做动静分离，?对于需要正则处理或动静分离的场景可能不太适用。?
- 复杂性：?对于网站应用比较庞大的情况，?实施LVS/DR+Keepalived起来比较复杂，?特别是后面有Windows Server应用的机器时，?实施及配置还有维护过程较为复杂。?相对而言，?Nginx/HAProxy+Keepalived就简单多了。?
- TUNNEL模式复杂性：?虽然可以跨vlan，?但RealServer上需要部署ipip隧道?？榈?#xff0c;?网络拓扑上需要连通外网，?较复杂，?不易运维。?为了解决上述问题，?FULLNAT诞生。?
LVS集群特点：
- 有实现三种IP负载均衡技术和八种连接调度算法的IPVS软件
- 在IPVS内部实现上，采用了高效的Hash函数和垃圾回收机制，能正确处理所调度报文相关的ICMP消息
- 虚拟服务的设置数目没有限制，每个虚拟服务有自己的服务器集群
- 它支持持久的虚拟服务（如HTTP Cookie 和 HTTPS等需要该功能的支持），并提供详尽的统计数据，如连接的处理速率和报文流量等
- 针对大规模拒绝服务（Deny of Service）攻击，实现了三种防卫策略
- 有基于内容请求分发应用层交换软件KTCPVS，它也是在Linux内核中实现的
- 有相关的集群管理软件对资源进行检测，能及时将故障屏蔽，实现系统的高可用性
- 主、从调度器能周期性的进行状态同步，从而实现更高的可用性
IPVS调度算法
- 轮询（Round Robin）
- 加权轮询（Weighted Round Robin）
- 最少链接（Least Connections）
- 加权最少链接（Weighted Least Connections）
- 基于局部性的最少链接（Locality-Based Least Connections）
- 带赋值的基于局部性最少链接（Locality-Based Least Connections with Replication）
- 目标地址散列（Destination Hashing）
- 源地址散列（Source Hashing）
LVS-DR VS/DR通过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器响应直接返回给客户。这种方法没有IP渠道的开销，对集群中的真实服务器也没有必须支持IP隧道的要求，但是要求调度器与真实服务器都有一块网卡在同一物理网段上 LVS-NAT 通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器是，报文的源地址呗重写，再返回给客户，完成整个负载调度过程 LVS-TUN 采用NAT技术是，由于请求和相应报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成文瓶颈。为了解决这个问题，调度器包请求报文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多，采用VS/TUN技术后，集群系统的最大吞吐量可提高10倍LVS与Nginx对比
| 负载均衡 | 4层负载均衡 | 7层负载均衡 |
|---|---|---|
| 技术原理 | IP+TCP端口 | URL应用层（内容交换） |
| 典型代表 | LVS | Nignx、Haproxy、Mysql Proxy |
| 优缺点 | 不理解mysql、ftp、http、等应用协议，满足不了特点需求，比如动静分离，缓存自定义等；但是配置简单，效率也很高 | 对负载均衡设备要求很高，处理七层能力一般低于四层模式的部署方式，但比较智能化，如动静分离，根据不同请求定义图片，缓存，可以对客户端请求和服务器的响应进行自定义修改，极大提升了应用系统在网络层的灵活性 |
| 安全性 | SYNFlood攻击，有的软四层应用则会转发到后端服务器，有的则可以防止攻击，这个和设备有一定的关系 | 一般可以在七层进行拦截，不影响后台服务器正常运营，可以设置多种策略，过滤特定报文 |
| 应用 | 对应tcp应用，比如C/S开发的ERP | 应用广泛HTTP协议，应用主要是网站或者内部信息平台等B/S开发系统 |
| 案列 | 接收客户的syn请求，通过选择后端指定服务器，彬彬对报文中目标IP地址进行修改，改为后端服务器IP,tcp连接是直接建立，而负载均衡类似路由器作用 | 如果要根据真正的应用层内容在选择服务器，则先代理最终服务器和客户端建立连接（三次握手）后，才可能接受客户端发送的真正应用层内容报文，然后根据该报文中特定字段，加上负载均衡设备服务器选择放手，决定最终选择的内部服务器。此时充当了代理服务器 |
消息中间件
RocketMQ
????????比如RocketMQ，RocketMQ?是一个开源的分布式消息传递和流处理平台，由阿里巴巴开发并贡献给Apache软件基金会。它被设计为高吞吐量、高可用性、可扩展和低延迟的消息中间件，适用于大规模的分布式系统。
????????总的来说，RocketMQ?是一个高性能、高可用、可扩展的消息中间件，特别适合于需要高吞吐量和低延迟的大规模分布式系统。然而，它也有一些缺点，包括学习曲线、运维复杂性和社区支持。
RocketMQ 的用途
消息队列：
RocketMQ?常用作异步通信的消息队列，支持发布/订阅和点对点消息模型。流量削峰：
RocketMQ?可以用于处理流量峰值，通过消息队列缓冲大量请求，避免系统过载。数据同步：
RocketMQ?可以用于不同系统之间的数据同步，确保数据一致性。日志收集：
RocketMQ?可以作为日志收集和处理的中间件，支持大规模日志数据的实时处理。分布式事务：
RocketMQ?支持分布式事务消息，可以用于实现跨多个服务的原子操作。
RocketMQ 的优势
高吞吐量：
RocketMQ?设计为高性能消息中间件，能够处理每秒百万级的消息。高可用性：
RocketMQ?支持主从复制和故障转移，确保消息服务的持续可用性。可扩展性：
RocketMQ?支持水平扩展，可以通过添加更多的节点来增加处理能力。低延迟：
RocketMQ?提供了低延迟的消息传递，适合实时数据处理和分析。丰富的消息模型：
RocketMQ?支持多种消息模型，包括普通消息、顺序消息、延迟消息和事务消息。灵活的部署：
RocketMQ?支持多种部署方式，包括单机部署、集群部署和云原生部署。
RocketMQ 的缺点
学习曲线：虽然
RocketMQ?提供了丰富的功能，但对于新手来说，仍然需要一定的学习时间来理解和掌握。运维复杂性：随着集群规模的扩大，
RocketMQ?的运维和管理可能会变得复杂，需要专业的知识和技能。社区支持：虽然
RocketMQ?是一个Apache项目，但相比一些更成熟的消息中间件（如Kafka），其社区和生态系统可能相对较小。功能限制：在某些高级特性（如复杂的流处理和实时分析）方面，
RocketMQ?可能不如一些专门的流处理平台（如Apache Flink）。
KFK
????????KFK，?即Kafka，?是一种分布式流处理平台，?广泛应用于构建实时数据流处理管道。?
????????Kafka以其高可靠性、?可扩展性、?耐用性和高性能等特点，?在实时数据处理、?日志聚合、?系统监控与报警等领域发挥着重要作用。?然而，?其复杂性和较高的日志处理成本也是在选择使用时需要考虑的因素
????????以下是关于Kafka的用途、?优点、?缺点以及适用场景的详细介绍：?
KFK用途：?
- 消息系统：?Kafka可以用作传统的消息系统的替代者，?提供高吞吐量和可用性，?适合处理大规模的消息1。?
- 存储系统：?写入到Kafka中的数据是落地到磁盘上的，?有冗余备份，?允许producer等待确认，?通过配置可实现直到所有的replication完成才算写入成功，?保证数据的可用性1。?
- 日志聚合：?Kafka常用来替代其他日志聚合解决方案，?提供高性能、?低延迟、?高可用的日志提交存储，?配合ELK技术栈，?起到buffer的作用，?进行日志的汇流1。?
- 系统监控与报警：?收集系统指标以进行监控和故障排除，?与日志分析系统类似，?但指标是结构化数据，?而日志是非结构化文本1。?
KFK优点：?
- 可靠性：?分布式、?分区、?复制和容错，?数据流分区存储在多个机器上2。?
- 可扩展性：?消息传递系统轻松缩放，?无需?；?。?
- 耐用性：?使用分布式提交日志，?消息会尽可能快地保留在磁盘上，?因此是持久的2。?
- 高性能：?对于发布和订阅消息都具有高吞吐量，?即使存储了许多TB的消息，?也保持稳定的性能2。?
KFK缺点：?
- 日志处理的成本：?虽然Kafka适合用于日志聚合，?但日志落地导致做日志聚合更昂贵1。?
- 复杂性：?对于初学者来说，?配置和管理Kafka可能需要一定的学习和实践3。?
KFK适用场景：?
- 操作监控数据：?聚合来自分布式应用程序的统计信息，?产生操作数据的集中馈送2。?
- 跨组织服务日志收集：?从多个服务收集日志，?以标准格式提供给多个服务器2。?
- 流处理：?流行框架从主题中读取数据，?进行处理，?并将处理后的数据写入新主题供使用2。?
- 门店核销系统：?作为一种管理软件，?提供线上全渠道营销和多渠道推广引客流的功能4。?
常用消息队列对比
缓存中间件
?高并发应对策略：缓存、限流、降级
?缓存：缓解系统负载压力，提高系统响应速度。Java web应用性能分析之【高并发之缓存-多级缓存】_javaweb并发-CSDN博客
限流：控制并发访问量，?；は低趁馐芄赜跋?。
Java web应用性能分析之【高并发之限流】_web服务限流-CSDN博客
限流：深入理解微服务高可用三板斧“限流”-CSDN博客
降级：保证核心功能的稳定性，舍弃非关键业务或简化处理。
Java web应用性能分析之【高并发之降级】-CSDN博客
Redis
????????比如Redis等，Redis（Remote Dictionary Server）是一个开源的、高性能的键值对存储系统，它支持多种数据结构，如字符串、哈希、列表、***、有序***等。Redis?通常用作数据库、缓存和消息中间件。
??Redis?是一个高性能、功能丰富的键值对存储系统，适用于各种需要快速读写和实时数据处理的场景。然而，它也有一些缺点，包括内存限制、持久化开销和运维复杂性。在选择使用Redis?时，需要根据具体的业务需求和资源情况进行综合考虑。
Redis 的用途
缓存：
Redis?常用作缓存层，存储频繁访问的数据，减少数据库的负载，提高应用性能。会话存储：
Redis?可以用于存储Web应用的会话数据，支持分布式会话管理。实时分析：
Redis?支持实时数据处理和分析，适用于实时统计、排行榜等场景。消息队列：
Redis?提供了发布/订阅和列表等数据结构，可以用于构建简单的消息队列系统。分布式锁：
Redis?可以用于实现分布式锁，保证分布式系统中的数据一致性。计数器和限速器：
Redis?支持原子操作，可以用于实现计数器和限速器。
Redis 的优势
高性能：
Redis?设计为内存数据库，读写速度非?？?#xff0c;适合处理高并发的读写请求。丰富的数据结构：
Redis?支持多种数据结构，可以满足不同的业务需求。持久化：
Redis?支持数据持久化，可以将内存中的数据保存到磁盘，防止数据丢失。高可用性：
Redis?支持主从复制和哨兵机制，可以实现高可用性和故障转移。可扩展性：
Redis?支持分片（Sharding），可以通过添加更多的节点来水平扩展存储容量和处理能力。社区和生态系统：
Redis?拥有庞大的社区和丰富的生态系统，提供了大量的客户端库和工具。
Redis 的缺点
内存限制：由于
Redis?主要运行在内存中，因此存储容量受限于可用内存的大小。持久化开销：虽然
Redis?支持持久化，但持久化操作可能会影响性能，特别是在高并发场景下。运维复杂性：随着数据量和访问量的增加，
Redis?的运维和管理可能会变得复杂，需要专业的知识和技能。数据一致性：在分布式环境下，
Redis?的某些操作（如事务）可能不如传统的关系型数据库那样保证强一致性。成本：虽然
Redis?是开源的，但在大规模部署和运维时，可能需要投入较多的硬件和人力成本。
Ehcache
Ehcache优点：
支持本地缓存和分布式缓存。
提供了丰富的配置选项和缓存策略，如过期时间、最大大小、持久化等。
可以与Spring框架无缝集成。
Ehcache缺点：
在高并发环境下，性能可能不如Caffeine、Memcached和Redis。
分布式缓存功能相对较新，可能不如Redis和Memcached成熟稳定。
Ehcache适用场景：
需要本地缓存和分布式缓存的场景。
对缓存的配置和策略有较高要求的场景。
Caffeine
Caffeine优点：
提供了高性能的本地缓存实现。
支持多种缓存策略，如最大大小、过期时间、自动加载等。
可以根据应用程序的需求进行灵活的配置。
Caffeine缺点：
不支持分布式缓存，只能用作本地缓存。
不支持持久化存储。
Caffeine适用场景：
需要高性能的本地缓存的场景。
对缓存的灵活配置和策略有较高要求的场景。
?
Memcached
Memcached优点：
提供了高性能的分布式缓存实现。
支持多种数据结构和缓存策略。
可以水平扩展，适用于大规模的分布式缓存需求。
Memcached缺点：
不支持持久化存储。
功能相对较简单，不如Redis丰富。
Memcached适用场景：
需要高性能的分布式缓存的场景。
对缓存的扩展性和可伸缩性有较高要求的场景。
搜索引擎中间件
Elasticsearch
????????比如Elasticsearch，以下简称ES。ES?是一个开源的分布式搜索和分析引擎，基于Lucene库构建，广泛用于各种场景，包括全文搜索、日志和事件数据分析、实时应用监控等。
ES 的用途
全文搜索：
ES?提供了强大的全文搜索功能，支持复杂的查询和分析。日志和事件数据分析：
ES?常用于收集、存储和分析大量的日志和事件数据，支持实时数据分析。实时应用监控：
ES?可以用于监控应用程序的性能和状态，提供实时的监控和报警功能。数据聚合和分析：
ES?支持复杂的数据聚合操作，可以用于生成各种数据报表和分析结果。地理空间数据分析：
ES?提供了地理空间搜索和分析功能，支持地理位置相关的查询和可视化。
ES 的优势
分布式和高可用性：ES 是一个分布式系统，可以水平扩展，支持高可用性和容错性。
实时搜索和分析：ES 提供了近实时的搜索和分析能力，数据写入后很快就可以被搜索到。
强大的查询和聚合功能：ES 支持丰富的查询?
DSL和聚合功能，可以进行复杂的数据分析。易于使用和集成：ES 提供了
RESTful API，易于使用和集成到各种应用程序中。社区和生态系统：ES 拥有庞大的社区和丰富的生态系统，包括
Kibana（可视化）、Logstash（数据收集）和Beats（轻量级数据发送器）等。
ES 的缺点
资源消耗：
ES?需要较多的内存和CPU资源，特别是在进行大规模数据分析时。复杂性：
ES?提供了易于使用的API，但在处理复杂查询和聚合时，仍然需要一定的学习和理解成本。数据一致性：
ES?是一个近实时的系统，不保证强一致性，特别是在分布式环境下。运维挑战：随着数据量和查询量的增加，
ES?的运维和管理会变得更加复杂，需要专业的知识和技能。成本：
ES?是开源的，但在大规模部署和运维时，可能需要投入较多的硬件和人力成本。
????????总的来说，ES?是一个功能强大的搜索和分析引擎，适用于各种需要实时数据处理和分析的场景。然而，它也有一些缺点，包括资源消耗、复杂性和运维挑战。在选择使用?ES?时，需要根据具体的业务需求和资源情况进行综合考虑。
分布式服务框架
????????Spring Cloud和Spring Cloud Alibaba是两个不同的技术栈，?它们都是用于构建分布式系统的框架，?但存在一些区别。?
Spring Cloud是基于Spring Framework的一套开发工具，?用于构建分布式系统的微服务架构。?它提供了一系列的组件和库，?包括服务注册与发现、?负载均衡、?断路器、?配置管理等，?以帮助开发者快速构建和管理微服务应用。?Spring Cloud是一个完整的微服务框架，?它使用HTTP协议进行通讯，?支持通过注解(@FeignClient)的方式配置接口绑定，?集成了Ribbon+RestTemplate进行服务调用，?支持多种服务降级框架如Hystrix和Sentinel等12。?
Spring Cloud Alibaba是在Spring Cloud基础上集成了阿里巴巴的一些开源组件，?如Nacos、?Sentinel、?Dubbo等。?Nacos作为一个服务注册与发现中心，?可以替代Eureka；?Sentinel是一个流量控制和熔断降级的组件，?可以替代Hystrix；?Dubbo是一个高性能的RPC框架，?可以替代Feign。?Spring Cloud Alibaba实际上对Spring Cloud实现了拓展组件功能，?提供了更多的选择和功能，?适用于大规模的分布式系统架构13。?
????????总结来说，?Spring Cloud是一个广泛使用的、?成熟的微服务框架，?它与Spring Framework紧密集成，?提供了丰富的功能和组件。?而Spring Cloud Alibaba则是在Spring Cloud基础上集成了阿里巴巴的中间件，?提供了更多针对性的解决方案，?适用于需要阿里巴巴中间件技术支持的场景。?选择使用哪个框架要根据具体需求、?团队技术栈和中间件依赖来决定。
一、SpringCloud组件的升级与替换
? ? ? ? 由于SpringCloud Netflix原先的一些组件进入停更维护状态，因此这些组件逐渐被SpringCloud Alibaba一些新技术所替代。
????????SpringCloud Alibaba，实际上对我们的SpringCloud2.x和1.x实现拓展组件功能。
????????1.Nacos=分布式配置中心+分布式注册中心=Eureka+Config。
????????2.目的是为了推广阿里的产品，如果使用了SpringCloud Alibaba，最好使用alibaba整个体系产品。
二、服务注册中心的比较
1、根据CAP理论对注册中心进行分类
- ????????保证CP（注重一致性）：Zookeeper、Consul
- ????????保证AP（注重可用性）：Eureka
- ????????既支持CP又支持AP：Nacos
2、Zookeeper通过Zab协议保证强一致性
????????因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像Zookeeper那样使整个注册服务瘫痪。
????????所有的写请求必须经过leader节点传递给其他follower节点。
????????但是当leader节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。
3、Eureka保证高可用性
????????Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用，只不过查到的信息可能不是最新的(不保证强一致性)。
????????此外，Eureka还有自我保护机制：如果在15分钟内超过85%的节点都没有正常的心跳（短时间内丢失过多客户端），那么Eureka就认为客户端与注册中心出现了网络故障（如不是服务真的不可用了），此时会开启自我?；せ?#xff1a;
????????Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
????????Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)。
????????当网络稳定时，当前实例新的注册信息会被同步到其它节点中。
????????因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像Zookeeper那样使整个注册服务瘫痪。
4、Nacos既支持AP模式又支持CP模式
????????AP模式：不需要存储服务级别信息且服务实例是通过nacos-clinet注册，且能够保持心跳上报，可采用AP模式。如SpringCloud服务。AP模式下只支持注册临时实例。
????????CP模式：如需要在服务级别编辑或存储配置信息，则需使用CP模式，如K8S,DNS。AP模式下只支持注册持久化实例。
三、服务调用框架的比较
1、Ribbon
????????Ribbon是一套客户端负载均衡的工具，使用时需与RestTemplate配合使用。
????????使用是需要模拟http请求然后使用RestTemplate发送给其他服务，步骤比较繁琐。
????????负载均衡：支持轮询、随机、空闲策略、响应时间策略。
2、OpenFeign
????????同样使用HTTP协议进行通讯。
????????使用时只需创建一个接口并使用注解（@FeignClient)的方式配置， 即可完成对服务提供方的接口绑定，是对Ribbon+RestTemplate的进一步封装。
????????OpenFeign内部集成了 Ribbon，本质上是通过Ribbon完成负载均衡功能。
3、Dubbo
????????支持多种传输协议：Dubbo、Rmi、http、redis。适合数据量小、高并发和服务提供者远远少于消费者的场景。
????????负载均衡：支持随机、轮询、活跃度、Hash一致性，负载均衡的算法可以精准到某个服务接口的某个方法。
四、服务降级框架的比较
? ? ? ? Hystrix和Sentinel的比较
????????Hystrix本身就是一个非常出色的熔断降级框架，Sentinel则是在Hystrix的基础上对其进行进一步的升级。
????????Sentinel使用更方便：Sentinel提供了一个非常简洁的控制台界面，在控制台界面中即可非常方便地配置限流降级规则。
服务治理中间件
Nacos
????????比如Nacos，Nacos（Dynamic Naming and Configuration Service）是一个开源的、易于使用的平台，用于动态服务发现、配置管理和服务管理。Nacos?由阿里巴巴开发并开源，旨在帮助开发者更轻松地构建云原生应用。
Nacos 的用途
服务发现：
Nacos?提供了服务注册和发现功能，帮助服务提供者和消费者之间进行动态的连接。配置管理：
Nacos?支持动态配置服务，允许应用在不重启的情况下更新配置，实现配置的热更新。服务管理：
Nacos?提供了服务元数据管理、流量管理和服务健康检查等功能。动态 DNS 服务：
Nacos?支持基于DNS的服务发现，可以与Kubernetes等容器编排平台集成。
Nacos 的优势
易于使用：
Nacos?提供了简洁的API和用户界面，使得服务注册、发现和配置管理变得简单易用。动态配置：
Nacos?支持配置的热更新，可以在不重启应用的情况下动态更新配置。高可用性：
Nacos?设计为高可用系统，支持集群部署，确保服务的稳定性和可靠性。多环境支持：
Nacos?支持多种环境（如开发、测试、生产）的配置管理和服务发现。丰富的生态系统：
Nacos 与Spring Cloud、Dubbo、Kubernetes等云原生技术紧密集成，提供了丰富的生态系统。社区支持：Nacos 是一个活跃的开源项目，拥有一个庞大的社区，提供了丰富的文档和示例。
Nacos 的缺点
学习曲线：虽然
Nacos?提供了简洁的API和用户界面，但对于新手来说，仍然需要一定的学习时间来理解和掌握。运维复杂性：随着集群规模的扩大，
Nacos?的运维和管理可能会变得复杂，需要专业的知识和技能。功能限制：虽然
Nacos?提供了丰富的功能，但在某些高级特性（如复杂的流量管理）方面，可能不如一些商业服务发现和配置管理解决方案。性能问题：在高并发和大规模数据处理场景下，
Nacos?的性能可能会受到影响，需要进行优化和调整。
总的来说，Nacos?是一个功能丰富、易于使用的服务发现和配置管理平台，特别适合于云原生应用和微服务架构。然而，它也有一些缺点，包括学习曲线、运维复杂性和功能限制。
分布式文件系统中间件
MinIO?
????????比如Minio等，MinIO?是一个开源的高性能对象存储系统，它兼容?Amazon S3 API，适用于存储大规模非结构化数据，如图片、视频、日志文件、备份和容器/虚拟机镜像等。MinIO?特别适合于私有云和混合云环境。
MinIO 的用途
对象存储：
MinIO?提供了一个高性能的对象存储解决方案，可以用于存储和管理大量的非结构化数据。云原生应用：
MinIO?设计为云原生应用，可以与Kubernetes等容器编排平台无缝集成。数据备份和归档：
MinIO?可以用于数据备份和长期归档，支持数据的高可用性和持久性。内容分发：
MinIO?可以用于内容分发网络（CDN），提供快速和可靠的内容交付服务。数据湖：MinIO 可以作为数据湖的基础存储层，支持大规模数据分析和处理。
MinIO 的优势
高性能：
MinIO?设计为高性能对象存储，支持高并发和低延迟的数据访问。兼容S3：
MinIO?完全兼容Amazon S3 API，可以无缝替换或集成现有的S3应用。易于部署和管理：
MinIO?提供了简单的部署和管理工具，支持快速启动和扩展。云原生：
MinIO?是一个云原生应用，支持容器化部署，与Kubernetes等云原生技术紧密集成。开源和社区支持：
MinIO?是一个活跃的开源项目，拥有一个庞大的社区，提供了丰富的文档和示例。
MinIO?的缺点
资源消耗：虽然
MinIO?设计为高性能，但在处理大规模数据时，仍然需要较多的硬件资源，包括CPU、内存和存储。运维复杂性：随着集群规模的扩大，
MinIO?的运维和管理可能会变得复杂，需要专业的知识和技能。数据一致性：
MinIO?在分布式环境下提供了高可用性和持久性，但在某些情况下，数据一致性可能不如传统的分布式文件系统。功能限制：虽然
MinIO?提供了丰富的功能，但在某些高级特性（如跨区域复制）方面，可能不如一些商业对象存储解决方案。
????????总的来说，MinIO?是一个高性能、易于部署和管理的对象存储系统，特别适合于云原生应用和大规模数据存储场景。然而，它也有一些缺点，包括资源消耗、运维复杂性和功能限制。在选择使用MinIO?时，需要根据具体的业务需求和资源情况进行综合考虑。
分布式事务中间件
Seata
????????比如Seata等，用于解决分布式系统中的事务一致性问题。
????????Seata 是一个开源的分布式事务解决方案，旨在提供高性能和易于使用的分布式事务服务。它主要用于解决微服务架构中的分布式事务问题，确保在多个服务或数据库之间的事务一致性。
Seata 的用途
分布式事务管理：Seata 提供了一套完整的分布式事务管理机制，包括全局事务的协调、分支事务的执行和回滚等。
微服务架构：在微服务架构中，不同的服务可能使用不同的数据库，Seata 可以帮助这些服务之间保持数据一致性。
数据库事务：Seata 支持多种数据库，可以与各种数据库事务集成，确保跨数据库的事务一致性。
Seata 的优势
高性能：
Seata?设计了高效的协议和算法，以确保在分布式环境中的高性能和低延迟。易于使用：
Seata?提供了简单易用的API和配置，使得开发者可以轻松地集成和使用分布式事务功能。灵活性：
Seata?支持多种事务模式，包括?AT、TCC、Saga?和?XA?模式，可以根据不同的业务场景选择合适的事务模式。可扩展性：Seata 的设计考虑了可扩展性，可以方便地集成到现有的微服务架构中，并且支持水平扩展。
社区支持：Seata 是一个活跃的开源项目，拥有一个庞大的社区，提供了丰富的文档和示例，便于开发者学习和使用。
Seata 的缺点
复杂性：分布式事务本身就是一个复杂的问题，
Seata?虽然简化了开发过程，但仍然需要开发者理解分布式事务的原理和Seata的工作机制。性能开销：尽管
Seata?设计了高效的协议和算法，但分布式事务的协调和通信仍然会带来一定的性能开销。依赖性：
Seata?需要依赖于其他组件（如注册中心、配置中心等），这增加了系统的复杂性和维护成本。学习曲线：对于新手来说，
Seata?的学习曲线可能比较陡峭，需要花费一定的时间和精力来理解和掌握。
????????总的来说，Seata?是一个强大的分布式事务解决方案，它提供了高性能和易于使用的特性，但也带来了一定的复杂性和性能开销。在选择使用?Seata?时，需要根据具体的业务场景和需求进行权衡。
TAG：微服务框架
客服1 