都在说微服务,那么微服务的反模式和陷阱是什么(一) http://www.jianshu.com/p/3986239138fe
都在说微服务,那么微服务的反模式和陷阱是什么(二) http://www.jianshu.com/p/c76f7f234a31
九、通信协议使用的陷阱
在微服务架构体系中要求每个服务都是独立布署,这就意味着服务之间会有通信,也就是说会有很多的远程访问。
当你不知道这些远程访问需要多长时间的时候,就会掉入到这个陷阱,当然我们可以假定远程访问一次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