OmniCore - 企业业务能力中心
企业应用里的支付、推送、文件上传和文档处理看似彼此独立，真正落地后却会反复遇到同一组问题：渠道凭据如何保护、不同应用如何隔离、回调如何验签、异步任务如何重试、配置变更如何不停机生效。OmniCore 将这些共性能力收敛为一个平台，让业务系统面向稳定契约开发，而不是直接依赖每一家渠道 SDK 和各自不同的状态语义。
项目采用模块化单体：支付、消息、核验、文件和文档等领域保持独立的服务与数据边界，共用应用注册、能力授权、渠道配置、存储、任务调度和可观测基础设施。这样的形态保留了单进程部署与事务协作的直接性，也避免把渠道差异扩散到业务代码。
三个服务平面，各自承担明确职责
内部服务通过 :9120 的 gRPC 接入支付、消息、核验、微信分享、Excel、PDF 生成和 PDF 原生解析。客户端流用于上传 Excel 与 PDF 分块，支付查单等普通请求走一元 RPC；统一拦截器负责恢复、访问日志、指标、错误映射，以及配置启用后的服务令牌验证和能力检查。
:9121 是需要被渠道或终端访问的 HTTP 平面，承载微信与支付宝支付回调、鸿蒙消息回执、设备 Token 注册、文件上传下载、协议公开页、App 最新版本查询和健康检查。它与内部 RPC 分开，公网暴露范围可以按真实路由精确收敛。
管理平面独立监听 :9122，提供接入应用、渠道实例、存储、协议、版本、模板和平台单据管理。入口验证统一 IAM 签发的管理令牌，再依据同步的 RBAC 策略包执行 API 级鉴权；管理端口只面向内网或运维网段，不与渠道回调共享暴露面。
应用身份贯穿每一次能力调用
平台以 platform_app 作为业务隔离起点。支付单、消息记录、文件对象、解析任务和渠道绑定都先解析 app_code，再落到内部 app_id，查询和状态变更始终携带应用范围。应用停用后，注册表不会再向调用链返回可用主体。
服务到服务鉴权启用后，调用方必须携带统一 IAM 签发的 service realm 令牌。授权层继续校验两件事：令牌 subject 是否登记在目标应用的 service_subjects 中，以及该应用是否拥有当前 RPC 对应的 capability。授权模式支持 off、observe 与 enforce，可以先记录拒绝原因和指标，再切换为强制拦截；enforce 模式按 fail-closed 执行。
应用回调密钥、文件令牌、渠道 Secret、存储凭据、代付收款信息和异步文档数据使用 AES-256-GCM 加密落库。明文密钥由环境变量、文件或 Vault/OpenBao 引用在启动期注入，不需要进入业务配置和管理页面的持久状态。
支付与消息共用可靠交付思路
支付服务统一封装微信、支付宝和 Mock 渠道，覆盖下单、查单、关单、退款与代付。每个应用可以绑定自己的渠道实例，JSAPI、小程序和 App 支付据此使用对应的渠道应用凭据；支付单在创建时固化实例，后续查单、退款和回调不会因重新绑定而漂移。
业务订单号和退款单号由数据库唯一约束提供并发幂等。渠道回调先完成签名验证和订单要素核对，再通过带状态前置条件的 SQL 推进终态，并在同一事务里写入业务通知任务。重复回调只会读到已经收敛的结果，不会再次触发状态迁移。
业务通知 worker 从 PostgreSQL 领取待发送记录，通过 Redis 分布式锁协调多实例执行，并使用应用独立的 HMAC 密钥签名 HTTP 回调。失败记录按照退避时间重试，通知编号保持不变，业务方可以稳定去重。
消息服务采用同样的记录与重试模型，当前适配极光 JPush、鸿蒙 Push Kit 和企业微信应用消息。应用按业务编号绑定推送实例，发送请求解析到对应 provider；设备注册接口从 App access token 中取得用户身份，避免客户端自行声明其他用户。每次发送都会形成可查询记录，失败消息由 worker 在最大重试次数内重新派发。
文件和文档形成一条处理流水线
文件服务同时支持普通 multipart、批量上传和 S3 语义的分片上传。服务端按实际内容嗅探 MIME，流式计算大小与 SHA-256，再将对象元数据登记到 PostgreSQL。MinIO 存储配置可以登记多套并为应用绑定专属实例；没有绑定的应用使用默认存储。私有对象只返回限时预签名 URL，也可以通过平台代理下载。
Excel 服务把解析规则设计成版本化模型。业务系统可以通过 gRPC 流上传 .xlsx、.xls，也可以提交经过公网地址校验的 URL；同步模式直接返回结果，异步模式保存私有源文件，由带租约的 worker 解析并按行持久化结果。导出方向复用同一模型定义列与格式，生成的工作簿作为私有文件保存并按查询请求刷新下载链接。
PDF 生成服务由管理端维护版本化 HTML/CSS 模板、字段模型和输出策略，运行时将 JSON 数据交给 Folio 渲染器，支持同步返回和异步任务。独立的 PDF 原生解析服务可以提取文档信息、逐页文本以及带页面坐标的文本和图片块，支持页范围、加密文档密码、严格解析与容错回退；源文件和逐页结果分别通过私有对象与 AES-GCM 密文保存。
Excel 解析、Excel 导出、PDF 生成和 PDF 解析都设置了文件大小、行数、页数、解压内存与任务重试上限。它们共用文件服务和任务记录，因此上传、处理、查询、下载与保留期清理能够沿同一条资源链路追踪。
渠道配置可以热切换，但不会带病替换
支付、推送、核验和分享渠道统一登记在 platform_channel_config。公开参数与加密 Secret 分列保存，应用通过 binding 选择命名实例。后台轮询配置版本后先构建一份完整的新快照，只有所有 provider 初始化成功才原子替换；新配置无效时继续保留上一份可用快照。
文件存储注册表采用相同策略：启动时要求至少能装载可用配置，运行期更新在校验桶与连接后切换。渠道与存储的 reload 结果都有 Prometheus 指标，/healthz 检查进程存活，/readyz 检查 PostgreSQL 与 Redis 依赖，HTTP 和 gRPC 在退出时执行优雅停机。
其余能力仍保持统一的应用边界
核验服务提供人脸核身初始化与结果查询、企业三要素和银行卡要素核验，具体厂商实现从渠道快照取得。微信分享服务向 App 下发客户端配置，并在具备服务端凭据时生成 JS-SDK 签名，应用绑定决定使用默认还是专属微信实例。
协议模块对用户协议、隐私协议和保密协议等内容做 HTML 清洗，已发布版本保持不可变，公开 HTTP 端点只返回当前生效版本。App 版本模块按应用分别维护 Android、iOS 与 HarmonyOS 版本，终端可以按应用和平台查询最新发布记录。
代码验证
仓库测试覆盖支付幂等和状态迁移、微信与支付宝回调验签、渠道多实例、通知重试、设备注册、应用能力授权、文件与分片上传、MinIO 路由、Excel 解析导出、PDF 生成与原生解析、管理平面 RBAC，以及配置校验和热重载。整理这篇项目时执行了 go test ./...，全部包通过或没有测试文件。
OmniCore 最终交付的是一套可复用的业务基础设施边界：业务系统只关心应用身份和业务参数，平台负责渠道选择、凭据保护、幂等状态、可靠通知、文件生命周期和运维观测。新增业务应用时，可以复用相同契约与治理方式，而不需要再次搭建一套支付回调、推送重试或文档任务系统。