vlambda博客
学习文章列表

Amazon 或 Netflix 等新兴高科技公司的自然趋势是使用微服务构建他们的新软件，这是理想的场景：他们在面向微服务的软件中获得巨大优势（通过本书，您将了解如何）为了不费吹灰之力扩大他们的新产品。问题是并非所有公司都可以预先规划他们的软件。这些公司没有计划，而是根据所经历的有机增长来构建软件：很少有软件组件按亲和力对业务流进行分组。拥有两大软件组件的公司并不罕见：面向用户的网站和内部管理 工具。这通常称为单体软件架构。

其中一些公司在尝试扩展工程团队时面临着很大的问题。很难协调构建、部署和维护单个软件组件的团队。发布冲突和重新引入错误是一个常见问题，会消耗团队的大量精力。这个问题的解决方案之一（它带来了好处）是将单体软件拆分为微服务，以便团队能够专注于一些较小的模块以及可以在没有版本控制、更新和部署的情况下进行版本控制、更新和部署的独立软件组件干扰公司的其他系统。

将单体架构拆分为微服务使工程团队能够创建独立且自主的工作单元，这些工作单元高度专业化于特定任务，例如发送电子邮件、处理卡支付等。

微服务是专门用于一项任务并协同工作以实现更高级别任务的小型软件组件。暂时忘掉软件，想想公司是如何运作的。当有人在公司申请工作时，他申请的是给定的职位：软件工程师、系统管理员、办公室经理。其原因可以用一个词来概括：专业化。如果你习惯了软件工程师的工作，你会随着经验变得更好，并为公司增加更多的价值。您不知道如何与客户打交道这一事实不会影响您的表现，因为这不是您的专业领域，并且几乎不会为您的日常工作增加任何价值。

微服务是一个自治的工作单元，可以执行一项任务而不会干扰系统的其他部分，类似于公司的职位。这有许多好处，可用于有利于工程团队，以帮助扩展公司的系统。

如今，数百个系统是使用面向微服务的架构构建的，如下所示：

面向微服务的架构具有一些特殊性，使其适合任何希望保持其 IT 系统弹性和向上/向下扩展的大中型公司 -就绪状态。

它们不是软件工程的圣杯，但如果小心处理，它们会成为解决技术面临的大多数重大问题的完美方法-附属公司。

牢记面向微服务架构设计的关键原则很重要，例如弹性、可组合性、弹性等；否则，您最终可能会得到一个分散在不同机器上的单一应用程序，这会产生问题，而不是一个优雅的解决方案。

还有一些关于面向微服务的架构的批评，因为它们引入了一些需要处理的问题，例如延迟、可追溯性和不存在的配置管理使用基于单片机的软件。部分问题描述如下：

一般来说，工程师应该尝试评估这种方法的优缺点，并决定是否使用微服务以满足业务需求。

面向微服务的架构有一些需要考虑的特殊性。当软件工程师编写单体软件时，由于所构建软件的性质，有一些会被完全忽略。

例如，假设我们的软件需要发送电子邮件。在单体软件中，我们只需将功能添加到应用程序的核心。我们甚至可以选择创建一个专门的模块来处理电子邮件（这似乎是个好主意）。现在，假设我们正在创建一个微服务，而不是向大型软件工件添加功能，我们创建一个可以独立部署和版本控制的专用服务。在这种情况下，我们将有一个不需要考虑的额外步骤，即 网络延迟，以到达新的微服务。

在前面的示例中，无论您采用哪种方法（单体或微服务）来构建软件，都不是什么大问题。例如，如果一封电子邮件丢失了，这并不是世界末日。根据定义，不能保证电子邮件的发送，因此我们的应用程序仍然可以工作，尽管我们可能会收到客户的一些投诉。

软件工程 最令人愉快的方面之一是创建一个新项目。在这里，您可以发挥所有创造力，尝试新的 架构概念、框架或方法。不幸的是，这在成熟的公司中并不常见。通常，我们所做的是在现有软件中创建新组件。在创建新组件时可以遵循的最佳设计原则之一是保持与软件其余部分的耦合尽可能低，以便它作为一个独立的单元工作。

考虑一个真实的例子：您公司的应用程序现在需要能够处理付款。

这里的逻辑决策是创建一个新模块，该模块知道如何处理所选支付提供商（信用卡、PayPal 等），并允许我们将所有与支付相关的业务逻辑保留在其中。让我们在下面的代码中定义接口：

public interface PaymentService {
  PaymentResponse processPayment(PaymentRequest request) throws MyBusinessException;
}

这个简单的接口大家都能看懂，但它是迈向微服务的关键。我们将所有业务知识封装在一个接口后面，这样理论上我们可以在不影响应用程序的其余部分的情况下切换支付提供商——实现细节对外界是隐藏的。

以下是我们迄今为止所知道的：

我们创建了一个高度内聚和松散耦合的业务单元。让我们在下面证明这个肯定：

下面的 图表显示了由许多 组件组成的系统如何获取其中一个（支付服务）剥离成一个微服务：

一旦实现了这个 模块，我们将能够处理付款和我们的单体应用程序将具有另一个功能，可以很好地提取到微服务中。

现在，我们可以推出新版本的支付服务，只要界面没有改变，以及与世界其他地方（我们的系统或第三方）的合同没有改变。这就是为什么保持实现独立于接口如此重要的原因，即使该语言不提供对接口的支持。

我们还可以根据需要扩展和部署尽可能多的支付服务，以便我们可以满足业务需求，而无需不必要地扩展可能没有压力的应用程序的其余部分。

超文本传输​​协议 (HTTP) 是最好的协议之一互联网上曾经发生过的事情。想象一个设计为无状态的协议，但通过使用cookies来保持状态。那是在 Web 1.0 时代，当时没有人谈论 REST API 或移动应用程序。让我们看一个 HTTP 请求的示例：

如您所见，它是一个人类可读协议，无需解释即可理解。

如今，人们普遍认为 HTTP 不仅限于在 Web 中使用，而且由于它是 设计的，现在它被用作通用用途<一个 id="id30" class="indexterm"> 协议，用于将数据从一个端点传输到另一个端点。 HTTP 是微服务之间通信所需的全部内容：一种传输数据和从传输错误中恢复（如果可能）的协议。

在过去的几年里，特别是在企业界，一直在努力创建智能 通信机制，例如 <强>BPEL。 BPEL 代表 Business Process Execution Language，它不关注通信操作，而是关注围绕业务步骤的操作。

这在通信协议中引入了某种程度的复杂性，并使应用程序的业务逻辑从端点渗入其中，从而导致端点之间存在某种程度的耦合。

业务逻辑应保留在端点内，而不是渗入通信通道，以便系统可以轻松测试和扩展。多年来的经验教训是，通信层必须是一个简单明了的协议，以确保数据和端点（微服务）的传输。这些端点应该在其实现中嵌入服务可能会关闭一段时间的事实时间（这称为弹性，我们将在本章后面讨论）或网络可能导致通信问题。

在构建面向微服务的软件时，HTTP 通常是最常用的协议，但另一个需要探索的有趣选项是使用队列，例如 Rabbit MQ 和 Kafka，以促进端点之间的通信。

排队技术提供了一种干净的方法来以缓冲的 方式管理通信，封装了 的复杂性在高度事务性的系统上确认消息。

单体应用程序的主要缺点之一是将所有内容集中在单个（或少数）软件组件和数据库上。这通常会导致需要根据公司需求和流的集中治理来复制和扩展庞大的数据存储。

微服务旨在实现去中心化。与其拥有庞大的数据库，不如将数据按照前面解释的业务单位进行拆分？

一些读者可能会将事务性作为不这样做的主要原因之一。考虑以下场景：

在单体软件中，所有调用都将包装在一个事务中，因此如果由于某种原因任何调用失败，其他调用的数据将不会保存在数据库中。

当您学习设计数据库时，ACID 首字母缩略词总结了首要且最重要的原则之一：

在面向微服务的软件上，ACID 原则并不能在全球范围内得到保证。微服务将在本地提交事务，但没有任何机制可以保证全局事务的 100% 完整性。可以在不处理付款的情况下发送图书，除非我们考虑到特定规则来防止它发生。

在面向微服务的架构上，无法保证数据的事务性，因此我们需要将故障因素考虑到实现中。解决这个问题的一种方法（虽然，变通方法是一个更合适的词）是分散治理和数据存储。

在构建微服务时，我们需要在设计中嵌入一个根据软件的可用性，或更多组件可能会发生故障并降低功能。

让我们看一下下面的图表：

此图表示单片软件的执行顺序。一个顺序的调用列表，无论如何，都将按照 ACID 原则执行：要么所有调用（事务）都成功，要么都不成功。

这只有在框架和数据库引擎设计者已经开发出事务的概念来保​​证数据的事务性时才有可能。

在使用微服务时，我们需要考虑工程师所说的最终一致性。在事务部分失败后，每个微服务实例都应存储恢复事务所需的信息，以便信息最终保持一致。按照前面的例子，如果我们在不处理支付的情况下发送书籍，支付网关将有一个失败的交易，稍后有人会处理，使数据再次一致。

解决此问题的最佳方法 是分散治理。每个端点都应该能够做出影响事务全局范围的本地决策。我们将在 第 3 章 中详细讨论这个主题, 从单体应用到微服务。

在构建一个新软件时，每个开发者都应该保持一个的概念牢记：标准。

标准保证您的服务将在技术上独立，以便使用不同的编程语言或技术轻松构建集成。

使用微服务对系统进行建模的优点之一是我们可以为正确的工作选择正确的技术，这样我们在解决问题时就可以非常高效。在构建单体软件时，将我们可以做的技术与微服务相结合是相当困难的。通常，在单体软件中，我们与一开始选择的技术联系在一起。

Java 远程方法调用 (RMI) 就是一个例子如果您希望您的系统对新技术开放，则应避免使用 的非标准协议。这是连接用 Java 编写的软件组件的好方法，但开发人员将很难（如果没有失败）使用 Node.js 调用 RMI 方法。这会将我们的架构与给定的语言联系起来，从微服务 的角度来看，这将扼​​杀一个最有趣的优势：技术异质性。

一旦我们决定将我们的系统建模为一组微服务，就会有总是有一个问题需要回答：到底有多小才算太小？

答案总是很棘手，而且可能令人失望：这取决于。

给定系统中微服务的正确规模取决于公司的结构以及创建易于由一小群开发人员管理的软件组件的能力。这也取决于技术需求。

想象一个接收和处理银行文件的系统；您可能知道，银行之间的所有付款都以特定已知格式的文件发送（例如 Single Euro Payments Area（SEPA) 用于欧元支付）。这种类型的系统的特点之一是大量不同的文件系统需要知道如何处理。

解决此问题的第一种方法是从微服务的角度解决它，将其与任何其他服务分开，创建一个工作单元，并为每种类型的文件创建一个微服务。它将使我们能够在不干扰系统其余部分的情况下对现有文件处理器进行修改。它还将使我们能够 继续处理文件，即使其中一项服务遇到问题。

微服务应该尽可能小，但请记住，每个微服务都会给需要管理新服务的运营团队增加开销。尝试从可管理性、可扩展性和专业化方面回答到底有多小？这个问题。微服务应该足够小，以便在不影响系统其余部分的情况下由一个人快速管理和扩展（或缩减）；它应该只做一件事。

弹性 在维基百科中被定义为系统应对变化的能力。我喜欢将弹性视为系统从异常中正常恢复的能力 （暂时性硬件故障、意外的高网络延迟等）或压力期，一旦情况得到解决，不会影响系统的性能。

虽然听起来很简单，但在构建面向微服务的软件时，由于系统的分布式特性，问题的根源扩大了，有时很难（甚至不可能）防止所有异常情况。

弹性是从错误中优雅恢复的能力。它还增加了另一个 级别的复杂性：如果一个微服务遇到问题，我们能否防止出现一般故障？理想情况下，我们应该以降低服务响应而不是导致一般故障的方式构建我们的系统，尽管这并不总是那么容易。

如今，公司中 的常见问题之一是系统的 可扩展性。如果您之前从事过单体软件的工作，我相信您在某个时候遇到过容量问题，以及公司的发展。

通常，这些问题不会跨越应用程序的所有层或子系统。总是有一个子系统或服务的执行速度明显慢于其他子系统，如果它无法满足需求，就会导致整个应用程序失败。

下图描述了如何在不干扰系统其余部分的情况下扩展微服务（两个邮件服务）：

如果我们的 保险系统是一个面向微服务的软件，那么唯一需要解决对报价计算的高需求将产生更多负责计算的微服务（或微服务）实例。请记住，扩展服务可能会增加运营它们的开销。

软件世界每隔几个月就会发生变化。新语言作为特定类型的事实上的标准进入行业的系统。几年前，Ruby on Rails 出现在现场，并在 2013 年成为新项目最常用的 Web 框架之一。Golang（一种由 Google 创建的语言）正在成为当今的一种趋势，因为它结合了巨大的性能和优雅而优雅的特性。任何对另一种编程语言有一定经验的人都可以在几天内学会简单的语法。

过去，我曾使用 Python 和 Java 作为编写微服务的成功替代方案。

尤其是 Java，自 Spring Boot 发布以来，它是编写敏捷（编写和操作）微服务的有吸引​​力的技术堆栈。

Django，也是一个在 Python 上编写微服务的强大框架。与 Ruby on Rails 非常相似，它可以自动化数据库迁移并创建 CRUD （创建读取更新删除）服务非常简单。

Node.js 利用一种著名的语言 JavaScript 创建了一个新的服务器端堆栈，该堆栈正在改变工程师创建新软件的方式。

那么，将它们全部组合起来有什么问题呢？平心而论，这是一个优势：我们可以为正确的工作选择正确的工具。

只要集成技术是标准的，面向微服务的架构就可以做到这一点。正如您之前所了解的，微服务是可以自行运行的小型独立软件。

下图显示了微服务如何隐藏数据存储/收集，只有公共通信点——使它们成为低耦合的一个很好的例子（一个服务实现更改不会干扰任何其他服务）：

我们之前谈到了性能。 我们系统的某些部分总是比其他部分承受更大的压力。使用现代多核 CPU，并行（并发）编程可以解决其中一些性能问题，但是，Node.js 并不是一种用于并行化任务的好语言。我们可以选择在压力下使用更合适的语言（例如 Erlang）重写微服务，以更优雅的方式管理并发。完成它应该不超过两周。

在同一系统上使用多种技术有一个缺点：开发人员和系统管理员需要了解所有（或少数）技术。采用微服务的公司通常会尝试使用一种核心技术（在本书中，我们将使用 Node.js）和一些辅助技术（虽然我们将使用 Docker 来管理部署，但我们可以使用 Capistrano 或 Fabricator 来管理发布）。

可替换性是在不干扰系统行为方式的情况下更改系统的一个组件的能力。

当谈到关于软件时，可替换性伴随着低耦合。我们应该以一种内部逻辑不会暴露给调用服务的方式编写我们的微服务，这样给定服务的客户端就不需要知道它是如何实现的，只需要知道接口。让我们看一下下面的例子。它是用 Java 编写的，因为我们只需要查看界面即可识别陷阱：

public interface GeoIpService {
  /**
   * Checks if an IP is in the country given by an ISO code.
   **/
  boolean isIn(String ip, String isoCode) throws SOAPFaultException;
}

乍一看，这个界面是不言自明的。它检查给定 IP 是否在给定国家/地区并抛出 SOAPFaultException，这是一个大问题。

如果我们构建使用此服务的客户端，考虑到它们的逻辑、捕获和处理 SoapFaultException，我们会将内部实现细节暴露给外部世界，并且很难替换 GeoIpService 接口。此外，我们正在创建与应用程序逻辑的一部分相关的服务这一事实表明 >有界上下文：一种高度内聚的服务或一组协同工作以实现一个目的的服务。

无论我们如何努力，人脑都不是为解决复杂问题而设计的问题。人类大脑最有效的运作模式是当时的一件事，以便我们将复杂的问题分解成更小的问题。面向微服务的架构应该遵循这种方法：所有服务应该是独立的，并通过接口交互，直到它们可以由不同的工程师组开发而无需任何交互，除了同意接口。这将使采用微服务的公司能够根据业务需求扩大或缩小工程团队，使业务能够灵活地响应需求高峰或平静期。

Seneca 是我在接下来的章节中选择的开发框架. Seneca 最吸引人的特性之一是 API 聚合。

API 聚合是一种高级技术，通过聚合不同的功能（插件、方法等）来组合接口。

让我们看一下下面的例子：

var express = require('express');
var app = express();

app.get('/sayhello', function (req, res) {
  res.send('Hello World!');
});
app.get('/saygoodbye', function(req, res) {
  res.send('Bye bye!');
});

var server = app.listen(3000, function () {
  var host = server.address().address;
  var port = server.address().port;
  console.log('App listening at http://%s:%s', host, port);
});

前面的示例使用 Express，这是一个非常流行的 Node.js 网络框架。该框架也是围绕 API 聚合技术构建的。我们来看看第四行和第七行。在这些行中，开发人员注册了两个方法，当有人点击 URL /sayhello 和 /saygoodbye获取请求。换句话说，应用程序由不同的较小且独立的实现组成，这些实现在单个接口上暴露给外部世界，在这种情况下，应用程序侦听 3000 端口。

在接下来的章节中，我将解释为什么这个属性很重要，以及在构建（和扩展）微服务时如何利用它。

JavaScript 最初被设计为一种在网络浏览器中执行的语言。对于那些工作或学习的人来说，使用 C/C++ 是非常熟悉的，这是将其作为 Web 2.0 中动态操作文档的标准采用的关键。 异步 JavaScript 和 XML (AJAX) 是 JavaScript 的导火索 增长。不同的浏览器对请求对象有不同的实现，因此开发人员很难编写跨浏览器的代码。

缺乏标准导致创建了许多框架来封装 AJAX 背后的逻辑，从而使跨浏览器脚本易于编写。

JavaScript 是一种脚本语言。它不是为面向对象而设计的，也不是为大型应用程序选择的语言，因为代码往往会变得混乱，并且很难在不同的公司之间强制执行代码应该如何布局的标准。我工作过的每一家公司都有不同的最佳实践和其中的一些甚至是矛盾的。

欧洲计算机制造商协会（ECMA）前来救援。 ECMAScript 6，ECMA 语言（JavaScript、ActionScript、 Rhino 等）引入了类、继承、集合的概念，以及许多有趣的特性，这些特性将使 JavaScript 软件的开发比实际的 V8 规范更容易和更标准。

我认为其中一个更有趣的功能是引入了 class 关键字，它允许我们使用对象对 JavaScript 软件进行建模。

目前，大多数浏览器都支持大量这些功能，但对于 Node.js，只有少数是默认实现的，其中一些是通过向解释器传递特殊标志（和谐标志）来实现的。 ）。

在本书中，我将尽量避免 ECMAScript 6 的特性，坚持大多数开发人员都广为人知的 V8 规范，一旦有人了解 JavaScript V8，就很容易在 ECMAScript 6 上升级。