译者序
当我们讨论云原生时,究竟在讨论什么?这些年来我一直在思索这个问题,大家的观点可能不尽相同。三年前从我翻译了第一本云原生领域的图书开始,陆续参与翻译和创作了一系列云原生作品,同时通过对云原生领域的开源项目、社区、基金会、应用云化过程的参与和观察,我得出了下面的结论 :云原生是一种行为方式和设计理念,究其本质,凡是能够提高云上资源利用率和应用交付效率的行为或方式都是云原生的。云计算的发展史就是一部云原生化的历史。云原生是云计算适应社会分工的必然结果,将系统资源、底层基础设施和应用编排交由云平台管理,让
开发者专注于业务逻辑,这不正是云计算长久以来孜孜以求的吗?云原生应用追求的是快速构建高容错性、弹性的分布式应用,追求极致的研发效率和友好的上线与运维体验,随之云原生的理念应运而生,它们天生适合部署在云上,可以最大限度地利用云计算带来的红利。
在此之前我曾翻译过几本云原生主题的图书,其中 Cloud Native Go 的作者 Kevin Hoffman,《云原生 Java》的作者 Josh Long,他们都来自 Pivotal 或曾在Pivotal 工作多年,当看到此书时,我惊奇地发现,作者 Cornelia Davis 同样来自这家公司,Pivotal 真可谓是云原生的“黄埔军校”。此书的内容跟以往的云原生图书有所不同,对于模式的梳理标新立异,因此我立即联系了电子工业出版社的张春雨编辑。经他了解到张若飞正在翻译此书,此前我与他合作翻译了《云原生 Java》,本书算是我跟他的第二次合作,他翻译图书的精准和高效着实让我佩服,我们各自
翻译了本书一半的内容。
人人都在讨论云原生,但是究竟如何实现却莫衷一是。本书主要关注的是云原生应用的数据、服务与交互,即应用层面的设计模式,这些模式穿插于本书第 2 部分的各个章节中,基本覆盖了云原生应用的各个方面,并将理论与实践结合,带领读者使用 Java 实现了一个云原生应用。
同时还要感谢 ServiceMesher 社区、云原生社区的成员及志愿者们对于云原生在中国的发展做出的贡献,你们的鼓励和支持是我在云原生领域不断努力和探索的动力。本书的翻译难免有一些纰漏,还望读者指正。
宋净超 2020 年 7 月 4 日于北京
序
六年来,我有幸与 Nicole Forsgren 和 Jez Humble 合作编写了《DevOps 现状报告》(State of DevOps Report),该报告收集了来自三万多名受访者的数据。这份报告给我的最大启示之一就是软件架构的重要性 :高效能团队的架构能够使开发人员快速、独立、安全、可靠地开发、测试和部署软件,从而为客户不断创造价值。
几十年前,我们可以开玩笑地说,软件架构师只擅长使用 Visio、绘制 UML 图表以及制作没人看的 PowerPoint 幻灯片,但今非昔比,大量企业在市场上的成败取决于它们所开发的软件。应该说,没有什么比它们每天必须使用的架构更能影响开发人员的日常工作了。
本书填补了理论与实践之间的一段空白。事实上,我认为只有少数人可以将它写出来。Cornelia Davis 是极其合适的人选,她曾在攻读博士学位时学习了编程语言,对函数式编程和不可变性产生了浓厚的兴趣,拥有数十年大型软件系统的开发经验,并且帮助大型软件企业获得过巨大的成功。
在过去的五年中,我多次联系她寻求帮助和建议,我们经常讨论有关诸如CQRS 和事件源模式、LISP 和 Clojure 语言(我最喜欢的编程语言)、命令式编程和状态的危险性,甚至像递归这样简单的事情。
本书的亮点在于 Cornelia 不仅仅从模式入手。她从模式的基本理论开始,然后通过论证(有时通过逻辑或者流程图)来证明它们的有效性。除了理论本身,她还通过 Java Spring 框架一个一个地实现了这些模式,以便让你更好地理解这些知识。
我发现,这本书兼具娱乐性和教育性,并且使我对大量以前只是略知皮毛的知识有了更深入的了解。我现在致力于通过 Clojure 语言来实现她的示例,以证明我可以将这些知识付诸实践。
本书可能会让你联系起一些令人感到兴奋甚至惊讶的概念。对我而言,其中一个概念就是无论是面向切面的编程(AOP)、Kubernetes 的挎斗(sidecar)模式,还是 Spring Retry 注入,都是为了统一处理横切关注点(cross-cutting concerns)。
希望你能像我一样喜欢这本书!
— Gene Kim,研究员以及 The Phoenix Project、The Devops Handbook 和 Accelerate 的联合作者
前言
我的职业生涯始于图像处理。我曾在休斯飞机公司(Hughes Aircraft)的导弹系统部工作,研究红外图像处理,处理边缘检测和帧与帧之间的关联。(这些功能在如今的手机应用上无处不见,这都要归功于 20 世纪 80 年代的研究!)
我们在图像处理中常用的计算之一是标准差。我从来不羞怯于提出问题,而我早年经常问的一个问题就是关于标准差的。我的一个同事总是会写下标准差的公式。真见鬼,三个月过去了,这个公式我大概已经写了六遍。
我真正想问的是 :“在这种情况下,标准差究竟意味着什么?”实际上,标准差是用来定义什么是“正常的”,这样我们可以寻找离群值。如果我正在计算标准差,然后发现了超出正常值范围的情况,那么是否表示我的传感器可能出现了故障,并且我需要舍弃这一帧图像,还是表示它暴露了潜在敌人的行动?
所有这些与云原生有什么关系?没有。但这一切与模式有关。正如你所见,我虽然知道这个模式(标准差计算),但是由于当时缺乏经验,所以不知道何时以及为什么要使用它。
在本书中,我将向你介绍云原生应用程序的多种架构模式,是的,我将向你展示许多的“公式”,但是为了说明何时及为何使用这些模式,我会在介绍上下文环境上花费更多的时间。实际上,模式通常并不那么困难(例如,第 9 章介绍的请求重试模式很容易实现),困难的是决定何时应用某个模式,以及如何正确地应用该模式。
在应用这些模式时,你需要了解很多的上下文环境,并且坦率地说,这些环境有可能很复杂。
那么上下文环境是什么呢?从根本上来说,它是一个分布式系统。当我三十多年前开始工作时,并不认识很多从事分布式系统工作的人,在大学也没有学过分布式系统的课程。没错,虽然人们在这个领域中工作,但说实话,这是一个非常小的领域。
如今,绝大多数软件都是分布式系统。软件的某些部分在浏览器中运行,而另一些部分在服务器上运行,或者我敢说,在一大堆服务器上运行。这些服务器可能在你公司的数据中心运行,也可能在俄勒冈州普莱恩维尔的一个数据中心运行,或者同时在两地运行。所有这些都是通过网络(可能是互联网)进行通信的,而且软件的数据也很可能是分布式的。简单地说,云原生软件是一个分布式的系统。此外,事情在不断变化 — 服务器正在不断下架,网络经常中断(即便是非常短暂的中断),存储设备可能会在没有任何警告的情况下崩溃 — 即使是这样,我们依然希望软件能够继续正常运行。这是一个非常具有挑战性的环境。
但是这完全是可控制的!本书的目的就是帮助你理解这种上下文环境,并为你提供一些工具,让你成为一名精通云原生的架构师和开发人员。
我从来没有像现在这样感受到如此剧烈的脑力激荡。这在很大程度上是因为技术领域正在发生重大变化,而云原生就是这个变化的核心。我绝对热爱我所从事的工作,我希望每个人,尤其是你,也能像我一样喜欢编写软件。这就是我编写这本书的原因 :我想与你分享整个行业正在面临的那些疯狂而又酷炫的问题,帮助你踏上解决这些问题的旅程。我很荣幸有机会与你一起踏上云原生之旅,哪怕是在其中扮演一个小小的配角。
我的云原生之旅始于 2012 年,当时我的老板 Tom Maguire 让我开始研究 PaaS(平台即服务)。作为 EMC CTO 办公室架构组的一员,关注新兴技术对我们来说并不新鲜 — 但是,这一次终于成功了!我将永远感激 Tom 给了我探索的动力和空间。
到 2013 年年初,我已经学到了足够多的东西,预见到未来我会在这个领域工作,而随着 Pivotal Software 公司的创立,我有了一个工作的地方。首先,我要感谢 Elisabeth Hendrickson,感谢她在我还在 EMC 的时候就邀请我参加 Cloud Foundry会议,感谢她把我介绍给 James Watters。我经常说,我做过的最好的职业选择是为James 工作。我感谢他给了我很多机会,感谢他的信任让我全身心投入工作,感谢与他大量的深度对话让彼此共同理解了什么是云原生,以及感谢我们之间六年的深厚友谊。
我很感恩自从 Pivotal 公司成立我就加入了公司,和这么多聪明、敬业、善良的同事一起学习。我要感谢 Elisabeth Hendrickson、Joshua McKenty、Andrew Clay-Shafer、Scott Yara、Ferran Rodenas、Matt Stine、Ragvender Arni,以及其他许多人(如果我漏掉了任何人,请原谅)帮助我学习,并与我一起度过我人生中最美好的六年!
我还要特别感谢 Pivotal 公司,特别是 Ian Andrews 和 Kelly Hall,感谢他们赞助了《云原生基础》(Cloud-Native Foundations)迷你书。
我从许多同行那里学到了很多知识,无法一一列举,但是感谢每一个人。我特别想感谢 Gene Kim。我还记得我们见面的那天晚上(再次感谢 Elisabeth Hendrickson,感谢她促成了我们那次会面),我立刻意识到,我们将合作很长一段时间。我感谢Gene 给了我在 DevOps 企业峰会(DevOps Enterprise Summit)上与他共事的机会,通过那次峰会,我认识了许多在不同公司工作的创新