現在網際網路的系統越來越趨向於複雜，從單體系統到現在的微服務體系演變。公司與公司的分工也越來越明確。

大資料公司提供了大資料服務

人臉識別公司提供了人臉識別服務

OCR 公司提供了專業的OCR 服務

車三百  公司提供了 車輛 評估服務

e籤寶/安心籤 公司提供了 線上電子簽約服務。

公司在做業務系統迭代的時候，我們是離不開與上述專業公司的對接，合作。那麼第三方公司提供的對接方式，一般都是 RESTFUL 風格的API.因為簡單，通用性強。我們在對接第三方服務的時候，有個最頭大的問題： 就是對方通常會叫我們提供一個回撥地址，第三方公司通常把自己的服務的處理結果通過我們之前提供的回撥地址，把結果，告知我方，如下圖所示：

這就產生了一個重要的問題：第三方非同步通知過來了，我方的業務介面掛了/我方的服務停了/或者我方接收到了但是消費失敗了 怎麼辦？  問題返過來說: 這部分的容錯機制、高可用機制、消費失敗預警機制，消費失敗補償機制 怎麼處理。

那麼 非同步 Bitter.NotifyOpenpaltform  非同步訊息接收排程中心 就是為解決上述問題而生。

如下圖：

在上圖中，第三方公司的HTTP 回撥先回調到我們 非同步訊息接收中心繫統中，由我們非同步訊息接收系統 在通知業務層服務介面消費。

在上圖中 我們發現： 非同步訊息接收排程中心是不處理邏輯層業務，它負責的就是接收非同步訊息，然後轉給業務層服務介面消費。如果業務層消費失敗，那麼容錯，預警，補償，全都在非同步訊息接收排程中心統一可查(失敗預警)，並通過自動人工 重新發起補償重試。

當然，這時候，非同步訊息接收中心就變得更加重要了，從上圖可以看出，如果，非同步訊息接收中心宕了，那麼問題是災難性的。因此非同步訊息接收中心在部署方式一定是叢集高可用性質的方式。當然 Bitter.NotifyOpenpaltform 是支援叢集高可用部署。

Bitter.NotifyOpenpaltform:

非同步訊息通知平臺，旨在解決多服務、異構系統，內外部系統之間的非同步訊息通知一致性消費問題，NotifyPaltform 採用的是訊息事務一致性方案中的最大努力通知方案來設計.

NotifyPaltform 解決的問題：

1: 規範非同步訊息通知

2: 規範問題查詢

3: 規非同步訊息補償機制

4: 及時發現通知失敗的原因以及報警機制

5:結構化查詢問題介面以及統一補償機制介面

一直努力-不思進取 ！

望大家主動接入，只要今後涉及到非同步訊息通知的.努力接