如何支撑DevOps微服务

  • 来源:DevOps.com
  •  2015-11-21
  •   浏览 583 次

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

以下为译文

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

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

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

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

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

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

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

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

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

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

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

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

原文链接: How to Handle DevOps Microservices

To Top