为什么2017年之后操作系统仍将扮演重要角色？

Ronny 2017年1月19日评论已关闭阅读 3,079 次

操作系统的历史虽然不像计算科学那么久远，但却也已经拥有相当可观的发展历程。大型机客户于上世纪五十年代末编写了第一批操作系统，这些系统直到数十年后的今天仍拥有相当的知名度——其中包括来自IBM公司的OS/360以及贝尔实验室打造的Unix。

在可预期的未来，操作系统仍将继续存在并保持活跃。

操作系统的历史虽然不像计算科学那么久远，但却也已经拥有相当可观的发展历程。大型机客户于上世纪五十年代末编写了第一批操作系统，这些系统直到数十年后的今天仍拥有相当的知名度——其中包括来自IBM公司的OS/360以及贝尔实验室打造的Unix。
为什么2017年之后操作系统仍将扮演重要角色？为什么2017年之后操作系统仍将扮演重要角色？
首先，操作系统立足于物理系统之上且与硬件直接交互。这使得众多应用软件能够充分享受到硬件提供的特性与功能。举例来说，这意味着开发商能够在硬件当中提供更多创新空间，因为操作系统能够完成对新型处理器及各类服务器设计方案的支持任务——而无需强迫开发者承担这部分工作。可以说，硬件创新将在机器学习及其它关键性软件发展趋势背景下焕发更为旺盛的生机，这意味着我们不再需要年复一年等待CMOS工艺提升带来有限的一点性能提升。随着混合云架构的广泛普及，由此抽象层带来的可移植能力亦将变得更为重要。

第二，操作系统本身——特别是操作系统内核——负责执行应用程序所必需的常规任务。其管理进程调度、电源管理、root访问权限、内存分配以及全部其它底层守护及运行类细节任务，从而保证系统整体能够高效安全地保持运作。

最后，操作系统还作为其自有“用户相关”程序——例如日志记录、性能配置等系统工具——以及用户所编写之应用程序的接口存在。操作系统应当通过各类基于开放标准的API(即应用程序编程接口)为应用提供一致性接口。另外，商业支持型操作系统亦会提供与其在业务及技术层面保持合作关系的第三方应用程序供应商的产品，同时作为内容通道为该平台提供更多受信内容。

过去几年以来，计算技术的发展前景已经发生了很大变化，这也同时改变了我们看待操作系统及其效果的方式——尽管其仍然扮演实在同样的核心角色。总体而言，我们需要考虑应用程序打包方式、计算基础设施快速发展以及未来威胁与漏洞等一系列实质性转变。

容器化

运行在Linux容器内的应用程序相当于立足于一套经过隔离并运行在物理服务器之上的单一操作系统副本内。这套方案不同于以往基于虚拟机管理程序的虚拟化实例。虚拟机方案意味着每款应用都绑定有一套完整的访客操作系统副本，并能够通过管理程序与硬件进行通信。简而言之，虚拟化管理程序负责对硬件资源进行虚拟化，而容器技术则负责对操作系统资源进行虚拟化。如此一来，容器技术需要占用的内存等系统资源量更低，且应用程序的运行基本不会带来额外性能损耗。

容器化技术在很大程度上依赖于大家熟知的操作系统概念。容器构建于Linux内核的进程模式之上，同时配合其它操作系统功能，例如命名空间(例如进程、网络、用户)、cgroups以及权限模式，旨在实现容器隔离的同时实现完整的系统功能。

容器技术的优势在于，其能够将整体应用程序拆分成一组可移植层结构，从而以极低成本实现在不同环境间的迁移。在这方面，容器其实只是个笼统的概念，其拥有多种不同的实现形式——且目前尚未成为主流。(至少还远未达到虚拟化应用的普及程度。)对于容器技术而言，当前最为重要的变化在于开源及开放标准开始发挥核心作用。以开放容器倡议为例，该合作项目由Linux基金会负责管理，旨在围绕容器的格式及运行时等建立开放性行业标准。

另外值得关注的是，容器技术与软件定义基础设施(例如OpenStack)相结合后，已经被纳入Linux范畴之内。通过计算机软件的发展历史，可以清晰地看到将技术方案集成至操作系统之内代表着相关技术将得到广泛采纳，并迎来更为广阔的发展空间及更加强大的生态系统支持——TCP/IP之于网络或者其它任何被广泛采用的安全相关特性都能够证明这一点。

规模化

另一大明显转变在于，我们越来越多地将计算资源表现形式归于大规模数据中心，而非个别服务器。这种转变早在Web诞生之初就已经出现，但必须承认，如今我们正在更为积极地利用高性能计算“网格”技术处理传统批量工作负载以及新型面向服务类负载。

与容器以及基于松散耦合型“微服务”(各服务运行于容器内)应用进行衔接——无论是否配合持久性存储——已经成为一类高人气云原生方案。尽管与面向服务架构(简称SOA)概念存在交集，但这类方案已经显示出强大的可行性，且开拓出不同于以往整体式应用开发理念的全新思路。通过细粒度、松散耦合架构实现的微服务应用允许我们在应用架构内反映经过确切定义的单一应用功能。微服务架构的快速更新、可扩展性以及容错性等优势正使得此类组合式应用全面压制传统整体型应用，毕竟我们很难在不影响其它组件的前提下，对后者的单一组件进行变更。

而这种转变从操作系统的角度来看，意味着应用能够更多将单一“计算机”作为一组聚合型数据中心资源集来看待。当然，其中仍然存在着大量底层独立服务器; 且虽已具备一定程度的自动化及自行运作能力，其仍需要运营及维护。不过，容器调度与管理的效率优势已经催生出新的抽象机制，即为工作负载的运行以及多层应用程序的组合带来全新实现层——而不再单纯依靠服务器。

隶属于Linux基金会的云原生计算基金会(简称CNCF)旨在“推动新型计算规范的采用，其面向包含成千上万拥有自我修复能力的多租户节点的现代分布式系统环境。”CNCF之下的杰出项目之一正是Kubernetes，这款开源容器集群管理工具最初由谷歌公司设计，但目前已经获得来自红帽等其它多家厂商的支持与贡献。

安全性

一切适用于虚拟化环境的安全强化机制、性能调整机制、可靠性技术手段以及认证，亦同样适用于容器化技术。事实上，操作系统在隔离化容器及软件定义基础设施领域承担的安全性与资源交付责任要远高于原有专用硬件或软件执行环境。Linux已经在利用开源模式构建综合性安全执行功能工具包当中成为受益者，其中包括通过SELinux实现强制性访问控制、广泛的用户空间与内核强化功能、身份管理与访问控制乃至加密等等。

不过就目前来看，信息安全态势仍然处于不断变化当中。无论是允许客户及合作伙伴访问特定系统与数据、允许员工使用自有智能手机与笔记本设备、使用来自软件即服务(简称SaaS)供应商提供的应用程序还是发挥公有云供应商的按需付费计价优势，我们都无法通过单一方案解决全部实际需求。

开放性开发模式允许整个行业认可同一套标准，并鼓励最为睿智的开发者不断对这些技术方案进行测试及改进。大型企业及其下辖部门能够及时向Linux及其它开源软件供应方提供安全性反馈，这也有力证明了社区合作在未来技术发展道路上解决问题的实际能力。另外，开源开发流程意味着一旦安全漏洞被曝光，整个开发者社区及供应商都能够协同提供代码更新、安全指导以及说明文档。

除了操作系统之外，同样的流程及实践方式亦被混合云基础设施所采用，旨在对现有方案进行升级并纳入更多新型功能。另外，当组件以微服务及其它松散耦合架构形式进行复用时，维护这些组件自身质量及其依赖性(当用于构建应用程序时)的重要意义将进一步提高。

有变化，亦有不变

目前操作系统开发及运营相关事务的具体优先级显然发生了转变。目前我们的关注重点在于如何以规模化方式进行自动化部署，而不再是对单一服务器进行定制、调整及优化。与此同时，威胁因素的发展速度及程度亦令安全边界变得更加模糊——这意味着我们需要立足系统层面了解网络以及快速加以应对的具体办法。

总结来讲，应用程序正变得更具适应性、更具移动性、更具分布性、更具稳定性且更具轻量性。其安置、配置以及保护方式必须配合更高水平的自动化方案。在此期间，有些作法应当保持，而有些作法则应当变更。这意味着我们必须找到一种能够随新要求演变并适应新型工作负载的解决方案?而答案，无疑正是操作系统——或者说，Linux操作系统。