服务绑定：连接应用到数据库的更佳方式

# 服务绑定：应用的自动化数据库访问 来源：https://openrun.dev/blog/service-binding/ OpenRun是一个开源的（https://github.com/openrundev/openrun）部署平台，专为代码优先的内部工具而设计。OpenRun是使用GitOps在单节点或Kubernetes集群上声明式部署Web应用的最简单方式。OpenRun为代码优先的应用提供了通常在低代码工具（如Retool）中才有的平台功能。 ## 背景https://openrun.dev/blog/service-binding/#background 大多数应用都需要数据库来实现数据持久化。部署平台通常假设每个应用安装时会配套提供一个新数据库。这就是常见的每个应用都有自己的Docker Compose或Helm chart的做法。这种做法忽略了确保数据库得到妥善管理（备份、监控、容量规划等）所涉及的复杂性。 在大型公司中，另一种做法是与你的数据库团队（“DBA”）协作，为你的应用申请新的数据库账户。在提供理由、性能要求和其他细节后，可能会在几周后收到使用的凭据，也可能根本没有回应。 ## 服务绑定https://openrun.dev/blog/service-binding/#service-bindings 对于服务绑定，目前没有一个统一的标准定义。一般来说，它是一种规范，用于指示你的应用需要使用某个特定的服务。使用该服务的凭据由服务提供方通过API提供。 Cloud Foundry（https://docs.cloudfoundry.org/services/managing-service-brokers.html）使用服务绑定的术语来表示服务实例，以预置并向应用交付凭据。Kubernetes有一个服务绑定（https://servicebinding.io/）规范。Red Hat为Kubernetes开发的服务绑定操作器已于2024年弃用（https://redhat-developer.github.io/service-binding-operator/userguide/intro.html）。 ## 工作原理https://openrun.dev/blog/service-binding/#how-it-works OpenRun实现了一个服务绑定（https://openrun.dev/docs/applications/servicebindings/）功能。其工作方式如下： - 你在OpenRun中创建一个服务，并指定该服务的管理员凭据。服务的安装和管理不在OpenRun的范围内。可以是托管的RDS数据库，也可以是由你的数据库团队管理的实例等。 - 每个应用都可以请求一个服务绑定。如果请求了，在应用安装期间，OpenRun使用管理员凭据连接到服务，并创建应用专用的账户。对于Postgres，这包括一个架构和角色；对于MySQL，则是一个数据库和用户等。对于派生绑定，数据库/架构是共享的，但角色/用户是唯一的。 - 应用专用的凭据在应用启动时被注入到应用的环境变量（ENV）中。应用代码读取环境变量并像往常一样连接到数据库。 初始设置服务需要一次性成本。之后，每个带有基础绑定的新应用都会自动获得一个隔离的数据库环境，无需任何手动配置。数据库/架构和用户凭据是隔离的。服务本身是共享的，因此在性能和容量方面没有隔离。数据库实例所需的监控和容量规划保持不变，但不再针对每个应用进行，而是针对服务统一进行。 请参见示例（https://github.com/openrundev/openrun/blob/main/examples/todo.star），其中创建了两个应用，每个应用都有自己的唯一数据库/架构。 基础绑定布局：一个具有管理员凭据的服务，两个基础绑定各自创建一个隔离的架构和角色，以及两个通过环境变量获取凭据的应用。 ## 预发布环境https://openrun.dev/blog/service-binding/#staging-environment OpenRun应用附带一个预发布应用（https://openrun.dev/docs/applications/lifecycle/#staging-apps）。由于数据库凭据由OpenRun管理，OpenRun会自动确保预发布应用获得单独的数据库/架构。这不需要额外的工作。默认情况下，预发布环境与生产环境位于同一个数据库实例上。在服务级别，可以设置一个预发布服务（https://openrun.dev/docs/applications/servicebindings/#staging-services）。如果这样做，该服务的预发布环境将位于一个单独的数据库实例上，从而确保预发布和生产环境之间的性能隔离。 ## 跨应用共享访问https://openrun.dev/blog/service-binding/#sharing-access-across-apps 这种方法的一个更有趣的用例是多个应用可以访问相同的数据库/架构，但使用不同的凭据。这可以实现以下场景： - 应用1对一个数据库/架构拥有完全访问权限。应用2是另一个不同的应用，对同一套表只有只读访问权限。 - 应用1和应用2是相同应用源代码的两次安装，但配置了不同的应用级身份验证。在数据库层面，可以配置权限授予，确保每个安装拥有最小权限。例如，通过SSO登录的最终用户比匿名用户拥有更多权限。 在OpenRun中，使用派生绑定（https://openrun.dev/docs/applications/servicebindings/#create-derived-bindings）来实现共享访问。派生绑定是基于基础绑定创建的。派生绑定上的权限授予控制该账户可以做什么。 授权功能通常是比较难以实现和验证的代码之一。在数据库层强制执行权限具有一个优势，即可以获得第二层正确性检查。 请参见示例（https://github.com/openrundev/openrun/blob/main/examples/todo_derived.star），其中创建了三个应用。管理员应用对一个架构拥有完全访问权限。待办事项应用对一张表拥有完全访问权限，对另一张表拥有只读访问权限。第三个视图应用与待办事项应用共享源代码，对两张表都只有只读访问权限。 服务绑定布局：一个具有管理员凭据的服务，一个基础绑定创建架构和角色，派生绑定共享架构但使用唯一角色，以及通过环境变量获取凭据的应用。 ## 行级安全https://openrun.dev/blog/service-binding/#row-level-security 对于Postgres，行级安全（RLS）被用作在共享数据库内实现用户/租户隔离的一种方式。虽然RLS有一些好处，但它需要仔细设置角色/会话上下文，并可能限制应用设计。RLS在大规模使用时也可能对性能产生一定影响。 服务绑定方法允许你以任何方式构建应用。它更广泛适用，并且可以针对大多数服务实现，甚至是非数据库服务（如消息队列）。