我总是使用 Eshell 来与操作系统进行交互，因为它与 Emacs 无缝整合、支持处理 (远程) TRAMP 文件，而且在 Windows 上也能工作得很好。

启动 shell 命令后 (比如耗时严重的构建任务) 我经常会由于切换缓冲区而忘了追踪任务的运行状态。

多亏了 Emacs 的 钩子 机制，你可以配置 Emacs 在某个外部命令完成后调用一个 elisp 函数。

我使用 John Wiegleys 所编写的超棒的 alert 包来发送桌面通知：

(require 'alert)

(defun eshell-command-alert (process status)
  "Send `alert' with severity based on STATUS when PROCESS finished."
  (let* ((cmd (process-command process))
       (buffer (process-buffer process))
       (msg (format "%s: %s" (mapconcat 'identity cmd " ")  status)))
    (if (string-prefix-p "finished" status)
      (alert msg :buffer buffer :severity  'normal)
    (alert msg :buffer buffer :severity 'urgent))))

(add-hook 'eshell-kill-hook #'eshell-command-alert)

alert 的规则可以用程序来设置。就我这个情况来看，我只需要当对应的缓冲区不可见时得到通知：

(alert-add-rule :status   '(buried)     ;only send alert when buffer not visible
          :mode     'eshell-mode
          :style 'notifications)

这甚至对于 TRAMP 也一样生效。下面这个截屏展示了失败的 make 命令产生的 Gnome 桌面通知。

via: https://blog.hoetzel.info/post/eshell-notifications/

作者：Jürgen Hötzel 选题：lujun9972 译者：lujun9972 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

6 月 15 日，你可以在当地的游戏商家庆祝桌面角色扮演游戏并获得免费的 RPG 资料。

（LCTT 译注：“ 免费 RPG 日 Free RPG Day ”是受“ 免费漫画书日 Free Comic Book Day ”启发而发起的庆祝活动，从 2007 年开始已经举办多次。这里的 RPG 游戏并非我们通常所指的电脑 RPG 游戏，而是指使用纸和笔的桌面游戏，是一种西方传统游戏形式。）

你有没有想过尝试一下《 龙与地下城 Dungeons & Dragons 》，但不知道如何开始？你是否在年轻时玩过《 开拓者 Pathfinder 》并一直在考虑重返快乐时光？你是否对角色扮演游戏（RPG）感到好奇，但不确定你是否想玩一个？你是否对桌面游戏的概念完全陌生，直到现在才听说过这种 RPG 游戏？无论是哪一个并不重要，因为免费 RPG 日适合所有人！

第一个免费 RPG 日活动发生在 2007 年，是由世界各地的桌面游戏商家举办的。这个想法是以 0 美元的价格为新手和有经验的游戏玩家带来新的、独家的 RPG 快速入门规则和冒险体验。在这样的一天里，你可以走进当地的桌面游戏商家，得到一本小册子，其中包含桌面 RPG 的简单的初学者规则，你可以在商家里与那里的人或者回家与朋友一起玩。这本小册子是给你的，应该一直留着的。

这一活动如此的受欢迎，此后该传统一直延续至今。今年，免费 RPG 日定于 6 月 15 日星期六举行。

有什么收获？

显然，免费 RPG 日背后的想法是让你沉迷于桌面 RPG 游戏。但在你本能的犬儒主义开始之前，考虑到它会慢慢上瘾，爱上一个鼓励你阅读规则和知识的游戏并不太糟，这样你和你的家人、朋友就有了共度时光的借口了。桌面 RPG 是一个功能强大、富有想象力和有趣的媒介，而免费 RPG 日则是对这种游戏很好的介绍。

开源游戏

像许多其他行业一样，开源现象影响了桌面游戏。回到世纪之交，《Magic：The Gathering and Dungeons＆Dragons》 的提供者 威世智公司 Wizards of the Coast 决定通过开发 开源游戏许可证 Open Game License （OGL）来采用开源方法。他们将此许可证用于世界上第一个 RPG（《 龙与地下城 Dungeons & Dragons 》，D&D）的版本 3 和 3.5。几年后，当他们在第四版上（对开源）产生了动摇时，《 龙 Dragon 》杂志的出版商复刻了 D＆D 3.5 的“代码”，将其混制版本发布为《 开拓者 Pathfinder 》 RPG，从而保持了创新和整个第三方游戏开发者产业的健康发展。最近，威世智公司在 D&D 5e 版本中才又重回了 OGL。

OGL 允许开发人员至少可以在他们自己产品中使用该游戏的机制。不管你可以不可以使用自定义怪物、武器、王国或流行角色的名称，但你可以随时使用 OGL 游戏的规则和数学计算。事实上，OGL 游戏的规则通常作为系统参考文档（SRD）免费发布的，因此，无论你是否购买了规则书的副本，你都可以了解游戏的玩法。

如果你之前从未玩过桌面 RPG，那么使用笔和纸玩的游戏也可以拥有游戏引擎似乎很奇怪，但计算就是计算，不管是数字的还是模拟的。作为一个简单的例子：假设游戏引擎规定玩家角色有一个代表其力量的数字。当那个玩家角色与一个有其两倍力量的巨人战斗时，在玩家掷骰子以增加她的角色的力量攻击时，真的会感到紧张。如果没有掷出一个很好的点数的话，她的力量将无法与巨人相匹敌。知道了这一点，第三方或独立开发者就可以为这个游戏引擎设计一个怪物，同时了解骰子滚动可能对玩家的能力得分产生的影响。这意味着他们可以根据游戏引擎的优先级进行数学计算。他们可以设计一系列用来杀死的怪物，在游戏引擎的环境中它们具有有意义的能力和技能，并且他们可以宣称与该引擎的兼容性。

此外，OGL 允许出版商为其材料定义产品标识。产品标识可以是出版物的商业外观（图形元素和布局）、徽标、术语、传说、专有名称等。未经出版商同意，任何定义为产品标识的内容都可能无法重复使用。例如，假设一个出版商发行了一本武器手册，其中包括一个名为 Sigint 的魔法砍刀，它对所有针对僵尸的攻击都给予 +2 魔法附加攻击值。这个特性来自一个故事，该砍刀是一个具有潜伏的僵尸基因的科学家锻造的。但是，该出版物在 OGL 第 1e 节中列出的所有武器的正确名称都被保留为产品标识。这意味着你可以在自己的出版物中使用该数字（武器的持久性、它所造成的伤害，+2 魔法奖励等等）以及与该武器相关的传说（它由一个潜伏的僵尸锻造），但是你不能使用该武器的名称（Sigint）。

OGL 是一个非常灵活的许可证，因此开发人员必须仔细阅读其第 1e 节。 一些出版商只保留出版物本身的布局，而其他出版商保留除数字和最通用术语之外的所有内容。

当卓越的 RPG 特许经营权拥抱开源时，至今仍能感受到的它给整个行业掀起的波澜。第三方开发人员可以为 5e 和《开拓者》系统创建内容。由威世智公司创建的整个 DungeonMastersGuild.com 网站为 D＆D 5e 制作了独立内容，旨在促进独立出版。Starfinder、OpenD6、战士，盗贼和法师、剑与巫师 等及很多其它游戏都采用了 OGL。其他系统，如 Brent Newhall 的 《Dungeon Delvers》、《Fate》、《Dungeon World》 等等，都是根据知识共享许可授权的的。

获取你的 RPG

在免费 RPG 日，你可以前往当地游戏商铺，玩 RPG 以及获取与朋友将来一起玩的 RPG 游戏材料。就像 Linux 安装节 Linux installfest 或 软件自由日 Software Freedom Day 一样，该活动的定义很松散。每个商家举办的自由 RPG 日都有所不同，每个商家都可以玩他们选择的任何游戏。但是，游戏发行商捐赠的免费内容每年都是相同的。显然，免费的东西视情况而定，但是当你参加免费 RPG 日活动时，请注意有多少游戏采用了开源许可证（如果是 OGL 游戏，OGL 会打印在书背面）。《开拓者》、《Starfinder》 和 D＆D 的任何内容肯定都会带有 OGL 的一些优势。许多其他系统的内容使用知识共享许可。有些则像 90 年代复活的 Dead Earth RPG 一样，使用 GNU 自由文档许可证。

有大量的游戏资源是通过开源许可证开发的。你可能需要也可能不需要关心游戏的许可证；毕竟，许可证与你是否可以与朋友一起玩无关。但是如果你喜欢支持自由文化而不仅仅是你运行的软件，那么试试一些 OGL 或知识共享游戏吧。如果你不熟悉游戏，请在免费 RPG 日在当地游戏商家试玩桌面 RPG 游戏！

via: https://opensource.com/article/19/5/free-rpg-day

作者：Seth Kenlon 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

如果你是设计师、开发者或艺术家，你可能一直在使用 Linux 上的实验性 Unity 编辑器。然而，不能一直用实验性版本 —— 开发者需要一个完整稳定的工作经验。

因此，他们最近宣布你可以在 Linux 上使用完整功能的 Unity 编辑器了。

虽然这是一个令人兴奋的消息，但它正式支持哪些 Linux 发行版？我们来谈谈更多细节……

非 FOSS 警告

Linux （或任何其他平台）上的 Unity 编辑器不是开源软件。我们在这里介绍它是因为：

官方支持 Ubuntu 和 CentOS 7

无论你拥有个人许可还是专业许可，如果你安装了 Unity 2019.1 或更高版本，都可以使用该编辑器。

此外，他们优先支持 Ubuntu 16.04、Ubuntu 18.04 和 CentOS 7。

在公告中，他们还提到了支持的配置：

• x86-64 架构
• 运行在 X11 窗口系统之上的 Gnome 桌面环境
• Nvidia 官方专有显卡驱动和 AMD Mesa 显卡驱动
• 桌面计算机，在没有仿真或兼容层的设备/硬件上运行

你可以尝试其他的 —— 但最好坚持官方要求以获得最佳体验。

关于第三方工具的说明

如果你碰巧在某个项目中使用了任何第三方工具，那么必须单独检查它们是否支持。

如何在 Linux 上安装 Unity 编辑器

现在你已经了解了，那么该如何安装？

要安装 Unity，你需要下载并安装 Unity Hub。

你需要完成以下步骤：

• 从官方论坛页面下载适用于 Linux 的 Unity Hub。
• 它将下载一个 AppImage 文件。简单地说，让它可执行并运行它。如果你不了解，你应该查看关于如何在 Linux 上使用 AppImage 的指南。
• 启动 Unity Hub 后，它会要求你使用 Unity ID 登录（或注册）以激活许可证。有关许可证生效的更多信息，请参阅他们的 FAQ 页面。
• 使用 Unity ID 登录后，进入 “Installs” 选项（如上图所示）并添加所需的版本/组件。

就是这些了。这就是获取并快速安装的最佳方法。

总结

即使这是一个令人兴奋的消息，但官方配置支持似乎并不广泛。如果你在 Linux 上使用它，请在他们的 Linux 论坛帖子上分享你的反馈和意见。

你觉得怎么样？此外，你是使用 Unity Hub 安装它，还是有更好的方法来安装？

请在下面的评论中告诉我们你的想法。

via: https://itsfoss.com/unity-editor-linux/

作者：Ankush Das 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Kubernetes 解决了一些开发和运维团队每天关注的的常见问题。

Kubernetes（K8S）是面向企业的开源容器编排工具的事实标准。它提供了应用部署、扩展、容器管理和其他功能，使企业能够通过容错能力快速优化硬件资源利用率并延长生产环境运行时间。该项目最初由谷歌开发，并将该项目捐赠给云原生计算基金会（CNCF）。2018 年，它成为第一个从 CNCF 毕业的项目。

这一切都很好，但它并不能解释为什么开发者和运维人员应该在 Kubernetes 上投入宝贵的时间和精力。Kubernetes 之所以如此有用，是因为它有助于开发者和运维人员迅速解决他们每天都在努力解决的问题。

以下是 Kubernetes 帮助开发者和运维人员解决他们最常见问题的五种能力。

1、厂商无关

许多公有云提供商不仅提供托管 Kubernetes 服务，还提供许多基于这些服务构建的云产品，来用于本地应用容器编排。由于与供应商无关，使运营商能够轻松、安全地设计、构建和管理多云和混合云平台，而不会有供应商锁定的风险。Kubernetes 还消除了运维团队对复杂的多云/混合云战略的担忧。

2、服务发现

为了开发微服务应用，Java 开发人员必须控制服务可用性（就应用是否可以提供服务而言），并确保服务持续存在，以响应客户端的请求，而没有任何例外。Kubernetes 的服务发现功能意味着开发人员不再需要自己管理这些东西。

3、触发

你的 DevOps 会如何在上千台虚拟机上部署多语言、云原生应用？理想情况下，开发和运维会在 bug 修复、功能增强、新功能、安全更新时触发部署。Kubernetes 的部署功能会自动化这个日常工作。更重要的时，它支持高级部署策略，例如蓝绿部署和金丝雀部署。

4、可伸缩性

自动扩展是处理云环境中大量工作负载所需的关键功能。通过构建容器平台，你可以为终端用户提高系统可靠性。Kubernetes Horizo​​ntal Pod Autoscaler（HPA）允许一个集群增加或减少应用程序（或 Pod）的数量，以应对峰值流量或性能峰值，从而减少对意外系统中断的担忧。

5、容错性

在现代应用体系结构中，应考虑故障处理代码来控制意外错误并快速从中恢复。但是开发人员需要花费大量的时间和精力来模拟偶然的错误。Kubernetes 的 ReplicaSet 通过确保指定数量的 Pod 持续保持活动来帮助开发人员解决此问题。

结论

Kubernetes 使企业能够轻松、快速、安全地解决常见的开发和运维问题。它还提供其他好处，例如构建无缝的多云/混合云战略，节省基础架构成本以及加快产品上市时间。

via: https://opensource.com/article/19/6/reasons-kubernetes

作者：Daniel Oh 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

继微软发布了 WSL 2 （Windows Subsystem for Linux 2）之后，前两天正式提供了 WSL2 更新，处于 Insider Fast 通道中的用户可以通过安装 Windows build 18917 更新来体验最新版本的 WSL2。

在这篇文章中，我们将介绍如何入门、新的 wsl.exe 命令以及一些重要提示。有关 WSL 2 的完整文档可在微软的文档页面上找到。

安装 WSL 2

要安装并开始使用 WSL 2，请完成以下步骤：

• 启用“ 虚拟机平台 （ Virtual Machine Platform ） ”可选组件
• 使用命令行设置要由 WSL 2 支持的发行版
• 验证你的发行版使用的 WSL 版本

请注意，你需要运行 Windows 10 build 18917 或更高版本才能使用 WSL 2，并且你需要安装 WSL（可以在此处找到相关说明）。

启用“虚拟机平台”可选组件

以管理员身份打开 PowerShell 并运行：

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

启用这些更改后，你需要重新启动计算机。

使用命令行设置要由 WSL 2 支持的发行版

在 PowerShell 中运行：

wsl --set-version <Distro> 2

并确保将 <Distro> 替换为发行版的实际名称。 （你可以使用以下命令找到它们：wsl -l）。 你也可以通过运行与上面相同的命令随时更改回 WSL 1，但将“2”替换为“1”。

此外，如果你想使 WSL 2 成为默认架构，可以使用以下命令执行此操作：

wsl --set-default-version 2

这将使你安装的任何新发行版初始化为 WSL 2 发行版。

完成验证发行版使用的 WSL 版本

要验证每个发行版使用的 WSL 版本，请使用以下命令：

wsl --list --verbose
或
wsl -l -v

你在上面选择的发行版现在应该在“version”列下显示“2”。 现在完成了，你随时可以开始使用你的 WSL 2 发行版了！

WSL 2 的体验变化

首次开始使用 WSL 时，你会注意到一些用户体验变化。以下是此预览中两个最重要的变化。

将 Linux 文件放在 Linux 根文件系统中

确保将 Linux 应用程序中经常访问的文件放在 Linux 根文件系统中，以享受文件性能优势。过去微软一直强调在使用 WSL 1 时将文件放入 C 盘，但 WSL 2 中的情况并非如此。要享受 WSL 2 中更快的文件系统访问权限，这些文件必须放在 Linux 根文件系统里面。而且现在 Windows 应用程序可以访问 Linux 根文件系统（如文件资源管理器！尝试在 Linux 发行版的主目录中运行：explorer.exe . 看看会发生什么），这将使这种转换变得更加容易。

在初始构建中使用动态 IP 地址访问 Linux 网络应用程序

WSL 2 做了架构的巨大变更，使用了虚拟化技术，并仍在努力改进网络支持。由于 WSL 2 现在运行在虚拟机中，因此你从 Windows 访问 Linux 网络应用程序需要使用该 VM 的 IP 地址，反之亦然，你需要 Windows 主机的 IP 地址才能从 Linux 中访问 Windows 网络应用程序。 WSL 2 的目标是尽可能使用 localhost 访问网络应用程序！可以在文档中找到有关如何执行此操作的完整详细信息和步骤。

要了解有关用户体验更改的更多信息，请参阅文档：WSL 1 和 WSL 2 之间的用户体验变化。

新的 WSL 命令

WSL 添加了一些新命令选项来帮助控制和查看 WSL 版本和发行版。

除了上面提到的 --set-version 和 --set-default-version 之外，还有：

• wsl --shutdown

立即终止所有正在运行的发行版和 WSL 2 轻量级实用程序虚拟机。

一般来说，支持 WSL 2 发行版的虚拟机是由 WSL 来管理的，因此会在需要时将其打开并在不需要时将其关闭。但也可能存在你希望手动关闭它的情况，此命令允许你通过终止所有发行版并关闭 WSL 2 虚拟机来执行此操作。

• wsl --list --quiet

仅列出发行版名称。此命令对于脚本编写很有用，因为它只会输出你已安装的发行版的名称，而不显示其他信息，如默认发行版、版本等。

• wsl --list --verbose

显示有关所有发行版的详细信息。此命令列出每个发行版的名称，发行版所处的状态以及正在运行的版本。默认发行版标以星号。

反馈意见

如果你遇到任何问题， 请在 Github 上提交问题： https://github.com/microsoft/wsl/issues ，如果你对 WSL 有一般性问题，你可以在这个推特列表上找到该团队所有成员的 Twitter。

前段时间，笔者参加了 UCloud 在京举办的 TIC 2019 大会，适逢 UCloud 实验室负责人叶理灯的演讲结束，就容器计算方面和他进行了短暂沟通。叶理灯是国内在云计算方面有深入研究和实践的资深专家，我觉得他的一些观点和看法值得分享给大家了解。

叶理灯，UCloud实验室负责人

叶理灯，UCloud 实验室负责人。现负责 UCloud 创新产品研发，专注面向企业的云计算产品的研发及运营。叶理灯拥有 10 年以上丰富的互联网研发经验，先后任职于腾讯、盛大云等互联网公司，从事海量分布式后台系统研发及运营工作。

定制违背了 K8S 初衷，提供原生 K8S 产品

记者：在官方的 K8S 发行版之上，各方云厂商提供 K8S 服务时都有一些自己的定制和调整，今天大会上提及的 UCloud 的 K8S 发行版 UK8S 主要做了哪些定制，有什么特色呢？

叶理灯：如果说定制 K8S 的话，其实是违背了 K8S 的初衷。我们并没有定制 K8S，我们是基于公有云给用户提供了原生的 K8S 产品。在公有云上提供原生的 K8S，其实要做很多的工作，例如与公有云的计算、网络和存储的整合，给用户提供一个开箱即用的原生K8S集群等等。

我为什么说不应该定制呢？因为大家知道 PaaS 发展到今天，一直存在的一个问题就是供应商绑定的问题。而 K8S 之所以那么有生命力，之所以迅速流行，是因为它提供了一个开源的标准，让用户使用 K8S PaaS 平台，可以避免厂商绑定。也就是说你的服务在某个服务商的 K8S 上运行，可以无缝的迁移到另外一个服务商。

作为云厂商其实最重要的工作是，基于我们自身云平台的体系，提供原生的 K8S 给用户使用，帮助他们减少在集群管理和资源整合方面的工作和投入。例如，我们网络能力、存储能力和计算能力的整合，就是让用户享受到原生K8S的好处，同时避免了很多运维的负担。

公有云的 K8S 处在底层 IaaS 和上层应用之间，一方面向下整合IaaS能力，一方面向上托管客户的应用。在整合 IaaS 方面，不改变 K8S原生特性，因为 K8S 本身架构足够开放，例如在我们实现的网络插件，是基于我们 IaaS 的 VPC 网络，让 pod 可以和我们托管区和物理云区域打通，这是我们 IaaS 能力在 K8S 产品上的体现，算是我们的特色之一，但这是在 K8S 体系支持下的插件方式实现的，不影响我们提供原生 K8S；在应用层面，厂商也可以基于 K8S 提供一些周边的功能以帮助用户提高效率，但它和提供一个一致的 K8S 环境不矛盾。

另外一方面，如果说定制的概念是指基于 K8S 本身开发体系所提供的插件机制去做二次开发，那每家厂商都要定制，因为 K8S 本身不是一个产品级就绪的环境，需要使用者去适配网络和存储还有计算，因为每个公有云厂商基于自己的 IaaS 去提供 K8S 产品，必然要去开发插件。

综上，向用户应该提供原生的、标准的 K8S 产品，但底层应该基于自身 IaaS 平台去定制，本质还是为了提高用户使用 K8S 的效率，让用户开箱即用。

K8S 落地挑战：改造成本和人才问题

记者：你觉得目前国内云厂商提供的 K8S 集群编排服务在推广方面目前欠缺的是什么？是什么阻碍了客户进一步去使用这些容器集群服务？

叶理灯：K8S 以容器技术为核心、以容器镜像为打包标准的特点，意味着如果要迁移到这个体系下，客户需要将软件做容器化打包和微服务改造，这个是有成本的。K8S 的特点决定它是运维和研发之间的桥梁，这样就要求公司的研发过程需要跟着改造。我们看到很多公司的运维人员有动力去推动，而研发人员则没有动力，因为它改变了研发的习惯和流程，增加了负担；当然也有的公司是研发希望用 K8S 管理应用，而需要运维跟着变。这样导致迁移到 K8S 的工作较重，但一旦这个阶段过去了，迁移后的效率和成本优势就体现出来了。

因此，这是个新技术落地的问题，涉及到用户教育和习惯的改变，这个需要社区和商业公司一起完成。而且每家公司的技术路线和文化不一样，上 K8S 的路径也不一样，所以没有一个放之四海皆准的最佳实践，但随着容器和微服务逐渐落地，K8S 作为事实标准，会逐步普及。

除了改造业务的成本，另外一方面是 K8S 人才比较缺乏，不同用户的情况不一样，有些用户的运维人员本来就很少，不可能专门抽出一两个人去做 K8S，以及用户又担心它出问题谁来帮我解决？其实，应该是云厂商再往前走一步，除了帮用户构建一个 K8S 平台，还要帮助解决很多技术上的问题。 UCloud 现在就是这么做的，一个用户进来，我们会拉一个群，他们所有技术问题我们帮他们解决。在落地方面，在人才和 K8S 本身对用户架构改造方面，我们可以多做点工作，帮助客户培养K8S的运维人员和为用户制定架构迁移的方案。但我相信随着技术的发展和普及，越来越多人懂 K8S。

最后，K8S 本身也在发展，K8S 刚推出的时候是为了让大家重新面向应用来运维，但是大部分用户用 K8S 同时管理集群里的节点和应用，就会同时有两个负担。我觉得目标应该是用户直接拿一个容器就可以跑起来，而不用知道它的节点在哪里，即 Serverless 形态。一旦这种技术更加成熟，对容器技术的落地也有很大的推动作用。另一方面，Serverless 形态也给用户节省了大量的成本，按需付费，免去用户的运维成本。我觉得 K8S 的落地已经是个趋势了，是不可避免的，但是 K8S 本身是要往前进步，它的革命还没有完成。

容器与 Serverless：覆盖场景不同，非替换关系

记者：你觉得现在目前 Serverless 的发展对于容器这种创新技术的迭代升级有什么影响？是不是可以让容器更加的轻量化？

叶理灯：不完全是这样，其实 Serverless 刚出现的时候是针对计算的。计算分很多层次，有物理机、虚拟机、容器和 Serverless。Serverless 刚出来的时候，它等同于 FaaS，有一个对标的产品叫 Lambda。

Serverless 出现的动力是，由于云计算的发展，带来了如对象存储等很多丰富的中间件，Serverless 概念的提出是希望应用开发者可以不用写后端逻辑，直接把逻辑写在客户端，组合云上的一些服务来完成业务逻辑，这样就没有管理后端资源的负担了。但是后来发现很多时候还是需要后端代码的，所以就演变成如果有后端代码，就拆成函数，托管在 FaaS 服务中，这样的话，你依然是不用管理服务器的，你用的还是一个个服务，没有服务器管理负担。

这个概念在不断进步，2017 年的时候 AWS 提出了一个新的概念，重新定义了什么叫 Serverless，只要一个服务具备了四方面特性：免运维、按需付费、高可用和自动扩容，这个服务就是个 Serverless 的服务。所以 Serverless 这个概念可以对应 FaaS，也可以代表一种架构，也可以代表一种服务的形态，例如 Aurora Serverless 就是把一个数据库的服务变成 Serverless 的。

容器和 Serverless 的区别在于，Serverless 是无容器的，除了不关注服务器，也看不到容器。两者是面向不同场景的，并不是互相替代的关系。FaaS 的特点，接收一个请求拉起一个函数执行，函数是无状态的，它的执行地点也不固定，这意味着延时相对于常驻进程要高，对一些延时敏感的地方它是不合适的，但是有些场景是非常合适的。我举个例子，在 IoT 场景中，有几十万的设备，为了节省电源，它们大部分时候处于睡眠状态，如果用传统的架构去为这几十万设备服务的话，肯定要考虑并发连接的时候，应该有多少计算资源去服务，这很浪费成本。所以最好的方式，来一个请求就拉一个函数服务一下，这就很节省成本。

这是按需的，但它不是完整的替换，相当于说 IT 领域里面不同的场景其实是使用不同的服务。我们推出这个服务的原因，背后的动力还是成本和效率，在某个场景上用某个解决方案它的成本更低、效率更高，而不是说新的东西会替换老的，因为不同场景需求是不一样的。K8S 接受的用户比 FaaS 的用户更多，因为 K8S 的面更广，它覆盖的场景更多，但是它不是替换的。

记者：目前，国内客户对 Serverless 和 PaaS 的接受和普及程度是怎么样的？

叶理灯：我觉得在国内还是处于起步和用户教育阶段。2014 年 Lambda 推出的时候，它的渗透率是 72%，什么原因呢？有 72% 的人用的 Lambda，我们有个 Serverless 产品叫 UGC，腾讯有 FaaS，阿里也有 PaaS，目前都不算是渗透率很高。

原因有几个。第一、国内用户对新技术接受程度是比较低的，可能是习惯问题，国内的IT的发展水平跟国外也有差距，有 5、6 年差距；其次，对国内用户来说，把一个架构改成 Serverless 架构，其实成本是很高，而且改造的收益和规模相关；最后， FaaS 本身不是一个独立能起作用的产品，你会看到 Lambda 推出时，不是个独立的产品，它是体系的副产品，例如其他产品要开放事件源，通过事件去触发 Lambda 函数执行。只有产品体系开放足够多的事件源，FaaS 才能渗透到整个平台里面去，才能覆盖更多场景。

我们国内的厂商还没有做到这一点。AWS 刚推出 FaaS 时，它主要是 S3 上的图片处理，不是每个用户都有这个场景，因此渗透率不高。随着 API 网关方式调用，和体系开放事件源越来越丰富，覆盖场景越来越多，我相信 FaaS 会逐步落地。

在现场的演讲中，提及了一个叫 USQL 的产品，就是 Serverless 方式的大数据分析工具，StepFlow 用 Serverless 的方式编排你的程序，这些都是 Serverless 的服务。

未来，虚拟化容器值得关注

记者：目前 UK8S 的主要发展方向有什么路线图吗？UK8S 是否已经开源？

叶理灯：有的，例如说我们让 K8S 管理更多的资源、异构的资源，还有物理机、GPU 资源，希望用户可以通过 K8S 对这些资源进行统一地管理。另外，再往业务层面走会提供一些微服务的基础设施，通过产品化，一方面减轻用户的资源负担，另一方面减轻应用层的架构负担，从而尽量减轻用户迁移到 K8S 的负担。

目前 UK8S 插件还属于正在整理开源的阶段，还没有正式的发布，但我们已经小范围的开放了代码，把我们的插件代码分发给到很多用户，但公开的开源，我们希望做的更加规范一点再进行，因为我们的插件还在不断的迭代中，有一天我们觉得达到一定程度的稳定了，我们就会进行公开开源。

记者：你认为未来 K8S 以及容器的技术方向上比较值得重点关注的技术点是什么？

叶理灯：虚拟化容器。未来的方向我们相信是 Serverless，这个也是云计算应该做的，持续地为了用户提高效率和降低成本。刚才我也说了，现在用户使用 K8S 还是有资源管理的负担的，不是完全的面向应用来运维，所以需要解决这个问题，让计算节点对用户透明。用户通过 Docker 镜像和配置文件就可以把一个应用跑起来，而不用去管资源问题。这需要我们去提供一个海量的集群去跑客户的应用，这就存在一个问题，多个客户的应用可能跑在一个节点上，考虑 Docker 本身的隔离问题，我们需要类似虚拟化容器的计算方式去做隔离，同时又希望拥有 Docker 本身轻量级快速启动的效率，现在看来，虚拟化容器是比较符合这个需求的。

尾声

通过和叶理灯的交谈，梳理了我对云计算、容器技术和 Serverless 等方面的一些认识，作为一个几年来亲自践行云计算发展，并有深入探讨和研究的专家，他的观点和认识或许值得从业云计算行业的技术人员参考。