“serverless”这个词已经流行起来了。在本文中，我将向您介绍如何将本地应用程序迁移到无服务器环境，非常详细和具体，希望对您有所帮助。注意：本文涵盖了我在2019年越南网络峰会上展示的所有内容，这是越南IT界最大的活动。“无服务器”一词最近变得非常流行。它正在改变开发人员和企业使用公有云来交付商业价值的方式。输入这个“关键词”，就可以轻松找到相关文章。但是，我敢肯定没有多少文章会逐步向您展示如何将本地应用程序迁移到无服务器环境，但在这篇文章中，我会这样做！我将向您展示一个案例研究，说明我和我的项目团队如何实施并交付给我们的一个客户。本文要点：客户的问题，为什么要用serverless？无服务器解决方案之路；我们的移民方式；我们面临的挑战。1.客户问题我们的客户提供了一个在线招聘平台。下图说明了系统的工作原理。这是一个非常传统的系统，有2个Web应用程序：1.身份服务器Web应用程序：用于身份验证和授权。此Web应用程序提供一些基本功能，如用户管理(CRUD)、登录/注销、用户权限等。除此之外，它还允许用户与他们的Google/Facebook帐户集成。2.招聘Web应用：这是整个系统的核心。作为用户，我们可以使用求职功能找工作，通过上传文件上传简历……作为管理系统，我们可以使用报表功能，通过客户沟通发送邮件、短信……这些网站应用程序使用相同的数据库，称为“招聘”数据库。此外，系统还包括消息队列、发送通知的后台作业、报表的数据处理……2.那么，问题出在哪里？问题1：庞大的代码库遗留系统太大而无法完全理解，尤其是对于新开发人员而言。我们的客户承认，有一次他们不得不编写一个新函数来修复错误而不是重构，因为导致问题的函数与其他函数紧密耦合。问题二：成本高此外，他们必须购买一台好的服务器来部署系统。运营和开发成本不小。问题3：可扩展性低系统中的模块存在资源冲突，如果要扩展某个特定的功能，比如“JobSearch”，就必须扩展整个应用。这造成了资源浪费，即使被接受，也无法迅速扩大规模。问题4：可用性低：一旦他们发布新功能或改进，甚至修复一个小错误，他们都必须部署整个系统。问题五：可靠性低任何模块中的错误（如堆栈溢出）都可能导致系统崩溃。此外，由于应用程序的所有实例都是相同的，因此错误会影响整个应用程序的可用性。问题六：对新技术不开放系统是用.NET开发的，这意味着Python、Java的新特性将永远无法使用，因为采用新技术会打破现有系统。我想，你可以在你的公司或你的客户系统中找到类似的地方:)3.为什么采用无服务器？我就不给你答案了，你可以从《财富》杂志上说的“汽车95%的时间都是停着的”这个事实就知道了。拥有一辆汽车类似于购买裸机服务器并在该服务器上部署系统。日复一日，您必须维护服务器以确保其正常运行。租车类似于使用VPS服务。您可以短期租用VPS。例子：圣诞节快到了，你预测很多学生打算找兼职工作。期间可以租用VPS来支持应用的扩展。虽然租车可以帮助提高使用率，但最好的选择是汽车共享，例如优步、滴滴……是的，这相当于软件世界中的无服务器。4、Serverless解决方案之路随着云计算的发展，IT基础设施发生了快速的变革。为了给云上的软件增加更多的灵活性和可扩展性，Serverless应运而生。下图说明了IT基础架构的革命。我们曾在1990年代构建和运营本地服务器，以便在其上部署应用程序。服务器是为长期使用而构建的（并且存在多年）。但是，安装、配置和运行需要大量工作。要扩展应用程序，我们需要扩展整个服务器。自2000年以来，我们提供了部署服务器的新选项，虚拟机(VM)进入了“游戏”。与VM一起出现的还有虚拟专用服务器(VPS)。这对于我们的短期使用（几天或几周）来说很方便，并且可以在几分钟内部署。缩放以机器为单位完成。2011年，Docker出现了。在我看来，docker的推出是过去十年中IT基础架构最大的变化之一。它影响我们设计软件架构和部署应用程序的方式。容器不仅可以使用比虚拟机(VM)更少的资源更快地运行应用程序，而且它们还可以扩展，使用多个容器协作以在生产中交付服务。然而，容器的广泛使用大大增加了管理它们的复杂性。无服务器计算不是使用容器来运行应用程序，而是用另一个抽象层代替容器，在这个抽象层中，云提供商充当服务器并动态管理机器资源的分配。5.我们的迁移方法注意：希望当您阅读本文时，您已经了解我们应该采用无服务器的一些原因。如果没有，请返回第2和第3部分重新阅读，或给我发消息。下图是我们系统未来的样子，换句话说，这就是我们和我们的客户想要实现的。虽然出于某些原因我们选择了Azure，但您可以轻松找到类似的AWS和Google云服务。我们使用AzureWebApp托管身份服务器，并使用AzureSQLServer为其创建一个独立的数据库。此外，我们使用Azure流量管理器来实现高可用性和故障转移规划。Azure流量管理器是一种基于DNS的流量负载均衡器，可让你以最佳方式将流量分配到全球Azure区域的服务。未来系统中的求职Web应用程序将仅包含UI/UX，因为我们会将整个业务逻辑移至AzureFunctions。AzureAPI管理（API网关）将用作单一入口点，以确保来自求职Web应用程序的每个请求都必须通过它才能访问AzureFunctions。此外，AzureAPI管理与身份服务器集成以进行身份??验证和授权。与IdentityServer类似，我们还将AzureWebApplication和TrafficManager应用于作业Web应用程序。Azure应用程序网关是我们职业Web应用程序的防火墙。尽管身份服务器和求职Web应用程序已迁移到云服务，但它们并不是无服务器的，它们只是PaaS。要了解PaaS和无服务器之间的区别，请阅读以下文章：https://www.cloudflare.com/learning/serverless/glossary/serverless-vs-paas/Azure提供了两种无服务器架构方法：AzureFunction：这是一种无服务器计算服务，允许您运行事件触发的代码，而无需显式配置或管理基础设施。Azure逻辑应用程序：它有助于构建自动化的可扩展工作流、业务流程和企业编排，以跨云服务和本地系统集成应用程序和数据。在未来的系统中，我们将包括以下Azure功能：职位搜索职位管理客户沟通报告发送电子邮件发送短信此外，还有一个用于“文件上传”功能的AzureLogicApp。此功能需要不同的流来服务于不同的文件类型。例如，excel文件用于数据导入，jpeg/png文件用于图片上传，需要调整大小...还有，我们还有其他Azure服务，如AzureServiceBus，用于文件上传的Blob存储，用于存储表存储用于日志数据。AzureApplicationInsight用于监控。6.迁移步骤我们实施的新架构必须与遗留系统并行运行，以确保对当前业务没有影响。在第一步中，我们必须选择要迁移到无服务器的功能。很难说这不是一场噩梦。假设您必须深入研究遗留代码库（我在上面提到过——庞大的代码库）并在没有任何技术文档或功能规范的情况下选择对其他人影响较小的功能。最终，经过业务分析团队、产品负责人、开发团队的多次讨论，我们决定将“作业管理”作为第一个采用Serverless的特性。接下来，我们创建一个Facade层(https://sourcemaking.com/design_patterns/facade)，提供作业管理功能的高级抽象，重构功能的所有消费者以使用此Facade。这给了我们一个单一的瓶颈点，我们将从中限制功能。现在，是“快乐”部分的时候了——使用AzureFunctions和AzureCosmos数据库创建一个新的实现。创建新功能时，谨慎使用我们用于构建外观的相同抽象。在这一步中，最重要的是使用CosmosDB在现有数据库和新数据库之间同步数据，我们称之为“回填”过程。接下来，我们创建一个Toggler-Facade的第三个实现，充当一种流量路由器，通过Facade层将请求转发到现有或新功能（AzureFunctions）。一旦AzureFunctions准备好使用。我们从CanaryLaunch开始，配置Toggler的功能标志，以便2%的请求被发送到AzureFunctions，而其余98%被路由到现有的实现。假设一切顺利，我们可以慢慢增加新实施的流量，直到最终100%的作业管理功能请求通过我们新的AzureFunctions交付。如果发现新实现有问题，就会触发回滚函数??，回滚请求，将请求重定向到已有函数。一旦我们对新实现感到满意-AzureFunctions按预期执行-我们将继续进行另一个有趣的部分-删除代码！我们现在可以删除已弃用的“作业管理”功能的实现。我们现在还可以删除Toggler。7.我们的挑战Serverless是个好主意！这是一种新范例，可应用于在云中开发和运行的现代应用程序，显着提高开发人员的注意力和生产力。但在开发和交付阶段，我们不得不克服一些挑战，甚至是“陷阱”。1.新技术项目开始时，只有两个人用过云服务和serverless。我们组织了许多培训课程。为了在项目中成功应用新技术，需要说服团队成员使用它。理想情况下，您可以让他们看到这些新技术的好处，并让他们为之兴奋。2.调试分布式应用程序意味着您更多地依赖日志跟踪来查找问题的根源。您可以下载AzureFunctionsCLI，该工具可帮助您在开发阶段调试AzureFunctions。为了在云端调试Azure功能，你必须安装远程调试，这并不容易。3.集成如上所述，我们需要实现新的Azure功能——与遗留系统并行的无服务器。因此，新的Azure功能与现有功能的集成存在问题。4.测试使用无服务器时测试非常困难，因为使用无服务器意味着您无法直接访问执行代码的环境。请记住，必须彻底和仔细地编写单元测试。5.监控无服务器允许应用程序被分解成更小的模块。但这可能会导致分布式监控出现新的问题。通过将一组无服务器组件链接在一起，端到端跟踪请求/响应的能力变得非常重要，但与传统监控工具一起使用会很麻烦。虽然AzureApplicationInsights可以帮助我们监控AzureFunctions，但熟悉指标并不容易。8.总结从单服务器迁移到无服务器并不容易。它需要大量的投资和管理参与。最重要的是，实际负责开发的团队需要令人难以置信的纪律和技能。但是，这样做有很多好处。通常，从小做起是个好主意。与其等待一次性的大动作，不如尝试采取渐进的步骤，从错误中吸取教训，迭代，然后再试一次。另外，不要从一开始就追求完美的设计。相反，您应该愿意迭代和改进。最后，请记住，无服务器不是目的地，而是一段旅程，一段持续改进的旅程。英文原文：https://hackernoon.com/migration-on-premises-application-to-serverless-72w32ju
