.NET环境下Service与Azure Function间配置数据共享方案咨询

针对你遇到的Service1与Service2的配置共享问题，以下是几个可行的解决思路，能避免数据重复、满足前端需求：

1. 中心化配置存储（推荐） #

用Azure App Configuration作为配置的唯一可信源：

• Service1作为配置的唯一写入入口：前端修改配置后，Service1直接将最新值写入Azure App Configuration，不再自行存储配置（或仅做备份）。
• Service2按需拉取：每日定时清理任务触发时，直接从Azure App Configuration读取最新的归档时间，不需要在自身数据库存储配置，彻底避免数据重复。
• 可选优化：如果需要低延迟，配置App Configuration的事件通知，当配置变更时通过Service Bus通知Service2更新本地内存缓存；即使缓存失效，任务执行时拉取源配置也能保证正确性。
• 前端需求满足：前端仍通过Service1的接口获取配置，Service1从App Configuration读取返回即可。

2. Service1提供配置查询API，Service2按需调用 #

如果配置变更不频繁（比如归档时间不会天天改），这个方案最简洁：

• Service1暴露一个只读的配置查询API（比如GET /api/config/archive-time），返回最新配置值。
• Service2的定时函数每次执行前，先调用该API获取归档时间，再执行清理逻辑。
• 容错处理：给Service2加个轻量缓存（比如用Azure Redis或Functions本地缓存），缓存失效时间设为1-2小时；如果调用API失败，就用缓存中的 fallback 值，保证清理任务不中断。
• 前端需求自然满足：前端依然从Service1获取配置，完全符合原有流程。

3. 共享数据库只读访问 #

如果两个服务在同一Azure租户下，权限管控方便，可以采用这种方式：

• 在Service1的数据库中，给配置表创建一个只读视图，然后给Service2的数据库账号授予该视图的只读权限。
• Service2的定时函数直接查询这个视图获取归档时间，不需要复制数据到自身数据库。
• 注意：严格限制Service2账号的权限，只能读取不能修改，避免数据安全风险；前端仍通过Service1获取配置，Service1保持配置的写入控制权。

方案对比 #

内容的提问来源于stack exchange，提问作者Katarina