DID 身份部署教程：自建签发服务与解析器的完整流程

理论看得再多，最终都要落到部署。如果你想为团队或社区搭建一套 DID 服务，本文给出一个从零开始的完整路径：解析器、签发服务、撤销列表、监控告警，环环相扣。

选择 DID 方法的依据

部署的第一步是选择 DID 方法。常用选项有 did:web、did:ethr、did:ion。did:web 部署门槛最低，把 DID 文档放在 HTTPS 服务器上即可；did:ethr 把控制权写入以太坊智能合约，去中心化程度更高；did:ion 基于 Sidetree，扩展性最强但运维复杂。

如果你的业务对成本敏感、对去中心化要求不高，可以从 did:web 起步；如果你的目标用户大量来自 Binance 等加密生态，建议直接选 did:ethr 或基于 BNB Chain 的实现，让链上身份与现有钱包打通。

解析器服务的搭建

解析器（resolver）负责把 DID 字符串转化为 DID 文档。社区维护着开源的 universal-resolver，支持几十种方法。部署方式是 Docker compose，一次命令即可拉起。

部署后，你需要把它放在 HTTPS 反向代理后面，配置缓存策略。许多 必安平台 衍生项目把解析结果缓存 5 分钟左右，既能减小压力又能保证更新及时。监控接口的 P99 延迟和命中率，是判断部署是否健康的核心指标。

凭证签发服务

凭证签发服务（issuer service）是 DID 应用的核心。它接受业务逻辑触发的「签发请求」，从 KMS 取出私钥签名，再把凭证返回给用户。私钥管理是这里的关键，强烈推荐使用 AWS KMS、GCP KMS 或本地 HSM，而不是把私钥写进配置文件。

业务逻辑通常是「KYC 通过 → 签发等级凭证」。例如 BN交易所 用户完成 KYC 后，issuer service 收到事件钩子，立即签发一张 VC 推送给用户钱包。用户便可以在其他 DeFi 应用上出示这张凭证。

撤销列表的部署

凭证一旦签出，撤销机制就是兜底保险。推荐使用 StatusList2021，把撤销状态压缩为 bitmap，发布在 IPFS 或自家 CDN 上。文档结构由规范定义，签名后的列表只需挂在 HTTPS 上即可。

部署撤销服务时要考虑高可用，因为 dApp 每次验证都会拉取最新列表。建议至少部署在两个区域，CDN 缓存 5 分钟左右刷新一次。许多 BN平台 的合规模块把撤销服务接入 SLA 99.99%，确保用户体验稳定。

监控告警与灾备

最后一步是监控告警。需要监控的指标至少包括：解析器命中率、签发服务延迟、撤销列表更新频率、KMS 调用错误率。任何指标异常都应通过告警系统触达运维。

灾备方面，建议同时备份 DID 文档和私钥的关键摘要。如果使用 multisig 控制根 DID，请把多签成员的地址做好物理冷备份。把这些细节都落地后，你的 DID 部署就具备了企业级生产环境的稳定性，足以支撑数十万乃至数百万用户的链上身份需求。