Bitter.NotifyOpenPaltform : HTTP 异步消息接收调度中心【开源】：简介

 

• Bitter.NotifyOpenPaltform :   Bitter.NotifyOpenPaltform : HTTP 异步消息接收调度中心--【开源】：简介

• Bitter.NotifyOpenPaltform :   Bitter.NotifyOpenPaltform : HTTP 异步消息接收调度中心--【开源】：使用 （还在编写....）

• Bitter.NotifyOpenPaltform :   Bitter.NotifyOpenPaltform : HTTP 异步消息接收调度中心--【开源】：开源地址：（还在整理....，具体代码还在整理中，大家可以关注下。）

 

现在互联网的系统越来越趋向于复杂，从单体系统到现在的微服务体系演变。公司与公司的分工也越来越明确。

大数据公司提供了大数据服务

人脸识别公司提供了人脸识别服务

OCR 公司提供了专业的OCR 服务

车三百  公司提供了 车辆 评估服务

e签宝/安心签 公司提供了 线上电子签约服务。

公司在做业务系统迭代的时候，我们是离不开与上述专业公司的对接，合作。那么第三方公司提供的对接方式，一般都是 RESTFUL 风格的API.因为简单，通用性强。我们在对接第三方服务的时候，有个最头大的问题： 就是对方通常会叫我们提供一个回调地址，第三方公司通常把自己的服务的处理结果通过我们之前提供的回调地址，把结果，告知我方，如下图所示：

这就产生了一个重要的问题：第三方异步通知过来了，我方的业务接口挂了/我方的服务停了/或者我方接收到了但是消费失败了 怎么办？  问题返过来说: 这部分的容错机制、高可用机制、消费失败预警机制，消费失败补偿机制 怎么处理。

那么 异步 Bitter.NotifyOpenpaltform  异步消息接收调度中心 就是为解决上述问题而生。

如下图：

 

 

在上图中，第三方公司的HTTP 回调先回调到我们 异步消息接收中心系统中，由我们异步消息接收系统 在通知业务层服务接口消费。

在上图中 我们发现： 异步消息接收调度中心是不处理逻辑层业务，它负责的就是接收异步消息，然后转给业务层服务接口消费。如果业务层消费失败，那么容错，预警，补偿，全都在异步消息接收调度中心统一可查(失败预警)，并通过自动人工 重新发起补偿重试。

当然，这时候，异步消息接收中心就变得更加重要了，从上图可以看出，如果，异步消息接收中心宕了，那么问题是灾难性的。因此异步消息接收中心在部署方式一定是集群高可用性质的方式。当然 Bitter.NotifyOpenpaltform 是支持集群高可用部署。

Bitter.NotifyOpenpaltform:

异步消息通知平台，旨在解决多服务、异构系统，内外部系统之间的异步消息通知一致性消费问题，NotifyPaltform 采用的是消息事务一致性方案中的最大努力通知方案来设计.

NotifyPaltform 解决的问题：

1: 规范异步消息通知

2: 规范问题查找

3: 规异步消息补偿机制

4: 及时发现通知失败的原因以及报警机制

5:结构化查询问题界面以及统一补偿机制界面