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:結構化查詢問題界面以及統一補償機制界面