如何支撑DevOps微服务

本文作者Kevin Dunne是QASymphony公司战略和业务开发的副总裁，曾在Deloitte负责管理大型政府和五百强在定制软件开发方面的测试工作。本文中，作者通过DevOps Microservices的介绍，进一步分析其优缺点和适用性，并在解决其复杂性方面为大家提供多种思路。

以下为译文

当下，市面上存在各种可集成到开发流程中的“最佳工具”，从而只要适当的编码就可以通过微服务来支撑业务。但万事过犹不及，以下向大家介绍如何在适当的时机使用微服务。

目前，微服务正风靡一时：使用微小的应用集成应用程序可以非常方便地进行更新。微服务像胶水，在DevOps自动流程中将处理和系统合并。采用微服务意味着更快更自动化的周期，更好地实现持续交付，同时有助于提高DevOps流程和部署的可见性。

对于开发和测试工作者来说，他们往往喜欢采用更适合某种工作的“最佳工具”，微服务允许开发者在DevOps流水线中使用各种不同的开源和商业工具，更好地满足需求。另一方面，也存在一些工具会内置集成这些工具，但这些集成并不能完全适应于用户需求。如果要求供应商根据需求重新定制集成工具则会出现成本过高，同时可能无法在规定时间内实现。

所以，开发团队不妨利用微服务灵活地构建自己的工具包，并可以整合所有用于提高开发过程可见性的产品。与此同时，相对于传统APIs，REST API能非常容易地适用于各种开发需求；无需任何关于该产品的专业知识，开发者便可以轻松编写微服务。以上只是众多微服务方式强大优势中的一部分。

不过，在享受这些优势时，用户同样需要注意以下几点：

1. 难以驾驭。微服务依赖于提供者的API，当这些API改变时，服务将会中断。然后必须从头开始重建服务。所以需要你腾出手来，开始这项耗时的工作：编写并完善代码。在成百上千微服务的环境下，开发者们会花费着大量时间来更新DevOps流水线上的那些恼火的小应用，而没时间开发新的用户功能。所以，这会导致成本和时间的增加。

2. 草率处理。在为团队写微服务时，任何人都想尽可能快地交差，所以会跳过一些步骤导致微服务脆弱不堪。鉴于所编写的微服务会面对成百上千的用户，因此它必须是坚强稳固的。通过微服务整合内部方法可能更容易遭到破坏。一旦某个服务出现故障，不可避免地会给其他集成点造成多米诺效应，导致开发过程的中断。

为了解决以上问题，不妨采用以下有效措施。首先，确保你已经采取了更实惠的方式。是否开发微服务的整合策略比提供的服务更为便宜（需考虑员工时间）。如果成本不是主要的考虑因素，那么开发一个定制的DevOps工具包的好处远远大于复杂性问题，包括服务中断的宕机风险。相对于供应商不够完善的集成来说，定制集成是否有更明确的好处？在选择微服务之前，必须结合商业利益及诸多方面进行细节分析。

以下方法可以进一步降低微服务的复杂性：

混合型：在大多数情况下，很多企业觉得供应商集成和微服务结合往往是更好的选择。

外包：对于关键业务的应用，让外包开发公司帮助你处理微服务部分，这不失为一种好主意。这种方式既可以降低你的风险，还能解放你的开发者，让他们专注于构建产品而不用纠结于管理集成。

工具和语言：选择与REST API有较好适用性的语言来编写微服务，比如Python和Ruby。同时，密切留意可以帮助公司工作的内部工具，如Zapier或Tasktop。当公司扩大微服务和容器的使用范围，进一步优化其DevOps操作时，我们期待这些自动选项会不断增加。

原文链接：How to Handle DevOps Microservices（责编/仲浩）