阅读量:4
概叙
如上两图所示，微服务架构下，需要的组件很多，上面中也并未列全。下面将梳理一下国内微服务架构下，用到的技术栈，仅供参考。
- 没有最好的架构，只有最适合的架构。
- 好的架构不是设计出来的，是演进变化而来的。
在前面架构介绍的文章中的两句话，也适用于微服务组件的选择。在微服务架构中，选择合适的中间件是一个重要的决策。这会影响到系统的可用性、稳定性、可扩展性和开发效率。以下是一些选择中间件的考虑因素：
系统需求：首先，你需要清楚地了解你的系统需求。这包括你的系统的规模（如用户量、请求量、数据量）、性能需求（如响应时间、吞吐量）和功能需求（如消息队列、缓存、数据库）。你选择的中间件需要能够满足这些需求。
中间件性能：你的中间件需要能够处理你的系统的负载。例如，如果你的系统需要处理大量的并发请求，那么你可能需要一个高性能的消息队列，如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支持模块化扩展，可以根据需要添加新功能。社区和生态系统：
Nginx拥有庞大的社区和丰富的生态系统，提供了大量的文档、教程和第三方模块。
Nginx 的缺点
学习曲线：虽然
Nginx的配置文件相对简洁，但对于新手来说，仍然需要一定的学习时间来理解和掌握。动态内容支持：
Nginx本身不支持动态内容生成，需要与后端应用服务器（如PHP-FPM、Node.js等）配合使用。模块开发：虽然
Nginx支持模块化扩展，但开发和维护第三方模块需要一定的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隧道模块等，网络拓扑上需要连通外网，较复杂，不易运维。为了解决上述问题，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。
- 耐用性：使用分布式提交日志，消息会尽可能快地保留在磁盘上，因此是持久的2。
- 高性能：对于发布和订阅消息都具有高吞吐量，即使存储了许多TB的消息，也保持稳定的性能2。
KFK缺点：
- 日志处理的成本：虽然Kafka适合用于日志聚合，但日志落地导致做日志聚合更昂贵1。
- 复杂性：对于初学者来说，配置和管理Kafka可能需要一定的学习和实践3。
KFK适用场景：
- 操作监控数据：聚合来自分布式应用程序的统计信息，产生操作数据的集中馈送2。
- 跨组织服务日志收集：从多个服务收集日志，以标准格式提供给多个服务器2。
- 流处理：流行框架从主题中读取数据，进行处理，并将处理后的数据写入新主题供使用2。
- 门店核销系统：作为一种管理软件，提供线上全渠道营销和多渠道推广引客流的功能4。
常用消息队列对比
缓存中间件
高并发应对策略：缓存、限流、降级
缓存：缓解系统负载压力，提高系统响应速度。Java web应用性能分析之【高并发之缓存-多级缓存】_javaweb并发-CSDN博客
限流：控制并发访问量，保护系统免受过载影响。
Java web应用性能分析之【高并发之限流】_web服务限流-CSDN博客
降级：保证核心功能的稳定性，舍弃非关键业务或简化处理。
Java web应用性能分析之【高并发之降级】-CSDN博客
Redis
比如Redis等，Redis（Remote Dictionary Server）是一个开源的、高性能的键值对存储系统，它支持多种数据结构，如字符串、哈希、列表、集合、有序集合等。Redis 通常用作数据库、缓存和消息中间件。
Redis 是一个高性能、功能丰富的键值对存储系统，适用于各种需要快速读写和实时数据处理的场景。然而，它也有一些缺点，包括内存限制、持久化开销和运维复杂性。在选择使用Redis 时，需要根据具体的业务需求和资源情况进行综合考虑。
Redis 的用途
缓存：
Redis常用作缓存层，存储频繁访问的数据，减少数据库的负载，提高应用性能。会话存储：
Redis可以用于存储Web应用的会话数据，支持分布式会话管理。实时分析：
Redis支持实时数据处理和分析，适用于实时统计、排行榜等场景。消息队列：
Redis提供了发布/订阅和列表等数据结构，可以用于构建简单的消息队列系统。分布式锁：
Redis可以用于实现分布式锁，保证分布式系统中的数据一致性。计数器和限速器：
Redis支持原子操作，可以用于实现计数器和限速器。
Redis 的优势
高性能：
Redis设计为内存数据库，读写速度非常快，适合处理高并发的读写请求。丰富的数据结构：
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就认为客户端与注册中心出现了网络故障（如不是服务真的不可用了），此时会开启自我保护机制：
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 时，需要根据具体的业务场景和需求进行权衡。
