插件合Azure函数及服务总线：异步整合于宏规

一数据宇宙之变。五下游系统当知：一ERP系，司财计；一检索之务，索引其录；一Power BI之集，供将帅之仪表；一通报之列，传讯于行役之员于携器；一数据之渊，储析理之留。

此之幼版，乃一异步插件，于同一操作后步骤调用五者。于开发中，其可行。于生产，五者中一旦有者不遂，插件步骤即误，重试十次，填塞系统任务队列，而操作者得受传唤。

吾辈所运于企业之规式异矣：插件之职，惟布信息于 Azure Service Bus 耳。五者独立，自该信息之题，各司其途。每者皆自为重试、自为死信、自为监察。插件未尝呼他物，惟及队列而已。

此乃架构之图，代码之文，失败之理，及六载真实之验，铸此而成.

架构

为题非列，因一事发多受。受者各有所择，故事随其心。每受各设死信，非统设——ERP与搜索之务，可各自败而不相染。

插件之小，乃有意为之。每行皆潜藏败笔；所为之事愈少，则愈为可靠。

三要决：

此载负乃元数据，非全行也。其讯含实名、其号，及所变之属。消费者若需全行，则自取之。讯体恒小（小于1KB），故驿传之费减，且避载负逾讯体之限之变例。
插件上下文中之关联标识。每条日志条目及下游消息皆载同关联标识，遂可于一查询中实现跨系统追踪。
筛选之主题字段。订阅者或以主题如 'account.%' 筛选，或以主题等于 'order.Update' 筛选。基于主题之筛选，服务器端代价低廉；基于内容之筛选，代价则较重。

主题之设：

每订阅者之设：

每订阅者皆为一 Azure Function，以 Service Bus Topic 订阅触发。共架一形，而下游逻辑各异。

共形者：

幂等存储，或为 Cosmos DB 配 TTL，或为 Redis。每成功处理之 MessageId 皆录之。TTL 合于 Topic 上之消息时寿，并加安全余裕。

核心之别，在于每户之理：

链无可观，则于生产无益。吾之设：

每项功能应用皆设应用洞察，共享工作空间，使查询跨越各项功能。
每条日志记录皆含CorrelationId与MessageId，依上述BeginScope之范式。
自定制之量：已处理之讯，已败之讯，已寂之讯，处理之时。
监控表（Azure Monitor 工作簿）：每事件类型端到端延迟（自Dataverse变更时间至最终写入目的地）。每消费者死信队列深度。每小时每消费者错误率。
报警：任一消费者死信队列深度> 10，任一消费者处理时长p95> SLA。

一事件之端到端追迹：以KQL查询Application Insights，以CorrelationId为键联。Dataverse中一行之变，自插件→Service Bus发布→每消费者→每下游调用，皆可溯。若有失，则链中所在，了然于心。

一客有：

今状：

功能应用实例与队列深度之比。消耗计划自动伸缩；其默认值较为保守。吾等调适每功能之maxConcurrentCalls，以使消费者处理近其每实例之容量，方启更多实例。

订阅之滤则。初时，每消费者皆得诸事，于码中自滤。移滤于订阅之级（伺侧），消者之费减其六成，盖消者不复为不相关之事而醒也。

去重之窗。初设一分钟之窗，过短；插件重试偶使复件相隔逾分。量得实重试间隔，延至十分，以应其实。

此模式之用过度矣：

下游消费者仅一二人者，直用 Power Automate 流程，事简。
低量场景<每日千事，其运筹之繁，过其通量之益。
无 Azure 之经验者，持 Service Bus、Function Apps、Application Insights，实为运营之重负。待运营之能成，乃择简易之式。

凡合乎其制者（如企业级、多用户、事件关键），此乃吾辈首选之架构。其能承重，其能明示故障，及至事有乖谬，其解必在所知之域，明察秋毫。