如何借助 Tekton 实现微服务的 Pipeline 作者|AlexSoto译者|张卫滨策划

作者|AlexSoto
译者|张卫滨
策划|丁晓昀
在微服务架构中，应用程序是由多个相互连接的服务组成的，这些服务协同工作以实现所需的业务功能。所以，一个典型的企业级微服务架构如下所示：

文章图片
最初，我们可能认为使用微服务架构实现一个应用程序是很容易的事情。但是，要恰当地完成这一点并不容易，因为我们会面临一些新的挑战，而这些挑战是单体架构所未曾遇到的。举例来讲，这样的挑战包括容错、服务发现、扩展性、日志和跟踪等。
为了应对这些挑战，每个微服务都需要实现在RedHat被称为“微服务特性（microservicility）”的内容。这个术语指的是除了业务逻辑之外，服务必须要实现的一个横切性关注点的列表。
这些关注点总结起来如下图所示：

文章图片
在本系列的第一部分和第二部分中，我们分别讨论了如何使用Quarkus和Istio实现这些微服务特性。但是，还有一个微服务特性是我们在这两篇文章中都没有涉及到的，那就是Pipeline 。
在微服务架构中，我们应该能够独立地部署服务，而不需要任何的部署编排（orchestration）。在服务间没有任何的编排意味着没有必要在每次部署的时候都部署和发布整个应用程序，只需要其中的很小一部分就可以了。
如果我们能够发布应用中各个小的组成部分的话，那么这会带来一些好处：
减少在应用中引入破坏性变更的几率。
如果出现错误的话，更容易部署和回滚。
我们可以增加部署至生产环境的频率。
出于这样的原因，每个服务应该都有自己部署Pipeline ，这样的话，我们就可以随时部署它，只需要遵循它自己的规则或流程即可。

文章图片
但是，为每个服务都创建一个部署Pipeline会带来一些挑战，这是我们需要解决的：
如何实现和管理多个Pipeline 。
如何为所有的服务实现自动部署。
如何跨服务共享Pipeline中的某些组成部分，同时又保持这些Pipeline的独立性。
如何在云环境中执行它们。
大多数问题的答案就是Pipeline即代码（pipeline-as-code）。这种技术能够允许我们以代码或可视为代码的文件（YAML）的形式创建持续交付Pipeline 。
因为Pipeline是以代码的形式定义的，所以它们应该置于源码控制之下，这意味着它们是可以重用、可以建立分支也可以创建tag 。更重要的是，我们能够将服务代码和交付Pipeline添加到相同的仓库中。
Kubernetes正在成为部署微服务的事实标准工具。它是一个开源的系统，用来自动化、编排、扩展和管理容器。
正如我们在前面的两篇文章中所讲到的那样，在我们提到的十个微服务特性中，通过使用Kubernetes能够覆盖其中的三个。

文章图片
如果我们使用Istio ，可以实现另外五个微服务特性，即服务发现、回弹性、认证、监控和跟踪。

文章图片
使用Kubernetes和Istio是个好主意，但是Pipeline该怎么实现呢？我们该如何实现一个Kubernetes原生的持续交付Pipeline呢？引入Tekton是一个可行的解决方案。
1
Tekton
Tekton是一个Kubernetes原生的构建CI/CDPipeline的解决方案，能够以Kubernetes扩展的方式安装和运行。它提供了一组Kubernetes自定义资源（customresource），借助这些自定义资源，我们可以为Pipeline创建和重用构建块。