Web Services 软件开发中的好习惯--在一般定义中,支持服务到底是什么?

hgb9j2n6  于 2022-11-15  发布在  其他
关注(0)|答案(1)|浏览(186)

在一个名为“The 12 factor app”的文档中,我看到4th factor是“支持服务”,我从中了解到,理想的应用程序不应区分本地服务和外部服务,这意味着每个服务都必须是外部服务,可以通过URL访问。
我还看了一下Docker背后的基本面,我的主要误解是:如果我在同一台计算机或虚拟机上有一个完全托管的应用程序,其微服务体系结构使用Docker,其中每个容器都独立执行其负责的任务,该应用程序是否被视为第四个因素?
换句话说,容器隔离是否被视为后备服务,或者它是不够的,要被视为后备服务,该服务必须位于本地主机之外的另一台机器上,并可通过TCP/IP访问?

voase2hg

voase2hg1#

The Twelve-Factor App: Backing Services中的重要部分如下(强调我的):
对于应用程序,[本地和第三方服务]都是附加资源,通过[...]定位器/配置中存储的凭据访问。
也就是说,重要的部分不是服务是“外部”的,也不是服务有明确的URL,而是您可以在建置时变更数据库的位置。页面中的范例与此相关:您可以在您正在开发的同一主机上的容器外部运行PostgreSQL数据库,或者在相邻的Composes管理的容器中运行PostgreSQL数据库,或者在Kubernetes StatefulSet+Service中运行PostgreSQL数据库,或者使用Amazon RDS之类的托管数据库,但是您不需要更改 code 来实现这一差异。
继续以PostgreSQL数据库为例,标准客户端库支持指定数据库主机名的环境变量$PGHOST(另请参见Config页面,环境变量在容器环境中更易于配置)。

version: '3.8'
services:
  database:
    image: postgres:14
  application:
    build: .
    environment:
      - PGHOST=database # <-- database host name as environment variable

由于这是配置和环境变量,* 无需更改代码 *,您可以在指向RDS数据库的容器外部运行相同的应用程序

export PGHOST=database.012345678901.us-east-1.rds.amazonaws.com
./myapp

有一些相当常规的问题会将数据库位置直接嵌入到代码中(通常是localhost),然后尝试调整网络环境以匹配硬编码的开发人员设置(通常通过使用network_mode: host禁用Docker网络)。这在Kubernetes之类的集群环境中不起作用,或者如果数据库没有测试在一个容器中。
我在这里一直以数据库为例,因为数据库很特殊:其中容器通常只能删除和重新创建,数据库尤其具有实际数据,需要备份,迁移等任务具有特定的生命周期。数据库尤其经常受到I/O限制,可以从负载下的专用硬件中受益。在裸机上运行数据库或使用托管数据库解决方案可能是一种很好的做法,然后运行调用外部数据库的完全无状态容器的集群。

相关问题