[译] REST？RPC？是时候改变你对微服务的认知了

大部分时候，微服务都是建立在一种基于请求和响应的协议之上。比如， REST 等。这种方式是自然的。我们只需要调用另外一个模块就是了，然后等待响应返回，然后继续。这样的方式确实也满足了我们的很多的场景：用户通过点击页面的一个按钮然后希望发生一些事情。

但是，当我们开始接触许多独立的 service 的时候，事情就发生改变了。随着 service 数量急速的增长，同步交互比例也随着 service 在急速增长。这时候，我们的 service 就会遇到很多的瓶颈。

于是，不幸的ops工程师们就被我们坑了，他们疲惫的奔波于一个又一个的service，拼凑在一起的二手信息片段，谁说了什么，去往哪里，什么时候发生？等等。。。

这是一个非常典型的问题。市面上也有一些解决方案。一种方案就是确保您的个人服务具有比您的系统更高的SLA。 Google提供了这样做的协议。另一种方法是简单地分解将服务绑定在一起的同步关系。

上面的做法都没有从模式上根本解决问题。我们可以使用异步机制来解决这个问题。比如，电商网站中你会发现这样的同步接口，比如 getImage() 或者 processOrder() ，也许你感觉蛮正常。调用了然后希望马上有一个响应。但当用户点击了“购买”后，触发了一个复杂且异步的处理过程。这个过程涉及到购买、送货上门给用户，这一切都是发生在当初的那一次的按钮点击。所以把一个程序处理逻辑切分成多个异步的处理，是我们需要解决的问题。这也正符合我们的真实的世界，真实世界本来就是异步的，拥抱异步吧。

在实际情况下，我们其实已经自动拥抱了异步了。我们发现自己会定时轮询数据库表来更改又或者通过 cron 定时 job 来实现一些更新。这些方法都是一些打破同步的方式，但是这种做法总让人感觉有种黑客范儿，感觉像是黑客行为，怪怪的。

在本文中，我们将会讨论一种完全不同的架构：不是把 service 们通过命令链揉到一块，而是通过事件流（ stream of events ）来做。这是一个不错的方式。这种方式也是我们之后要讨论的一系列的一个基础。

命 令（comm ands）、事件 （events）和查询 （queries）

当我们进入正式的例子之前，我们需要先普及三个简单的概念。一个 service 与另外一个 service 有三种交互方式：命令（Commands）、事件（Events）以及查询（Queries）。

事件的美妙之处在于“外部数据”可以被系统中的任何 service 所重用。

而且从 service 的角度来说，事件要比命令和查询都要解耦。这个很重要。

服务之间的交互有三种机制：

1. Commands  。命令是一个操作。希望在另一个服务中执行某些操作的一个请求。 会改变系统状态的东西。 命令期待有响应。

2. Events 。事件既是一个事实也是一个触发器。 发生了一些事情，表示为通知。

3. Queries 。查询是一个请求，是一个查找一些东西的请求（request）。重要的是，查询不会使得系统状态发生改变。

ps：这里注意 请求  事件 的区别。命令和查询都属于请求驱动。

一个 简单事件驱动流程

让我们开始一个简单的例子：用户购买一个小东西。那么接下来要发生两件事情：

1. 支付。

2. 系 统检查 是否 还 有更多的商品需要被 订购 。

在请求驱动（ request-approach ）的架构中，这两个行为被表现为一个命令链条。交互就像下面这样：

首先要注意的问题是“购买更多”的这个业务流程是随着订单服务（ Order Service ）一块被初始化的。这就使得责任不独立，责任跨了两个 service 。理想情况下，我们希望 separation of concerns ，也就是关注隔离。

现在如果我们使用事件驱动，而不是请求驱动的方式的话，那么事情就会变得好一些。

1. 在返回 给 用 户 之前 ，UI service  发 布一个 OrderRequested 事件，然后等待 OrderConfirmed （或者 Rejected ）。

2. 订单 服 务（ Orders Service ） 和 库 存服 务 （ Stock Service）  react 这 个事件。

仔细看这里， UI service 和 Orders Service 并没有改变很多，而是通过事件来通信，而不是直接调用另一个。

这个 Stock service （库存服务）很有趣。 Order Service 告诉他要做什么。然后 StockService 自己决定是否参与本次交互，这是事件驱动架构非常重要的属性，也就是： Reciver Driven Flow Control ，接收者驱动流程控制。一下子控制反转了。

这种控制反转给接收者，很好的解耦了服务之间的交互，这就为架构提供了可插拔性。组件们可以轻松的被插入和替换掉，优雅！

随着架构变得越来越复杂，这种可插拔性的因素变得更加重要。 举个例子，我们要添加一个实时管理定价的 service ，根据供需调整产品的价格。 在一个命令驱动的世界里，我们就需要引入一个可以由库存服务（ Stock Service ）和订单服务（ Orders Service ）调用的类似 updatePrice() 这样的方法。

但是在事件驱动（ event-driven ）世界更新价格的话， service 只需要订阅共享的 stream 就是了，当相应的条件符合时，就去执行更新价格的操作。

事件（ Events ）和查询（ Q ueries ）的混合

上面的例子只是命令和事件。并没有说到查询。别忘了，我们之前可是说到了三个概念。现在我们开始说查询。我们扩展上面的例子，让订单服务（ Orders Service ）在支付之前检查是否有足够的库存。

在请求驱动（ request-driven ）的架构中，我们可能会向库存服务（ Stock Service ）发送一个查询请求然后获取到当前的库存数量。这就导致了模型混合，事件流纯粹被用作通知，允许任何的 service 加入 flow ，但查询却是通过请求驱动的方式直接访问源。

对于服务（service）需要独立发展的较大的生态系统，远程查询要涉及到很多关联，耦合很严重，要把很多服务捆绑在一起。 我们可以通过“内部化”来避免这种涉及多个上下文交叉的查询。 而事件流可以被用于在每个 service 中缓存数据集，这样我们就可以在本地来完成查询。

所以，增加这个库存检查，订单服务（ Order Service ）可以订阅库存服务（ Stock Service ）的事件流，库存一有更新，订单服务就会收到通知，然后把更新存储到本地的数据库。这样接下来就可以查询本地这个“视图（ view ）”来检查是否有足够的库存。

纯事件驱动系统没有远程查询的概念 - 事件将状态传播到本地查询的服务

通过事件来传播（   “ Queryby Event Propagation ”）的查询有以下三个好处：

1、更好的解耦：在本地查询。这样就不涉及跨上下文调用了。这种做法涉及到的服务们远远不及那种”请求驱动”所涉及到的服务数量多。

2、更好的自治：订单服务（Order Service）拥有一份库存数据集的copy，所以订单服务可以任意使用这个本地的数据集，

而不是说像请求驱动里的那样仅仅只能检查库存限额，而且只能通过Stock Service所提供的接口。

3、高效Join：如果我们在每次下订单的时候都要去查询库存，就要求每次都要高效的做join，通过跨网络对两个service进行join。随着需求的增加，或者更多的数据源需要关联，这可能会变得越来越艰巨。所以通过事件传播来查询（Query by Event Propagation）将查询（和join）本地化后就可以解决这个问题（就是本地查询）。

但这种做法也不是没有缺点。 Service从本质上变得有状态了。这样就使得他们需要被跟踪和矫正这些数据集，随着时间的推移，也就是你得保证数据同步。状态的重复也可能使一些问题更难理解（比如如何原子地减少库存数量？），这些问题我们都要小心。但是，所有这些问题都有可行的解决方案，我们只是需要多一点考虑而已。 

单一写入者原则（ Single Writer Principl e ）

针对这种风格的系统，也就是事件驱动风格的系统，一个非常有用的原则就是针对指定类型的传播的事件分配责任的时候，应该只分配给一个单一的 service ：单一的写入者。什么意思呢？就是 Stock Service 只应该处理库存这一件事情，而 Order Service 也只属于订单们，等等。

这样的话有助于我们通过单个代码路径（尽管不一定是单个进程）来排除一致性，验证和其他 “ 写入路径（ writepath ） ” 问题。 因此，在下面的示例中，请注意，订单服务（ Order Service ）控制着对订单进行的每个状态的更改，但整个事件流跨越了订单（ Orders ），付款（ Payments ）和发货（ Shipments ），每个都由它们各自的服务来管理。

分配“事件传播”（ event propagation ）的责任很重要，因为这些不仅仅是短暂的事件，或者是那种无须保存短暂的聊天。 他们代表了共同的事实（ facts ），以及“数据在外部（ data-on-the-outside ）“。 因此，随着时间的推移，服务（ services ）需要去负责更新和同步这些共享数据集（ shared datasets ）：比如，修复错误，处理 schema 的变化等情况。

上图中每个颜色代表Kafka的一个topic，针对下订单（Order）、发货和付款。  当用户点击“购买”时，会引发“Order Requested”，等待“Order Confirmed”事件，然后再回复给用户。 另外三个服务处理与其工作流程部分相关的状态转换。 例如，付款处理完成后，订单服务（Order Service）将订单从“已验证（Validated）”推送到“已确认（Confirmed）”。

模式（ Patterns ） 和集 群服务（ Clustering Services ）的混合

上面的说到的模型有点像企业消息（ Enterprise Messaging ），但其实是有一些不同的。企业消息，在实践中，主要关注状态的转换，通过网络有效地将数据库捆绑在一起。

而事件 协作（Event Collaboration）则更偏重的是 协作，既然是协作就不简单的是状态转换，事件协作是关于服务（ service ）通过一系列事件进行一些业务目标，这些事件将触发 service 的执行。 所以这是业务处理（ business processing ）的一种模式，而不是简单的转换状态的机制。

我们通常希望在我们构建的系统中这种模式具有两面性。 事实上，这种模式的美妙之处在于它确实既可以处理微观又可以处理宏观，或者在有些情况下可以被混合。

模式组合使用也很常见。 我们可能希望提供远程查询的方便灵活性，而不是本地维护数据集的成本，特别是数据集增长时。 这样的话就会让我们的查询变得更加的简单，我们只需要轻松部署简单的函数就可以了。而且我们现在很多都是无状态的，比如容器或者浏览器，在这种情况下也许远程查询是一种合适的选择。

远程查询设计的诀窍就是限制这些查询接口的范围，理想情况下应该是在有限的上下文中（context）。通常情况下，建立一个具有多个特定，具体视图的架构，而不是单一的共享数据存储。注意是多个具体的视图，而不是单一的共享数据存储。（一个独立（bounded）的上下文，或者说是偏向原子，这里说的原子不是侧重微服务中常说的那个“原子服务”。独立上下文，一般是指有那么一组service，它们共享同一个发布流水线或者是同一个领域模型【domain model】）。

为了限制远程查询（ remote queries ）的边界（ scope ），我们可以使用一种叫做“集群式上下文模式（ clustered context pattern ）”。这种情况下，事件就流纯粹是用作上下文之间的通信。但在一个上下文里的具体 service 们则可以既有事件驱动（ event-driven ）的处理，同时也有请求驱动（ request-driven ）的视图（ view ），具体根据实际情况需要。

在下面的例子中，我们有三个部分，三个之间只通过事件相互沟通。 在每一个内部，我们使用了更细粒度的事件驱 动流。其中一些包括视图层（查询层）。

还是看下图吧：

集群上下文模型（Clustered Context Model）

事件驱动（event-driven）五个关键好处：

1. 解耦：把一个很长的同步执行链的命令给分解，异步化。 分解同步工作流。 Brokers 或topic解耦服务（service），所以更容易插入新的服务（service），具有更强的插拔性。

2. 离线/异步流：当用户点击按钮时，很多事情都会发生。 一些同步，一些异步。 对能力的设计，无论是以前的，还是将来的，都是更自由的。提高了性能，提高了自由度。

3. 状态同步更新：事件流对分布式数据集提供了一种有效的机制，数据集可以在一个有界的上下文里被重构（“传播”或“更新”）和查询。

4. Joins：从不同的服务（service）组合/join/扩展数据集更容易。 join更快速，而且还是本地化的。

5. 可追溯性: 当有一个统一化的，中心化的，不可变的，保持性的地方来记录每个互动时，它会及时展现，debug的时候也更容易定位问题，而不是陷入一场关于“分布式”的谋杀。（这里有点晦涩）

总结

Ok ，在事件驱动的方法中我们使用事件（ Events ）而不是命令（ Commands ）。 事件触发业务处理过程。 事件也可以用到更新本地视图上。 然后我们向你介绍了，在必要时，我们可以再回到远程同步查询这种方式，特别是在较小的系统中，而且我们还将远程同步查询的范围扩大到更大的范围（理想情况下，还是要仅限于单个独立的上下文，也就是单个领域模型，不能再扩大了，刚刚好才是真的好）。

而且所有这些方法都只是模式（pattern）。模式就会有框得太死的问题。模式覆盖不到的地方，我们就要具体情况具体对待了。例如，单点登录服务，全局查询的service仍然是一个好主意，因为它很少更新。

这里的秘诀就是从事件的基准出发去考虑问题。 事件让服务之间不再耦合，并且将控制（ flow-control ）权转移到接收者，这就有了更好的“分离关注（ separated concerns ）”和更好的可插拔性。

关于事件驱动方法的另一个有趣的事情是，它们对于大型，复杂的架构同样适用，就像它们对于小型，高度协作的架构一样。 事件让 service 们可以自主的决定自己的所有事情，为服务们提供自由发展所需的自主权。

然后我们向你介绍了事件和查询混合的场景。说到查询，在纯事件驱动方法中，查询完全基于本地的数据集，而没有远程查询。本地数据集则是通过事件触发来更新状态。然而，很多时候，基于请求驱动的查询方式在很多时候也是比较方便的，因为本地数据集的方式，状态的同步更新确实是一件更加需要成本的事情。

然后我们说到了单一写入z者原则。单一写入者让我们数据更新有了统一的入口，有助于我们通过单个代码路径（尽管不一定是单个进程）来排除一致性，验证和其他“写入路径（writepath）”问题。

然后我们讨论了集群上下文模型。每个领域模型组成一个独立的区域，然后再由多个区域共同组成一个领域模型集群，模型之间又通过Kafka来交互。每个领域模型里又可以包含几种模式的混合，比如Events、Views、UI，这些里边可以既有事件驱动模式，又有请求驱动模式。

大体就这么多。

感谢Antony Stubbs，Tim Berglund，Kaufman Ng，GwenShapira和Jay Kreps，他们帮助我们回顾了这篇文章。

译者曰：最近也恰好在做有关事件流的内容，对本文中讲到的异步解耦和拆解同步请求链条过长问题深有感触，也非常认同。另外最近有人聊到有关数据库查询效率问题，通过阅读本文也许会让你对查询有一个全新的认识。这些微服务理念看起来好像专属于“微服务”，好像其他人就不需要了解一样。其实也许微服务的这些先进理念就像其他任何的先进的架构理念一样，他们都是我们软件架构知识体系的储备之一，也许在哪天你正在进行的项目遇到了瓶颈，没准本文讨论的这些内容就能派上用场了，不仅仅限于本文举的那个例子。

微服务"交互方式"观念转变：

是时候更新一下你对于构建微服务的一些知识体系了。如果你认为REST就是微服务构建的主要交互方式的话，那么也许你错了；如果你认为rpc就是构建微服务的的主要交互方式的话，那么也许你又错了。

因为这两种都属于一种类型，那就是他们都属于请求驱动（request-driven）模式，而这种模式很多时候是同步的，一条链上挂了很多的服务调用，势必在链条变长后，性能堪忧。

本文向你推荐了一个构建微服务的新的工具，或者说是向你补充了。那就是事件驱动（event-driven）的模式。它解耦、异步，带来了更好的扩展性和性能。很多时候，同步会让事情变得异常糟糕！

如果以后有人和讨论起微服务的模式的时候，你可以说REST、rpc（请求驱动）以及事件驱动共同混合使用才会构建出更好的微服务来！

ps：文中部分段落翻译用词略显晦涩，我曾尝试用大白话来翻译，但发现会损失原意，故请仔细斟酌消化。