是时候改变你对微服务的认知了!

2018-04-22 14:56:31 admin

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

 

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

Queries 。查询是一个请求,是一个查找一些东西的请求(request)。重要的是,查询不会使得系统状态发生改变。

 

一个简单事件驱动流程

 

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

 

支付。

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

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

 

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

 

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

 

在返回给用户之前,UI service 发布一个OrderRequested事件,然后等待OrderConfirmed(或者Rejected)。

订单服务(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)和查询(Queries)的混合

 

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

 

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

 

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

 

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

为您推荐