這是有關OpenHub框架的系列文章中的第三篇，第一篇介紹OpenHub框架 ，第二篇介紹異步消息傳遞模型 。

該系列的最后一篇文章將更詳細地介紹其他一些有趣的功能，并說明為什么OpenHub可以成為您的集成項目的理想選擇的原因。

節流

節流是一種功能，用于檢查對集成平臺的輸入請求的數量，如果該數量超過定義的限制，則新請求將受到限制。

節流的主要目標是通過大量的處理輸入請求來限制集成平臺的不成比例的（通常是故意的）過載。 這將對應用程序性能產生嚴重影響，甚至可能停止處理當前消息。

節流組件對來自指定源（外部）系統以及特定操作的輸入請求進行計數。 如果此計數在定義的時間間隔內超過了定義的限制，則OpenHub將開始拒絕新的輸入請求（僅來自指定源系統和指定操作的請求）–引發異常。 節流組件支持集群。

節流功能可以配置如下：

############################################################################### # Throttling configuration # # There the following property names: # - throttling.defaultInterval: default time interval (in seconds) if not defined by system/operation # - throttling.defaultLimit: default limit if not defined by system/operation # - throttling.sourceSystem.operationName, where # - sourceSystem is specific source system or '*' if any system # (source system is case-insensitive value from trace header (ExternalSystemExtEnum)) # - operationName is specific operation name or '*' if any operation # # Property values (except for default values) have the following format: # limit [/interval] # # Examples: # throttling.crm.op1=10 # throttling.crm.*=10/40 # throttling.*.sendSms=60/30 ###############################################################################throttling.defaultInterval=60 throttling.defaultLimit=60 throttling.sourceSystem.*=300/60 throttling.*.syncHello=15/60 throttling.*.asyncHello=50/60

例如：

throttling.crm.op1 = 10 （從CRM系統到操作op1的調用限制為60秒內有10個請求）
throttling.crm。* = 10/40 （限制從CRM系統到40秒內10個請求的任何調用）
* .sendSms = 60/30 （限制從任何系統到30秒內60個請求的sendSms操作調用）

警報

警報定義用于監視數據庫數據的度量標準，如果任何度量標準超出其限制，則會激活警報并可以執行進一步的操作。

度量是可配置的–用于獲取項目計數和檢查限制的SQL查詢。

警報示例（還包括后續操作）：

• 當最近10分鐘的失敗消息計數超過5時，則向管理員發送電子郵件
• 當等待外部系統響應超過5分鐘的郵件數超過10時，則向管理員發送電子郵件

默認配置示例：

############################################################################### # Alerts configuration # # There the following property names: # - alerts.N.id: unique alert identification (if not defined then order number (=N) is used instead) # - alerts.N.limit: limit that must be exceeded to activate alert # - alerts.N.sql: SQL query that returns count of items for comparison with limit value # - [alerts.N.enabled]: if specified alert is enabled or disabled; enabled is by default # - [alerts.N.mail.subject]: notification (email, sms) subject; can be used Java Formatter placeholders (%s = alert ID) # - [alerts.N.mail.body]: notification (email, sms) body; can be used Java Formatter placeholders (%d = actual count, %d = limit) # ################################################################################ checks if there is any waiting message that exceeds time limit for timeout alerts.900.id=WAITING_MSG_ALERT alerts.900.limit=0 alerts.900.sql=SELECT COUNT(*) FROM message WHERE state = 'WAITING_FOR_RES' AND last_update_timestamp < (current_timestamp - interval '3600 seconds')

注意：每種配置都可以通過JMX即時設置。

預定的工作

OpenHub支持兩種類型的計劃作業 ：

可以在隨機節點上運行并可以同時執行的作業（沒有條件同時啟動作業 ）

無論在哪個節點上，群集中只能運行一次的作業（請注意：我們沒有考慮計劃的作業只能在特定節點上運行的可能性）

OpenHub框架提供了自己的用于作業定義的API。

配置示例：

@OpenHubQuartzJob(name = "AsyncPostponedJob", executeTypeInCluster = JobExecuteTypeInCluster.NOT_CONCURRENT,simpleTriggers = @QuartzSimpleTrigger(repeatIntervalMillis = 30000)) public void invokePostponedJob() {}@OpenHubQuartzJob(name = "MoreTriggerJob", executeTypeInCluster = JobExecuteTypeInCluster.CONCURRENT,cronTriggers = {@QuartzCronTrigger(cronExpression = "0 00 23 ? * *",name = "FirstTriggerForJob",group = "MoreTriggerGroup"),@QuartzCronTrigger(cronExpression = "0 00 10 ? * *",misfireInstruction = CronTriggerMisfireInstruction.FIRE_ONCE_NOW,name = "SecondTriggerForJob",group = "MoreTriggerGroup")},simpleTriggers = {@QuartzSimpleTrigger(repeatIntervalMillis = 10000,repeatCount = 20,name = "ThirdTriggerForJob",group = "MoreTriggerGroup"),@QuartzSimpleTrigger(repeatIntervalProperty = ASYNCH_PARTLY_FAILED_REPEAT_TIME_SEC,intervalPropertyUnit = SimpleTriggerPropertyUnit.SECONDS,misfireInstruction = SimpleTriggerMisfireInstruction.FIRE_NOW,name = "FourthTriggerForJob",group = "MoreTriggerGroup")}) public void invokeJob() {}

請求/響應跟蹤

請求/響應跟蹤功能允許將路由之間的內部通信或與外部系統的通信保存到數據庫中。 之后，您可以直接進入數據庫并瀏覽請求和響應表，或者查看管理控制臺。

消息詳細信息–請求/響應跟蹤

錯誤處理

Apache Camel中有一個基本的錯誤處理 ，但是OpenHub框架有其自己的概念來處理錯誤：

• 有自己的帶有基本IntegrationException的異常層次結構
• 錯誤目錄定義了帶有描述的唯一錯誤代碼–這有助于識別源系統中的問題
• 錯誤目錄顯示在管理控制臺中

錯誤目錄

翻譯自: https://www.javacodegeeks.com/2017/11/openhub-framework-next-interesting-features.html

總結

以上是生活随笔為你收集整理的OpenHub框架–下一个有趣的功能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。