踢开绊脚石：微服务难点之服务调用的解决方案

微服务已经成为越来越多企业IT部门研究的对象，逐步趋向于火热，数人云之前给大家分享过：《实录|微服务企业级落地将会带来哪些转变？》深入地阐述了微服务能够带来的利益，但是作为一项新兴的技术，总难免会遇到这样或那样的难题，今天就来一起看看微服务的难点之一：服务调用的解决方案。

微服务有很多难点，比如分布式系统：

本文作者与红帽的顶级战略客户紧密合作，帮助其成功地驾驭这些困难的部分，实现服务框架以保持竞争力，根据创新去创造商业价值，作者也非常接近于开源社区中技术的快速发展。

当继续在服务架构的这些概念上进行探讨时，不可避免的会对一些难题进行讨论，作者希望在探索并实现微服务时，已经看到并消化了分布式计算的错误，同时作者也推荐了Jeff Hodges的《Notes on Distributed Systems for Young Bloods 》。

大部分一直在用过时的方法去解决这些问题，并一直在寻找“如何让开发者编写能够交付价值并尝试抽象分布式系统的业务逻辑”的解决方案。所做的事情是为了让服务调用看起来如本地调用通过抽象的网络与本地接口（CORBA、DCOM、ejb等等），但后来发现这并不是一个好方法，然后切换到WSDL/SOAP/代码生成类似的东西，以摆脱这些其他协议的脆弱性，但仍然使用相同的实践（SOAP客户机代码生成），有些人确实让这些方法奏效了，但也有很多不足之处，下面来看看当简单地调用服务时会遇到的一些问题：

• 错误或延迟
• 重试
• 路由
• 服务发现
• 可观察性

错误或延迟

当我们向服务发送消息时会发生什么？出于这个讨论的目的，这个请求被分成小块并通过网络路由。

因为这个“网络”，我们处理分布式计算错误想法，应用程序通过异步网络进行通信，这意味着对时间没有单一且统一的理解，服务以自己对“时间的含义”理解去工作，这可能与其他服务不同，更重要的是，这些异步网络路由数据包根据可用性的路径、拥堵、硬件鼓掌等，没有保证消息在有限的时间内将其接受者（注意，这个相同的现象发生在“同步”网络没有一个统一的理解时间）。

这其实很糟糕，现在不可能确定错误或只是缓慢，如果客户要求在售票网站上搜索演唱会，可不想等到天荒地老，希望能得到响应，在某个时候，