diff --git a/docs/cn/features/0-introduction.md b/docs/cn/features/0-introduction.md deleted file mode 100644 index 7df673178a..0000000000 --- a/docs/cn/features/0-introduction.md +++ /dev/null @@ -1,56 +0,0 @@ -# DeFiBus - -       -** -DeFiBus=RPC+MQ，是基于开源消息中间件打造的安全可靠的分布式金融级消息总线。DeFibus不仅提供了RPC同步调用，还提供了MQ的异步事件通知、事件组播和广播等常用服务调用和消息模式，同时增加了应用多中心多活、服务就近、灰度发布等分布式场景下的高可用能力。在对于机器故障的容错能力方面的增强，也让消息总线的服务更加稳定可靠，为业务提供7x24的服务。** - -### 整体架构 - -
- -![architecture1](../../../docs/images/features/a-distributing-architecture-in-financial.png) - -
- -![architecture2](../../../docs/images/features/architecture-p1.png) - -DeFiBus主要包括以下几个组件（模块）： - -* **Broker**：通过轻量的Topic和Queue机制提供消息存储功能。Broker定期将Topic信息上报到NameServer中，同集群中的Broker实例上报的NameServer必须保持一致，避免路由信息不一致。 - -* **NameServer**：NameServer提供Topic的发现和路由，每一个NameServer接受Broker上报的Topic信息，并维护Topic的路由信息供客户端查询。 - -* **GSL**：全局服务定位（Global Service - Location）服务提供服务级别的路由发现。服务可以部署在不同的区域（比如不同的数据中心、逻辑分区等），服务请求方在请求某一个具体服务时，无需关注服务部署的区域，GSL能够根据服务发现规则自动定位到具体的服务，将服务信息返回给客户端。 - -* **SGS**：服务治理系统（Service Government - System）负责全局的服务管理，包括服务的申请、服务部署规划、服务下线等服务全生命周期的管理。在DeFiBus中，服务与Topic一一对应，Topic的名称由对应的服务按照一定的规则来命名。Topic的创建、更新和删除由SGS统一管理。SGS在服务的部署区域对应的Broker集群中创建Topic之后，将更新全局服务路由数据，供GSL定位服务使用。 - -* **EventMesh**：服务代理（EventMesh）提供HTTP接入方式，同时允许按照协议规范开发的C、GO、Python等其他语言客户端的接入。 - -### 服务和Topic的定义 - -       -DeFiBus把服务和Topic做了一一对应，每个服务必须对应一个Topic。Topic根据服务的唯一ID和服务的部署区域来命名。每个服务需要有服务的唯一标识，可以用数字ID或者字符串来表示。每个部署区域使用3位长度的字符串（限数字和字母构成）表示。 -Topic按照如下格式来命名： - -``` -[区域代码]-[服务唯一ID] -``` - -比如，余额查询服务的服务ID为20190001表示，部署在“A10”这个区域，那么该服务在A10区域的Topic就命名为“A10-20190001”。Topic的命名规则 - -### 特性列表: - -* [RPC调用：即“Request-Reply”模式，支持系统间的同步调用](docs/cn/features/1-request-response-call.md) -* 消息发布/订阅：消息的发布和订阅 -* [灰度发布：服务级别的灰度发布](docs/cn/features/2-dark-launch.md) -* [熔断机制：应用实例级别的熔断](docs/cn/features/3-circuit-break-mechanism.md) -* [服务就近：就近进行服务的请求和响应，减少跨区调用](docs/cn/features/4-invoke-service-nearby.md) -* [应用多活：应用多中心多活](docs/cn/features/5-multi-active.md) -* [动态扩缩队列 ：自适应应用实例数量，动态调整队列个数](docs/cn/features/6-dynamic-adjust-queue.md) -* [容错机制：故障和错误隔离](docs/cn/features/8-fault-tolerant.md) -* 服务路由和定位：动态路由及定位(后续开源) -* 服务代理：HTTP及多语言的代理(后续开源) -* 服务治理：服务元数据的管理(后续开源) -* 平滑升级：平滑升级、平滑扩容(后续开源) \ No newline at end of file diff --git a/docs/cn/features/1-request-response-call.md b/docs/cn/features/1-request-response-call.md deleted file mode 100644 index 10166d74ef..0000000000 --- a/docs/cn/features/1-request-response-call.md +++ /dev/null @@ -1,34 +0,0 @@ -## 1. Request-Reply同步调用 - -       Request-Reply同步调用指的是请求方发出一条消息之后，需要响应方在消费完这条消息后回复一个响应结果。 - -
- -![RR](../../images/features/RR-call-p1.png) - -
- -整个调用过程包含了两个消息的产生和消费过程。 -**1.请求方产生请求消息，服务响应方消费这条请求消息** -       请求方根据服务提供方的协议将请求内容设置到消息体中，并将消息发送到Broker上。服务响应方订阅相应的Topic，从Broker上获取到请求消息，并消费。 - -**2.服务响应方产生响应消息，请求方接收这条响应消息** -       -服务响应方收到请求消息后，执行相应的处理，并将请求结果设置到响应消息的消息体中，将响应消息发送到Broker上。请求方接收响应消息的方式采用的是Broker推送的形式，而不是由Producer订阅的方式，从而使得响应消息能够精准回到发出请求消息的实例上。 - -       -DeFiBus在每条请求消息中增加REPLY_TO属性来唯一标识每一个请求方实例。在创建响应消息时将REPLY_TO属性透传到响应消息中。Broker收到响应消息后，根据REPLY_TO属性，查找出对应的请求方实例的连接，将响应消息推送给该请求方实例。 - - ---- - -#### Links: - -* [架构介绍](../../../README.md) -* [Request-Reply调用](docs/cn/features/1-request-response-call.md) -* [灰度发布](docs/cn/features/2-dark-launch.md) -* [熔断机制](docs/cn/features/3-circuit-break-mechanism.md) -* [服务就近](docs/cn/features/4-invoke-service-nearby.md) -* [应用多活](docs/cn/features/5-multi-active.md) -* [动态扩缩队列](docs/cn/features/6-dynamic-adjust-queue.md) -* [容错机制](docs/cn/features/8-fault-tolerant.md) \ No newline at end of file diff --git a/docs/cn/features/10-flow-control.md b/docs/cn/features/10-flow-control.md deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/docs/cn/features/2-dark-launch.md b/docs/cn/features/2-dark-launch.md deleted file mode 100644 index 148838614e..0000000000 --- a/docs/cn/features/2-dark-launch.md +++ /dev/null @@ -1,26 +0,0 @@ -## 2.灰度发布 - -       -同一个消费组中的消费者实例通常订阅的Topic是相同的。在有新业务上线时，我们希望仅仅在个别实例上进行灰度，验证通过之后再进行全量。DeFiBus提供了灰度发布的能力，同一个消费组中，允许不同消费者实例订阅不同的Topic，只有订阅了某个具体Topic的实例才能够收到这个Topic的消息，同消费组中没有订阅这个Topic的实例不会收到消息。 - -       -假设一个消费组有3个消费者实例，上线初期只涉及到Topic1和Topic2。当业务扩展，需要增加Topic3的订阅时，可以先灰度其中一个实例，验证Topic3在灰度实例上执行正常之后，逐步再替换其他实例。在这期间，实例1和实例2不会收到Topic3的消息。 - -
- -![avater](../../images/features/dark-launch-p1.png) - -
- ---- - -#### Links: - -* [架构介绍](../../../README.md) -* [Request-Reply调用](docs/cn/features/1-request-response-call.md) -* [灰度发布](docs/cn/features/2-dark-launch.md) -* [熔断机制](docs/cn/features/3-circuit-break-mechanism.md) -* [服务就近](docs/cn/features/4-invoke-service-nearby.md) -* [应用多活](docs/cn/features/5-multi-active.md) -* [动态扩缩队列](docs/cn/features/6-dynamic-adjust-queue.md) -* [容错机制](docs/cn/features/8-fault-tolerant.md) \ No newline at end of file diff --git a/docs/cn/features/3-circuit-break-mechanism.md b/docs/cn/features/3-circuit-break-mechanism.md deleted file mode 100644 index 3ae2f7a635..0000000000 --- a/docs/cn/features/3-circuit-break-mechanism.md +++ /dev/null @@ -1,28 +0,0 @@ -## 3.熔断 - -       -DeFiBus基于队列来做消费端的负载均衡，对同一个消费组，除广播模式外，每个队列只由一个消费者实例消费。当一个实例处理能力下降或者异常出现消息堆积时，为了避免堆积情况继续加剧，DeFiBus会触发队列的熔断，此时生产者实例在感知到队列熔断之后，会优先把消息发送到其他没有熔断的队列上，暂停往熔断队列上写入新消息。当堆积消除后，熔断被解除，生产者恢复往该队列发送消息。 - -       -DeFiBus对每个Topic定义了深度的属性，表示Topic的队列允许堆积的最大消息条数。消息堆积数表示队列中尚未下发给消费者实例的消息条数，可由队列中最新一条消息的offset与消费者实例已经获取到的消息的offset的差值计算。 -
- -![offset](../../../docs/images/features/circuit-break-p1.png) - -
- -       -当Consumer出现异常或者触发了流控，Consumer拉消息过程受阻，队列的DeliverOffset停止不前，新消息持续写入，MaxOffset不断变大，最终MaxOffset与DeliverOffset将超过Topic的最大深度限制，触发队列熔断。 - ---- - -#### Links: - -* [架构介绍](../../../README.md) -* [Request-Reply调用](docs/cn/features/1-request-response-call.md) -* [灰度发布](docs/cn/features/2-dark-launch.md) -* [熔断机制](docs/cn/features/3-circuit-break-mechanism.md) -* [服务就近](docs/cn/features/4-invoke-service-nearby.md) -* [应用多活](docs/cn/features/5-multi-active.md) -* [动态扩缩队列](docs/cn/features/6-dynamic-adjust-queue.md) -* [容错机制](docs/cn/features/8-fault-tolerant.md) diff --git a/docs/cn/features/4-invoke-service-nearby.md b/docs/cn/features/4-invoke-service-nearby.md deleted file mode 100644 index 4a24248fd6..0000000000 --- a/docs/cn/features/4-invoke-service-nearby.md +++ /dev/null @@ -1,34 +0,0 @@ -## 4.服务就近 - -       -为了保证高可用，服务的部署通常分布在多个机房、区域。我们希望服务之间能够就近调用，减少跨机房跨区域网络访问的时延问题。对此，DeFiBus在Broker和客户端上都增加了区域的属性来标识实例属于哪个区域。对于Producer，消息会优先发往同区域内的Broker集群上；对于Consumer，则优先监听同区域内的Queue；当一个区域内没有Consumer实例监听时，则由其他区域的Consumer实例跨区域监听。 - -### 就近发送 - -       在创建Producer时，通过设置```DeFiBusClientConfig.setClusterPrefix("your region")``` -来标识Producer实例所在的区域。Producer在每次发送消息会先选则一个Queue来作为发送的目标队列。当启用就近发送时，Producer优先选择与自己同区域内的Queue，当本区域内没有可用Queue时，则选择其他区域的Queue。 -
- -
- -### 就近监听 - -       -就近监听指的是Consumer在做负载均衡分配Queue的时候，每个区域内的Queue只由该区域内的Consumer监听和消费，当且仅当一个区域内没有订阅该Topic的Consumer时，由其他区域订阅了该Topic的Consumer跨区域监听和消费这些Queue。虽然Consumer是在同区域内就近消费，但仍通过心跳维持跨区域的连接，以保证能够随时跨区域接管消费。 - -
- -
- ---- - -#### Links: - -* [架构介绍](../../../README.md) -* [Request-Reply调用](docs/cn/features/1-request-response-call.md) -* [灰度发布](docs/cn/features/2-dark-launch.md) -* [熔断机制](docs/cn/features/3-circuit-break-mechanism.md) -* [服务就近](docs/cn/features/4-invoke-service-nearby.md) -* [应用多活](docs/cn/features/5-multi-active.md) -* [动态扩缩队列](docs/cn/features/6-dynamic-adjust-queue.md) -* [容错机制](docs/cn/features/8-fault-tolerant.md) \ No newline at end of file diff --git a/docs/cn/features/5-multi-active.md b/docs/cn/features/5-multi-active.md deleted file mode 100644 index 9e19d6d7cc..0000000000 --- a/docs/cn/features/5-multi-active.md +++ /dev/null @@ -1,21 +0,0 @@ -## 5.同城多中心多活 - -       -同城多中心多活指的是应用的多活，在DeFiBus集群正常运行的情况下，应用部署在多个数据中心，一个数据中心的应用实例全部挂掉后，DeFiBus能够自动将应用流量切换到另一个数据中心的应用实例上，保证应用能够持续稳定地提供服务而不中断。同城多中心多活得益于DeFiBus的服务就近特性，结合应用部署的规划，使得正常情况下服务调用发生在同一个数据中心，当一个中心的应用出现故障时，能够有其他中心的实例接管服务。 - -
- -
- ---- - -#### Links: - -* [架构介绍](../../../README.md) -* [Request-Reply调用](docs/cn/features/1-request-response-call.md) -* [灰度发布](docs/cn/features/2-dark-launch.md) -* [熔断机制](docs/cn/features/3-circuit-break-mechanism.md) -* [服务就近](docs/cn/features/4-invoke-service-nearby.md) -* [应用多活](docs/cn/features/5-multi-active.md) -* [动态扩缩队列](docs/cn/features/6-dynamic-adjust-queue.md) -* [容错机制](docs/cn/features/8-fault-tolerant.md) \ No newline at end of file diff --git a/docs/cn/features/6-dynamic-adjust-queue.md b/docs/cn/features/6-dynamic-adjust-queue.md deleted file mode 100644 index 287fa7fc54..0000000000 --- a/docs/cn/features/6-dynamic-adjust-queue.md +++ /dev/null @@ -1,38 +0,0 @@ -## 自动伸缩Queue - -       -在同一个消费组内，每个队列只由一个实例消费。当队列数小于消费者实例数时，会有部分消费者实例分不到队列；反之，当队列数大于消费者实例数时，每个消费者需要消费多个队列。队列数不是消费者实例数的整数倍时，则会出现部分实例需要消费比同组内的其他实例更多的队列，出现负载不均衡问题。 - -       -DeFiBus提供了队列数量自动调整的特性。当有Consumer新注册或者去注册时，Broker触发队列的自动伸缩，根据当前在线的消费者实例个数，增加或者减少队列个数，使队列个数与消费者实例数保持一致。 - -       -当队列数需要增加时，首先调整Topic的ReadQueueNum，将可读的队列数扩增；10s之后，再调整Topic的WriteQueueNum，将可写的队列数扩增。这样使得新扩增的队列能够先被消费者感知并监听上，然后才让生产者感知到，往新队列上发送消息，是扩增操作更平滑。 - -
- -
- -       -当队列数需要减少时，首先调整Topic的WriteQueueNum，将可写的队列数缩减；5分钟（默认，可配置）后先检查即将被缩减的队列中是否有消息没有被消费完，如果有，则继续延迟缩减操作，使消费者能够继续消费完队列中的消息；如果没有，则调整ReadQueueNum，将可写的队列数缩减。 - -
- -
- -       -对于多个消费组订阅相同Topic并且是集群消费模式时，在计算扩缩的队列个数时，以最大的消费组的消费者实例数为准，保证拥有最多实例数的消费组内每个消费者实例都能够分到Queue进行消费。 - - ---- - -#### Links: - -* [架构介绍](../../../README.md) -* [Request-Reply调用](docs/cn/features/1-request-response-call.md) -* [灰度发布](docs/cn/features/2-dark-launch.md) -* [熔断机制](docs/cn/features/3-circuit-break-mechanism.md) -* [服务就近](docs/cn/features/4-invoke-service-nearby.md) -* [应用多活](docs/cn/features/5-multi-active.md) -* [动态扩缩队列](docs/cn/features/6-dynamic-adjust-queue.md) -* [容错机制](docs/cn/features/8-fault-tolerant.md) \ No newline at end of file diff --git a/docs/cn/features/7-isolation-mechanism.md b/docs/cn/features/7-isolation-mechanism.md deleted file mode 100644 index 3c86bc9aaf..0000000000 --- a/docs/cn/features/7-isolation-mechanism.md +++ /dev/null @@ -1,26 +0,0 @@ -## 隔离机制 - -Producer在往Topic发送消息时，会按照MessageQueueSelector定义的选择策略，从Topic的所有MessageQueue中选择一个作为目标队列发送消息。 -当队列发生熔断，或者Broker故障导致队列发送消息异常时，如果没有对这些队列进行特殊处理，下次再轮到发这个队列的时候仍然可能失败。 - -DeFiBus提供异常队列的隔离机制，当往某个队列发送消息失败时，将队列标记为隔离状态，在隔离过期之前将不再往这个队列发送消息，避免再次失败，降低失败概率。 - -异常队列隔离机制分为两步： -**-发现并标记队列为隔离** -在发送回调中更新发送队列的健康状态，如果执行的是onSuccess分支，则标记队列为健康，去除队列的隔离标记；如果执行的是onException分支，则标记队列为隔离状态。 - -**-不选择隔离中的队列发送消息** -在MessageQueueSelector中实现隔离机制的过滤逻辑，每次进行队列的选择时，优先从没有标记为隔离的队列中选择。当所有队列都被标记为隔离时，则从所有队列中选择，保证每次都要选出一个队列。 - ---- - -#### Links: - -* [架构介绍](../../../README.md) -* [Request-Reply调用](docs/cn/features/1-request-response-call.md) -* [灰度发布](docs/cn/features/2-dark-launch.md) -* [熔断机制](docs/cn/features/3-circuit-break-mechanism.md) -* [服务就近](docs/cn/features/4-invoke-service-nearby.md) -* [应用多活](docs/cn/features/5-multi-active.md) -* [动态扩缩队列](docs/cn/features/6-dynamic-adjust-queue.md) -* [容错机制](docs/cn/features/8-fault-tolerant.md) \ No newline at end of file diff --git a/docs/cn/features/8-fault-tolerant.md b/docs/cn/features/8-fault-tolerant.md deleted file mode 100644 index 6814e12c34..0000000000 --- a/docs/cn/features/8-fault-tolerant.md +++ /dev/null @@ -1,51 +0,0 @@ -## 8.容错机制 - -       在金融场景下，对可用性和稳定性的要求非常高，中间件对机器故障、网络故障、应用故障以及中间件本身的故障等常见故障场景需要有容错能力，降低故障带来的影响。 - -### 隔离机制 - -##### 1. Producer端的隔离 - -       -Producer在往Topic发送消息时，会按照MessageQueueSelector定义的选择策略，从Topic的所有MessageQueue中选择一个作为目标队列发送消息。 -当队列发生熔断，或者Broker故障导致队列发送消息异常时，如果没有对这些队列进行特殊处理，下次再轮到发这个队列的时候仍然可能失败。 - -       DeFiBus提供异常队列的隔离机制，当往某个队列发送消息失败时，将队列标记为隔离状态，在隔离过期之前将不再往这个队列发送消息，避免再次失败，降低失败概率。 - -异常队列隔离机制分为两步： -**-发现并标记队列为隔离** -       -在发送回调中更新发送队列的健康状态，如果执行的是onSuccess分支，则标记队列为健康，去除队列的隔离标记；如果执行的是onException分支，则标记队列为隔离状态。 - -**-不选择隔离中的队列发送消息** -       -在MessageQueueSelector中实现隔离机制的过滤逻辑，每次进行队列的选择时，优先从没有标记为隔离的队列中选择。当所有队列都被标记为隔离时，则从所有队列中选择，保证每次都要选出一个队列。 - -##### 2. Consumer端的隔离 - -       -Consumer由拉消息线程只负责把拉消息请求以异步发送的形式发送出去。在正常情况下，每次拉消息请求的执行都很快，不会有卡顿。一旦有Broker故障导致PullRequest的执行发生了卡顿，则该Consumer监听的所有Queue都会因为PullRequest执行的延迟而出现消息消费延迟。对于RR同步请求的场景，这种是不能够接受的。 - -       -创建连接采用的是同步建立连接的策略，线程执行创建新连接时必须等待连接创建完成或者连接超时。当有Broker故障连不上时，就算是异步发送，也会因为同步等待连接建立而阻塞。此时就会出现一个Broker的故障导致其他健康Broker的消息消费出现延迟。 - -       -DeFiBus在Consumer拉消息的过程中增加了对拉消息任务的隔离，此处的隔离指的是将疑似有问题的任务隔离到另外的线程中执行，保证拉消息线程能够正常处理其他正常的任务。当发现执行拉消息耗时超过设定的阈值时，将该拉消息任务对应的Broker列入“隔离名单”中，在隔离过期之前，隔离Broker的拉消息请求都转交给另外线程执行，避免阻塞拉消息主线程，从而避免故障的Broker影响健康Broker的消息消费时效。 - -### 连接空闲机制 - -       当连接的读或者写空闲超过60秒时，将主动断开连接。 - - ---- - -#### Links: - -* [架构介绍](../../../README.md) -* [Request-Reply调用](docs/cn/features/1-request-response-call.md) -* [灰度发布](docs/cn/features/2-dark-launch.md) -* [熔断机制](docs/cn/features/3-circuit-break-mechanism.md) -* [服务就近](docs/cn/features/4-invoke-service-nearby.md) -* [应用多活](docs/cn/features/5-multi-active.md) -* [动态扩缩队列](docs/cn/features/6-dynamic-adjust-queue.md) -* [容错机制](docs/cn/features/8-fault-tolerant.md) \ No newline at end of file diff --git a/docs/cn/features/9-publish-type.md b/docs/cn/features/9-publish-type.md deleted file mode 100644 index 18ddd6bfe2..0000000000 --- a/docs/cn/features/9-publish-type.md +++ /dev/null @@ -1,33 +0,0 @@ -## 2. 单播、多播、广播 - -       DeFiBus支持单播、多播、广播消费模式。 - -### 单播 - -
- -![unicast](../../images/features/unicast.png) - -
- -单播模式下，topic只被一个消费组监听；接收消息时，消费组内有且仅有一个实例会收到消息。 - -### 多播 - -
- -![multicast](../../images/features/multicast.png) - -
- -多播模式下，topic被多个消费组监听；接收消息时，每个消费组内有且仅有一个实例会收到消息。 - -### 广播 - -
- -![broadcast](../../images/features/broadcast.png) - -
- -广播模式下，监听此topic的每个消费组中的每个实例都需要收到消息。 \ No newline at end of file diff --git a/docs/en/features/architecture.md b/docs/en/features/architecture.md deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/docs/en/features/request-response-call.md b/docs/en/features/request-response-call.md deleted file mode 100644 index e69de29bb2..0000000000