推荐序3

从云计算到云原生，这一以云为起点的浪潮已持续10年之久，我所在的团队也有幸在这一方向实践了近8年，我能深刻感受到其中有一些逻辑在驱使云计算技术栈的发展，使陆续出现的许多技术演进似乎成为一种必然，也使从云计算到云原生能产生被广泛认同的标准，形成许多行业的共识，进而形成一个广阔的相对标准的产品、服务市场。

在从事云计算、云原生相关工作的这些年里，我经常要面对的问题是“为什么做”，经常要面对的情况则是“不得不做”。云计算技术的应用与算法、前端等有很大不同，我们很难以技术进步带来的直接价值驱动业务进行技术升级，因此很多时候都是已经感受到明显的瓶颈或对未来发展过程中的技术瓶颈有了明确的预期，才能推动技术的升级。

以互联网业务服务端的演进来看，这是一个应对业务发展所产生的复杂性的过程，自Web 1.0到Web 2.0再到移动应用，互联网业务越来越复杂，一个应用聚集了足够流量之后总会向平台化发展，以寻求商业模式的突破，而平台由于多元、共生的特性，复杂性远远大于单一应用。以网易为例，我们遭遇了资源生命周期管理类运维操作大增、服务器型号碎片化等问题，使建设云计算平台从2010年的“为什么做”变成了2012年的“不得不做”。而OpenStack亦诞生于2010年，并在2012年达到一定的成熟度。这完全不是巧合，而是因为有众多企业正在面对同样的问题，是市场的需求使然。

随着移动应用浪潮的到来及流量红利的激增，平台的价值被进一步放大，电商、社交等平台的复杂性达到了前所未有的高度，此时原有的服务拆分粒度已经过于粗放，单个服务內的业务逻辑修改牵一发而动全身的情况屡见不鲜，所以把服务进一步进行细粒度拆分成为必然的选择。同样以网易为例，2015年用户量过亿的网易云音乐、2015年诞生的考拉海购，在经历迭代的困境后均逐步发展为微服务架构，这是“不得不做”的选择。另外，对服务的细粒度拆分不断给运维带来挑战，中心化的运维角色不能满足海量服务的维护需求，开发人员也需要参与到运维协作中来，尤其需要分担更为高频的发布工作。我们在实践中也遇到了一些挑战，例如为解决运行环境问题产生了大量的环境初始化模板，模板与制品的分离管理造成了诸多的混乱，在服务节点的生命周期管理和应用编排方面则涉及IaaS层接口和编排服务接口如何设计等问题。我们在不断踩坑过程中意识到在缺乏社区标准支持的情况下自行解决这些问题的代价是巨大的，此时逐渐成熟的容器、Kubernetes让我们看到了解决问题的希望。2016年左右，我们几乎毫不犹豫地转向了容器和Kubernetes技术栈，至此从微服务到容器、Kubernetes，云原生便成为了我们延续至今且尚在不断探索的技术路线。

技术架构和技术栈的更新不仅解决了我们在发展过程中面对的问题，更让我们看到了后续发展的可能性，在软件架构不断拆分且转向服务化的过程中，传统的基于代码的重用由于直接共享数据模型与数据层，难以支持快速迭代，给人以包含业务逻辑的软件重用不靠谱的印象。而在服务化架构下，服务方保障了接口的稳定兼容，服务抽象了业务的能力，新业务的构建得以大量依赖已存在的服务，形成了中台这样高级的业务能力重用的形态。在服务化重用的浪潮背后有一项基础软件服务是不可或缺的，参考代码级重用时代的制品管理机制，一个可运行的服务、应用也需要有自己的仓库以支持服务化形态交付。同时，由于代表企业业务能力的软件服务在数字化时代已成为企业的核心资产，因此需要的企业级管控能力远高于制品管理要求。Harbor从2016年开源至今，功能逐步完善，无论是企业级镜像管理，还是镜像复制、漏洞扫描等功能都切实解决了企业的难题，Harbor自2.0版本开始更是兼容OCI标准，成为较早遵循云原生标准的仓库项目，可以说，Harbor已经成为承载服务、应用镜像管理的标准。对于这样一个重要的基础软件，网易的云原生团队也积极加入其社区代码的维护工作中，推动Harbor在越来越多的企业中应用。

另一方面，很多“不得不做”云原生的Harbor新用户，对这个软件的能力、架构设计及优秀实践并不熟悉，往往会走一些弯路。这部由Harbor社区核心维护者和贡献者倾力编撰的《Harbor权威指南》适时完成，从组件介绍、源码解析到生态融合，结构清晰，案例详尽，具有很强的实操性，能帮助我们少走弯路。面对云原生的浪潮，我们很有必要深入理解Harbor这样的云原生基础软件。相信阅读本书会有助于我们快速入门、进阶乃至精通Harbor。

陈谔

网易云计算中心总经理