微服务如何影响持续交付

作者：Tracy Ragan，CDF理事会成员

最初于medium.com发布

https://medium.com/@tracy_35812/its-more-than-just-containers-2fce4ad5832

向微服务架构发展是组织迎接未来的关键。

采用容器策略是开始现代架构之旅的好方法。但不要止步于此。当你接受了容器和Kubernetes，下一个也是最重要的一步就是转向微服务架构。微服务是种独立部署的小型功能，它将定义你的完全数字化转型。微服务使你能够编写全新一代的软件。他们使AI和ML成为可能，同时也为高度可伸缩的软件创造了一个平台，与单体解决方案相比，成本只是一个很小的部分。

如果已经将应用程序容器化，那么就可以进行下一步了。迁移到微服务架构有很多好处，并且大多数公司将在未来5年内转移到这个开发平台。这些好处并非没有挑战。任何转变都有破坏。这种破坏是受欢迎的，如果我们能够理解微服务架构与单体架构的区别和相似之处，就可以克服这种破坏。

事实上，微服务是很复杂的。它们的创建和交付与单体的实现非常不同。但是你可以这样做。作为一个集体社区，我们在过去经历了类似的大转变，例如从大型机到分布式，我们不仅生存了下来，而且茁壮成长。就像从大型机到分布式系统的转变一样，微服务扰乱了我们编写和交付代码的方式。因此，是时候进行软件开发的下一个发展了。

三个基本事实

当转向微服务时，考虑以下3个基本事实：

1. 微服务不需要传统的“构建”步骤。链接不是在CI构建步骤中完成的，而是通过API在运行时完成的。

2. 为了获得微服务的全部好处，应该在团队之间共享它们。

3. 微服务是独立部署的，可以影响多个“逻辑上的”应用程序。

CI构建

“十分钟构建”多年来一直是持续集成的战斗口号。目标是在10分钟或更少的时间内修复构建。好消息是，每个人的构建时间都将少于10分钟。坏消息是，进入CI构建步骤的配置管理和决策制定将不复存在。相反，你的构建将专注于为你的服务创建一个容器并注册它。构建完成。我们在这个过程中失去的是“逻辑上的”应用。它仍然存在，但我们不再创建一个构成完整解决方案的“完整”构建。我们只是在建造一个可重复使用的小部件。

微服务共享和领域

应该重用大多数微服务。微服务扩展表明你的总体架构没有利用微服务重用的优势。为了避免这种错误，你的微服务策略应该围绕领域驱动设计的概念进行定义。这种方法要求你后退一步，从“解决方案”的角度来看待你的组织。这些解决方案将定义需要在组织竖井之间创建和共享哪些微服务。当确定了这些解决方案，你很可能会发现，将近80%的微服务将被重用，只有20%的自定义微服务将用于任何单独的解决方案。在下面的例子中，你将看到网站A和B如何在共享的基础上自定义。

微服务分享

这种级别的代码重用对于我们满足21世纪数字转型的要求是必不可少的。我们有很多软件需要设计，而微服务重用是实现这一目标最划算的方法。

“逻辑上的”应用程序没了

微服务的好处也是其复杂性。当你丢弃应用程序构建过程时，你也丢弃了应用程序版本控制过程。对于微服务，需要一种新的方式来考虑软件配置管理和应用程序版本。虽然我们不再将应用程序作为一个整体来发布，但我们仍然在创建应用程序。银行将继续建立抵押贷款、汽车贷款和结算应用。它们只是构建方式不同而已。当我们开始转向微服务架构时，对完整的“逻辑上的”应用程序进行跟踪、版本控制和可视化的方法对于简化微服务实现是必不可少的。

总结

迁移到Kubernetes和微服务架构让你的组织面向未来。要做到这一点，你将需要重新设想你的软件开发实践来支持微服务实现。当你开始这个旅程时，请考虑丢失一个完整的应用程序构建的影响，该构建决定了一个独立的应用程序版本将如何基于作为一个整体编译和链接的代码和库进行操作。其次，检查并标识你的微服务模式，将它们定义为逻辑解决方案空间或领域。领域驱动设计是成功实现微服务的关键。没有这个，你可能会创建微型服务蔓延。最后，软件配置管理和应用程序版本控制仍然很重要。考虑跟踪微服务版本到应用程序版本的方法。你需要了解逻辑上的应用程序使用什么、影响应用程序的微服务以及跟踪所有集群中的应用程序版本差异的能力，以实现微服务所需的大规模DevOps。

关于作者

Tracy是DeployHub的首席执行官和联合创始人。DeployHub是第一个微服务管理平台，旨在促进微服务的共享、关系映射和部署。Tracy是配置管理和流水线生命周期实践方面的专家，特别关注微服务和云原生架构。她目前担任持续交付基金会（CDF）的董事会成员，并被选为总会员代表。她也是Ortelius开源项目的执行董事，该项目是DeployHub的开源核心。

http://www.deployhub.com/

http://www.ortelius.io/