architecture - 部署在云上与本地部署时应用程序级别的变化是什么

Question

如果我们使用云/内部部署，我想知道应用程序范围内的变化。
Cloud based：我们不需要担心服务器、软件、可扩展性、会话管理、负载平衡等。
On-Premise：所有这些也可以在本地实现。

示例：我们可以考虑一个简单的 Web 应用程序，该应用程序存储客户信息，另一个页面列出了在应用程序中注册的所有客户详细信息。它正在使用 Web API、SQL 数据库和 Angular/React 作为前端技术进行开发。

如果我们选择云或内部部署，是否需要在应用程序中进行任何特定更改？

标签： architecturecloud

Answer 1

您几乎可以在不更改应用程序代码的情况下将本地应用程序直接迁移到云中。

但是如果你这样做了，你就几乎错过了云的意义，因为你仍然要负责修补服务器、配置负载平衡器、优化数据库等。

如果您的唯一目标是降低物理基础设施成本，并且您不担心运营成本（例如，将管理您的基于云的基础设施的人员）并且云计算肯定更便宜，那么您可以这样做。

但是，如果您想利用云的真正优势 - 弹性和更全面管理的服务 - 那么您可能需要查看云原生功能。

例如（以 AWS 为例）：

• 与其自己管理 MongoDB 数据库，不如考虑 DynamoDB（完全托管的非 SQL 数据库）
• 考虑 RDS（支持 PostgreSQL、MariaDB、MySQL 等多个数据库的完全托管的数据库即服务），而不是像 PostgreSQL 这样的传统 SQL 数据库。
• 与其自己配置负载平衡器，不如考虑 ELB（托管网络和应用程序负载平衡器）
• 考虑使用 SQS 和 SNS（基于 HTTP 的轻量级消息传递），而不是像 RabbitMQ 这样运行消息代理
• 与其运行您的操作系统、应用程序服务器和微服务代码的大量虚拟 EC2 服务器，不如考虑您是否可以将其实现为无状态 Lambda（功能即服务，即只有您的代码，没有 O/S 或应用服务器或容器管理）。

许多这些服务可以自动无缝地扩展和缩减以满足需求，并且您只需为使用的内容付费，而不需要过度配置。

这只是关于如何重新考虑应用程序设计以利用云的一些想法。请注意，您将自己锁定在此路径上的供应商中。

编辑：好的，所以如果您计划在本地构建然后稍后迁移，那么上面的云原生选项显然不起作用，尽管有些仍然适用。

因此，最简单的方法是像平常一样构建您的应用程序，然后转向基础架构即服务 (IaaS)，让您的操作系统、应用程序服务器和应用程序在今天的基础上运行。将您的数据库移动到等效的托管服务。考虑简单地丢弃您的本地负载均衡器并在迁移时使用云原生负载均衡器。

另一种方法是使用容器，特别是 Docker，在本地打包和部署。您需要在本地管理自己的 Docker 集群，但是当您将应用程序转移到云端时，您可以将其托管在 ECS（AWS 弹性容器服务）或 EKS（AWS 弹性 Kubernetes 服务）等托管服务上。