今天的消息，又挣扎了两年的《Linux Journal》，宣布倒闭了。他们宣布：

2019 年 8 月 7 日，Linux Journal 关闭了大门。所有员工都被解雇了，公司没有任何经营资金可以继续以任何身份持续下去了。这个网站在接下来的几个星期内将继续维持，如果可以的话，希望可以保持更长时间的存档。

—— Linux Journal，LLC

这不是 Linux Journal 第一次发出悲呼。在一年半前，他们就宣布了停刊，但幸而在宣布停刊之后得到了社区的援手，得以复活，又持续了一年多。他们甚至对新的希望报以了很大的信心，在他们庆祝 25 周年的时候，还写了一篇文章来分析发生了什么，以及将来的想法。而且，确实，他们也在努力做出了新的改变。

但是，不管什么原因吧，这份创刊于 1994 的 Linux 杂志，在放弃了纸质杂志、电子杂志之后，可能要变成一个历史遗迹了。他们在网站上，用一张血红的纸张上扯破露出“TIME TO SAY GOODBYE”表达了对这份持续了 25 年的努力的不甘和哀伤——我是真能感受到这背后的哀伤。

说起来，Linux Journal 真是一个非常有价值的杂志/门户/社区，与之相比，我们的 Linux 中国社区就逊色多了，但是正是同一时刻，我也面临了 Linux 中国是否能继续下去的一些风刀雪箭，莫非天意？

说起来，Linux 中国也持续性的走了至少 6 年了 —— 如果从 2013 年 9 月 10 日 LCTT 成立算起的话。刚刚我在朋友圈发了一条消息，询问大家觉得 Linux 中国有无商业价值，不敢太严肃的问，怕引来各种联想。当然，有很多开玩笑的回答，也有一些感性的估计，也有一些用心的感激。其实，何必问呢，答案我心里有啊。

或许，Linux 中国有一些社会价值，也许帮到过许多人，也有很多人在这里付出了很多、很多的努力，但是，我们这 6 年没有尺寸进益，这说明了什么，我们究竟有没有商业价值？

很多人都知道，我一直坚持 Linux 中国的公益性、非商业性，也主张 Linux 中国是大家的，而不是我的或谁的。可是如果连起码的商业平衡也不能积累，是不是从一开始就是一个乌托邦式的空中楼阁？

Linux Journal 就倒在我的身侧，我遥望远方……

老王写于昆明，2019/8/8

正在开发一个将广泛分发的项目吗？了解一下黄金镜像吧，以便在出现问题时轻松恢复到“完美”状态。

如果你正在从事于质量保证、系统管理或媒体制作（没想到吧），你可能听说过 正式版 gold master 这一术语的某些变体，如 黄金镜像 golden image 或 母片 master image 等等。这个术语已经进入了每个参与创建完美模具的人的集体意识，然后从该模具中产生许多复制品。母片或黄金镜像就是：一种虚拟模具，你可以从中打造可分发的模型。

在媒体制作中，这就是所有人努力开发母片的过程。这个最终产品是独一无二的。它看起来和听起来像是可以看和听的最好的电影或专辑（或其他任何东西）。可以制作和压缩该母片的副本并发送给急切的公众。

在软件中，与该术语相关联的也是类似的意思。一旦软件经过编译和一再测试，完美的构建成果就会被声明为黄金版本，不允许对它进一步更改，并且所有可分发的副本都是从此母片生成的（当软件是用 CD 或 DVD 分发时，这实际上就是母盘）。

在系统管理中，你可能会遇到你的机构所选的操作系统的黄金镜像，其中的重要设置已经就绪，如安装好的虚拟专用网络（VPN）证书、设置好的电子邮件收件服务器的邮件客户端等等。同样，你可能也会在虚拟机（VM）的世界中听到这个术语，其中精心配置了虚拟驱动器的黄金镜像是所有克隆的新虚拟机的源头。

GNOME Boxes

正式版的概念很简单，但往往忽视将其付诸实践。有时，你的团队很高兴能够达成他们的目标，但没有人停下来考虑将这些成就指定为权威版本。在其他时候，没有简单的机制来做到这一点。

黄金镜像等同于部分历史的保存和提前备份计划。一旦你制作了一个完美的模型，无论你正在努力做什么，你都应该为自己保留这项工作，因为它不仅标志着你的进步，而且如果你继续工作时遇到问题，它就会成为一个后备。

GNOME Boxes，是随 GNOME 桌面一起提供的虚拟化平台，可以用作简单的演示用途。如果你从未使用过 GNOME Boxes，你可以在 Alan Formy-Duval 的文章 GNOME Boxes 入门中学习它的基础知识。

想象一下，你使用 GNOME Boxes 创建虚拟机，然后将操作系统安装到该 VM 中。现在，你想要制作一个黄金镜像。GNOME Boxes 已经率先摄取了你的安装快照，可以作为更多的操作系统安装的黄金镜像。

打开 GNOME Boxes 并在仪表板视图中，右键单击任何虚拟机，然后选择属性。在属性窗口中，选择快照选项卡。由 GNOME Boxes 自动创建的第一个快照是“Just Installed”。顾名思义，这是你最初安装到虚拟机上的操作系统。

如果你的虚拟机变成了你不想要的状态，你可以随时恢复为“Just Installed”镜像。

当然，如果你已经为自己调整了环境，那么在安装后恢复操作系统将是一个极大的工程。这就是为什么虚拟机的常见工作流程是：首先安装操作系统，然后根据你的要求或偏好修改它，然后拍摄快照，将该快照声明为配置好的黄金镜像。例如，如果你使用虚拟机进行 Flatpak 打包，那么在初始安装之后，你可以添加软件和 Flatpak 开发工具，构建工作环境，然后拍摄快照。创建快照后，你可以重命名该虚拟机以指示其真实用途。

要重命名虚拟机，请在仪表板视图中右键单击其缩略图，然后选择属性。在属性窗口中，输入新名称：

要克隆你的黄金映像，请右键单击 GNOME Boxes 界面中的虚拟机，然后选择克隆。

你现在可以从黄金映像的最新快照中克隆了。

黄金镜像

很少有学科无法从黄金镜像中受益。无论你是在 Git 中标记版本、在 Boxes 中拍摄快照、出版原型黑胶唱片、打印书籍以进行审核、设计用于批量生产的丝网印刷、还是制作文字模具，到处都是各种原型。这只是现代技术让我们人类更聪明而不是更努力的另一种方式，因此为你的项目制作一个黄金镜像，并根据需要随时生成克隆吧。

via: https://opensource.com/article/19/7/what-golden-image

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

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

我通常会严格保持此博客的技术性，将观察、意见等内容保持在最低限度。但是，这篇和接下来的几篇文章将介绍刚进入系统管理/SRE/系统工程师/sysops/devops-ops（无论你想称自己是什么）角色的常见的基础知识。

请跟我来！

“我的网站很慢！”

我只是随机选择了本文的问题类型，这也可以应用于任何与系统管理员相关的故障排除。我并不是要炫耀那些可以发现最多的信息的最聪明的“金句”。它也不是一个详尽的、一步步指导的、并在最后一个方框中导向“利润”一词的“流程图”。

我会通过一些例子展示常规的方法。

示例场景仅用于说明本文目的。它们有时会做一些不适用于所有情况的假设，而且肯定会有很多读者在某些时候说“哦，但我觉得你会发现……”。

但那可能会让我们错失重点。

十多年来，我一直在从事于支持工作，或在支持机构工作，有一件事让我一次又一次地感到震惊，这促使我写下了这篇文章。

有许多技术人员在遇到问题时的本能反应，就是不管三七二十一去尝试可能的解决方案。

“我的网站很慢，所以”，

• 我将尝试增大 MaxClients/MaxRequestWorkers/worker_connections
• 我将尝试提升 innodb_buffer_pool_size/effective_cache_size
• 我打算尝试启用 mod_gzip（遗憾的是，这是真实的故事）

“我曾经看过这个问题，它是因为某种原因造成的 —— 所以我估计还是这个原因，它应该能解决这个问题。”

这浪费了很多时间，并会让你在黑暗中盲目乱撞，胡乱鼓捣。

你的 InnoDB 的缓冲池也许达到 100％ 的利用率，但这可能只是因为有人运行了一段时间的一次性大型报告导致的。如果没有排除这种情况，那你就是在浪费时间。

开始之前

在这里，我应该说明一下，虽然这些建议同样适用于许多角色，但我是从一般的支持系统管理员的角度来撰写的。在一个成熟的内部组织中，或与规模较大的、规范管理的或“企业级”客户合作时，你通常会对一切都进行检测、测量、绘制、整理（甚至不是文字），并发出警报。那么你的方法也往往会有所不同。让我们在这里先忽略这种情况。

如果你没有这种东西，那就随意了。

澄清问题

首先确定实际上是什么问题。“慢”可以是多种形式的。是收到第一个字节的时间吗？从糟糕的 Javascript 加载和每页加载要拉取 15 MB 的静态内容，这是一个完全不同类型的问题。是慢，还是比通常慢？这是两个非常不同的解决方案！

在你着手做某事之前，确保你知道实际报告和遇到的问题。找到问题的根源通常很困难，但即便找不到也必须找到问题本身。

否则，这相当于系统管理员带着一把刀去参加枪战。

唾手可得

首次登录可疑服务器时，你可以查找一些常见的嫌疑对象。事实上，你应该这样做！每当我登录到服务器时，我都会发出一些命令来快速检查一些事情：我们是否发生了页交换（free / vmstat），磁盘是否繁忙（top / iostat / iotop），是否有丢包（netstat / proc/net/dev），是否处于连接数过多的状态（netstat），有什么东西占用了 CPU（top），谁在这个服务器上（w / who），syslog 和 dmesg 中是否有引人注目的消息？

如果你从 RAID 控制器得到 2000 条抱怨直写式缓存没有生效的消息，那么继续进行是没有意义的。

这用不了半分钟。如果什么都没有引起你的注意 —— 那么继续。

重现问题

如果某处确实存在问题，并且找不到唾手可得的信息。

那么采取所有步骤来尝试重现问题。当你可以重现该问题时，你就可以观察它。当你能观察到时，你就可以解决。如果在第一步中尚未显现出或覆盖了问题所在，询问报告问题的人需要采取哪些确切步骤来重现问题。

对于由太阳耀斑或只能运行在 OS/2 上的客户端引起的问题，重现并不总是可行的。但你的第一个停靠港应该是至少尝试一下！在一开始，你所知道的是“某人认为他们的网站很慢”。对于那些人，他们可能还在用他们的 GPRS 手机，也可能正在安装 Windows 更新。你在这里挖掘得再深也是浪费时间。

尝试重现！

检查日志

我对于有必要包括这一点感到很难过。但是我曾经看到有人在运行 tail /var/log/... 之后几分钟就不看了。大多数 *NIX 工具都特别喜欢记录日志。任何明显的错误都会在大多数应用程序日志中显得非常突出。检查一下。

缩小范围

如果没有明显的问题，但你可以重现所报告的问题，那也很棒。所以，你现在知道网站是慢的。现在你已经把范围缩小到：浏览器的渲染/错误、应用程序代码、DNS 基础设施、路由器、防火墙、网卡（所有的）、以太网电缆、负载均衡器、数据库、缓存层、会话存储、Web 服务器软件、应用程序服务器、内存、CPU、RAID 卡、磁盘等等。

根据设置添加一些其他可能的罪魁祸首。它们也可能是 SAN，也不要忘记硬件 WAF！以及…… 你明白我的意思。

如果问题是接收到第一个字节的时间，你当然会开始对 Web 服务器去应用上已知的修复程序，就是它响应缓慢，你也觉得几乎就是它，对吧？但是你错了！

你要回去尝试重现这个问题。只是这一次，你要试图消除尽可能多的潜在问题来源。

你可以非常轻松地消除绝大多数可能的罪魁祸首：你能从服务器本地重现问题吗？恭喜，你刚刚节省了自己必须尝试修复 BGP 路由的时间。

如果不能，请尝试使用同一网络上的其他计算机。如果可以的话，至少你可以将防火墙移到你的嫌疑人名单上，（但是要注意一下那个交换机！）

是所有的连接都很慢吗？虽然服务器是 Web 服务器，但并不意味着你不应该尝试使用其他类型的服务进行重现问题。netcat 在这些场景中非常有用（但是你的 SSH 连接可能会一直有延迟，这可以作为线索）！ 如果这也很慢，你至少知道你很可能遇到了网络问题，可以忽略掉整个 Web 软件及其所有组件的问题。用这个知识（我不收 200 美元）再次从顶部开始，按你的方式由内到外地进行！

即使你可以在本地复现 —— 仍然有很多“因素”留下。让我们排除一些变量。你能用普通文件重现它吗？ 如果 i_am_a_1kb_file.html 很慢，你就知道它不是数据库、缓存层或 OS 以外的任何东西和 Web 服务器本身的问题。

你能用一个需要解释或执行的 hello_world.(py|php|js|rb..) 文件重现问题吗？如果可以的话，你已经大大缩小了范围，你可以专注于少数事情。如果 hello_world 可以马上工作，你仍然学到了很多东西！你知道了没有任何明显的资源限制、任何满的队列或在任何地方卡住的 IPC 调用，所以这是应用程序正在做的事情或它正在与之通信的事情。

所有页面都慢吗？或者只是从第三方加载“实时分数数据”的页面慢？

这可以归结为：你仍然可以重现这个问题所涉及的最少量的“因素”是什么？

我们的示例是一个缓慢的网站，但这同样适用于几乎所有问题。邮件投递？你能在本地投递吗？能发给自己吗？能发给<常见的服务提供者>吗？使用小的、纯文本的消息进行测试。尝试直到遇到 2MB 拥堵时。使用 STARTTLS 和不使用 STARTTLS 呢？按你的方式由内到外地进行！

这些步骤中的每一步都只需要几秒钟，远远快于实施大多数“可能的”修复方案。

隔离观察

到目前为止，当你去除特定组件时无法重现问题时，你可能已经偶然发现了问题所在。

但如果你还没有，或者你仍然不知道为什么：一旦你找到了一种方法来重现问题，你和问题之间的“东西”（某个技术术语）最少，那么就该开始隔离和观察了。

请记住，许多服务可以在前台运行和/或启用调试。对于某些类别的问题，执行此操作通常非常有帮助。

这也是你的传统武器库发挥作用的地方。strace、lsof、netstat、GDB、iotop、valgrind、语言分析器（cProfile、xdebug、ruby-prof ……）那些类型的工具。

一旦你走到这一步，你就很少能摆脱剖析器或调试器了。

strace 通常是一个非常好的起点。

你可能会注意到应用程序停留在某个连接到端口 3306 的套接字文件描述符上的特定 read() 调用上。你会知道该怎么做。

转到 MySQL 并再次从顶部开始。显而易见：“等待某某锁”、死锁、max_connections ……进而：是所有查询？还是只写请求？只有某些表？还是只有某些存储引擎？等等……

你可能会注意到调用外部 API 资源的 connect() 需要五秒钟才能完成，甚至超时。你会知道该怎么做。

你可能会注意到，在同一对文件中有 1000 个调用 fstat() 和 open() 作为循环依赖的一部分。你会知道该怎么做。

它可能不是那些特别的东西，但我保证，你会发现一些东西。

如果你只是从这一部分学到一点，那也不错；学习使用 strace 吧！真的学习它，阅读整个手册页。甚至不要跳过历史部分。man 每个你还不知道它做了什么的系统调用。98％ 的故障排除会话以 strace 而终结。

via: http://northernmost.org/blog/troubleshooting-101/index.html

作者：Erik Ljungstrom 译者：wxy 校对：wxy

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

从炎热的夏日中走入到钱塘江畔清凉的网易云会客室，我见到了陈谔，开始这次“轻舟”之行。

说实话，初次近距离见到陈谔时，心中有点愕然，作为网易杭研的元老之一、网易云基础服务的领头人，我竟然从他身上感到一点点腼腆和技术人员的质朴。联想到之前网易云这边作为背景信息给出的个人介绍，这样的一位领军人物，居然自谦自己“对分布式系统设计开发、云计算平台系统架构有一定的经验和理解”，我不禁有些恍然。

我接触和采访过很多开源和互联网公司的技术领袖，陈谔应该是我见过的最温和而又不失自信的人之一，他的脸上总是浮现着内敛的笑容，让我们在谈话的一开始，就有了一个良好的氛围。

受访者（左）：网易云陈谔，采访者（右）：老王

网易云：千锤百炼终成型

和很多互联网公司推出的云服务一样，网易云也是一个脱胎于内部实践的云服务。网易杭州研究院作为整个网易公司的技术攻坚力量和创新业务孵化团队，随着网易业务和规模的不断的变化，杭州研究院面临着非常大的压力去做好基础设施的相关工作。

随着移动互联网的到来，原本可以很好应对博客、游戏等业务的 IT 基础设施逐渐变得捉襟见肘，原本的资源调度能力无法处理好随着新业务和新模式的快速增长和迭代而产生的需求和复杂度。IT 基础设施成为了当时网易发展业务的新瓶颈。

为了能够更好的服务网易内部的业务， 2012 年，网易杭州研究院组建了专门的云平台产品部，来建设网易内部使用的云计算平台，以应对移动互联网到来而产生的更加复杂应用带来的基础设施需求。

随着网易云产品对内提供服务，规模上的问题被逐渐解决，但是，产品的研发模式也在不断的迭代，网易内部开始不断地实践微服务架构。在这个过程中，陈谔感觉到，现有的 IaaS 产品和 PaaS 产品已经渐渐无法支撑来自微服务架构的复杂度，但在那时，云原生理念和技术尚未成熟的时代，对于微服务的探索只能独立践行。网易云针对性的提供了 CI/CD、分布式架构链路跟踪、服务治理的工具，帮助用户更好的去实践微服务。

到了 2015 年 7 月，随着 CNCF 的成立，这时陈谔发现，网易云的很多产品和服务，和 CNCF 的理念是一致的或相似的，于是，网易云决定将自己的探索和成果更好地结合社区的发展，向社区贡献自己的努力，也吸纳来自社区的营养，将网易云的发展和开源社区的路线结合起来。

也正因为拥抱社区，网易云很早就走上了 Kubernetes + Docker 的发展路线。谈起对于 Docker 和 Kubernetes 的选择，陈谔表示，网易云选择 Docker 和 Kubernetes 并不是偶然之下的决定。

实际上，早在 Docker 出现之前，网易云已经开始使用 LXC 技术来进行更细粒度的资源分配，实现了类似的容器技术栈，在此过程中，陈谔及其团队亲历了 LXC 技术在实施的过程中各种问题和技术缺陷带来的困扰。而 Docker 的横空出世使得整个云计算领域眼前一亮。虽然网易云自建的技术栈已经可以满足当时及近期业务的需求，但作为具有技术远瞻力的技术负责人，陈谔知道，相比于得到业界普遍看好的 Docker，自研的专属技术栈的生态环境狭窄，技术人员的培养成本也居高不下。而另外一方面，Docker 的镜像机制、分层文件系统机制，也使得之前在 LXC 技术栈里面斩荆披棘的网易云似乎看到容器技术发展的堂皇大道，使用 Docker 也就变得顺理成章。因此，网易云十分自然的就完成了从 LXC 向 Docker 的转移。

我问及 Kubernetes 的选择，陈谔笑了笑，他提到，网易云对于 Kubernetes 的支持是非常早的，在早期 Kubernetes、Swarm、Mesos 尚三足鼎立的时候，网易云就坚定的投入了 Kubernetes 生态。这一点和网易云过去在微服务、容器编排方面的实践是密不可分的。Kubernetes 解决了网易云在过去运维过程中遇到的诸多问题：如何进行弹性伸缩、如何进行服务调度、如何使用配置来进行控制。Kubernetes 所提供的配置能力，特别适合于需要解决微服务架构编排问题的网易云。

对于网易云来说，他们并不是一个刻意追求新奇的团队，相比于新兴的技术，网易云更在乎什么能够解决问题。显然，对于微服务架构支持最好的 Kubernetes 成为最终之选。

企业云：只为解决客户问题

网易云和很多云计算公司不同，没有将目光全部投放在公有云上，而是专注于为企业提供业务云化的解决方案。网易云也和容器云厂商的定位不同，容器是网易云的产品，更是网易云的工具，因此网易云虽然很早就应用了 Docker、Kubernetes 等技术，但是并没有突出这些看起来非常时髦的技术名词，而是根据企业需求，更多的将这些作为服务于上层的微服务产品的基础。通过结合容器的网络方案、存储方案等云原生技术积累，网易云希望更好的服务自己的客户。

陈谔说，网易云之所以选择了企业云的路线，更多是因为网易云发现自身更适合于在云原生领域深耕细作。与其在公有云的红海中去竞争，不如在云原生领域去深入挖掘，提升技术和竞争力。这样，就将竞争从 IaaS 层面，提升到了基于云原生体系的 PaaS 层面，避开了红海的竞争。同时，这种基于 Kubernetes 标准化的 PaaS 服务，其生命力也远超普通的 IaaS 产品，Kubernetes 的设计使得它能够消除厂商锁定，基于其实现的 PaaS 服务可以运行在任何一家 Kubernetes 服务商的云产品上。

陈谔还提到，作为一个面向企业提供解决方案的服务商，网易云和其他的容器云不同的是，更多是希望去靠近企业的 IT 的技术的认知，不会给企业造成过多的认知负担和业务侵入性。在业务落地时，能够根据企业的需要来不断的完成落地，而不是从一开始就要求企业去实践容器等，造成更大的负担。如果不是企业的需求要做容器化的话，不会第一时间要求用户完成容器化的迁移。但陈谔也发现，当用户真正去实施微服务框架的时候，往往会考虑实施和部署容器化，这时，网易云早已准备好的容器平台就可以很好的完成这部分的工作。

对于不希望进行容器化的企业，陈谔提到，网易云针对于这些异构的环境，也提供了不同的解决方案，诸如支持裸金属集群和虚拟机环境的 服务网格 （ Service Mesh ） 等能力，可以帮助那些不打算做容器化的企业完成自己的工作。

网易云希望自己的产品能够基于客户的 IT 策略来考虑，而不是将网易内部的实践生搬硬套到客户的业务中去。

DevOps 认知：陈谔的 DevOps 观

在谈到网易云内部的 DevOps 实践时，陈谔提到，在网易云内部其实很早就开始进行了 DevOps 实践。从 2014 年开始，网易云内部就开始推行服务化的组织架构和协作方式。在网易云内部，所有的工作都是接口先行，在网易云看到的每一个界面，都是先有接口，后有界面的。每一个接口背后都对应着网易云的一个服务以及对应的研发团队。这样从一开始，网易云就不设立专门的应用运维团队来负责业务的发布和上线，而是由各服务团队自行完成业务的发布和上线。除了 IaaS 层面基础设施的运维有专门的 SRE 团队来负责以外，各服务的运维都由各自团队自行来负责，这使得对应的团队必须自行解决运维需求。而且，为了更好的协作，网易云内部的所有的 API ，都会放在一个统一的 API 网关中，所有的用户都可以借助 API 来完成自己想要的操作，而无需进行 Web 界面的操作。

我们还谈到了 DevOps 和容器化的关系，在过去的一段时间里，宣传上总是将二者联系起来。在陈谔看来，容器化和 DevOps 的关系实际上是相辅相成的。

在他看来，之所以 DevOps 会出现，核心是随着企业业务的不断服务化拆分、微服务架构的实施，中心化的运维成为瓶颈，这使得企业不得不去提升运维的能力，去招募更多的运维。但是基于企业成本的考虑，运维人员的数量终归是有限的，因此有一些开发人员不得不兼任运维工作。但是，开发人员在运维方面的思路、关注点、风险意识上和传统运维人员存在一定差异，基于这样的考虑，需要一批工具来辅助开发人员进行运维工作，规范开发人员可以做的事情。在这样的一个大背景下，容器技术应运而生了。他相信，即使没有 Docker 公司搞出了容器化，也会有其他的公司来做出类似的产品，不同的只不过是各家的方案的优劣罢了。

轻舟微服务：帮助企业更好落地微服务

此次会见陈谔是在网易云创峰会上，而此次大会浓墨重彩介绍的产品之一就是网易轻舟微服务。

轻舟微服务是网易云在完成了基础设施的 Docker、Kubernetes 等改造完成后，基于对业界的分析和研究后提出来的。出于标准化技术栈的考虑，网易云最终启动了轻舟微服务的项目，将现有的技术栈，打造成一个个独立的标准化技术产品。到了 2018 年，在完成了对所有技术栈的标准化以后，将轻舟微服务发布了出来。

陈谔认为，异构系统整合，包括兼容、通信和系统间事务一致性，和多供应商建设，包括多团队协作、软件资产沉淀，是目前企业在建设在线业务中台过程中遇到的最大障碍，而网易轻舟微服务新品的发布，正是要通过服务网格、分布式事务框架 GTXS、全新 API 网关与原有轻舟产品的整合，完成全栈化在线中台技术体系升级，帮助企业完成业务架构的进化，支撑业务快速创新。

网易云陈谔和老王

陈谔介绍，轻舟服务网格是基于 Istio 和 CNCF 的 Envoy 等主流开源技术构建，可以实现 Java、Python、NodeJS、Golang 和 PHP 等不同技术栈的兼容和通信，能够与网易已有微服务框架 NSF 统一管控、互相发现、互相调用，并且支持容器、虚拟机和裸机部署，将异构系统的支持实现到了业界领先的程度。

在陈谔看来，轻舟微服务的推出，是网易云内部的微服务能力的对外输出，是网易云内部技术能力的输出体系，针对企业客户，提供了一整套的技术方案，以及对应的咨询服务和最佳实践的指导，帮助先前没有足够能力独力完成微服务化的企业，完成企业产品和服务的微服务化。

很多企业的 独石应用 （ Monolithic applications ） 随着企业的发展和产品的变迁，都面临新的挑战，而微服务化改造是企业所寄予众望的一条发展路径。但或因为微服务的技术储备不足，或因为既有业务的历史包袱过重，企业自行开发微服务体系不但耗时周期过长，而且可能因经验不足而走了弯路，因此，网易云在推出了轻舟微服务以后，赢得了不少企业用户的关注。

在实际的使用过程中，轻舟的部署也帮助企业大幅度提升了新业务接入的效率和版本发布的效率。举个例子来说，如果同时有数十个微服务的不同版本在开发，在传统的模式下，就需要提供数十个测试环境来完成测试，但在轻舟下，就可以基于无侵入的流量染色功能重用一套测试环境，仅将测试流量路由至特定版本微服务，降低了环境的成本。

后记

由于我离开了中国电信好几年了，近些年我对企业级产品和服务接触并不太多。而这次的采访，使得我对于一直以来缺少了解的网易云和其产品有了更深刻的认识。显然，网易云在这场云计算大潮中，找到了企业界真正的痛点，关注到了众多企业的真实需求，这种深耕的思路，一方面让网易云支撑起来网易云音乐、网易考拉等明星产品，另外一方面也使得网易云在企业上云和 IT 现代化方面不断攻城略地，取得不菲的成果，这值得云计算领域的细分厂商学习。

“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。

取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。

从十多年前云计算开始兴起，这些年云计算已经逐渐蔓延到了我们身边，如今，你所使用的很多服务其背后都是由云计算所支撑的。

但是，很多企业的 IT 设施以及网络服务，还一直因为种种原因而迟迟难以迈出上云的一步。这里面，有很多原因，有 IT 预算和迁移成本问题，有基础设施和应用迁移改造的问题，也有对云计算环境的安全性、可靠性的担忧问题，还有企业技术储备和能力问题。今天，我们将从技术的角度来看看，企业是否已经到了全面上云的拐点？

“企业全面上云的拐点到了”一语最近来自于 7 月 25 日在上海举办的阿里云峰会。在该次大会上，阿里云智能总裁张建锋表示，“全面上云是时代必然，今年是一个非常重要的拐点。”经过了过去十年的发展，云计算以及在关键技术和应用规模上实现了对传统 IT 的全面超越。

这里有个重要的信号，据 IDC 最近发布的《全球云计算 IT 基础设施市场预测报告》显示，2019 年全球云上的 IT 基础设施占比超过传统数据中心，成为市场主导者；而在中国，服务器出货量出现 10 年来首次下滑，企业快速迁移上云是背后主要诱因。

迁移工具就绪

企业上云最大的阻碍之一就是现有 IT 基础设施、应用和数据如何平滑地转移到云上，因此，一套可以无痛解决这个问题的迁移工具是企业上云所面临的当务之急。

各个云厂商均纷纷加大在企业迁云工具方面的努力，这里我们就阿里云来看，他们已经全面考虑到了企业上云的实操问题，提供了从服务器迁移到数据、数据库迁移的完整工具，完善地解决了传统 IT 中积累的大量数据无法搬迁的问题。

服务器迁移面临着三大痛难点，主要是应用高度复杂、操作麻烦、无从下手；迁移周期长、可能影响业务正常运行；通过制作镜像的方式迁移消耗大量人力资源。

阿里云已经免费提供自动化迁云效率工具—— 服务器迁移中心 （ ServerMigration Center ） （SMC），帮助企业服务器快速上云。

数据迁移时，必须要保证迁移数据的完整性、实现迁移时业务无感知，最终以最高的效率完成迁移。

阿里云的明星产品闪电立方，既可以满足轻量级的数据迁移，也能够支持TB到PB级别的数据量迁移。此前还支持过 115 科技完成互联网史上最大规模的数据迁移上云：规模超过 100 PB，整个项目耗时仅 45 天。

传统的数据库迁移工具要求数据库在迁移中必须停服，极大影响业务。

早在 2015 年，阿里云就发布了 数据传输服务 （ Data Transmission Service ） （DTS），采用 DTS，数据库在迁移过程中依然可以正常提供服务。目前，DTS 可支持多达 18 种数据源，已完成约 40 万个数据库上云。

云端环境就绪

在消除了迁移上云的障碍之后，完善就绪的云端环境决定了企业是否能在云端环境延续计算和应用。而云端环境不仅仅要求能够节省 IT 成本，也要求提供更高的稳定性、安全性和扩展性，以及更丰富的云端产品服务生态。

基础设施的上云不外乎服务器、存储、数据库等核心产品。对阿里云来说，在各个产品维度已经具备了完美的替代，IaaS 层面它们共同构成了飞天云操作系统。

例如服务器，除了性能稳定的 ECS，还有软硬一体的神龙云服务器，兼具虚拟机的灵活、可扩展，又有物理机的稳定和安全隔离特性。

数据库上，云原生数据库 POLARDB 在可用性、安全、成本、管理难易程度上都远远优于商业数据库。

阿里云存储已经连续三年入选 Gartner 全球云存储魔力象限，和 AWS、Microsoft、Google 共同跻身全球四强，服务客户由国家天文台、华大基因、今日头条等。

基础设施上云后，随后考虑的则是可以在云上获取价值的模块上云，包括大数据上云、云上中台、智联网 AIoT，这也都是阿里云承载客户上云的“王牌”。

飞天大数据平台是当前国内规模最大的计算平台，可扩展至 10 万台计算集群，曾创下四项海量数据排序世界纪录。在阿里巴巴经济体中支撑了全局数据存储和计算，单日数据处理量超过 600PB。

双中台是指数据中台和业务中台，已经帮助阿里巴巴经济体多元业务互联互通，业务创新层出不穷，人机协同大量运用，数据智能开创全新的商业形态。通过中台技术，在海外再造一个淘宝天猫，只需要两三个月时间，而盒马更是仅用 4 周就开发上线。

智联网 AIoT 融合了云边端一体化的人工智能与物联网能力。具备从高性能 AI 芯片至云平台、AI 算法、AI 组件以及产业 AI 的立体能力。

当行业大势已定，当阿里云的准备也一切就绪，还有什么可以阻挡企业全面上云的步伐呢？

本期人物介绍：

郭理靖，京东云产品研发部高级总监、产品委员会主席，专注于公有云服务、Docker、API 与数据开放平台、数据库服务等领域。擅长数据库、分布式存储系统、高可用服务架构等技术。

在任职期间，郭理靖研发上线了 MySQL、SQL Server、MongoDB、PostgerSQL、MariaDB、Percona、JDW（数据仓库）、DRDS（分布式数据库服务）、时序数据库、TiDB、BDS（区块链 BI 数据分析服务）等多款京东云产品 。京东云不仅是国内第一家支持 MySQL 8.0 的云厂商，也是国内第一家支持 MariaDB 的云厂商，而区块链 BI 数据分析服务也是可以代表全球区块链先进技术的创新产品，聚合了业界知名项目的核心数据，目前 BDS 已经对外开源。

前言

盛夏，在一家幽静的咖啡馆，我见到了匆匆赶来的郭理靖。我们深入谈了关于云计算、关于数据库方面的一些话题。我将这些谈话中的精彩内容整理出来，以飨读者。

与京东云共同成长的人

在谈话中，我了解到，郭理靖在京东的工作历程是伴随着京东云的发展一路走过来的。

从 2006 年到现在，郭理靖一直专注于云计算领域。从 2013 年京东云作为内部的基础设施云服务开始，他亲历了京东云从内部自用到正式商用的多个阶段的发展。

作为核心人员之一，郭理靖又在其中扮演了什么样的角色呢？

“其实我有两层角色，”郭理靖说到，“第一层，我负责数据库相关的服务，包括 RDS、数据仓库，现在京东云还推出了时序数据库、分布式数据库等，把京东技术体系内部的各种数据库的技术拿出来。另外，我还在京东云产品委员会，负责对京东云产品进行中长期规划， 评审产品开发可行性与必要性，规范产品上线流程，跟踪竞品动态与对标，统一产品培训资料，推进内、外部培训认证机制，精心打造京东云产品。”

谈到这里，我发现一个现象，根据我的了解，包括京东云在内的很多公有云服务商的产品负责人都是出身于一线技术岗位。之前也有人跟我说，“为什么云服务行业是技术人员来担任产品经理，这是因为云计算服务就是技术性的产品，不懂技术的没法制定和设计这样的产品出来。”

郭理靖表示：

“这种说法是比较有道理的，因为整个云计算的产品主要是给技术人员使用，要求产品经理有很强的技术功底、技术视野以及技术敏感度，不是技术背景出身的产品经理，难于理解用户诉求，很多细节没法把握。比如做时序数据库，到底是做成什么样的时序数据库，提供什么样的功能，只有做过技术支撑的产品经理，才能理解要什么样的产品和什么样的用户体验。”

从私有云到公有云

最初，京东云只是作为内部基础设施服务，那时候京东云的人手也比较少，最初采用的技术是 OpenStack 技术栈，从 2014 年开始全部转向了 Docker 容器技术。那个时候，京东已经把统一监控、部署、代码管理、日志服务这些技术部分都已经建设完备了，但是还缺乏一个核心的运行环境，而其时崛起的容器技术正好填补了这个空白。这个技术体系一直发展到现在。

到 2016 年， 京东云平台经历内部历练和打磨后，已经有了大规模的对外开放的技术基础了。在基础架构细节梳理的比较清晰、底层的基础设施服务和中间件服务都逐渐成熟、内部的使用和运营非常顺畅之后，当时决定，可以对外做公有云了。当然，做公有云和私有云的难度不是一个量级的，私有云很多事情都是在掌控范围之内，而做公有云要改造的东西特别多的。这包括网络管控、存储结构改造等几大的难点。

然而，京东云以后来者居上的节奏，从决定要对外开放，到真正的对外开往，仅用了几个月的时间，在 2016 年的 4 月 1 号正式对外开放公有云服务。

在京东云的公有云服务上线之后，逐渐往上增加各种产品和服务。产品从 20 多款已丰富至现在的 220 多款。

云计算从最初一个概念的提出，到后来发展为公有云、私有云、混合云等不同的形态，关于到底哪种云服务形态才是未来，人们也有不同的看法。不过从当前阶段看起来，主流的认识是，在认可公有云的基础上，企业希望有一种“私有化”的公有云服务。那么如何看待公有云、私有云以及接下来的发展呢？

郭理靖说：

“这个事情我们分两方面看，一方面就是看现状，另外一方面看接下去的发展。”

“当前的云服务的现状是公有云、私有云、混合云并存，而且这个阶段可能会比较长。……京东也在做私有云服务，……我们称之为 JDStack 专有云，专业服务中大型企业以及政务云 。JDStack 既能把京东云所有的能力集成起来，而又提供灵活选配的功能，除了核心的几个组件，如 SDN、RDS 等必需的产品之外，其他产品都可以选配，用户可以将京东云的能力复制一份带回家，这个产品目前的市场前景也非常好。”，同样，对于混合云，“我们可以提供的 VPN 以及专线接入，打通用户的私有云与我们的公有云，我们有完整的混合云方案，京东云的很多客户也是采用混合云的模式。”至于公有云，就更不用说了。这三种模式我们都有，主要是使用于不同场景……就目前来看，公有云市场最大，而私有云的销售份额要比混合云大。”

“你刚才讲到公有云上的私有云，确实有些用户希望在公有云里面划分一些独占的资源池，它的所有 VPS，RDS 都分配到那个资源池里面去，这种客户独享资源池的模式我们也是完全支持的。”郭理靖接着补充到，“存在这样的需求我觉得主要还是在于，政策法规上对于数据安全上面的规定。在金融、保险等领域，对数据保存的位置与管理都是有特殊要求的，使用这个解决方案，不仅能够满足合规的要求，而且能复用公有云统一的技术栈、管理服务，不用担心升级运维等基础设施性的问题。”

Docker 出现以后，随着 Kubernetes 编排系统的进一步普及和标准化，用户逐渐摆脱了被厂商绑定的情况，目前京东云在容器服务方面的进展是怎么样的？

“其实在云端提供容器服务的最大难点是资源隔离，在这方面我们做的还比较出色。我们应该是国内厂商中比较早做容器服务的。现在 Docker 是用 cgroup 进行隔离的，但会造成 Docker 容器之间的逃逸，导致同一台物理机上的 Docker 容器可以读取另一个 Docker 容器的数据。这在私有云上这不是太大的问题，但在公共云上是不可接受的，所以我们开发了原生容器服务，利用虚拟化去承载容器镜像。用传统的虚拟化技术进行隔离，同时兼容所有 Docker 的镜像，在启动速度方面，丝毫不逊色于 Docker，甚至在不少场景还会更快。同时原生容器还可以无缝衔接我们现有的 SDN 和云硬盘等底层服务，在公有云产品线里是属于与云主机平级的‘一等公民’，这会比在虚拟机里运行 Docker 要好很多。”

专注于数据库

除了云计算方面，郭理靖也植根于数据库领域。

“京东云的关系型数据库（RDS）覆盖面还是比较广的，支持的数据库类型也比较多，除此之外我们还有自己的 DTS 服务，可以做数据迁移服务。”他说，“京东云非常重视数据库，数据库研发团队也非常精悍。我们对新技术的敏感度及理解一直走在前面。例如，京东云是国内首发支持 MySQL8.0 的云厂商，同时也是第一家支持云数据库 MariaDB 服务的云厂商，我们也在积极进行云原生数据库的研发工作。

新的数据库，新的服务模式

关于京东云自研的新数据库服务，我表示很好奇，因为一个全新的数据库的研发难度显然要远远大于将已有的开源产品进行适配、优化后提供给客户使用。

郭理靖说，“因为 MySQL 在单一实例上自身存在容量限制，并不能发挥云端的优势：按需付费。比如购买云厂商的 RDS，企业实际购买的数据库服务的 QPS 是受限的，如果买更高性能则可能很多时候是浪费的。这就没有把云服务的资源和能力完全发挥出来：随着用户的体量越来越大，对容量的需求相对更大，应该在访问高峰时能够满足服务要求，在访问低峰时足够便宜，按照实际用量来收费。这样的数据库产品很值得设计研发。”

京东云对未来这样一个按需付费的数据库期望达到：

“第一、兼容SQL 标准；第二、按需付费、按性能付费，小规格的存储也能享受高性能，存储和运算深度分离；第三、性能非常好。”

开源开放

作为开源社区，我们自然也关注京东云的开源。

郭理靖说，“参与开源社区活动我们是非常积极的。我们不但是云原生基金会（CNCF）的会员，也加入了 Enterprise Ethereum Alliance（EEA），我们对开源这件事持很开放的态度。”

“在过去的几年中我们的工作压力比较大，更多的精力是投放在产品的打磨上，先要达到一定的产品丰富程度才能去做到精益求精，才能在对外开源，才能在开源社区上去贡献更大的力量”，郭理靖补充道。

当然，开源从来不仅仅是一种意愿，而是代表着背后很多的工作投入的。

开源这件事需要必要的时间和投入，京东云事业部对此也是持开放的态度，希望可以通过开源进行技术和品牌侧的建设。从这一点看，我觉得中国的技术公司已经有这样的思想和氛围了。

“要做一个完整的开源项目还是存在一些挑战，比如京东云的很多项目相互依赖比较多，要做开源的话首先要进行整理和切割，否则开源出去也无法独立运作，就没有开源的意义了。举个例子，如果要开发一个中间件，那必须把原先和用户、计费、管理、监控相关的东西全部切割出来，这个任务代价是很大的。”

郭理靖说，“目前我们的 BDS 项目已经完成代码的整理，已经对外开源了。BDS 是京东云打造一个行业标准的区块链的 BI + 数据搜索服务。区块链项目的底层区块存储结构各不相同，需要对不同的项目的数据进行解析与整理，基于此，京东云开源了区块链数据服务 (BDS)，以望让更多的开发者与社区可以参与其中，接入更多公有链、联盟链、私有链等区块链项目。区块链数据服务将以区块链数据搜索引擎形式聚合所有区块链相关的内容，最大化区块链上可信数据价值，方便社区能在 BDS 上进行区块链数据的一站式查询。。”

“技术开源也能从另一个纬度考验我们的技术能力，进而驱动我们不断打磨技术和产品”。

作为京东集团技术能力对外输出的重要出口，京东云商用三年以来，正在逐渐演化为京东技术的“开源”代表，对内整合 AI、区块链等硬核技术，对外不断携手上下游伙伴扩张生态，京东云希望让各种技术通过云端整合相互促进，业务侧对外赋能可以像积木一般拆分重组，实现“即插即用”的模块化方式，为社区、为生态带来普惠价值。

结语

和郭理靖的谈话匆匆过去了一个小时，通过和一位直接负责云产品的技术负责人的深入沟通，让我对京东云丰富的云产品背后所掩盖的宏大的技术背景有所了解，也对云计算的发展有了更多的切实体悟。

“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。

取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。