网站上云（企业如何完美上云）

原文来自Medium，作者Victoria Drake原文链接：https://medium.com/better-programming/migrating-to-the-cloud-without-screwing-it-up-ee8455ca0c9e现在，一个试图拓展的应用程序，不使用托管云架构就好像在临渴挖井。这需要大量劳力、许多设备、很多时间，而且很有可能出错，因为无论如何，个人不会有丰富的挖井经验。我们排除一种情况——没有云，也就是用别人的电脑。现在，云服务远远超出我们对单机操作的期待。快速强大的计算能力，已经不需要巨大的办公室空间容纳，衍生出众多监测、管理和分析工具，在指尖即可完成操作。值得注意的是，云并不是一把万能钥匙。对于可以上云的应用程序，比起搭建自己的本地基础设施，它计算能力更强、更快、也更省钱。问题是知易行难。从一开始，迁移到云端就是项艰巨的任务。我们如何才能将日积月累的本地数据和系统转移到别的计算机？毕竟云端看不见也摸不着，怎么才能不把事情搞砸？尽管建立或维护本地系统工作量更小，花销更低，最开始转移到云端还是有一定的工作量。重要的是，一旦应用程序完成迁移，就能充分享有云服务的优势。为实现这一目标并顺利过渡，准备工作至关重要。实际上，这就像搬家一样。本文将高屋建瓴地介绍本地应用程序或自托管应用程序迁移到云端的大体步骤，旨在为特定情况规划合理的流程，更好地了解云迁移的过程。尽管对部分应用程序来说，比如没有可拓展结构或需要大量算力的应用程序，云端可能不是最佳选择，但对大部分现代模块化应用来说，迁移到云大有裨益。近日在亚马逊云服务平台（Amazon Web Services，以下称AWS）解决方案架构的活动中，已经实现了平稳高效且仍旧保持可用性地迁移到云，几乎不折损用户可用性。我会具体介绍AWS提供的服务。当然，其他云服务平台也可提供相似的服务。我发现AWS所提供的服务基本都经过模块化，这点非常好，这也是为什么我偏爱AWS的原因。为使迁移更顺利，以下是我们需要考虑的事宜：迁移类型、保留和清理的内容、基础设施类型和大小、峰值测试准备。迁移类型我们需要了解为什么要将应用程序迁移到云上，同时我们也需要大致了解迁移结果。迁移的方法主要有三种：重新托管（re-host）、更换平台（re-platform）和重构（refactor）。重新托管重新托管是云迁移时最常见的策略。它不会改变应用程序创建或运行的方式。例如，如果目前有Python（计算机程序设计语言）代码，使用PostgreSQL（开源的对象-关系数据库），并通过Apache（开源网页服务器软件）为应用程序提供服务。在此情况下，重新托管就意味着将所有相同的组件以相同的方式组合在一起，只不过组装在云上。这就好比搬入一个房型完全一致的新房子。所有房间布局、家具都和以前一样。当我们住进去时，就会感觉很熟悉。重新托管的好处在于它可以利用云端优势，降低复杂性。比如可扩展应用获得自动管理应用程序资源的能力。值得注意的是，重新托管虽然可以促进应用程序的自动化扩展，但其本身并不能使应用程序具有扩展性。如果应用程序的基本设施本身属性无法拓展，就需要重构应用程序。更换平台若当前应用程序中的某组件运行情况不甚良好，我们可能需要考虑更换平台。这种情况下，我们会更改架构中的至少一个组件。比如，在Amazon云关系数据库（RDS，基于云计算平台的即开即用、稳定可靠、弹性伸缩、便捷管理的在线关系型数据库服务）把数据库从Oracle数据库管理系统更换为MySQL开源数据库。就像从东京一间小公寓搬到纽约一间同样大小的公寓一样，更换平台并不会改变应用程序的基本性质，只是改变了外观和运行环境。以数据库的更改为例，内部数据保持相同，但其组构方式会有些许不同。大多数情况下，我们不需要进行手动调整。像Amazon数据库迁移服务（Database Migration Service）这样的工具可以帮助我们无缝地将数据转移至新数据库。更改平台帮助我们能够更好满足未来的业务需求，比如说扩大业务规模、与其他科技组件融合、或选择一个更现代化的技术堆栈（technology stack）。重构相比其他的方法，重构应用程序会比较复杂。但对于能够使用此类方法的公司或应用程序来说，大有利处。重构对代码进行编辑以满足业务需求。具体细节因情况而异，但通常会涉及对架构组件或组件之间相互关系的更改。为优化应用程序在云环境性能，重构也可能会更改应用程序代码。打个比方，就好像我们从父母的郊区地下室搬到市区里漂亮的联排别墅。我们不可能把陈旧的沙发一起搬出来，所以我们需要购买新的家具，甚至还需要购买窗帘。重构对过时的应用程序进行现代化改造，换句话说，提高应用程序效率。凭借更高的效率，我们可以更好地利用云服务、获取大量资源、以及深度分析能力。如果时间有限，或许我们可以先选择重新托管或更换平台，再进行重构。此举避免因为匆忙调整，引发更多问题。保留 VS 清理在一个地方生活多年，许多东西往往会堆积在角落并被渐渐遗忘。搬家可以让我们好好整理东西，看看哪些要保留，哪些可以送人或丢弃。从应用程序的角度来看，迁移到云的过程就和搬家过程类似。尽管现在云存储的价格并不贵，但有些东西不再适合存储，或者说，至少不能和我们的主应用程序存储在一起。若因为相关政策法规有些数据无法被丢弃，我们可以选择不同的存储类别来存放主程序之外的数据。以Amazon简单存储服务（Simple Storage Service，S3）为例，我们可以选择不同的存储类别存放数据。虽然每日业务运行的数据基本都可以归为“标准类”（使用率达到99.99%），但那些用于长期静态存储的数据（如文档备份），可以归到“冰川类”，这样可存储时间会更长，成本也更低。选择正确类型和规模大小最令人困扰的部分通常是选择合适的云基础设施类型和规模大小。对于在新环境中或正在成长的公司，我们如何预测所需的计算能力？无需采购硬件的好处之一就是不用预测。通过云存储及服务器，我们可在几分钟，甚至几秒钟内完成扩展或缩减资源。若借助托管服务，甚至可以自动完成任务。如果应用程序具备扩展性，就好比有了一间魔法屋，可以生成任何房型和所需的便捷设施。我们可以自主操作确保使用合适且性价比高的资源，这一点也可以通过相关图表直观呈现。对于首次登入云端的应用程序来说，需要先进行测试。虽然云服务能够快速启动并尝试使用不同架构，但不能保证所有设置适合我们的应用程序。例如，运行一个单独的服务器实例可能会比选择无服务器便宜。但是在测试前，我们是无法知道这一点的。首先，我们需要足够的存储空间和计算能力支持当前运行的应用程序。例如，在存储方面，我们需要考虑当前数据库的大小——实际数据库数据，而不是内部硬件的总存储容量。在详细的成本方面，AWS甚至提供了一个带有用例样本的月度计算器，帮助用户预估成本。预先测试运行一个云迁移的试用版，听起来可能有点奇怪，但这能确保一切有条不紊按计划进行迁移，并减少服务中断。试想，如果可以自动运行测试，在上述搬家的例子中，我们可以节省多少时间和精力。我们总是会忘了把一些盒子或墙上挂着的相片带走，于是只好下次再想办法来搬。多次测试可以确保顺利完成任务，从而最大限度地降低迁移导致日常业务中断的可能。一般来说会创建应用程序的副本进行测试。特别是数据异常大的时候，我们的副本与原版越接近，测试就越彻底。尽管创建副本可能有些繁琐，测试实际要迁移的组件可以确保整个迁移过程按部就班进行。毕竟，如果我们想模拟搬家，一个盒子是远远不够的，因为这并不具有代表性。测试运行可以确认可能遇到的挑战，包括停机时间限制、加密传输数据、转换新目标模式、访问数据库（利用防火墙或VPN）、制定程式确保成功迁移所有数据，比如使用哈希函数。测试运行还有助于了解迁移需要的总时间，同时也给了我们微调的机会。可能影响迁移总体速度的因素包括：原服务器及目标服务器的规模大小、移动数据的可用宽带、模式配置、原服务器上的交易压力（比如数据和交易量的更改）。一旦应用程序副本通过一个或多个选项迁移后，我们就可以测试应用程序在云环境的性能，以确保其运行正常。理论上说，在正式迁移原始应用程序之前，我们会采取同样的步骤迁移副本，并且将原始应用程序或网址无缝迁移到云中的新位置。这意味着客户几乎不会经历停机时间。实际上，也只有数据真正迁移的时候会受到短暂影响。针对一些特殊情况，比如许多组件或多个团队同时工作的超复杂（大）应用程序，相较于直接粗暴的方法，循序渐进的方法可能更合适，并且有助于减少中断的风险。这意味着需要一个组件一个组件地迁移，并在各阶段之间进行测试，确保所有的应用程序都能按预期交互运行。前期准备对顺利迁移至关重要希望通过本文，读者能够对云迁移有更实际深入的了解。只有充分的准备，才可以充分利用云服务的所有优势，并将风险降到最低。