微服务架构实践原则

在微服务体系架构中，多个松散耦合的服务一起工作，每个服务专注于一个目标，并与相关行为和数据保持高度内聚。其定义包括 3 条设计原则：
单一职责——每项服务都应该专注于一个目的并把它做好
松耦合服务——服务之间没有太多的联系，对一个服务的变更不应该要求更改其他服务，服务之间的通信只能通过公开的服务接口进行。
高内聚性——每个服务都将所有相关的行为和数据封装在一起，如果需要构建新功能，所有的更改都应该局限于一个服务中。

这些原则是充分利用微服务体系架构潜力的唯一途径，任意两者的缺乏都将使之成为一种反模式。如果没有一个单一的职责，每个微服务最终都会做很多事情，并成长为多个“单体”服务，因此我们没法从微服务架构中获得好处，但却需要支付运营成本。如果没有松耦合，对一个服务的更改会影响到其他服务，因此我们没法快速安全的发布变更，而这正是微服务体系架构的核心优势。更重要的是，由紧耦合引起的问题可能是灾难性的，比如数据不一致甚至数据丢失。如果没有高内聚性，我们将最终得到一个分布式的单体系统，一组混乱的服务，必须在构建单一功能的同时进行更改和部署。由于多服务协调（有时跨多个团队）的复杂性和成本，分布式单体系统通常比集中式单体系统还要差劲。

此外，微服务不是代码行更少或处理小任务的服务，只要满足了这 3 个原则，服务就可以实现复杂而重要的功能。事实上，由于我们可以直接从单体服务中提取逻辑，因此微服务并不总是采用新技术或者从头开始构建的。

在采用微服务体系架构时，我们会面临什么问题？
微服务也有可能出问题，并在实际上损害生产环境。有 7 种策略可以帮助我们：

用清晰的思路构建新的服务

单一的持久化存储是有害的

解耦“构建服务”和“运行服务”

详细一致的可观测性

注意失败

从一开始就避免“微服务综合症”

用清晰的思路构建新的服务
有人可能认为，采用新的服务端架构意味着需要长期暂停产品开发并且重写所有内容。但实际上这是一种误解，我们永远不应该为了构建新的服务而构建。每当我们建立一项新服务或采用一项新技术时，我们必须有一个清晰的产品理念或工程价值。产品价值是造福用户，与单体 Node.js 应用相比，新服务需要提供更多的价值或更好的性能。工程价值指的是使工程团队更好、更快的合作。如果构建一个既没有产品价值也没有工程价值的新服务，我们还不如仍然停留在单体应用中。

单一的持久化存储是有害的
为微服务建模只是微服务架构的一部分工作，另一大部分工作是为持久化存储的数据建模。跨服务共享持久数据存储似乎是集成微服务的最简单方法，然而，它实际上是有害的，我们应该不惜一切代价避免。首先，持久化数据存储与实现细节有关，跨服务共享数据存储将向整个系统公开服务的实现细节。如果服务更改了数据格式，或添加了缓存层，或切换到不同类型的数据库，那么其他服务也必须相应的更改，而这违反了松耦合原则。

另外，如何修改、描述和使用数据并不是一种服务行为。如果我们跨服务共享数据存储，意味着其他服务也必须复制这些服务行为，而这违反了高内聚原则，会将给定域中的行为泄露给多个服务。如果我们修改一个行为，将不得不同时修改所有这些服务。

在微服务体系架构中，只有一个服务应该负责特定类型的数据，所有其他服务都应该通过服务 API 请求数据，或者保留只读的非规范（可能是具化的）数据副本。

这听起来可能有点抽象，这里有一个具体的例子。假设我们正在构建一个新的推荐服务，需要来自发布数据表中的一些数据，该数据表目前存储在 AWS Dynamo DB 中。