这是在 Ensemble 中实现“微服务”设计的初学者指南。 “微服务”是当今流行的一个词，具有广泛的解释。我的解释是：“微服务”是一种“NoSQL 服务”。一个什么？答案在文章中。

我们了解了 SQL 和 NoSQL 数据库之间的区别。对我来说，SOA Web 服务和“微服务”之间的区别几乎相同。我将通过一个例子来解释它。

请注意，虽然这是一本初学者指南，但我假定我对数据建模、RESTful 服务和 Ensemble 有深入的技术知识。

航班预订——示例

我的例子很简单。我想为我的家人订一张机票。我使用www.skyscanner.hu ，但它可以是任何预订网站。那我该怎么办？在着陆页上，我输入了航班信息：我需要从布达佩斯到布拉格并返回的机票，10 月²⁹日起飞，11 月 1^日返回，直飞航班，经济舱四人。提交搜索表单后，我会返回可用选项。我选择一个并输入乘客详细信息、折扣计划，最后通过 PayPal 付款。直截了当。

在更详细的版本中：后台发生了什么。

n 开始预订

n 输入选择条件

n 生成匹配航班列表

n 选择航班

n 临时封号

n 输入乘客详细信息

n 根据标价应用一些折扣程序计算机票

n 切换到 PayPal 支付

n 完成预订，释放临时块

当任务是使用 SOAP Web 服务开发后端时，最常见的架构如下：

n 将有支持预订的 SOAP 服务。假设它称为 FlightBookingService。

n 该服务将有类似的方法

o 搜索——基于查询参数（出发地、目标、飞出、飞入日期、等级、乘客人数）返回航班选项列表。

o Block – 锁定特定航班的机票。它是一段时间的临时块。如果阻塞超时，阻塞自动释放。

o 分配机票 – 通过为被冻结的机票分配姓名来将机票分配给特定乘客。

o 计算价格——返回基于正常关税并应用折扣计划的全价。

o 完成预订 – 接受付款确认并使被冻结的机票有效。可选择使用电子商务软件检查付款确认。

即使在封面上它是一种面向服务的方法，实际上设计模式遵循单体编程原则。建立一个单一的服务来提供所有的方法，每个方法都有自己复杂的输入结构来处理，每个结构描述了识别数据内容的所有潜在变化和组合。在内部有一个复杂的数据模型（关系或对象）描述数据结构和关系。显然模型中必须的数据必须来自方法输入参数结构。但是，如果带有参数的数据多于模型准备的数据，那也是一个问题。例如，如果航空公司引入新服务（如机上宠物），则数据模型和服务接口都需要更改。最后我们有什么？一种僵硬的、难以扩展的、复杂的服务。当然，它仍然比将演示文稿放在同一层要好得多……但仍然：这真的是我们想要的吗？

好的。还有更好的选择吗？是的。这是作为 RESTful Web 服务实现的微服务。为什么不将微服务实现为 SOAP Web 服务？因为 SOAP 通过 WSDL/XSD 结构定义来冻结输入和输出结构。为什么不将整体服务实现为 RESTful Web 服务？因为即使输入和输出结构是灵活的，内部数据模型也是死板的。因此，我们需要灵活地定义服务接受、存储和发出的结构。是吗？还没有。还有一种压力是使服务的定义尽可能接近业务对象，并将描述对象所需的数据集最小化到绝对最小。

现在我想我可以分享我对微服务的定义。微服务管理基本的业务对象类型或资源类。定义了服务所需的最小数据集，但可以不受任何限制地扩展。最小集合由服务的功能要求决定。或者从适当的角度来看：如果执行任何功能都不需要数据，那么它就会进入扩展。在服务内部，对核心数据集的任何扩展都会被接受、存储和发出，但不会被管理。

在我们看一下如何构建我们的示例之前，让我解释一下名称“NoSQL 服务”。在多年的数据建模中，SQL（关系建模）曾经（现在仍然）占据主导地位。关系数据库使用严格的数据结构。作为对它的回答，引入了 NoSQL 概念。 NoSQL 拥有 scheme 数据的“发明”。就像 NoSQL 将数据库引擎从管理字典驱动的数据中解放出来一样，微服务将服务从管理复杂数据结构中解放出来。所以微服务是服务架构的 NoSQL。

那么我们的示例将如何构建？首先，我们需要将整体服务分解为资源类。我们将有：

n BookingSubject——可预订的东西。在我们的例子中，它将是航班上的一个座位。每个资源都有一个唯一的标识符。比如航空公司/日期/航班号/排号/座位。例如 OK/2016-10-29/361/23/D。资源的属性可以是状态（免费、临时保留、保留）和预订参考。其他任何东西都只是扩展。比如出发地、目的地、出发时间、单价、舱位、机上宠物、吸烟、餐饮选择。

n Booking – BookingSubjects 的预订。可预订主题的集合。预订有一个到期日期/时间来处理临时冻结。除此之外，它还有一个唯一的 ID 和预订项目列表。

n 人——乘客。选修的。我们在之前的一个会议中的示例是“人员”服务。是什么让一个人成为乘客？她/他有一张票。当航空公司有选择地维护个人登记时，机票可以引用登记条目。

n 机票——使用航班的授权。机票是对可预订主题和预订对象的唯一参考。因为票并不真正关心人的详细信息，票结构必须具有票所有者的明确标识。它可能只是一个名字（在航班上大多是唯一的）或护照号码（但不能同时是两者）。但是，如果航空公司出于某种原因维护人员登记，则机票可以引用登记条目。

还有一些。这种模式如何替代原来的服务？

n Search – 获取符合搜索条件的BookingSubject集合。搜索同时获取核心数据和扩展数据，并匹配高级搜索条件。返回的集合包含匹配资源的 ID。

n Block – 创建一个新的预订。将到期时间设置为floor(now+15minutes,departure time-50minutes) 。将选定的BookingSubjects添加到其中。将个人BookingSubjects状态更新为reserved 。

n 分配工单——创建新工单。制作机票参考Booking 。添加人员信息。

n Finalize booking – 将Booking expiration 更改为never 。

如果我们需要创建一个酒店预订系统怎么办？需要改变什么？什么可以重复使用？我把答案留给你。

实施模式

我认为本系列的前几篇文章在您作为初学者为 Ensemble 开发微服务时提供了一组非常有用的实现模式。

n 我们讨论了如何创建服务。

n 如何以及为什么启用 CORS 。

n 作为客户端使用服务。

n 如何将服务参数传递给服务。

n 我们还学习了处理异常。

n 以及设计服务API。

我想我们快完成了。拼图中少了一块。 “奖励部分”。

所以我最后一次说：敬请期待，我会很快回来进一步阅读 Ensemble RESTful Web 服务。接下来是“将微服务架构应用于Ensemble”。