都在说微服务，那么微服务的反模式和陷阱是什么

Posted 2022-11-27 小程故事多_80

都在说微服务，那么微服务的反模式和陷阱是什么（一）
http://blog.csdn.net/u013970991/article/details/78079910

都在说微服务，那么微服务的反模式和陷阱是什么（二）
http://www.jianshu.com/p/c76f7f234a31

九、通信协议使用的陷阱

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

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

9.1 延迟测量

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

9.2 通信协议比较

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

从图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.2 广播能力

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

10.3 事务请求

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

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

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

结束语

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

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