San Francisco QCon大会上，Rafael Schloming提出了“面向服务的开发”，他认为，想迁移到微服务的组织必须要寻求一种方法来打破单一的开发过程，而不仅仅是试图打破传统的系统架构。将新成立的微服务团队看作是内部的“衍生品（spinoffs）”，他们具有团队边界，并且鼓励他们自给自足和自我管理，除此之外，这些团队必须得到有效工具的支持，以便在生产中调试、部署和监测服务。

Schloming是Datawire的CTO和首席架构师，演讲开始时，他问了听众一个问题，将一个庞大的系统迁移到基于微服务的应用程序时，他们遇到的第一个难题是什么。常见的回答有：“如何分解一个大型系统？”、“如何用微服务构建我的应用程序？”以及“我需要怎么样的基础架构才能使我在微服务中受益？”。根据他2013年在Datawire开发微服务应用程序的经验，Schloming说，最重要的问题也是通常最容易被忽略的问题是“如何分解一个大型系统？”，因为开发过程对于建立和保持开发速度来说至关重要。

在开发应用程序或服务时，应用程序的交付生命周期可以划分为三个阶段：原型（prototyping）阶段、生产（production）阶段以及关键任务（mission critical）阶段。在原型阶段，维护高速的功能交付通常要容易得多，因为在这个阶段产品稳定性不那么重要。当产品交付从生产阶段转移到关键任务阶段时，为了提高稳定性往往会牺牲速度。对于应用程序中的所有组件来说，使用单一交付过程是十分低效的，因为这样做往往会导致在单一稳定性与速度间侧重点的不同（总是要牺牲其中的一项）。

以基于微服务的系统开发一个应用程序时可以使用多个流程：每个微服务产品团队都可以根据当前该过程在交付生命周期中的阶段而选择合适的流程。微服务可能是一个分布式的开发架构，但是它们也可以使用分布式的开发工作流，该工作流由各种的同步开发过程组成，并且具有不同的速度与稳定性间的侧重程度。然而，采用这种工作方式需要组织的变革以及技术的改变。

站在组织的角度来看，创建一个围绕产品开发自给自足、自治的软件团队是颇有裨益的。然而，从单一过程到微过程的转变需要训练、交流和代理（delegation）。微服务产品团队中的每个人都将经历完整的开发生命周期（从本地编码到通过持续交付将代码部署到生产，再到监测应用程序），这个过程需要额外的训练。最终，这种变化意味着专家有机会成为多面手，从而使得整体系统以及各项操作的实现更加完善。

在产品团队中，人们可能不会使用同一种语言，但是如果这种冲突处理得当的话，它会成为协作的来源。组织内的一个小团队可能把握着整个系统的重要部分，自治是一个组织在快节奏的市场环境中有效规模化的唯一方法。团队应该努力确保他们不需要依赖其他团队来实现自己的目标，这其中包括消除对中心化架构和运营团队的依赖（即使依赖一个提供自助访问架构的“平台团队”通常情况下是有好处的）。

Schloming认为，要想实现微服务的组织变革，最好的方法是把每一个产品团队都看作是一个商业衍生品。就像现有的开发团队可能会使用诸如Twilio或Stripe这样的第三方服务一样，产品团队也应该使用同样的方式与内部服务进行集成。

关于微服务的技术实现，Schloming概述了产品交付生命每个周期阶段的目标。原型阶段的目标：工具以及用户的快速反馈；生产用户以及增长（production users and growth）阶段的目标：不影响用户的前提下增加新功能；以及关键任务阶段的目标：保证稳定性。这样通常会形成一个并行的单一平台（基于微服务的）工作流，该工作流可以随着产品的成熟而转换。可以使用Docker、Kubernetes和Envoy服务代理作为底层平台组件，这个实例就展示了产品生命周期中每个阶段的技术挑战。

在原型阶段，要在生产过程中获得组织对实验性项目的投资是很有挑战性的（例如，进行A/B测试或者canarying的试验）。除此之外，从技术上来说，在本地运行微服务也是具有挑战性的。克服这一问题的策略是提供自助服务供应（provisioning）和开发容器，这些容器可以通过连续的交付流水线部署到远程环境中。Schloming给出了一个使用Datawire创建的开源工具（forge.sh和telepresence）的例子。forge.sh用于创建一个轻量级的开发环境，它是产品构建和相关依赖关系的单一数据源。telepresence用于代理远程的Kubernetes集群。通过这种方式可以使本地开发的应用程序(以及相关的调试工具)与远程服务进行交互，就好像它在集群中运行一样。

对于交付生命周期的生产用户和增长阶段，核心挑战是度量用户对实验性功能的影响(并认识到在速度和稳定性之间的侧重点)，以及测试新特性和降低软件缺陷的影响。使用多版本部署可以克服这些问题，通过canarying添加新特性（将其部署为新服务），并随着所观测的用户指标的升高，逐渐增加流量。Envoy，是一个第7层（应用层）代理，它是由Matt Klein和Lyft工程团队构建并运行的，它可以用于解决上述问题，因为所有的流量都可以通过这个代理进行路由和控制。在过去的6个月里，由于Istio（它使用Envoy作为服务网格数据平面）和其它“服务网格（meshes）”的出现，人们对这个概念越来越感兴趣了。

最后一个阶段，关键任务软件阶段围绕防止软件功能和应用程序可观察性的倒退而进行。克服这一问题的策略包括定义服务水平目标（SLOs）和实现第7层（应用层）的可观察性。SLOs的创建和执行需要通过契约型服务级协议（Service Level Agreements，SLAs），并且需要在整个组织范围内进行应用。第7层的可观测性可以通过Envoy（或者类似的代理）进行实现，因为这个代理在网络堆栈层中运行，并且可以访问网络中的所有服务端到服务端的流量。

Schloming在演讲的最后阶段总结道，当一个组织开始进行微服务迁移时，需要注意的是，除了分解整体架构之外，还应该优先对整体流程进行分解。将微服务产品团队组织为自给自足和自治的“衍生品”是有好处的。除此之外，组织必须创建相关工具来实现有效的面向服务的开发。

Rafael Schloming主题演讲“面向服务的开发”（PDF，2MB）中的演示文稿可以在QCon SF网站上进行访问。这个演讲的视频以及所有的演讲视频会由InfoQ在接下来的几个月内整理出来，届时可以在相关网站进行访问。

查看英文原文：Service-Oriented Development: Rafael Schloming Shares Lessons Learned with Building Microservice