专访 Rafael Schloming：用于微服务开发人员的工作流程和部署模式

关键要点

• 对于转变为微服务本身，人们实际上并不怎么关心他们真正关心的是提升特性的完成速度。为了让很多人应对一个问题，你需要把他们分成团队，因为人们不能在非常大的群体中有效地沟通。
• 你可以将你的人组织成独立的、跨职能的、自给自足的特性团队，从头到尾都可以自主掌控一个完整的特性。如果你这样做，最终会打破这个庞大的整体过程，这是特性完成速度的控制因素。
• 任何复杂的微服务系统都不能完成在本地进行实例化，因此托管的开发平台必须提供开发人员隔离和开发人员驱动的实时部署。
• 像 Envoy 这样的服务 (mesh) 代理就是种好方法，它通过智能路由实现开发人员隔离，它还可以使用像金丝雀发布这样的技术来提供开发人员驱动的部署。像 Istio 和 Ambassador API 网关这样的项目针对 Envoy 提供了一个用户友好的控制计划。

InfoQ 最近与 Datawire 的技术总监和首席架构师 Rafael Schloming 坐下来，讨论了现代软件驱动组织所面临的挑战。虽然微服务的实现通常只是希望通过应用程序分解和解耦来提高速度，但是也有固有的开发人员工作流和部署需求得去满足。Schloming 在这里进一步阐述了这一点，并讨论了 Kubernetes 和 Envoy 服务代理 (与 Istio 和 Ambassador 一起) 如何能够满足这一需求。

InfoQ: 你最近的 QCon San Francisco 提出的一个关键前提是，组织如果要从单体大型应用转变为基于微服务的体系结构就得要打破它们的庞大的整体流程。你能再进一步解释一下吗?

Rafael Schloming: 对于转变为微服务本身，人们实际上并不怎么关心，他们真正关心的是提升特性的完成速度。为了提升特征的完成速度就必需做出改变，而微服务只是这种改变所产生的一个附属物罢了。

对于组织来说非常常见的一种情况是，当他们发展到一个临界点，增加再多的人也不会提升特性的完成速度。当这种情况发生时，通常是因为组织用于产出特性的结构和 / 或过程成为了瓶颈，而不是人员的数量。

当一个组织遇到这种障碍，开始调查为什么这些特性似乎花费的时间远远超出了合理的资源，答案往往是，每个特性都需要太多不同团队的协调。

这会发生在两个不同的维度上。你的人员可以按职能划分为团队：产品与开发、质保与运维。你的人员也可以按组件划分: 例如，前端与领域模型、搜索索引和消息通知。当单个特性需要跨多个不同的团队进行协调时，交付特性的控制因素是不同团队之间的沟通速度和效率。像这样组织结构的组织实际上是被一个庞大的整体过程所阻碍的，这个过程要求每个特性 (在某种程度上) 要有许多许多的组织来理解它。

InfoQ: 那么如何解决这个问题呢?

Schloming: 为了把很多人用在一个问题上，你需要把他们分成团队，因为人们不能在非常大的群体中有效地沟通。你这么做的时候，其实就是在做出一系列的权衡。你所营造的是每支团队内部具有高保真的沟通和协调，而团队之间是低保真和相对较差的协调。

为改进一个组织内的特性完成速度，您可以将你的人组织成独立的、跨职能的、自给自足的特性团队，可以从头到尾自主掌控一个完整的特性。这将以两种方式提高特性的完成速度。首先，由于不同的职能 (产品、开发、质保和运维) 都圈定于一个特性内，你就可以自定义该特性区域的流程了，例如，对于一个没有人正在使用的新特性，你的流程就不需要优先考虑其稳定性了。其次，由于该特性所需的所有组件都由同一个团队拥有，因此，要想赶紧推出一个特性，就可以进行更快速有效的沟通和协调。

当你这样做的时候，你最终会打破这个庞大的整体过程，这是特性速度的控制因素，你创建了许多更小的过程，由你的独立的特性团队自己掌控。应运而生的是，这些独立团队会将其特性作为微服务交付。实际上，它是伴生而来的，这一点很重要。那些希望从微服务中直接获益的组织，如果不理解这些原则，就会导致许多小型组件团队的出现，并使他们的沟通问题恶化，从而加剧他们的问题。

InfoQ: 你曾提到，应用要经过原型、生产和关键任务这三个开发阶段，你能否解释一下它与这三个阶段的关系?

Schloming: 每个阶段代表了稳定和速度之间的不同的权衡。这反过来又会影响你如何最佳地执行交付特性所需的不同类型的活动: 产品、开发、质保和运维。

在原型开发阶段，人们非常重视在用户面前快速添加功能，而且由于没有现有用户，所以对稳定性的需求相对较小。在生产阶段，你通常要平衡稳定性和速度。你希望添加足够的特性来增加用户基数，但是你也需要足够稳定的东西来保持现有用户的满意度。在关键任务阶段，稳定是你的首要目标。

如果你的组织中的人员按照产品、开发、质保和运维这些边界来进行划分，那么就很难针对单个特性调整应用到每个活动的资源数量。这可以表现为，因为将新特性当成关键任务特性而遵循同样的过程，使新特性的进度变慢，或者，为了适应更快地发布新特性而频繁中断关键任务特性。

通过将你的人员组织成独立的特性团队，你可以使每个团队找到理想的稳定性和速度的折衷点，以实现其目标，而不需要为整个组织强制一个全局的折衷点。

InfoQ: 那次讨论中的另一个关键前提是，构建微服务的团队必须是跨职能的，并且能够以自助服务的形式访问部署机制，以及相应的平台属性，如监视、日志记录等。你能详述一下吗?

Schloming: 这里实际存在两个不同的因素。首先，如果你的团队拥有一个完整的特性，那么你们就得精于这个特性中的所有组件，从前端到后端，以及介乎之间的所有东西。第二，如果你的团队拥有从生产以运维的整个生命周期，那么你们就得精于与这些活动相关的所有不同的工程学，而不仅仅是支开发团队。

当然，这需要许多的专家，所以如何又使团队保持较小的规模呢？你需要找到一种方法，使你的特性团队能够利用组织中其他团队的工作成果，而不需要团队之间的沟通途径，从而进入特性开发的关键路径。这就是自助服务基础设施发挥作用的地方。通过提供一个自服务平台，特性团队可以从平台团队的工作中获益，而不需要打申请等别人照章行事。

InfoQ: 什么样的工具可以帮助实现自服务的部署，也可以对平台有所帮助?

Schloming: Kubernetes 为这类事情提供了一些伟大的原语——例如，你可以使用名称空间和配额使独立的团队能够在单个集群中安全地共存。然而，随着系统复杂度的增加，保持高效的开发工作流程是一个更大的挑战。作为开发人员，你的生产力很大程度上取决于你从运行的代码中获得反馈的速度。

单体大型应用通常只有数得过来的几个组件，你可以手动将它们连接到一起，在本地运行必要的系统，在开发过程中，你可以从运行的代码中得到快速的反馈。如果使用微服务，很快你就会发现走不下去了。这意味着，除了能够在生产中运行所有服务之外，你的平台还需要为开发人员提供一个高效的开发环境。这可归结为两个问题:

1. 开发者隔离: 由于许多服务都在积极开发中，所以你不能让所有开发人员共享一个开发集群，否则所有的东西都会随时被中断。你的平台需要能够为纯粹的开发目的提供部分或全部系统的隔离副本。
2. 开发人员 / 实时部署: 一旦你能访问系统的独立副本了，就需要想个方法，使你指尖新鲜出炉的代码能够尽快地与系统的其余部分一齐运行。从物理上讲，这就是一次部署，因为你其实就是在获取源代码，然后在一个生产副本上运行它。

虽然在其他一些重要方面这有着非常大的不同。如果你部署的生产环境要遵循严格的政策和周密的程序: 例如，得经过测试、金丝雀部署, 等等。而针对这些开发人员的部署, 可以专注于速度，不必在安全和程序上那么严格，这样可以带来巨大的生产力: 例如, 只运行上次失败过的测试, 而不是整个套件, 不需要等待 git commit 和 webhook, 等等。

InfoQ: 你能不能更深入地解释一下这些问题，以及如何解决它们?

Schloming: 对于开发人员隔离，有两种基本策略:

• 复制整个 Kubernetes 集群。
• 使用共享的 Kubernetes 集群，但是为了隔离则复制单个资源 (如 Kubernetes 服务、部署等)，然后使用请求路由访问目标的代码。

几乎任何一个系统都会发展到同时需要这两种策略的地步。

为了实现开发人员的隔离，你需要确保你的所有服务都能够进行多版本的部署，你需要一个七层路由器，再加上相当数量的胶水模块将其全部连接到基于 git 的安全高效的工作流中。对于多版本的部署，我看到人们有很多进行模板化的做法，从 sed 到 envsubst 再到更高级的工具，如 Helm ， ksonnet 和 Forge 。对于七层路由器， Envoy 是一个很好的选择，它非常容易使用，并且可以在诸如 Istio 和 Ambassador API 网关（添加更友好的控制平面）的项目中使用。

对于开发人员 / 实时部署，有两种基本策略:

• 在 Kubernetes 集群中运行你们的代码，并优化构建 / 部署时间。
• 在本地编译并运行你们的代码，然后将来自远程 Kubernetes 集群的通信路由到你们的笔记本电脑，然后再从运行于你们笔记本电脑上的代码返回到你们的远程集群。

这两种策略都可以显著提高开发人员的生产力。像 Draft 和 Forge 这样的工具都是针对第一种策略的，针对第二种策略有 kube-openvpn 和 Telepresence 之类的工具。

有一件事是肯定的，为组装成一个可行的解决方案，仍然有很多需要 DIY 的东西。

InfoQ: 你提到了像 Envoy 之类的服务网格技术的好处，可以提供在可观察性和容错方面的跨服务通信 (“东西”通信)。那么入口通信（“南北”通信）呢？在这里使用类似的技术有好处吗?

Schloming: 是的。事实上，出于性价比考虑，我首先就会把 Envoy 之类的东西部署在那儿。通过在网络边缘部署 Envoy，你就有强大的工具来度量你的用户体验到的服务质量了，这是一个在你的开发工作流程添加金丝雀发布的关键构件，对于任何生产或关键任务服务都很关键。

InfoQ: 你认为明年的 Kubernetes 生态系统会如何发展? 你提到的一些工具是否会集成到这个平台中?

Schloming: 如果看到 Envoy 和 Kubernetes 之间的深度集成我丝毫不会感到惊讶。我最希望看到的当然是稳定性。Kubernetes 和 Envoy 都是技术的基础部分。它们一起提供了一个非常灵活和强大的平台的核心部分，但你要成为能充分利用它们的专家也确实得需要花上一段时间。

我认为，在更大的生态系统方面，我们将看到更多的项目，使非专家能够利用这些工具所能提供的一些好处。

InfoQ: 你还有什么想与 InfoQ 的读者分享的吗?

Schloming: Datawire 团队正在开发一系列开源工具，以改进 Kubernetes 开发人员的体验，因此我们一直都渴望得到社区的反馈。读者可以通过我们的网站、 Twitter 或者 Gitter 和我们联系，你可以经常在技术会议上找到我们的发言。

你可以在 InfoQ 上找到 Schloming 的 QCon San Francisco 2017 “微服务：面向服务的开发”演讲视频，同时还有一个对本次演讲的总结。

关于受访者

Rafael Schloming 是 Datawire 的联合创始人和首席设计师。他是全球公认的消息传递和分布式系统专家，也是 AMQP 规范的规范作者。之前，Rafael 是 Red Hat 的首席软件工程师。

查看英文原文： Patterns for Microservice Developer Workflows and Deployment: Q&A with Rafael Schloming