#5 可移植性与迁移
时间：2022-03-04 18:40:01 | 来源：行业动态
时间：2022-03-04 18:40:01 来源：行业动态
无服务器：假定大家已经在使用AWS的多种不同服务，这时候选择Lambda函数肯定是明智之举，因为其能够与其他服务顺畅集成且可支持快速访问。
即使您并没有使用AWS服务、而且担心供应商锁定问题，也可以通过域映射/DNS变更等方式保证代码中使用的所有API端点和URL始终处于您的控制之下。
这样我们就可以随时切断特定服务，并将其重新定向至您所选定的其他端点（例如其他FaaS服务商）。这种方式显然比在不受控制或者您无法调整的端点中部署硬编码代码要安全得多。
但考虑到市面上FaaS服务商众多，大家对供应商锁定问题的担忧也自有道理。以Lambda为例，如果它无法满足您所在地区的特定要求，大家可以执行以下操作。一切Lambda处理程序的代码都应处于隔离状态，仅仅以垫片的形式在其他模块/类中充当逻辑。
这种方式不仅提高了可重用性，而且能够大大降低重构时Lambda迁移的便捷度与直接性。另外，这种方式还有利于支持单元测试。下面来看瘦Lambda处理程序实例：
说起迁移，目前人们对于如何将FaaS融入现有DevOps框架仍充当争议。组织可能一口气编写了几百个函数，但在一段时间之后再也没人清楚哪些函数中包含着哪些其他函数、又有多少函数仍在正常使用。
容器：如果大家选择了基于容器的微服务架构，就能享受到由此带来的良好可移植性。我们可以轻松将程序代码从开发者的笔记本电脑处转移到本地数据中心或者不同云服务商的云计算平台，整个过程既不费力也不费神。
随着企业承担的创新压力越来越大、产品上市时间越来越短，微服务架构的加持能帮助大家快速为应用程序建立起全新版本。因此，如果大家是出于降低迁移难度、使用丰富的容器技术堆栈等目的而决定从单体式应用程序转向容器，那么微服务架构应该是个理想的探索起点。
然而，在云平台上运行容器时仍然涉及众多依赖项。例如代码升级需要协同规划，具体涵盖容器主机、容器镜像、容器引擎以及容器编排等。
对于某些需要迁移至微服务形式的遗留应用程序，直接容器化所带来的操作难度和成本往往要低于对整体应用程序进行重构。
在线咨询
