（译）面向性能的微服务

   <p> </p>    <p>摘要：从性能响应延迟的角度解读微服务带来的影响，并提出了几个保证服务低延迟的建议。</p>    <h2>概述</h2>    <p>微服务是目前的一个热门词汇。它是原创的还是基于最佳实践产生的？虽然在实施微服务的过程中有一些缺点，但这些缺点能被克服么？</p>    <h2>组件可测试性和稳定性</h2>    <p>一旦你组装好了一个大系统，那么几乎不可能监测到系统的最大延迟来自哪里。你可以监测到平均的延迟和吞吐量，但为了达到稳定的延迟，需要去分析系统的关键部分。这正是一个由简单组件构成并且可以独立运行和测试的系统可以帮到你的地方，它能帮你实现系统端到端的延迟稳定性。</p>    <h2>UNIX 哲学</h2>    <p>微服务中的许多关键概念已经在分布式系统中使用多年了。</p>    <p>它与 <a href="/misc/goto?guid=4959671228030938088" rel="nofollow,noindex">Unix哲学</a> 有很多共同之处。</p>    <p>引用 <a href="/misc/goto?guid=4959671228118390027" rel="nofollow,noindex">Mike Gancarz</a> 总结的这些原则，如下所示：</p>    <ul>     <li>小即是美。</li>     <li>一个程序只做好一件事。</li>     <li>尽可能早地创建原型</li>     <li>可移植性比效率更重要。</li>     <li>数据应该保存为文本文件。</li>     <li>尽可能地榨取软件的全部价值。</li>     <li>使用shell脚本来提高效率和可移植性。</li>     <li>避免使用可定制性低下的用户界面。</li>     <li>所有程序都是数据的过滤器。</li>    </ul>    <p><a href="/misc/goto?guid=4959671228213089942" rel="nofollow,noindex">微服务</a> 即是把UNIX哲学应用到分布式系统。</p>    <p>微服务架构哲学与UNIX哲学中“一次做好一件事”本质上是相同的。它描述如下：</p>    <ul>     <li>服务小且细粒度的，完成单一功能。</li>     <li>企业文化应拥抱部署和测试自动化。这减轻了管理与运维负担。</li>     <li>文化和设计原则应接受失败和错误，类似于高容错性系统。</li>     <li>每个服务都是有弹性的，易恢复的，可组合的，最小化且完备的。</li>    </ul>    <p>使用微服务架构有一些 <a href="/misc/goto?guid=4959671228286178296" rel="nofollow,noindex">缺点</a> ：</p>    <ul>     <li>服务带来信息屏障。</li>     <li>该架构引入了额外的复杂性和需要处理的新问题，如网络延迟、消息格式、负载均衡和容错，忽略其中任何一点都属于对“分布式计算的误解”。</li>     <li>测试和部署变得更复杂了。</li>     <li>单体应用的复杂性仅仅转移到了服务的网状分布中，但是依然存在。</li>     <li>过于细粒度的微服务已经被批评是反模式。</li>    </ul>    <p>我们能得到单体应用和微服务都有的最佳特性吗？还是只能二选一？难道我们不该使用最适合我们问题的方法么？微服务的关键方面之一是控制应用的部署。在哪些情况下，我们应该把一个组件部署为一个单体应用或微服务，这样做最有意义。</p>    <p>对于超微服务的建议替代方案包括：</p>    <ul>     <li>将功能打包为一个库而非服务。</li>     <li>和其他功能组合产生一个更有实质意义和有用的服务。</li>     <li>重构系统，将功能放在其他服务里或者重新设计系统。</li>    </ul>    <h2>我们怎样才能两全其美？让组件可组合</h2>    <p>如果你的组件是可组合的，那么其大小就总是合适的。你可以按需把它们组合成一个服务集，或者全部组成一个服务。</p>    <p>这点对于测试和调试特别重要。你需要知道一组组件在隔离基础设施的情况下如何协同工作。为方便单元测试，你可能想要让所有组件运行在一个线程里并且可以直接相互调用。这样的测试不会比测试单体应用组件更复杂，你可以单步调试你的代码，从一个组件到另一个组件看看到底发生了什么。</p>    <p>一旦你的组件在没有基础设施的情况下协作正常，接下来需要测试它们如何和基础设施协同。</p>    <h2>让你的基础设施符合应用对性能的需求</h2>    <p>低延迟交易系统是一种分布式系统，并且它们也有非常严格的延迟需求。大多数交易系统被设计为高度延迟敏感的，它对速度的要求远超你所能直接看见的。在Java领域，一个交易系统要求99%甚或99.9%的耗时低于100微秒的情况并不少见。这可以使用像Java这样的高级语言在商用硬件上实现。</p>    <p>实现低延迟的关键是：</p>    <ul>     <li>用于消息和日志的低延迟基础设施。理想情况下，对于短消息大约1微秒。</li>     <li>最小网络跳数。</li>     <li>一个高水平的真实生产负载再现能力，这样你就能研究99%（最差的1%）或99.9%（最差的0.1%）的延迟情况。</li>     <li>将每个CPU核心视为运行一个特定的任务或服务，并使用它自己的缓存数据和代码。焦点在于应用在CPU核心间的分布（而非计算机之间）。</li>    </ul>    <p>你的二级高速缓存一致性总线是高性能服务之间的消息通道。</p>    <p><img src="https://simg.open-open.com/show/c70f8ef1d78e25c29ba9561db359f758.jpg"></p>    <p>你可以在两个不同的CPU核上对同样的数据执行CAS操作，这样一个线程可以很快感知到由其他线程设置的值，其往返时间在Sandy Bridge的处理器上不超过50纳秒，而在新一代型号上会更短。</p>    <p>Java领域中低延迟的基础设施的例子</p>    <ul>     <li><a href="/misc/goto?guid=4959646064477733394" rel="nofollow,noindex">Aeron</a> 一个可靠的UDP传输组件。</li>     <li><a href="/misc/goto?guid=4959618011071857063" rel="nofollow,noindex">Chronicle Queue</a> 一个用于消息和日志的持久化队列。</li>    </ul>    <p>这些传输组件在处理负载均衡和故障转移方面有各有不同的优势。</p>    <h2>使消息格式可配置</h2>    <p>对于消息格式有许多互相矛盾的考量。你想要：</p>    <ul>     <li>对人友好易读，以便你可以验证消息不止表现正常，而且行为符合你的期望。我常常感到惊讶能从导出的存储文件和消息日志中发现了如此多的问题。</li>     <li>对机器友好的高效二进制格式。</li>     <li>schema改变的灵活性。灵活性意味着增加冗余，所以软件可以应对未来的字段新增、删除和数据类型变化。如果你不需要这些，这种冗余就是浪费。</li>    </ul>    <p>理想情况下，你可以在测试或部署时选择最佳选项。</p>    <p>一些能让你写时改变格式并适合你需求的序列化库的例子有：</p>    <ul>     <li><a href="/misc/goto?guid=4958874683079507013" rel="nofollow,noindex">Jackson Speaming API</a> 支持JSON、XML、CSV、CBOR（一种二进制格式）。</li>     <li><a href="/misc/goto?guid=4959671228463806204" rel="nofollow,noindex">Chronicle Wire</a> 支持将对象序列化为YAML，还有许多不同形式的二进制YAML、JSON、CSV、原始数据。</li>    </ul>    <p>我发现 <a href="/misc/goto?guid=4959671228549262826" rel="nofollow,noindex">YAML</a> 相比JSON更好用，它的语法设计更简洁而且易读。不像JSON是另一门语言的子集，它对数据类型、注释、二进制内容和消息分隔符的支持很自然。</p>    <h2>总结</h2>    <p>我觉得有很多关于如何使用微服务的好想法，而很多围绕它们的批评是针对该如何去实施落地的，然而我相信这些问题都是可以解决的。</p>    <p>来自： <a href="/misc/goto?guid=4959671228631237704" rel="nofollow">http://mindwind.me/blog/2016/04/18/译-面向性能的微服务.html</a></p>