最近，Gregor Hohpe 发表了一篇文章，建议进行范式转换，以解决无服务器云应用程序的供应商锁定问题。使用模式设计解决方案可以将功能特征与底层云实现解耦，从而更容易避免供应商锁定或采用多云。
尽管人们通常都说云平台服务产品从根本上是相互等价的，但它们之间还是存在足够多的差异，以至于重要的应用场景无法进行直接移植。
因此，在设计系统时，可移植性是一个值得着重考虑的问题，特别是当系统涉及多云部署时。然而，从可移植的角度考虑问题并不件容易的事。
Hohpe 认为其中一个重要的障碍是“心理锁定”。一方面，以往的经验可能会限制一个人的思维模式，导致在采用不同的架构时面临挑战。另一方面，现代云平台倾向于用服务产品来描述解决方案。这样就很难将解决方案转移到不同的平台上。
纯粹的平台服务思维会导致应用程序设计意图丢失，并在思想上将你锁定。
服务映射表太高级了，无法准确地描述可移植性，因为特定的服务功能并非一对一对应的。此外，云服务不一定能够表达解决方案的需求或设计人员的意图。
软件工程领域的一个典型做法是在特定的服务实现之上构建一个可移植的层。Hohpe 指出，这种方法很快就会导致最小公分母效应。这是一个缺点，因为它阻碍了在快速发展的云应用程序领域采用创新技术。
Hohpe 建议，与其从实现时的抽象考虑问题，不如从设计时的抽象考虑问题。作为“与技术无关的设计时词汇表”，设计模式提供了有用的设计时抽象。
将解决方案表示为设计模式可以简化移植到另一个平台的过程。
使用设计模式来表达解决方案，架构师的意图和解决方案的需求都变得显而易见。
/filters:no_upscale()/news/2022/09/design-patterns-serverless/en/resources/1pattern_lockin_3-1663947784248.png)
图片来源：https://architectelevator.com/cloud/serverless-design-patterns/
任何一个设计模式，例如聚合器、发布和订阅通道、编配器，都可以使用特定于每个云供应商的服务产品来实现。有时候，这些产品可能需要组合起来实现特定的设计模式，但这并不是什么问题。
服务组合将成为实现细节而不是设计选择。
Hohpe 补充说，系统设计需要使用“形成单一词汇表的内聚语言”来表达。可以使用多种模式语言来形成这个词汇表，但有必要对它们所应用的系统有清晰的认识。例如，可以使用企业集成模式来设计数据流，但最好使用面向对象的模式来构建组件。
模式语言通过与服务无关的方式表达开发者的意图。
平台的演进意味着模式需要做出权衡变更。这种演进意味着，例如，无服务器云平台可能倾向于使用不同于旧平台首选的模式。由于被广泛使用，可能会发展出新的模式。
原文链接：
Preventing Serverless Vendor Lock-in with Design Patterns
相关阅读：
活动推荐：
2023年9月3-5日，「QCon全球软件开发大会·北京站」 将在北京•富力万丽酒店举办。此次大会以「启航·AIGC软件工程变革」为主题，策划了大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构算力、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近30个精彩专题。咨询购票可联系票务经理 18514549229（微信同手机号）。
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论