6、探索无服务器架构：API 网关、组件拆分与互补服务

探索无服务器架构：API 网关、组件拆分与互补服务

1. Knative 与数据集成

Knative Revisions 试图做到独立运行，但它无法检测并重启依赖于运行时发生更改的 ConfigMap 或 Secret 的容器。为确保服务器定期重启，可设置容器生命周期的上限，例如借助 descheduler 项目。

应用已完成首次数据集成，还可轻松实现与其他 API 的集成，如：
- GitHub 或 Jira，用于显示未解决问题的数量
- 日历数据，用于展示下一个或即将到来的事件
- RSS 订阅源，获取最新新闻
- 视频源，搭配一些前端代码

示例使用的是无需认证令牌的公共 API 服务，不过 Knative 可结合标准的 Kubernetes ConfigMap 和 Secret 对象，在运行时注入配置。可将值加载到环境变量中，或挂载到文件系统，若希望应用能实时接收配置更改，后者通常更受青睐。

此外，API 目前仅限于为单个硬编码用户（/my/）获取数据。若有用户账户系统，可利用 Flask 的 URL 模板，为不同用户提供不同的 URL，以获取不同的仪表盘（用户期望的仪表盘可存储在 MySQL 等数据库或 Redis 等键值存储中）。

2. API 网关与应用组合

将整个集成构建到单个容器镜像中存在问题，任何组件的更改都需重新构建整个应用，而且应用的动态仪表盘部分运行缓慢或崩溃时，可能导致静态 Node.js 应用无法加载，因为静态服务器和动态内容混合在一起。

传统解决方案是使用 API 网关或 HTTP 反向代理，将不同的 URL 路径路由到不同的后