Skip to content

Latest commit

 

History

History
65 lines (33 loc) · 2.61 KB

File metadata and controls

65 lines (33 loc) · 2.61 KB

示例项目


示例项目基于 .NET 6.0 实现,位于 samples/SKIT.FlurlHttpClient.Wechat.Api.Sample_Net6

示例项目依赖以下第三方库:

示例项目实现了以下功能:

  • 多租户微信账号;

  • AccessToken 中控;

  • 验证并接收微信服务器推送数据;

  • 一个根据 OpenId 获取用户信息的 API。


【重要】使用前须知:

示例项目仅作为业务上的参考,不代表可直接用于生产。

开发者应提前知晓:

1. 分布式锁:

示例项目使用分布式锁来确保多节点并发情况下不会产生 AccessToken 刷新冲突问题。

示例中的分布式锁是基于文件系统实现的,仅为展示工作原理,只可用于单机环境下;如在生产项目中,请自行替换成基于数据库或 Redis 等实现的锁。

更多的分布式锁实现方案可直接参考 DistributedLock 的开发文档。

2. 数据持久化:

示例项目仅为展示工作流程,未集成数据库来实现数据持久化。

程序中的全部数据都只在运行时内存可访问,一旦进程终止,数据将会丢失;如在生产项目中,请自行集成 MySql / SQL Server / Oracle 等数据库,或其他数据持久化方案。

3. 容错性:

示例项目中未特殊处理可能产生的异常(如:空指针等),也没有考虑 AccessToken 中控刷新失败等业务逻辑问题,开发者可根据业务需要自行实现。

4. 安全性:

示例项目中不包含授权认证等相关的业务逻辑,开发者可根据业务需要自行实现。


【附录】关于 AccessToken 的刷新机制:

示例项目遵循微信官方建议的“使用中控服务器统一获取和刷新”原则,实现了 AccessToken 的主动刷新机制,开发者不需要、也不应该在业务代码中手动执行刷新操作。

所谓“主动刷新机制”,即由系统在后台周期性地执行刷新操作,在需要使用 AccessToken 时直接读取已有的记录即可,无需关心 AccessToken 是否过期。

与之相对应的是“被动刷新机制”,即在每次读取时先判断已有的记录是否过期,如果未过期则直接返回,如果过期则执行一次刷新操作后再返回。

开发者可根据业务需要自行实现被动刷新机制,也可以二者相结合。