问题描述
注意：我是开发和 GCP 的新手，如果这个问题太基础，我提前道歉。
你好。我正在处理一个项目，其中 Dialogflow 将向我的 Node.JS Web 服务（运行 Express.JS）发送多个 webhook 请求，以检索一些用户帐户信息。我计划在 Cloud Functions 中运行此 Web 服务（在此称为“Webhook 服务器”）。在繁忙时期，Dialogflow 会每分钟向 Webhook 服务器发送数十个（可能数百个）Webhook 请求。每个请求都会导致在 Cloud Function 中创建一个新的 webhook 服务器实例。
在执行过程中的某个时刻，Webhook 服务将需要访问外部/第三方 Oauth 保护的资源。这意味着 webhook 服务器（Oauth 术语中的“客户端”）将需要获取 Oauth 令牌。这个特定的 Oauth 系统使用“客户端凭据”授权类型。
我已经能够获得 webhook 服务器的单个实例来获取和使用 Oauth 令牌，但是，我很难思考如何为这个特定的 Cloud Functions 场景构建应用程序。更具体地说，我假设让 webhook 服务器的每个实例都请求一个新令牌将是一个糟糕的主意；相反，采用某种设计更有意义，其中单独的服务负责在需要时请求令牌，而数十/数百个 webhook 服务器实例将共享由“token_service”检索的令牌。
到目前为止我的假设是否正确？如果是，我该如何设计这种系统？以下是我想到的一些想法：
==========
想法 #1：让“token_service”将令牌保存在数据库中，例如 Datastore。
以下是我对这个想法的担忧：
想法 2： 让“token_service”在获得新令牌时更新 webhook 服务器 Cloud Function 环境中的环境变量。
这个选项似乎很棒：不是每次创建 webhook 服务器实例时都执行数据库查询，它只是检查“OAUTH_TOKEN”环境变量。无需管理数据库，性能会好得多。但是，不幸的是，我认为这是不可能的。更具体地说，据我所知，“token_service”无法更新 webhook 服务器环境中的变量。如果不是这样，请告诉我。
想法 #3： 让“token_service”通过 REST API 向 Webhook 服务器实例提供共享令牌。换句话说，每次创建 webhook 服务器的新实例时，它都会向 token_service 发送一个 GET API 请求，后者将使用令牌进行回复。
我的理解是 token_service 必须持续运行，这意味着 Cloud Functions 不是一个好的选择。相反，我必须让它在 App Engine 等服务或 VM 中运行，对吗？这个选项有什么优点或缺点吗？从复杂性和性能的角度来看，这似乎比想法 #1 更好，对吧？
==========
如果我完全离开，或者您有任何更好的想法、想法或提示，请告诉我。我在互联网上搜索了所有内容，但没有找到任何关于如何执行此操作的明确指南。
谢谢！
-格斯
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@）