星云中台调用黑洞引擎，一个token还是两个token呢?
背景
在前面星云图形中台设计理念这篇文章中，我们介绍了星云中台所采用的高性能国产图形引擎——黑洞引擎。要实现与黑洞引擎的顺畅对接，首先必须成功获取黑洞引擎的 Token。更重要的是，在用户使用星云中台时，我们需要确保该 Token 始终有效，避免因 黑洞Token 过期而导致的中断和操作失败。
两个token方案
在最初的设计阶段，我们采用了前端保存两个 Token 的方式，即一个第三方系统的token和一个黑洞token。该方式包括以下两个步骤：
第一步：生成两个token。
（1）用户登录嵌套中台的第三方系统（如星云系统）时，首先调用本系统接口生成自身的 Token。
（2）成功生成自身 Token 后，调用中台接口来生成黑洞 Token。该接口会收集必要参数，调用黑洞引擎生成 Token，成功后将 Token 返回给前端。
（3）第三方系统的前端将自身 Token 和黑洞 Token 保存到 Cookie 中。
第二步：使用黑洞token访问黑洞系统。
（1）当前端发起对黑洞系统接口的调用时，首先从 Cookie 中解析黑洞 Token，并将其放入请求 Header 中。
（2）中台的 Nginx 转发请求至黑洞系统。
（3）同时，利用 Nginx 的流量复制功能（通过配置 /mirror），在请求转发到黑洞系统的同时，也将请求转发到中台的刷新 Token 接口。该接口会同时刷新第三方系统的 Token 和黑洞 Token 的有效期，确保它们的生命周期一致。代码如下：
location /blackholeapi/ {
mirror /mirror;
proxy_pass https://${engine_addr}/;
}
location /mirror {
internal;
proxy_pass http://${gateway_addr}/bjuserplatform/refreshToken;
}（4）黑洞系统验证 Token，通过验证后处理用户请求，并返回相应结果。
在初期，我们采用这种方式，虽然能够实现对黑洞系统的访问，并确保两个系统 Token 的生命周期一致，但给前端同学带来了很大困扰。前端不仅需要维护两个 Token，还要根据不同的请求知道该带上哪个 Token。尤其是在移动端接入图形引擎功能时，这一过程需要重复实现。更为关键的是，如果星云中台未来需要对接客户的第三方系统，这样复杂的对接方案，客户是否能够接受呢？
一个token方案
于是，我们开始思考，是否可以让用户始终使用自身系统的 Token，在访问黑洞系统时，通过后端动态获取黑洞 Token，再进行访问。最简单的方案是将黑洞相关操作封装在后端接口中，统一处理。然而，这引发了后端同学的异议——前端本可以直接调用黑洞接口，为什么还要经过后端这一层？而且，多加一层后端调用无疑会影响性能。那么，能否将生成黑洞 Token 的过程移到 Nginx 层呢？Lua 可以实现这个需求，但这会引入新的技术栈，增加运维复杂度。此时，运维团队也觉得在 Nginx 层实现会带来不必要的负担。经过深入查阅资料，我们终于发现了 Nginx 的 auth_request 指令，它能够在 Nginx 层实现鉴权，解决我们的问题。
（1）用户发起对黑洞系统接口的请求。
（2）请求首先经过第三方系统的 Nginx，并被转发至中台的 Nginx。
（3）在中台 Nginx 转发请求至黑洞系统之前，通过 auth_request 指令调用中台的生成黑洞 Token 接口。此调用经过网关（Gateway），对用户携带的第三方 Token 进行认证，认证通过后，才将请求转发至用户服务。用户服务调用黑洞系统接口生成黑洞 Token，并将 Token 返回给 Nginx。这一步，可以简称为“用第三方系统的token换黑洞token”。
（4）中台 Nginx 使用 auth_request_set 指令将生成的黑洞 Token 保存到变量 bh_token 中，然后通过 proxy_set_header 指令将该 Token 设置到请求黑洞系统的 Header 中的 Authorization 字段，之后将请求转发给黑洞系统。代码如下：
location /blackholeapi/ {
auth_request /auth4Blackhole;
auth_request_set $blacktoken $sent_http_blackholeToken;
proxy_set_header 'Authorization' $blacktoken;
proxy_pass https://${engine_addr}/;
}
location ~ /(auth4Blackhole) {
internal;
proxy_pass http://${gateway_addr}/bjuserplatform/$1;
proxy_connect_timeout 30s;
proxy_read_timeout 60s;
}（5）黑洞系统处理转发过来的请求，并返回结果。
采用单一 Token 方案的最大优势在于显著简化了前端的工作流程。前端不再需要同时处理两个 Token，也不必担心两个 Token 生命周期是否保持一致的问题。无论是请求其他后端接口，还是请求黑洞接口，前端只需携带一个统一的 Token，即可完成所有操作。这种简化不仅减少了前端开发的复杂度，还提升了系统的可维护性和可靠性。
此外，单一 Token 方案对于星云中台的对接能力至关重要。它使得外部系统（如客户的第三方系统）能够更加便捷地与星云中台进行对接，避免了复杂的 Token 管理和传递问题，从而提升了整个系统的扩展性和灵活性。这一设计为未来更多的系统集成和合作奠定了坚实的基础。
总结
本文通过星云中台与黑洞系统对接的案例，详细阐述了如何通过 Nginx 的auth_request 指令，在后台隐式地获取第三方系统的 Token。这种方案不仅限于星云中台与黑洞系统的对接，而是一种通用的解决方案，适用于多种第三方系统的对接场景。无论是需要处理复杂身份验证、还是需要多个系统之间共享 Token，这种方式都能显著简化 Token 的管理和生命周期控制，降低集成的复杂度。
我是维搭的小刘，非常期待与您一起深入探讨，共同探索更多的实现方案和技术细节。