Question

具有讽刺意味的是，在写书的时候，所写的书的最后一部分往往是这本书的前言。这往往也是最棘手的部分。为什么？因为你必须向所有人解释为什么你对一个主题如此热情，以至于你最后花了一年半的时间来写一本关于这个主题的书。很难说清楚为什么有人会花这么多的时间在一本技术书上。人们很少会为名或为利撰写软件开发书籍。

我写本书的原因就是——我热爱编码。这是对我的一种召唤，也是一种创造性的活动，它类似于绘画或演奏乐器。软件开发领域之外的人很难理解这一点。我尤其喜欢构建分布式应用程序。对我来说，看到一个应用程序跨几十个（甚至数百个）服务器工作是一件令人惊奇的事情。这就像看着一个管弦乐队演奏一段音乐。虽然管弦乐队的最终作品很出色，但完成它往往需要大量的努力与练习。编写大规模分布式应用程序亦是如此。

自从 25 年前我进入软件开发领域以来，我就目睹了软件业与构建分布式应用程序的“正确”方式作斗争。我目睹过分布式服务标准（如 CORBA）兴起与陨落。巨型公司试图推行大型的而且通常是专有的协议。有人记得微软公司的分布式组件对象模型（Distributed Component Object Model，DCOM）或甲骨文公司的 J2EE 企业 Java Bean 2（EJB）吗？我目睹过技术公司和它们的追随者涌向沉重的基于 XML 的模式来构建面向服务的架构（SOA）。

在各种情况下，这些用于构建分布式系统的方法常常在它们自身的负担下崩溃。我并不是说这些技术无法用来构建一些非常强大的应用程序。它们陨落的真相是它们无法满足用户的需求。10 年前，智能手机刚刚被引入市场，云计算还处于起步阶段。另外，分布式应用程序开发的标准和技术对于普通开发人员来说太复杂了，以致于无法在实践中理解和使用。在软件开发行业，没有什么能像书面代码那样说真话。当标准妨碍到这一点时，标准很快就会被抛弃。

当我第一次听说构建应用程序的微服务方法时，我是有点儿怀疑的。“很好，另一种用于构建分布式应用的银弹方法。”我是这样想的。然而，随着我开始深入了解这些概念，我意识到微服务的简单性可以成为游戏规则的改变者。微服务架构的重点是构建使用简单协议（HTTP 和 JSON）进行通信的小型服务。仅此而已。开发人员可以使用几乎任何编程语言来编写一个微服务。在这种简单中蕴含着美。

然而，尽管构建单个微服务很容易，实施和扩展它却很困难。要让数百个小型的分布式组件协同工作，然后从它们构建一个弹性的应用程序是非常困难的。在分布式计算中，故障是无从逃避的现实，应用程序要处理好故障是非常困难的。套用我同事 Chris Miller 和 Shawn Hagwood 的话：“如果它没有偶尔崩溃，你就不是在构建。”

正是这些故障激励着我写这本书。我讨厌在不必要的时候从头开始构建东西。事实上，Java 是大多数应用程序开发工作的通用语言，尤其是在企业中。对许多组织来说，Spring 框架已成为大多数应用程序事实上的开发框架。我已经用 Java 做了近 20 年的应用程序开发（我还记得 Dancing Duke applet），并且使用 Spring 近 10 年了。当我开始我的微服务之旅时，我很高兴看到 Spring Cloud 的出现。

Spring Cloud 框架为许多微服务开发人员将会遇到的常见开发和运维问题提供开箱即用的解决方案。Spring Cloud 可以让开发人员仅使用所需的部分，并最大限度地减少构建和部署生产就绪的 Java 微服务所需的工作量。通过使用其他来自 Netflix、HashiCorp 以及 Apache 基金会等公司和组织的久经考验的技术，Spring Cloud 实现了这一点。

我一直认为自己是一名普通的开发人员，在一天结束的时候，需要按期完成任务。这就是我写这本书的原因。我想要一本可以在我的日常工作中使用的书。我想要一些直接简单的（希望如此）代码示例。我总是想要确保本书中的材料既可以作为单独的章使用也可以作为整体来使用。我希望读者会觉得本书很有用，希望读者会喜欢读它，就如同我喜欢写它一样。