微服务给DevOps带来了什么?


一些企业总是避开定期投资架构解耦和现代化技术,因此现在无法摆脱巨大的产品架构,使得发布变成无法预测。

一个庞大僵化的系统就像个“泥石流”,滚下山坡,越滚越大。下面就是这个庞然大物的缺点:
  1. 如果当系统笨重时,密密麻麻的数据准备生产,某物崩溃的概率会高于假如它是个更易于管理的规模。
  2. 考虑到整体的密度,大团队都有责任,有时候跨越多个团队。分担责任有时候意味着没人负责。
  3. 更糟的是,这个庞然大物每次要变更时都需要经过构建、打包和测试这些步骤,即使是个微小的变更,且它只占整个整体的一小部分。


如果这个庞然大物面临一个需要紧急修复的生产问题,它可能不会给团队带来安心,因为他们知道,固定版本的相同巨石已经开始慢慢地滚下同样危险的山丘。如果第一个补丁不起作用,我们会回到起点, 一部分、二部分、三部分,然后重复,直到产品按照预期执行。听起来很糟是吧?它的确是。

进入微服务和DevOps

没有一个玩笑能够概括全球所有不同科技公司的意图。然而却有一个普遍的真理。


全世界的所有组织都试图频繁地发布高质量的产品,来提高客户的满意度。
作为Atlassian Bitbucket的开发人员,我非常熟悉这个事实,因为我们的目标是帮助各地的技术组织更快地交付更好的软件。这就是为什么我们不断改进产品,并在我们的套件中增加新选项——提供工具,让它更容易、有效地交付高质量的产品。

在这方面,我们将回顾以下内容:
  • DevOps Microservices好处
  • 它们的共存如何提高产品发布的速度、质量和可预测性。


1. 微服务架构和DevOps允许分散开的团队控制他们自己的命运

集中允许一组人在技术堆栈、工具和标准上做决定,而其余的组织必须遵守这些决策。虽然这听起来像是个新方法来减少重复和成本,但它可能导致沉闷和成员士气低落。为了促进创新,我们必须授权小团队以自己的速度进行创新,并控制自己的命运。

微服务架构就是关于把一件事做好,从设计一个由许多“服务”集中到一个的庞然大物中,这是一种范式转变。对庞大系统的扼杀催生了更小的微服务,并加速了庞大笨重团队的瓦解,研发变成了多个更小(更灵活)的团队。

由于微服务是围绕独立业务功能组织的,所以可以用不同的编程语言进行开发。这里的关键概念是建立定义良好的、清晰的接口,接口决定了这些模块化的多语言服务之间的交互。这样可以让较小的团队自由选择自己的标准和成功指标,同时也满足了组织KPI。接口决定了服务(以及团队)如何交互,从而让架构决定组织,而不是反过来。这也是康威定律的精髓所在:


"Any organization that designs a system (defined broadly) will produce
a design whose structure is a copy of the organization's communication
structure."
此外,权力分散也正好符合DevOps的核心原则,缩小了两者之间的差距:
  1. UI、中间层和后台专家,他们倾向于在自己的筒仓中操作。
  2. 业务、产品管理、开发、QA、发布、安全、运营,以及其他成员,这些人都倾向于在自己的部门工作。


最重要的是,微服务架构和DevOps都支持产品模型和项目模型,即5-7个成员团队设计、构建、测试、发布、监控和维护他们在开发/测试、阶段和生产上的应用。

2. 区分开的服务可以作为独立的、可展开的构件发布

大多数组织都倾注于设计和实施有弹性的持续交付管道,这可以帮助他们:
  1. 在一个安全的、受保护的和可审计的方式下测试新功能
  2. 很快从失败中恢复,而不去影响客户


如果系统是由多个子系统组成,并且只能作为一个整体来发布,“一个链条的强度由它最薄弱的一环决定”,这听起来很老套。相反,微服务架构本质上是一套具有清晰边界的服务。通常,每个微服务都转换成一个可独立部署的(版本化)构件,生成一个线性管道结构。每个模块服务都是围绕一个业务功能组织的,它可以(也应该)独立发布,来提高开发人员的生产力和团队速度。这些区分开的(或组件化的)服务并不是为了成功和让更快的团队能够领先于较慢的团队而绑在他们后面。

尽管整体架构模式是成功的,但微服务提供的模块性使发布能够快速地以增量的方式进行。DevOps也支持小批量的规模,并允许小型团队拥有服务并将其交付。

然而,我们再次看到,微服务和DevOps在和谐地发挥作用,以帮助组织扩大规模。

3.微服务和DevOps提高了测试周期,并且加速推向市场

一些组织常常面临激烈的竞争,或者至少是保持不掉队。他们想建立可持续的商业模式,这样就可以让新想法迅速付诸实践,而不会消磨团队精力。然而,用庞大僵化的系统来实现这一目标是有可能的,但与颗粒状的微服务相比,可能性要小得多。下面就是原因。

一个庞然的系统经常导致一场“庞大测试”:
  • 系统在重要的一段时间内被设计和实施,在此期间团队成员可能多次改动。
  • 可能不允许单独测试,因为测试用例、设计测试数据和测试配置没有被设计用来独立执行。
  • 由于添加新的测试用例,每个新版本就越来越大。有时候,即使是在生产中不常用的功能,也会有缓慢的、归档的过期测试。在测试存档过程中可能存在不确定性,因为可能没有一个人完全理解系统架构。


所有相关的或其他的测试,在系统每次变更的过程中执行,以确保密集的功能不会在不经意间退化。这将组织的测试周期时间以指数性的增加,测试执行时间决定是否进行释放或中止。测试周期时间与功能生成时间成正比,就是发布一个功能到生产所需的时间。反过来,这又为新的业务功能发布到市场增加时间,这让组织容易受到干扰。

颗粒度的微服务通过独立的、可部署版本的构建被发布到生产中,这些构件分别被验证。微服务相互作用,提供特定的客户用例,因此需要智能集成测试。在集成测试期间,这些邻近的服务中有一些是由它们的测试替身和清晰定义的合约来表示的。测试替身和合约应该被重视,并且应该由拥有、交付和维护真实服务和接口的小团队拥有。

底线是:我们应该避免一个高度集成的验证环境,在这个环境中,所有的子系统都集成到一个系统或几个小型系统中,然后作为一个整体进行验证和发布。DevOps提倡小规模和增量的批量大小,而微服务架构帮助我们以一种细粒度的方式开发、测试和发布服务。它避免了组合(或组装)模式,并为单独的变更执行选择测试套件,而不是采用全或无方法。

总结

微服务和DevOps关键的结论是:

1.它们是相辅相成的
2.现场试验
3.促进采用

如果组织被迫选择其中一个,或如果它们在某种程度上有不一致的话,那将非常可惜。此外,微服务架构和DevOps简化了软件的交付方法,如持续交付和持续部署,并帮助生成可伸缩的交付管道。

0 个评论

要回复文章请先登录注册