我正在做一个个人项目，现在准备部署到生产中。关于此问题的独特之处在于，可能有多个客户端要使用该应用程序，并且每个客户端都需要使用自己的服务器来拥有自己的独立应用程序实例（我目前正在使用now.sh来托管应用程序，使用Nuxt构建）。如果说这样的话，我有点困惑，我需要对代码库进行更改，并希望所有客户实例都获得相同的更改。使用2-3个实例会很容易，但是如果有10-20或100-200怎么办？您将如何组织实例，以将更改推送到所有实例，而无需花费半天时间手动进行操作？我希望这是有道理的，请让我知道是否可以澄清。非常感谢！
答案 0 :(得分：1)
每个客户端都需要使用自己的服务器的单独的应用程序实例
[供将来参考的元点–由于您已经实现了应用程序，其实用性可能很低。]
从以这种方式设计的支持系统的经验来看，一个开发模型会要求每个租户拥有独立的基础架构，因此随着扩展规模的增加，维护该模型的成本将很高。
此外，在特定问题域之外， 1 几乎没有必要。在部署和维护生产中的服务时，此类方法通常会以更轻松的开发工作（通过避免与为每个租户划分数据模型相关的问题）进行交易，并且开销更大且复杂。特别是，您遭受以下相互关联的问题：
成本低廉：应用程序的每个实例都需要资源来提供服务。为每个租户复制这些资源将导致支付资源的直接成本以及运输代码和维护车队的运营间接成本中的间接成本。
与每个租户的机器相比，少数共享机器更易于推理和管理，特别是如果您不熟悉托管生产服务。此外，如果您希望从Google的SLA中受益，则必须根据其robust design principles部署每个租户实例，这意味着通过多区域部署为每个租户的部署增加冗余（更多的基础架构成本）。
缺乏资源池和弹性：当您可以通过扩展资源池（尤其是CPU，内存）并灵活地运行应用程序时，公有云工作得非常好响应您全球实际需求的决策，并在所有租户之间共享。按租户部署模型仍然可以获得这些好处，但是您需要扩展扩展域，以按租户进行操作。除非您的租户庞大且具有重要的基础架构，否则几乎可以肯定会让您付出更多。每个租户的实例必须单独扩展，并且当租户不使用您的系统时，您可能需要支付大量空闲实例的费用。 （免责声明：我不知道您的系统是做什么的，所以我只是顺应行业趋势。）
1 这样的问题域包括高度管制的行业，这些行业需要硬性边界以在系统租户之间实施严格的数据隔离；任何具有安全性质或出售给具有安全意识的个人的东西（有争议）；实例（旧的（本地）应用程序）从每个租户的本地金属迁移到云部署，而无需大量重构其数据或部署模型。
使用2-3个实例会很容易，但是如果有10-20或100-200怎么办？您将如何组织实例，以便将更改推送到所有实例，而无需花费半天时间手动完成呢？
您将需要使模型可复制，并确保过程自动化。更少的东西将变得难以管理，并不可避免地导致部署之间的漂移，使其成为特殊的“雪花”，并且随着时间的推移将变得更加难以推理。
这里有多种工具和方法可以帮助您
配置管理：诸如Ansible或Salt之类的工具。在源代码中以声明方式指定每个实例的所需配置。无需手动执行命令（例如通过SSH到每台计算机），您可以委派给特定工具来解释所需的配置并更改远程实例的配置以使它们收敛到表示的状态。如果计算机死机，则可以通过针对干净的实例重新运行部署手册来轻松地替换它。
图像铸造厂：公共云使旋转新实例的成本降低。与物理计算机不同，您可以销毁实例并在每个部署中重新创建它们。这可能会在构建链中迈出更高的一步，也许是在机器需要为每个租户进行自定义之前（避免重复劳动），并用从干净映像构建的已知良好版本替换机器有助于消除漂移。像Packer这样的工具与配置管理工具结合使用，有助于构建常见的映像，您可以使用managed instance groups对其进行部署。
基础结构作为代码：Terraform之类的工具与用于声明性定义基础结构的配置管理工具的工作类似–指定实例组及其在代码中的配置，而不是在云管理控制台中指向并单击。
要点：这些工具可帮助您定义流程，但它们本身并不是解决方案。您需要确定在交付管道中需要执行哪些步骤才能将代码从提交到生产并实施 。这些工具会有所帮助，但不是万能药。
如果需要按租户部署并且现在更改应用程序体系结构为时已晚，则可以考虑对应用程序进行容器化，并使用Google Kubernetes Engine之类的托管容器平台进行部署。 GKE允许您为每个租户运行一个通用的基础架构（Kubernetes的“集群”），从而受益于基础架构的规模经济，同时为系统中的每个租户托管一套独立的容器。
在此模型中，您的部署管道将涉及以下步骤：使用代码（使用您喜欢的CI系统或Google Cloud Builder之类的托管服务）从代码构建容器映像，并实施将这些映像运送到生产环境的过程。