读书笔记-SpringCloudAlibaba微服务原理与实战-谭锋-【未完待续】
SpringCloudAlibaba微服务原理与实战 谭锋 电子工业出版社
ISBN-9787121388248
仅供参考, 自建索引, 以备后查
一、应用架构演进、微服务发展史
1.单体架构
一般来说，如果一个WAR包或JAR包就能包含一个应用程序的所有功能，我们就称其为 单体架构。早期互联网公司或创业型公司中，这种架构由于足够简单，能够快速开发上线，且初期用户量不大，单体架构足以满足业务的正常运行。
2.集群及垂直化
若应用程序需要长期运营，则单体架构面临了诸多挑战，用户量增大，服务器负载增大，业务场景越来越复杂。慢慢的，服务器的响应会越来越慢。而且单体架构中，随着业务复杂程序的提升，业务之间的耦合度越来越高，对代码维护和升级等也愈发困难。
此时，可以横向扩展，即增加服务器，单台变集群；或者把业务拆分，减少耦合度，即增加Tomcat服务器，变为服务集群，每个Tomcat服务器包含一个或多个业务子系统；同时拆分数据库，分库分表。
3.SOA (Service-Oriented Architecture) 面向服务架构
在上面介绍的集群模式中，各个业务在一个或多个Tomcat服务器中，但是业务之间存在调用关系，则会存在这么多检查逻辑，共享业务等，这些都会产生非常多的冗余代码。
针对以上问题，SOA架构应运而生，它和 面向过程、面向对象、面向组件的思想一致，是利用软件组建及开发的方式。SOA架构目标是把通用的，会被上层服务调用的共享业务提取封装为基础服务，这些基础服务可以被重用且相对独立。总体来说，SOA架构解决信息孤岛，增强了共享业务的重用。
4.微服务架构
泛泛来讲，微服务是SOA的子集，对可重用业务服务的进一步优化，即把服务拆分的更加细化，如原本10个服务（模块）拆分为100个微服务（模块）。不过一旦如此，服务的构建、发布及运维复杂度也会成倍增加，所以微服务的前提是 软件交付链路 及 基础设施的成熟。在此书作者来看，微服务是SOA服务化思想的最佳实践。
SOA关注点在于服务的重用及解决信息孤岛；而微服务关注的是解耦，虽然特定程序上来说，解耦和重用类似；另外，微服务更多的关注于应用的版本更新，持续交付；同时，由于服务粒度细化，开发运维更加重要，所以为了避免运行环境的一致性问题，微服务与容器技术关联的更加紧密。
业务构建为可独立运行的微服务后，每个微服务仅关心某个特定功能，服务之间采用RESULT API通信。开发人员更加能关注某个特定业务，如注册服务等。
微服务的优势：
复杂度可控：一句话来讲，就是拆分颗粒度，细化到极致还是达到某种程序；
技术灵活度：只需要遵循对外接口访问规则，每个微服务的实现自由度高；
可扩展性强：单个微服务可以保留一个，亦可以作为集群来部署；
独立部署：微服务单独运行，不影响到其它业务；
容错性：若某个微服务故障，调用者可以重试、降级、熔断等或默认返回调用结果。
面临的挑战：
微服务并不能解决所有问题，虽然本身优势人多，但也带来了诸多挑战。如：数据库如何拆分、API交互、开发维护和运维等。更多的是如下问题：
故障排查：一个请求可能会调用数个微服务，交互链路复杂，若要定位故障位置比较困难；
服务监控：单体架构中很容易实现监控，毕竟所有功能集中在一起。而微服务架构中，服务监控比较复杂，成千上万个微服务需要监控，性能开销较大；
分布式架构的复杂性：微服务其实也是一个分布式系统，涉及到各个服务之间的远程通信，所以通信的弊病，网络延迟和网络故障是很淘宝网的；
服务之间的依赖：服务之间的调用问题，若依赖较多，则系统调用显而易见的会复杂的多；
运维成本：保证成千上万微服务正常支行，挑战巨大，如：快速扩容、单点故障、快速部署和统一管理等。
典型的微服务架构：
除了图中提到的，还需要考虑：分布式配置中心、服务路由、负载均衡、熔断限流和链路监控等
二、SpringCloud简介
Spring Cloud 简述
微服务架构最先考虑的是服务间的远程通信问题，目前有许多的RPC框架，如 Thrift、Dubbo、Motan、gPRC等。接着要考虑服务之间的动态感知，总不能硬编码调用地址吧。由于此类问题浮现，最终在2015年诞生了SpringCloud，目前流行的版本有 Spring Cloud Netflix 、 Spring Cloud Alibaba 和 Spring Cloud Consul。
SpringCloud主要致力于解决如下问题：
- Distributed/versioned configuration 分布式及版本配置；
- Service registration and discovery 服务的注册与发现；
- Routing 服务路由；
- Service-to-service calls 服务间的调用；
- Load balancing 负载均衡；
- Circuit Breakers 熔断；
- Global locks 全局锁；
- Leadership election and cluster state 主服务的选举及集群状态；
- Distributed messaging 分布式消息。
SpringCloud并不是全新研发的框架，而是根据相应的规范整合了一些已经存在且比较优秀的开源框架，结合SpringBoot屏蔽掉了每个框架的复杂配置，开发者可以快速上手使用。事实上，SpringCloud是一套规范。
SpringCloud版本的全名规则不同以往，而是采用了伦敦地铁站的名字来定义。而且，大版本号后面多了 .SRX 字样，其中SR为Service Release，X为递增的数字，每当更新内容积累到一定程序或修复了Bug后，会增加X来发布新版本。
除此之外，SpringCloud依赖SpringBoot，所以需要在使用时注意相应的版本。
Spring团队最厉害的地方是他们很少造轮子，这是作者的有的话。Spring Framework最核心的功能是IoC和AOP，对于ORM、MVC等，Spring都提供了非常好的兼容性，如Hibernate、MyBatis、Struts2。而SpringMVC是由于考虑到Struts2的安全漏洞才造出来的，同样的还有Spring Cloud Gateway，来取代Zuul网关的。
目前最主要的两个SpringCloud解决方案是Spring Cloud Netflix和Spring Cloud Alibaba。
Spring Cloud Netflix 解决方案
SpringCloud Netflix的微服务框架包含了如下组件：
- Eureka 服务注册与发现；
- Zuul 服务网关；
- Ribbon 负载均衡；
- Feign 远程服务的客户端代理；
- Hystrix 断路器，服务熔断和限流功能；
- Hystrix Dashboard 监控面板；
- Turbine 聚合管理各个服务上的Hystrix监控信息。
Spring Cloud Netflix是SpringBoot和Netflix OSS （Netflix Open Source Software）在Spring Cloud规范下的产物，而Eureka、Zuul等都是Netflix OSS的开源组件。不过有些组件已被标记为维护模式，将不会再有重大功能更新，只会修复bug及安全问题，如：Spring-Cloud-Netflix-Hystrix、Spring-Cloud-Netflix-Ribbon和Spring-Cloud-Netflix-Zuul等。
Spring Cloud Alibaba 解决方案
Spring Cloud Alibaba是阿里巴巴集团下的开源组件和云产品在Spring Cloud规范下的实现，主要组件如下：
- Sentinel 流量控制和服务降级；
- Nacos 服务注册与发现、分布式配置中心；
- RocketMQ 消息驱动、消息队列；
- Seate 分布式事务；
- Dubbo RPC通信；
- OSS 阿里云对象存储（收费云服务）。
优势：
相对于 Spring Cloud Netflix，Alibaba的优势主要有两点。Alibaba的开源组件，在实现Spring Cloud规范之前就已经被各大公司使用，所以可以让开发者轻松实现技术整合与迁移。如Dubbo早就支持了多种通信，迁移不会投入太多成本。另外，由于经历数次双11的考验，所以Alibaba的开源组件在服务治理及高并发处理上有天然优势。
三、SpringBoot、自动装配、自定义Starter
四、ZooKeeper、 Dubbo （Dubbo、Apache Dubbo、Dubbo Spring Cloud）
五、Nacos服务注册发现
六、Nacos配置管理
七、Sentinel微服务限流及熔断
八、分布式事务
数据库事务：从事务开始到结束的所有数据库操作，要么同时成功，要么同时失败。
ACID：原子性 Atomicity 一致性 Consistency 隔离性 Isolation 持久性 Durability
分布式事务应用场景：单体数据库纵向拆分为多个平行的数据库后，由于数据库事务仅支持单个数据库，当需要对多库实现事务时，需用到分布式事务
分布式事务问题也叫 分布式数据一致性问题，实际应用中，就尽可能从设计层避免分布式事务问题
X/Open 分布式事务模型 2PC
X/Open DTP (X/Open Distributed Transaction Processing Reference Model)
两阶段提交(2PC, Two-Phase-Commit)，包含有三种角色：
- AP：Application 用户应用程序
- RM：Resource Manager 资源管理器，即数据库等
- TM：Transaction Manager 事务管理器，事务协调者，为AP提供编程接口管理RM等。类似于 Spring 中 Transaction Manager
RM 注册到 TM，AP 从 TM 申请 RM 连接，生成全局事务并获取 XID。之后 AP 加入 XID 参数执行操作，事务结束，TM 通知事务结束并根据 RM 执行结果执行提交或回滚操作。TM 与 多个 RM 之间的事务控制是基于 XA (XA Specification) 协议来完成的，Oracle、MySQL、DB2 实现了此 XA 协议接口。
两阶段提交 2PC：
- 准备阶段：TM 通知 RM 准备分支事务，记录事务日志，反馈准备结果
- 提交/回滚阶段：任何一个 RM 执行失败则回滚，全部成功才提交
缺点：
- 同步阻塞：所有参与者 RM 阻塞等待下一步指令
- 过于保守：任何一个 RM 结点失败就回滚
- TM单点故障：若 TM 故障则所有 RM 参与者会一直锁定
- 数据不一致：多个 RM 在最后提交阶段出现局部故障
三阶段提交（加入超时机制，避免资源永久锁定）
- CanCommit 询问阶段：TM 询问 RM 是否可以执行指令
- PreCommit 准备阶段：TM 向 RM 发起 PreCommit 请求，RM 执行操作并写入 redo 和 undo 日志，等待下一步指令
- DoCommit 提交/回滚阶段：根据上一阶段执行结果告知 RM 执行 提交或回滚 操作
CAP定理
CAP定理，又名 布鲁乐定理。 简单来说指：在分布式系统中不能同时满足 一致性 Consistency、可用性 Availability 和 分区容错性 Partition Tolerance，最多同时满足两个，如满足 CP 或 AP，不可能实现 CAP 或 CA。原因是 网络通信 不是绝对可靠，网络延时、网络异常时常发生。
- C：数据在多个副本中保持强一致，如主从数据库
- A：系统对外提供访问，任何时候都能获得响应
- P：分布式系统中遇到分区故障，系统仍能正常对外提供服务
CP 模式：两阶段与三阶段提交就是采用这种方案，可能导致用户完成操作需要等待较长时间的问题
AP 模式：放弃强一致，运用其它技术实现最终一致，AP 模式是解决分布式数据一致性问题的主要选择
BASE理论
基于CAP中CA模式不可实现而衍生的新思想，通过牺牲数据一致性获得高可用性，有以下有三个特性：
- Basically Available 基本可用：分布式系统出现故障时，允许损失部分功能的可用性，保证核心功能可用
- Soft State 软状态：允许数据存在中间状态，不影响系统可用性，就是数据副本同步之间允许存在延时
- Eventually Consistent 最终一致性：数据中间状态或延时，经过一段时间最终 数据一致
分布式事务问题常见解决方案 TCC补偿方案 (两阶段提交)
TCC (Try-Confirm-Cancel) 比较成熟的分布式数据一致性解决方案，把完整业务拆分为三个步骤：
- Try：对数据校验或资源预留
- Confirm：执行任务，只操作 Try 阶段的资源
- Cancel：取消执行，释放 Try 阶段的资源
分布式事务问题常见解决方案 基于可靠性消息的最终一致性方案
互联网公司常用的方案，主要利用消息中间件 (Kafka RocketMQ RabbitMQ) 的可靠性机制来实现数据一致性。
分布式事务问题常见解决方案 最大努力通知型
与基于可靠性消息类似，适用于对数据一致要求不高的场景，如支付宝支付，用户支付之后，支付宝服务器会在一定时间内不停的通知用户程序，并提供交易结果查询接口。
分布式事务框架 Seata
开源分布式事务解决方案，主要针对微服务分布式事务，提供 AT、TCC、Saga 和 XA 事务模式。
Seata AT 模式 (两阶段提交)
Seata 主推方案，基于 XA 演进而来，分为 TM、RM 和 TC 三大模块。TM 与 RM作为 Seata 客户端与业务系统交互，TC 则作为 Seata 服务端独立部署。
Seata Saga 模式（多事务，若失败则挨个回滚）
又称长事务解决方案，主要用于在没有两阶段的情况下使用。核心思想是：跨多个数据库的业务流程拆分为多个本地短事务，之后若出现回滚操作，则对已提交的事务进行补偿。例如：对增加值的进行减法操作（对某些资源会出现一定的问题）
Seata 安装
独立安装、Docker、Kubernetes、Helm 等方式。
Linux/Mac 下启动
# sh seata-server.sh
# sh seata-server.sh -p 8091 -h 192.168.0.120 -m file 指定机器端口及file存储模式
可以使用 -m db 来使用 db 模式存储相关数据，并在文件 \conf\file.conf 中配置数据库连接
全局事务 globaltable 、分支事务 branchtable、全局锁 lock_table
\conf\registry.conf
其中 registry 表示使用的注册中心组件，如 nacos、zookeeper，默认情况是 file 可快速集成 Seata，但 file 模式不具备注册中心的动态发现与动态配置功能；
而 config 则用于配置 Seata 服务端，通过此项设置 Seata 服务端的加载的配置文件，支持从远程配置中心读取或本地读取，远程读取设置的设置方式与 registry 相同。
\conf\file.conf
存储 Seata 服务端的配置信息，包含 transport、server、metrics 分别表示 协议配置、服务端配置、监控
配置中心加载配置信息
使用 Nacos 作为配置中心
Seata AT 模式集成 Dubbo
示例：订单服务、库存服务、账户服务、公共服务、业务REST接口服务；服务之间相互调用
分布式数据库：seata_order、seata_repo、seata_account 共三个
每个服务创建单独 module 并引用相关依赖
逐个启动服务并访问 业务REST接口服务 对外的接口
添加Seata分布式事务
引用Seata的Starter组件依赖
application.yml中添加Seata配置项
在各个数据库中添加 回滚日志表
添加全局事务控制 @GlobalTransactional
Spring Cloud Alibaba 集成 Seata AT 模式
添加 Spring Cloud Alibaba Seata 依赖，由于不支持 yml 形式，只能用 file.conf 与 registry.conf 来配置。
在访问数据库中的服务中，添加配置类，设置 数据源代理DataSourceProxy、初始化GlobalTransactionalScanner装载到Spring IOC容器
注意 @SpringBootApplication(exclude=GlobalTransactionalAutoConfiguration.class)
Seata AT 模式实现原理
AT模式从XA事务模型演进而来，也是一个 改进版的两阶段提交协议
把修改前及修改后的数据存入 undo_log 表中，之后释放本地事务锁定的资源，若之后阶段出现异常，则根据 undo_log 进行回滚。
在 XA 中则会一直锁定资源到最后阶段，这是最大的不同点。
TC收到所有事务分支的事务状态汇报后，来决定提交或回滚。
若提交：清理 undo_log 的回滚数据即可，毕竟之前一步中，所有分支事务都已经提交了。
若回滚：根据 undo_log 的数据进行补偿，只要各个分支事务回滚成功，数据一致性就得到保证了。
ACID中的隔离性，指的是：多个用户并发访问数据库时，多个并发事务之间要相互隔离，互不干扰。
AT模式中，多个全局事务操作同一张表时，事务隔离性是基于全局锁来实现的，
写隔离：（针对同一张表同一字段的更新）分布式事务分为本地锁(数据库锁)和全局锁(分布式锁)，本地锁获取后只要是全局锁获取不成功，最终不会提交，会回滚。因此就算多个事务同时执行，仍不会发生脏写；
读隔离：Read Uncommitted 读取未提交内容、Read Committed 读取提交内容、Repeatable Read 可重读、Serialiable 可串行化
九、RocketMQ 分布式消息通信
多个服务之间相互通信 即 系统间通信协作通常有两种：
HTTP/RPC 通信实时，但耦合性高；
消息通信 降低耦合，提高系统处理能力，但非实时
RocketMQ 是分布式消息中间件（消息队列），阿里巴巴经多年双11难的一个低延迟、高可靠、可伸缩、易于使用的消息框架，提供顺序消息、事务消息、定时消息、消息重试和追踪等功能。应用场景：削峰填谷(解决突发的大量请求)、异步解耦(主要业务完成后附加业务异步通知执行)、顺序收发(各个子业务之间需要先后执行，如先扣款再发货之后收货等)、分布式事务一致性(交易系统与支付系统要最终数据一致)、大数据分析、分布式缓存(各服务器缓存数据，接收通知更新缓存)。
安装：依赖JDK1.8及以上，分三种集群部署模式，可源码安装或w使用安装包。
发消息：Spring Cloud Alibaba 已集成 RocketMQ，使用 Spring Cloud Stream 即可。
引入依赖、配置连接信息等、编码使用Binder发送消息
@EnableBinding({Source.class}) 绑定配置文件中名称为 output 的消息通道，output 在 Source 类中定义。
可以自定义消息通道，参考 Source，使用 @Output("order_output") 即可定义一个 order_output 消息通道；当然，需要在配置文件中配置 order_output 的配置项。
接收消息：引入依赖、配置连接信息等、编码监听消息
@EnableBinding({Sink.class}) 默认存在 input 的消息通道，使用 @StreamListener(value=Sink.INPUT) 标记方法用于接收消息。
同样可以自定义，参考 Sink，使用 @Input("order_input") 即可定义 order_input 消息通道；同样需要进行配置 order_input 配置项。
Spring Cloud Stream：用于简化 Spring Cloud 应用程序中消息业务的开发。
应用程序通过注入输入通道 input 和 输出通道output 与 消息中间件Middleware通信，输入输出通道通过绑定器 Binder 连接到外部代理。
此框架基于 发布/订阅 机制，
核心由四部分构成： SpringFramework 中的 Spring Messaging 和 Spring Integration，以及 Spring Cloud Stream 中的 Binders 和 Bindings。
Spring Messaging：Spring Framework 中的统一消息编程模型
Message(消息对象，包含消息头Header和消息体Payload)、
MessageChannel(消息通道接口，用于接收发送消息)、
MessageHandler(消息处理接口)
Spring Integration：Spring Framework 中用于支持企业集成的扩展机制，对 Spring Messaging 进行扩展
MessageDispatcher(消息分发接口，用于分发消息和添加删除消息处理器)
MessageRouter(消息路由接口，定义默认输出消息通道)
Filter(消息过滤注解，配置消息过滤表达式)
Aggregator(消息聚合注解，用于多条消息合并)
Splitter(消息分割，一条消息拆分为多条)
Binders：目标绑定器，负责与消息中间件集成
doBindProducer(绑定消息中间件发送消息模块)
doBindConsumer(绑定消息中间件接收消息模块)
Bindings：外部消息中间件系统与应用程序的生产者和消费者(由Binders创建)之间的桥梁
Spring Cloud Alibaba RocketMQ 架构图
MessageChannerl(output)、MessageChannel(input) 为消息通道，用于发送订阅消息，Spring Cloud Stream标准接口
Binder bindProducer、Binder bindConsumer 目标通道绑定器，与RocketMQ消息服务器交换消息，即发布与接收消息，
由 Spring Cloud Alibaba 按照 Spring Cloud Stream 标准协议实现
Spring Cloud Stream 消息发送流程
业务代码调用 MessageChannel send()；
org.springframework.integration.channel.AbstractMessageChannel 是接口 MessageChannel 的抽象实现类，定义发送、接收消息的公用方法；
消息传递到 org.springframework.integration.channel.AbstractSubscribableChannel 类，执行 doSend()，方法中 获取 MessageDispatcher 的实现类 UnicastingDispatcher；
调用 org.springframework.integration.dispatcher.UnicastingDispatcher dispatcher() 把消息分发给所有的 MessageHandler；
MessageHandler 执行 handleMessage() 处理消息。
注册 MessageHandler 是通过 org.springframework.cloud.stream.binder.AbstractMessageChannelBinder 在初始化 Binding 时执行 doBindProducer 调用 AbstractSubscribableChannel subscribe() 设置的。
AbstractMessageChannelBinder 的初始化则由 org.springframework.cloud.stream.binding.AbstractBindingLifecycle 在 Spring 容器加载 Bean 完成初始化后执行的。
RocketMQ Binder 集成消息发送
同时 AbstractMessageChannelBinder 提供了创建 MessageHandler 的规范，即调用 abstract 方法 createProducerMessageHandler()，而 com.alibaba.cloud.stream.binder.rocketmq.RocketMQMessageChannelBinder 则是实现了此方法并创建了 com.alibaba.cloud.stream.binder.rocketmq.integration.RocketMQMessageHandler 实例，是 MessageHandler 的 RocketMQ 具体实现，在 RocketMQBinder 中实现转化消息格式并发送消息。
RocketMQMessageHandler 中有 org.apache.rocketmq.spring.core.RocketMQTemplate 对象，是对 RocketMQ 客户端API的封装，SpringBoot支持RocketMQTemplate，SpringCloudStream对其同样兼容。
DefaultMQProducer 是 RocketMQ 客户端提供的 API，用于将消息发送到 RocketMQ 消息服务器。
RocketMQMessageHandler 则对 Message 进行解析，根据参数设置调用不同实现。如根据Header属性决定发送普通消息、事务消息、定时消息或顺序消息。
RocketMQ Binder 集成消息订阅
AbstractMessageChannelBinder createConsumerEndpoint() 用于创建 MessageProducer ，在初始化Binder时调用。
RocketMQMessageChannelBinder 具体实现了 createConsumerEndpoint() 并创建了 com.alibaba.cloud.stream.binder.rocketmq.integration.RocketMQInboundChannelAdapter 对象，此类是接口 MessageProducer 的实现类，其适配了 SpringFramework的重试和回调机制，用于在 RocketMQ Binder 中订阅消息并转化消息格式。
com.alibaba.cloud.stream.binder.rocketmq.consuming.RocketMQListenerBindingContainer 是接口 RocketMQListenerContainer 的实现，通过 setupMessageListener() 方法设置 RocketMQListener 来消费消息。DefaultMessageListenerOrderly 与 DefaultMessageListenerConcurrently 是 MessageListener 的两种实现，顺序消费和并发消息。在 consumeMessage() 执行时会调用 RocketMQListener onMessage() 来调用业务代码处理消息。
Spring Cloud Stream 消息订阅流程
企业Binder 收到订阅消息，发送到 MessageChannel，再通过 Dispatcher 调用 MessageHandler，最后调用 @StreamListener 注解标记的方法调用业务方法。
RocketMQInboundChannelAdapter extends MessageProducerSupport 调用 sendMessage() 发送消息。
方法内部调用 getOutputChannel 得到初始化 RocketMQ Binder 时传入的 DirectChannel 通道。
MessagingTemplate extends GenericMessagingTemplate 执行 send() 再次发送消息，通过 DirectChannel 通道获取 MessageDispatcher 的实现类 UnicastingDispatcher；
之后进行消息分发，传递消息给 MessageHandler。
DirectChannel 对应的消息处理器是 StreamListenerMessageHandler ，此处理器会调用使用 @StreamListener 注解标记的业务方法。
StreamListenerAnnotationBeanPostProcessor 扫描类找到使用 @StreamListener 标记的 Method，并创建 StreamListenerHandlerMethodMapping 对象，保存了映射关系。
映射关系为 StreamListener 到 HandlerMethod。因此在 StreamListenerMessageHandler 处理器中可以调用 @StreamListener 的业务方法。
RocketMQ 集群管理
分布式服务SOA中，中间件和应用不允许单点存在，服务发现机制因此是必备的。
RocketMQ 是淘宝中间件团队参考 Kafka 重新设计用 Java 编写出来的，因此概念会有 Kafka 相似。
Kafka、RabbitMQ、RocketMQ 等都是基于 发布/订阅 机制，消息发送方Producer 发送消息到 消息服务器，消息接收方Consumer 从 消息服务器订阅消息。 发送方与接收方为客户端，消息服务器是服务端，客户端与服务端需要通过 注册中心 来感知对方。
RocketMQ 架构四大组件：
Producer：消息提供者，发送消息到 Broker，支持分布式集群方式部署
Consumer：消息接收者，负责从 Broker 订阅消费消息，同样支持分布式集群方式部署
Broker：消息存储角色，用于消息存储、投递和查询，具有服务高可用保证，支持分布式部署
NameServer：服务管理角色，负责管理 Broker 集群的路由信息，支持分布式集群方式部署。 简单Topic模式的路由注册中心，类似于Dubbo中的Zookeeper、Nacos，支持 Broker 动态注册与发现。包含 服务注册(接收Broker注册信息，保存并启动心跳检查) 和 路由信息管理(提供给客户端查询Broker接口，因此客户端可以与Broker进行消息发送与接收)。
基本概念:
Message：消息，传输信息的物理载体，生产和消费数据的最小单位。必须关联一个Topic，且拥有唯一MessageID，并可携带具有业务标识的Key
Topic：主题，一类消息的集合，包含若干消息，Topic是RocketMQ进行消息订阅的基本单位
Queue：消息队列，组成Topic的最小单元。默认情况是一个Topic对应多个Queue。Topic是逻辑概念，Queue是物理概念。消费Topic消息实际是拉取Queue消息。
Tag：区分同一个主题下不同类型的消息，优化RocketMQ的消息查询系统，且可以根据Tag实现不同的处理逻辑，扩展性更好
UserProperties：用户自定义属性，属于Message一部分
ProducerGroup：同类Producer集合，发送消息逻辑一致的一组服务器。当某台消息提供者出问题，则Broker从组内选取其它一台进行交互
ConsumerGroup：同类Consumer集合，接收消息后的处理逻辑一致的一组服务器，订阅了相同的Topic消息
ZooKeeper VS NameServer
Kafka服务注册与发现通常用ZooKeeper来完成，在Kafka中，Topic是逻辑概念，分区(Partition)是物理概念。1个Topic可以设置多个分区，每个分区又可以设置多个副本(Replication)，即1 Master - N Slave 模式。 Master是经过选举得出的，Broker实例具有Master/Slave双重身份，就看选举结果如何了。
RocketMQ使用NameServer，Topic也是逻辑概念，队列(Queue)是物理概念(与kafka的分区对应)，同样 1 Master - N Slave 模式。Master与Slave是预告设置的。
本人根据书中介绍得到的是，Kafka中，Master和其对应的Slave在同一个进程中进行管理，而Rocket则用不同进程来管理Master与Slave。有其它见解或者实际研究过的欢迎来更正、来打扰
顺序消息 ：业务流程需要先后次序时使用，实现类似对列FIFO的效果；分为 局部有序 和 全局有序
局部有序：发送到同一队列的消息有序，发送时需指定队列。
发送：设置输出通道的 sync=true e.g. spring.cloud.stream.rocketmq.bindings.output.producer.sync=true；消息发送时，指定Header头信息 MessageBuilder.withPayload(message).setHeader(BinderHeaders.PARTITION_HEADER,0);
接收：设置接收通道的 orderly=true e.g. spring.cloud.stream.rocketmq.bindings.input.consumer.orderly=true。
全局有序：设置Topic指定全局有序，性能差，不推荐使用
发送方式：同步、异步、单向
同步：发送请求后等待Broker服务器返回，支持失败重试，适用较重要的场景
异步：异步发送消息，不阻塞进程，不支持失败重试，适用响应时间要求高的场景
单向：与异步一致，但不支持回调，应用于时间要求超高，可靠性要求不高的场景
十、Spring Cloud Gateway
读书笔记-SpringCloudAlibaba微服务原理与实战-谭锋-【未完待续】相关推荐
- 「读书笔记」《如何阅读一本书》 | 随笔 |摘抄 |未完待续
<如何阅读一本书>–随笔.记录 写的是一些读后感和自己觉得应该记录下来的东西. 阅读有四个层次:基础阅读,检视阅读,分析阅读,主题阅读 1.基础阅读 是在自己熟悉语言的领域已经掌握 ...
- spring cloud alibaba微服务原理与实战_SpringBoot+Cloud全家桶微服务实战项目之文档型数据库MongoDB四...
一.MongoDB简介以及使用场景 MongoDB 是一个跨平台的,面向文档的数据库,是当前 NoSQL 数据库产品中最热门的一种.它介于关系数据库和非关系数据库之间,是非关系数据库当中功能最丰富, ...
- 【笔记】LR配置ODBC连接数据库进行参数化(mysql )未完待续
很多时候我们需要大量的参数数据,但是光光靠手填写是非常麻烦的,既然被测对象的数据都在数据库,那么我们直接读取数据库回来就轻松简便很多. data wizard 提供了一个从ODBC的连接获得数据转化 ...
- C语言笔记(1.3版本，目前3.5w字)----未完待续
目录 前言 0.基础常识 (1)进制 (2)变量与常量 (3)内存 (4)其它零零碎碎的点 (5)运算符 1.关键字 1.switch 2.关键字总览(不需要记,认识即可) 3.函数 4.数组 5.指 ...
- Kafka原理介绍及安装使用(未完待续)
1.Kafka简介 2.Kafka的安装.管理和配置 3.第一个Kafka程序 4.Kafka的生产者 5.Kafka的消费者
- Spring Cloud 微服务项目操作实战流程（完结）
Spring Cloud入门项目操作实战流程 Day01~02 〇.Service - 业务服务结构 商品服务 item service,端口 8001 用户服务 user service,端口 81 ...
- gradle 指定springcloud 版本_SpringCloud微服务架构开发实战：实现服务注册与发现
实现服务的注册与发现 在前面分别用Eureka Server和Eureka Client来搭建了一台注册服务器,以及多个Eureka Client客户端.Eureka Client在启动后,就会将自己 ...
- javaee 中文帮助文档_大牛耗时三天整理的：微服务+Nginx+Kubernetes实战文档和面试题...
前言 十年之前,相信大家掌握了Java EE互联网轻量级框架整合开发 SSM框架SpringMVC+Spring+MyBatis就已经能够轻轻松松找到一份薪资很高的java开发工作了,而如今只会SSM ...
- 微服务架构开发实战：如何实现微服务的自动扩展？
微服务架构开发实战:如何实现微服务的自动扩展? 程序员高级码农II 2020-09-25 07:25:00 如何实现微服务的自动扩展 前面讲了一些关于自动扩展的理论知识,但如何实现自动扩展,并不是三言 ...
最新文章
- 数据库学习day_03:关联关系/ 关联查询/ JDBC
- EAR项目构建的几种方式
- android apk 微信登入_Android集成第三方微信登录
- 备战618，京东如何保障系统稳定性？
- SAP CRM one order三层内存模型
- 解决pip安装pygal在TensorFlow环境下调用失败问题
- oracle gg 有两个字段没同步到,GG配置Oracle同步到SQLServer
- VB 全局热键HOOK (不占系统资源版本)
- java 文本词频统计_Java实现中文词频统计
- AR实战开源项目——Miku和“极乐净土”
- MMA7660传感器使用心得
- 若依ruoyi框架整合magic-api快速开发
- Ubuntu18安装微信(deepin-wine版本)完整过程以及采坑记录
- Android 获取联系人姓名和电话号码信息
- TMC2130-TA/LA电机驱动芯片对比DRV8880、DRV8846、DRV8886
- 安装WampServer后无法打开localhost的问题
- 人工智能及其背后的技术简介
- 软通纽约_纽约地铁数学
- 学python能考什么证书比较实用_关于python能考什么证书的阿里云论坛用户知识和技术交流...
- android 弹幕动画,Android自制精彩弹幕效果