都在说微服务,那么微服务的反模式和陷阱是什么(三)

前文导读:
《都在说微服务,那么微服务的反模式和陷阱是什么(一)》
《都在说微服务,那么微服务的反模式和陷阱是什么(二)》

九、通信协议使用的陷阱

在微服务架构体系中要求每个服务都是独立布署,这就意味着服务之间会有通信,也就是说会有很多的远程访问。

当你不知道这些远程访问需要多长时间的时候,就会掉入到这个陷阱,当然我们可以假定远程访问一次50毫秒,但我们是否真正的进行过测试呢?那么服务的平均响应时间是多少呢?即使有看上去很好的平均响应时间,那么糟糕的“长尾延迟”也会将整体系统摧毁。

9.1 延迟测量

在生产环境中进行压力测试,是检测我们系统性能的重要手段之一,举个例子:我们有一个特定业务需要四个服务来协调处理,假如远程访问一次的时间是100毫秒,那么这个特定业务就需要消耗500毫秒(初始请求+四个服务的调用时间),这个只是远程访问的时间,还不算实际业务代码的执行时间,这是大多数应用系统都不能接受的时间。

9.2 通信协议比较

不同协议的延迟响应时间其实在不同的环境中表现的差异很大,因此我们也需要在不同的业务请求下建立一些测试基准。

图9-1

从图9-1中可以看出AMQP的性能要比REST的快近一倍,可以我们就可以做出一些选择了,在什么场景下应该用什么协议,另外在选择协议时性能并不是唯一的考虑因素,在第十章将会为大家介绍除了性能还需要考虑的点是什么。

十、REST陷阱

目前使用REST协议已然成了微服务协议的最佳选择了,现在最流行的DropWizard和Spring boot就是基于REST进行通信的,那问题来了,如果REST是一个最佳选择,那为什么又说它是一个陷阱呢?如果把REST作为唯一的通讯方式,就有可能掉入这个陷阱,比如如何处理异步通讯(http 1.1是blocking的)、如何在一个事务中管理多次服务调用?如何支持广播?

你应该考虑两种类型的消息标准作为微服务架构中的消息传递:特定平台的标准和平台无关的标准。特定平台的标准比如 JMS for java、MSMQ for .net。平台无关的比如 AMQP。

使用消息系统的好处可以异步请求,还可以实现广播的方式,还可以实现事务请求。

10.1 异步请求

使用微服务架构首先要考虑的是异步通信方式,因为异步通信的调用者不需要考虑等待服务的响应时间,如图10-1所示。

图10-1

使用异步方式的好处不仅提升了整体性能,还增加了一些可靠性的因素,另外也不需要担心超时问题和在程序中设置断路器模式。

10.2 广播能力

这个最典型的就是消息的“发布-订阅”,如图10-2所示。

图10-2

10.3 事务请求

消息系统需要支持事务消息的概念,这意味着如果消息被发送到多个队列或Topic中,在发送方对该事务进行提交之前, 这些消息实际上不会被接收方所接收。服务消费者发送一个消息到第一个服务,然后发送另一个消息的第二个服务,如图10-3所示。在服务使用者执行提交之前,这些消息都保存在队列中。一旦服务使用者执行提交,两个消息就会被释放。

图10-3

在图10-3中,服务消费者将消息发送到第一个队列中,然后服务消费者业务报错, 这时可以在消息事务中进行回滚,从消息系统的队列中删除掉刚才发的消息。

使用REST实现这种事务能力就非常困难,其实就是要求服务使用者使用TCC、或者补偿方式来达到最终一致性。

结束语

关于微服务的反模式和陷阱三部曲,到现在为止已经全部翻译完成,英文文档一共60多页,这里面有不少内容大家都是耳熟能详的,关于原版的英文文档我也提供给大家做一个参考,最后感谢大家的支持和帮助。

原版文档链接如下:http://pan.baidu.com/s/1qY3Etoo 密码:l26d

本文作者:小程故事多
原文链接:http://www.jianshu.com/p/46a81ce30e9c
版权归作者所有,转载请注明出处