服务端的发展史

服务端开发这个分工，出现的历史极短。短得让人难以想象。

1946 年，第一台电子计算机问世。1954 年，第一门高级语言 Fortran 发布。整个信息科技发展到今天，大约也就 60~70 年的历史。

1974 年，Internet 诞生。1989 年，万维网（WWW）诞生，但刚开始只限于政府和学术研究用途，1993 年才开始进入民用市场。

从这个角度来说，服务端开发这个分工，从互联网诞生算起也就 40 多年的历史。真正活跃的时段，其实只有 20 多年。

但其发展速度是非常惊人的。我们简单罗列下这些年来的标志性事件。

通过回顾服务端的发展历史，我们可以发现，它和桌面开发技术迭代的背后驱动力是完全不同的。

桌面开发技术的迭代，是交互的迭代，是人机交互的革命。而服务端开发技术的迭代，虽然一开始沿用了桌面操作系统的整套体系框架，但它正逐步和桌面操作系统分道而行，转向数据中心操作系统（DCOS）之路。

服务端程序的需求

这些演进趋势的根源是什么？

其一是规模。

桌面程序是为单个用户服务的，所以它关注点是用户交互体验的不断升级。

服务端程序是被所有用户所共享，为所有用户服务的。一台物理的机器资源总归是有限的，能够服务的用户数必然存在上限，所以一个服务端程序在用户规模到达一定程度后，需要分布式化，跑在多台机器上以服务用户。

其二是连续服务时长。

桌面程序是为单个用户服务的，用户在单个桌面程序的连续使用时长通常不会太长。

但是服务端程序不同，它通常都是 7x24 小时不间断服务的。当用户规模达到一定基数后，每一秒都会有用户在使用它，不存在关闭程序这样的概念。

其三是质量要求。

每个桌面程序的实例都是为单个用户服务的，有一亿的用户就有一亿个桌面程序的实例。

但是服务端程序不同，不可能有一亿个用户就跑一亿个，每个用户单独用一个，而是很多用户共享使用一个程序实例。

这意味着两者对程序运行崩溃的容忍度不同。

一个桌面程序实例运行崩溃，它只影响一个用户。

但一个服务端程序实例崩溃，可能影响几十万甚至几百万的用户。

这是不可接受的。

一个服务端程序的实例可以崩溃，但是它的工作必须立刻转交给其他的实例重新做，否则损失太大了。

所以服务端程序必须能够实现用户的自动转移。一个实例崩溃了，或者因为需要功能升级而重启了，它正在服务的用户需要转给其他实例来服务。

所以，服务端程序必须是多实例的。单个程序实例的临时不可用状态，要做到用户无感知。

从用户视角看，服务端程序 7x24 小时持续服务，任何时刻都不应该崩溃。就如同水电煤一样。

在 “01 | 架构设计的宏观视角” 这一讲中，我们将一个服务端程序完整的体系架构归纳如下：

这个架构体系，是为了方便你和桌面开发的体系架构建立自然的对应关系而画的。

它当然是对的，但它只是从服务端程序的单个实例看的，不是服务端程序体系架构的全部。

在 “15 | 可编程的互联网世界” 这一讲中，我们把 TCP/IP 层比作网络的操作系统，一个网络程序的体系架构如下：

一个服务端程序当然也是一个网络程序，它符合网络程序的体系架构。

但它也不是服务端程序体系架构的全部。

从宏观视角看，一个服务端程序应该首先是一个多实例的分布式程序。其宏观体系架构示意如下：

相比桌面程序而言，服务端程序依赖的基础软件不只是操作系统和编程语言，还多了两类：

为什么会需要负载均衡（Load Balance）？为什么会需要数据库或其他形式的存储？你可以留言探讨一下。我们在接下来的几讲将聊聊负载均衡和存储。

今天我们从服务端的发展历程、服务端开发的需求谈起，以此方便你理解服务端开发的生态会怎么演化，技术迭代会走向何方。

我们这里探讨的需求和具体业务无关，它属于服务端本身的领域特征。就像桌面的领域特征是强交互，以事件为输入，GDI 为输出一样，服务端的领域特征是大规模的用户请求，以及 24 小时不间断的服务。

这些领域特征直接导致了服务端开发的体系架构和桌面必然是如此的不同。

如果你对今天的内容有什么思考与解读，欢迎给我留言，我们一起讨论。下一讲我们将聊聊负载均衡（Load Balance）。

如果你觉得有所收获，也欢迎把文章分享给你的朋友。感谢你的收听，我们下期再见。