最后一套"客户端-服务器"系统将于何时关停?

译文
云计算
客户端-服务器的时代将在云计算的全面普及之下终结。在未来20年中,根据我的个人观察,除了特殊领域之外不会再有新的客户端-服务器系统与广大用户见面。

虽然老旧的计算模式往往历久而弥新,但客户端-服务器机制却不在此列——它就是种错误,且需要尽早被时代所淘汰。

这篇文章是我在参加本周于拉斯维加期召开的IBM Insight大会时写下的。还记得当初曾有人断言,全世界最后一台大型机会在1996年正式关停。但就在这个礼拜,我还亲眼看到IBM公司在一台大型机上运行Apace Spark——而且其性能依然强大到令人叹服。

是的,大型机上的Spark,这就是本周蓝色巨人给出的对话主题。IBM公司热爱大型机,因为他们喜欢在这一领域维持自身无可匹敌的硬件业务王者地位——截至目前,IBM的大型机业务仍然占全球总体份额的近50%。

而大型机业务同时也是目前惟一一类仍然会在启动屏幕上显示“©1980”字样的计算解决方案。客户端-服务器计算模式并不取决于特定硬件。相反,其只是一种单纯的计算实现思路,其中包含有多种多样的硬件以及网络元素。

我敢肯定,对于客户端-服务器以及与之针锋相对的所谓“纯分布式”计算模式在具体定义方面还有很大的探讨空间。因此请让我首先对客户端-服务器模式做出定义:这代表着单一或者多个客户端与某台持续监听插槽集合或者资源池的服务器相对接,其主要采取纵向扩展模式且通常配备有集中式数据存储体系。总而言之,这是一种LAN模式。

而对于分布式模式,我将其描述为N个客户端或者同类机制同N台服务器相对接,后者主要以横向方式进行规模扩展且采用共享及分布式处理的数据存储方式。这种模式的设计思路在于提高容错能力并承受资源需求峰值,同时允许大家根据实际需要添加更多节点(通常以线性方式增加)并重新规划基础设施位置。而这也正是云计算的核心实现模式。

这种分布式模式相较纯向上扩展模式更为强大,因为其能够轻松实现规模伸缩。这种能力之所以如此重要,是因为客户端-服务器模式的最大弊端之一就是将工作负载的可预测性作为构建前提。

然而这种前提从早年间就被证明是一种误区。遥想当年,我曾经负责过系统管理方面的工作,那时候EoM报告当中几乎就没什么真正有用的信息,惟一的作用就是不断闪灯然后提示我们距离本月周期末还有多少天。颇具讽刺意味的是,这也正是大型机TPC无法发挥就有作用的主要原因。还记得那时候我们都会把Slashdot设为自己的浏览器主页,而且站点由于峰值流量而引发的停机则会被称为Slashdot效应。现在的互联网与当初的状况简直一模一样。

不知道大家有没有尝试建立起一套大型的、基于甲骨文方案的现有测试数据库项目。要达成这一目标,我们需要能够在出现预料之外的互联网数据流量及使用规模峰值时进行向上扩展,但同时又需要在资源需求趋于平稳时进行规模收缩(主要为了节约AWS开销)并实现灵活的适配性(有时候我们甚至需要在笔记本电脑上测试自己的项目)。

总体而言,如今的工作负载已经呈现出愈发夸张的不可预测性,而且大多数情况下其规模非常可观。此外,我们对于网络服务表现的预期也开始上升。枯燥的响应等待已经无法被用户所接受,而谷歌时代下常见的服务中断如今被视为非常严重的事故。目前技术竞争已经愈演愈烈且扩散到全球范围,而监控要求也变得更加严格(至少在Trump当选总统之前是这样)。

我们的客户端-服务器系统根本无法以实时需求为依据进行规模伸缩。它们不具备弹性能力,而且在大多数情况下不能实现云体系的基本要求。与此同时,编写分布式系统本身也要更加简便易行。相较于甲骨文甚至是SQL Server,MongoDB实例的部署工作显然要轻松得多得多。Spark拥有极易上手的API。NodeJS能够帮助我们编写出事件驱动型弹性分布式系统;另外,这些方案的易用性都要比其前辈们好得多。

反对者们可能会指出,这些新兴技术目前的市场占用率还比较有限,不过必须承认其普及规模正在逐步扩大。有些人认为当相关开发人员退休之后,与之对应的技术就会彻底消亡。诚然,甲骨文那帮“老不死”的PL/SQL开发人员一个赛一个的长命,但他们终将退位——这是无法改变的现实。就目前而言,千禧一代技术人员们普遍认为MongoDB要比MySQL更易于使用及打理。

客户端-服务器的时代将在云计算的全面普及之下终结。在未来20年中,根据我的个人观察,除了特殊领域之外不会再有新的客户端-服务器系统与广大用户见面。而新一代解决方案则会以更为出色的表现取代那些老古董。这并不是说非要在部署方式层面有所突破,新方案只需更易用且成本更低廉,同时能够满足现代业务领域的期望及具体用例即可。

那么最后一套客户端-服务器系统是否会在未来20年内正式关停?答案恐怕是否定的——某些业界领域的发展速度并不会太快,竞争关系可能起到一定的保护作用,或者是需要满足某些新型监管要求抑或对应行业不需要编写或者购置太多新型软件方案。从这个角度讲,仍将有很多领域始终持续使用传统的客户端-服务器实现模式。

不过作为技术行业的从业人员,我们并不需要为以上情况太过分心——毕竟他们不是咱们的核心客户群体。相反,我希望他们像出租车行业被Uber屠杀那样倒在历史的车轮之下——抱歉,我这个人就是这么直率啦。

原文标题:Why client-server must die

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

 

责任编辑:Ophira 来源: 51CTO
相关推荐

2021-02-07 18:19:44

RabbitMQ客户端

2011-06-09 10:51:26

Qt 服务器 客户端

2009-08-18 12:51:19

服务器+客户端

2018-12-18 10:47:37

2018-07-17 09:59:10

PythonUDP服务器

2019-08-28 15:19:15

PythonTCP服务器

2009-12-25 10:47:17

DNS服务器

2009-09-16 16:09:41

NIS服务器客户端NIS

2018-12-19 10:31:32

客户端IP服务器

2014-01-17 15:23:55

Nagios

2010-08-27 10:18:24

DHCP服务

2010-10-26 13:54:45

连接Oracle服务器

2009-06-27 20:32:00

LinuxNFS客户端

2010-06-09 14:39:58

2024-02-22 13:47:40

2014-06-01 11:03:13

VDI零客户端

2011-08-02 14:11:19

服务器打印机

2023-10-23 12:31:40

2012-05-29 09:38:04

Linux客户端服务器

2009-09-16 15:44:25

点赞
收藏

51CTO技术栈公众号