中间件能否在无服务器时代存活

本文最初发布于medium技术博客，经原作者授权由InfoQ中文站翻译并分享。

无服务器架构避免了配置中间件的繁琐操作，简化了应用的运行环境。中间件能否在无服务器时代继续存活乃至发展？本文剖析了核心、集成、辅助中间件等应用层次受无服务器的影响情况，探索了云部署和本地部署环境下中间件的优劣所在。

思维实验

请读者考虑以下场景。假设如下：

• 无服务器部署已经取得突破，并形成了统领新软件服务市场半壁江山的三大云服务巨头。
• 由于各巨头间大打价格战，用户从云中获取主机的成本要低于自建服务器。
• 大多数新应用是使用IDE编写的，这简化了无服务器部署。开发人员使用IDE编写功能函数，然后通过函数调用构建可工作的应用。进而应用将在本地开发、调试、一步步执行和追踪，一旦可正确运行就在云端部署。IDE还支持版本控制和CI/CD。

上述假设场景中的三巨头可映射为现实中面带微笑的杰夫·贝索斯、立刻跟进的微软，以及掌控了庞大资金来源的谷歌。最终，随便一名小朋友都能在一小时内让应用在无服务器环境中运行起来，为自己的了不起开心不已。

那么中间件将置于何处，其未来何在？下面我们基于不同类型的中间件，分别阐释这个问题。

应用架构刨析

一个典型的应用，其底层通常包括数据库等多个核心中间件服务，还可能依赖于其它一些服务，例如消息队列、缓存和流处理器等。

在核心中间件层之上，是ESB、工作流引擎和API管理工具等集成中间件。这些集成中间件整合多种服务，以交付特定的业务用例。

集成中间件层之上，将为终端用户提供应用体验，一般是运行在浏览器中的Web应用，或者是移动App等形式。

最后一层提供一些辅助服务（helper services ），用于提升用户体验，改进应用操作环境，目的是使服务生命周期尽可能的平滑。

上述各层都离不开中间件的支持。下面我们将阐释无服务器云将如何影响各层的实现。

对核心中间件的影响

核心中间件包括为服务和应用的编写和托管提供帮助的中间件（例如应用服务器、Web服务器等），以及应用直接使用的中间件（例如数据库、消息代理、缓存和流处理器等）。

核心中间件受无服务器冲击最严重。考虑到广域网中存在高延迟，所有中间件会尽可能地部署在同一处。

应用服务器首当其冲，受到了无服务器的直接威胁。很多新应用都倾向于采用微服务架构，无服务器是微服务架构的自然扩展。微服务架构已将单体应分解为各个松耦合的服务，由此应用非常易于迁移到无服务器架构。

无服务器云服务以PaaS方式提供数据库、消息代理和流处理器等服务。这里需要考虑两个问题。首先，是否依然给中间件留下了足够的独立用例？其次，如果无服务器架构接管了大部分开发，是否也将选择接管中间件层？

对于第一个问题，应认识到无服务器架构固守着自己的做法。因此，用户可能会遇到并不符合自身期望的情况。这完全可能成为中间件得以延续的理由。另一方面，要解决此类问题，需要精心编排客户服务。中间件市场依赖于被服务商和组织视为合作伙伴关联的客户关系和客户服务，而非“不容讨价还价”的黑匣子。但是在云服务巨头服务的DNA中，从来都没有客户服务和客户关系的一席之地。二者的业务模型完全是背道而驰的，存在难以弥补的鸿沟。云服务巨头如果无法解决这一问题，那么就完全忽视了落于长尾分布尾部的大量应用。这一鸿沟为中间件企业留出了足够的生存空间，甚至完全挤掉云服务巨头，赢得长期竞争。一种好的做法是，云服务巨头可以拿出部分收入，让中间件供应商去处理客户服务。这种模式更具可行性。

对于第二个问题，即便无服务器占据了大部分市场，也不能说云服务巨头会吞并所有中间件，干掉所有独立项目。中间件可不简单，它历经数十年的时间，汇聚无数人的聪明才智，解决了大量的分歧，才达成目前的现状。一旦缺乏维护，中间件代码会随着其所依赖的终端、硬件和业务的不断演化而腐烂变质。接手它们有太多太多的工作要做，即便是云服务巨头也很难做到。

许多中间件项目都具有活跃的开源社区。由此，云服务巨头可以参加到项目中，做出贡献，并引导项目，进而成为市场领导者，甚至可出于自身的利益考虑做一些市场营销。这样，那些不属于开源项目的独立中间件将会陷入困境，进而逐渐消亡。多家云服务巨头甚至可以出于共同利益或者是并非真正竞争点的考虑，合作构建出类似于Kubernetes那样的项目。

对于非开源厂商主导的市场，例如当前使用的Oracle数据库和微软Windows，云服务巨头可通过支付许可费或实现收益分成而参与其中。一方面，随着无服务器的崛起，中间件独立开发的市场将收缩。另一方面，通过向无服务器授权，中间件公司也可获得新的收入来源。但是在这种关系中，云服务巨头无疑处于价格谈判的上峰。中间件公司将会看到自身的收入虽然增加了，但利润去下降了。鹿死谁手，尚待观察。

如果许可费过高，并且中间件并未受到法律保护，那么云巨头们可能会选择另起炉灶，重新编写一个新版本。具体结果将取决于中间件的复杂性，因为重写并非易事。巨头们可能会在烧掉数百万投资后，才发现自身缺乏相应的才能和对问题的理解。复杂性将是云巨头的敌人。如果试水重写，它们可能会像一些古帝国那样分崩离析。

如果中间件受到法律的保护，或者这些中间件产品的构造非常复杂，那么云巨头可考虑并购方式。云巨头可在运营这些公司的同时，控制“使用收益”，并以更高的利润向每个单独用例出售。

对集成中间件的影响

核心中间件之上一层是集成中间件，例如ESB、工作流引擎和API管理工具等，它们组合和集成函数、服务和API。

读者可能会认为集成中间件并非无服务器。这就是为什么我们关注“无服务器支持的中间件”，而不是“无服务器”。在iPaaS和本地部署的集成中间件之间存在着竞争。

但是，这场战斗的胜负很可能是在其他地方决出的。集成中间件的性能取决于其获取所集成服务的延迟。如果大部分服务、API和功能都部署在云中，那么云中的集成中间件相比本地部署的同类产品具有明显的优势，反之同样成立。如果集成中间件和所集成的服务都部署在云中，那么它们之间的网络连接性能更高，因此延迟也会更低。并且，云巨头也可能做一些优化，将同一应用的相关部分部署于同一处。

在少数情况下，延迟无关紧要，这时将取决于iPaaS和本地部署中间件之间的功能差距。纵观历史，本地部署中间件一直在功能上处于领先。但是，随着iPaaS的成熟，他们也将面临艰苦的战斗。

对辅助服务中间件的影响

辅助服务包括安全性、可观测性、追踪和调试、运维、异常和欺诈检测、应用生命周期管理（例如CI/CD、版本管理以及金丝雀、红绿部署等负载均衡模式）等。

我认为辅助服务正是云巨头的强大之所在。巨头们控制着运行环境，进而通过投入资金，为开发人员提供缺省环境之外的更多优秀的辅助服务。这一过程正在进行中。虽然本地部署也能做到这一点，但是设置环境并使其正常运行需要耗费大量的时间、精力和技能，因此一般仅适合于大型组织中的开发人员。

云巨头并不会直接插手本地部署的辅助中间件。云巨头本身也会使用辅助中间件。但是，辅助中间件可能会发现自身的用户群越来越多地迁移到云中。它所导致的动态发展与我们在核心中间件一节中所阐释的类似。

无服务器平台也将对编辑器和工具提出挑战。编辑器和工具同样需要与无服务器紧密集成在一起，云巨头也鼓励编辑器和工具支持无服务器。但是不同于其他中间件，编辑器和工具本身很少受无服务器的挑战。例如，开发人员可以在笔记本电脑上构建应用，然后推送到无服务器云中，这并不会产生任何运行时延迟。看上去似乎云巨头也对插足编辑器不感兴趣。

私有无服务器平台

无服务器面对的最大风险，就是用户会顾虑在缺乏标准情况下产生“供应商锁定”的问题。人们真正关注的并非无服务器本身所提供的功能，而是这些功能所需的辅助服务以及安全性、可观测性等平台服务。这些服务是构建有意义应用所不可或缺的。如果缺乏诸如用于API调用的SQL这样的标准，则很难有效地抽象出这些服务。

标准化正受到当前无服务器市场主导者的抵制。尚不清楚云巨头更应该担心的是其它的云巨头，还是担心用户对供应商锁定的反感。如果云巨头间的合作将提供可移植的应用，那么就可以扩大整体的市场份额，进而使大家都从中受益。但达成这一愿景尚需时日。另一种可能性是由政府去实施标准化。尽管这一考虑目前的可能性不大，但在一个能推行GDPR的世界里，也并非是完全不可能的。任何形式的标准化，都将大大推进无服务器的采用。

Apache OpenWhisk等私有无服务器平台（PSP，Private Serverless Platforms）正致力于为此提供解决方案。他们提出，组织可以通过运行PSP，不依赖云巨头而获得无服务器的大部分好处。这正是IBM等中间件公司在应对无服务器对中间件的威胁时所采取的战略性解决方案。

但是，PSP需面对两个挑战：

首先，一旦没有了平台服务，PSP将失去其大部分生命力。PSP中必须加入数据库，否则由于无服务器的无状态本质，将造成交易的中断。缺失其他平台服务所造成的影响，尚待进一步观察。诚然，我也并未押注于PSP。

第二，只有在组织能够运行一定规模无服务器平台的情况下，PSP才能通过提供规模经济为组织节省成本。在云巨头的IaaS产品中运行PSP将会失败。即便PSP可以运作，云巨头也会相应地调高IaaS的价格。反过来看，探索多个小型组织是否可以将自身的资源安全地集成到同一个无服务器平台，应该是一种有意思的尝试。

微软将自己的大部分无服务器平台做了开源，并因此占据了一席之地。企业可以选择在本地运行同一工具。

尚未波及之处

机器学习算法本身已经形成了一些针对优化性能的专用硬件、GPU和系统。

看上去无服务器并未插足机器学习算法。对于算法交易、系统管理工具、AR和VR等对低延迟有需求的应用，同样如此。

无服务器也可反戈一击。例如通过使用机器学习或基于人工判断等优化技术，支持将相关应用物理部署在同一机器上，类似于Kubernetes对pod的操作。无服务器可以处理部分用例，但并不是全部适用。

无服务器也可以通过提供预封装版本的通用机器学习算法，在市场中分一杯羹。

即使无服务器无法进入这一细分市场，但从总体上看，这只是市场的很小一部分。无服务器难以进入的市场会越来越小，一切只是时间上的问题。

结论

中间件将继续存在，尚未失去一切。很多应用依然依赖于核心中间件，本地部署的中间件也难以通过无服务器等将服务托管迁移到云。服务托管一旦失守，多米诺骨牌开始倒下，其它所有都会失守。我认为的这一战场上，专利和商业机密相比开源软件要起到更大的作用，因为开源软件已在云巨头们的掌控中。

原文链接： Can Middleware survive the Serverless enabled Cloud