AutoScout24通往微服务之路
2016-02-18 10:26:41   来源：Daniel Bryant ，译者 邵思华   评论：0 点击：

在Dublin微服务用户组的一次活动中，Christian Deger进行了一场名为“通往天堂之路：在云端构建微服务”的演讲，讲述了AutoScout24是如何从使用典型的IT开发流程在一个一体化的应用中部署代码的方式，转变为由跨职能的团队构建与部署微服务架构的历程。这种技术与组织上的转变让业务组织能够更快速地应对不断变化的市场情况。

InfoQ最近与来自AutoScout24的一位架构师Deger进行了一次访谈，Deger回答了一些流程方面的问题，以及在启动这种大规模流程转变时所遇到的各种挑战。Deger向采访者分享了在组织里驱动这一转变过程的动力以及相关技术，谈到了过程中所必需的计划工作，并且对于Linux、Scala及AWS这些技术选择提出了他的见解。

InfoQ：欢迎你Christian！能否请你进行一下自我介绍，以及你近期所做的有关微服务的演讲“通往天堂之路”背后的核心思想？

Deger：在5年以前，我作为一名.NET软件开发者加入了AutoScout24，因此我对之前所采用的技术栈的运作方式有所了解，组织对我们当时的技术选择十分支持。2014年初，新的CEO Greg Ellis上任了，他对于我们所采用的Windows .NET技术栈未来的前景提出了质疑。当时我正负责一个开发团队的领导工作，但这次转型的目的是使我们已成熟的IT技术转为次世代的“web规模”的IT平台，这中间所面临的挑战吸引我开始研究架构师这一角色中更偏重技术的一面。

我们在2014年11月启动了Tatsu项目，当时仅有1个团队参与，自那之后，这个转型项目的规模逐渐扩大到了8个团队。Tatsu（竜）这个单词起源于日语，是传说中一种会飞的动物。在加州某处有一个过山车也与此同名，它很形象地诠释了我们在这次转变过程中的体验。就像乘坐真正的过山车一样，你最好能够紧紧抓住某样东西。对于我们来说，这样东西就是我们所提出、并且在不断演变的一系列原则。这些原则能够作为我们的讨论的指导意见，并使我们的方向保持一致。因此，这次演讲的核心内容是我们所选择的途径、坚守的原则以及所学到的经验。

InfoQ：AutoScout24从一体化架构转变为微服务架构，这听起来是一个规模很大的项目，你们对此进行了哪些前期计划工作？

Deger：对于AutoScout24来说，这确实是一个很大的项目，但我们并不相信大量的前期设计这种方式。我们当然会在产品的能力与预算的计划方面保持应有的审慎。但对于我们来说，更重要的一点在于进行一系列合理的初期决策。AWS与Linux是很明显的选择，而JVM与Scala的选择则不是那么容易确定的。但对于我们所具备的.NET经验来说，这看起来应该是一个良好的起点。工程师之间对编程语言的讨论是无法避免的，在AutoScout24选择Scala时也产生了激烈的争论。另外我们还打算采用微服务架构，这让我们能够容纳更多的不同技术，这一决定也起到了很大的作用。

随后，我们就四处寻找一些合作伙伴，希望能够在这些领域为我们提供一些支持与指导。最终，我们决定对一个功能进行重写，以实现我们第一个微服务。在第一个团队投入开发工作之后，其他人将学习他们的经验，并且应用到其他功能的实现过程中。

InfoQ：我们还注意到一点，你前面提到除了转向微服务架构之外，你们还选择了将系统迁移至云平台，并从.NET/Windows平台转为JVM/Linux环境。事后看来，你是否也会建议其他组织进行这种方式的转换呢？

Deger：对我们来说，整个转换项目及其核心决策就是一块块拼图，他们能够完美地结合在一起。我们当然也可以选择以更小的步伐完成这次转变，但这将使我们失去这一机会。我们很了解这个行业，下一波挑战正在到来。因此，即使是让我重来一次，我也会不对核心决策进行任何改动。

虽然整个转变过程是同时启动的，但我们还是决定尽量减少对于组织带来的影响。我们先从一个团队开始尝试，并且极力强调向他人取经的思想。每两至三个月，就会有新的团队加入其中，项目中包括资深工程师与新手。这一过程对于早期加入的各个团队非常有效，但我们也学到一点，即你必须知道何时停止对团队进行分解的过程。当相互学习的阶段结束、并且项目的交付需要更多的关注时，我们必须让团队保持稳定。

从技术角度来说，我们都还有许多JVM或Linux的知识要学习，但我们已经成功地实现了全部自动化。我们的整个基础设施都由代码管理，包括不可变的服务器。我从来没有听说团队中有哪位工程师更愿意通过Windows技术栈解决这些问题。

InfoQ：你们的项目只包括“开发”与“生产”环境的构建，而没有搭建一个预发布环境，你能否对这一点详细地说明一下吗？

Deger：当我刚加入AutoScout24时，一共有3个预发布环境与1个生产环境。当时让每个发布候选通过所有预发布流程始终是一件令人头疼的事，因为这些环境与生产环境有着不同的配置。此外，这些预发布环境的“安全网”并不能够始终保证不会在生产环境中出错，因为这些环境中的数据、负载量与模式与生产环境都是不一致的。

不仅如此，在独立地发布服务时，一个运行着所有服务的预发布环境还带来了另一个问题，即与你集成的其他服务的版本与生产环境中有所不同。这些外部服务或许正处于交付周期的未完成阶段。既然如何，何必自找麻烦去配置一套预发布环境呢？为什么不让事情简单一点，只配置一个环境，让所有服务在该环境中都可用不就解决了吗？

我们希望能够“更大胆些”，但并不是说要犯傻，因此我们进行了大量的调查研究，以了解如何才能放心地将代码直接部署至生产环境。在过程中我们经历了一些失误，服务本身可能会出错，新的特性也可能不像预期中的方式运行，服务之间的集成也可能会出错。

• 我们采取了动态特性开关策略，它帮助我们实现代码部署与特性发布的分解，这使我们对于新特性的发布实现了完全控制。我们在过去两年多时间内构建了自己的工具，名为FeatureBee（https://github.com/AutoScout24/FeatureBee），用于金丝雀发布、A/B测试以及验收测试。举例来说，AutoScout24的每位员工都可以通过Chrome扩展自行开启一个新特性。就在最近，Pete Hodgson在Marin Fowler的网站中解释了这一概念：http://martinfowler.com/articles/feature-toggles.html
• 客户驱动契约（CDC）能够帮助我们验证某个服务是否破坏了与正在生产环境中所运行的版本的服务之间的契约。服务可以在自己的发布管道中运行由使用者提供的契约测试，而无需与已发布的服务进行集成。我们目前正在将这些测试迁移至Pact（https://github.com/realestate-com-au/pact）。
• 我们为会新服务应用Shadow Traffic，这让我们得以在正式发布之前消除所有性能问题。但我们在一开始应用此方法时效果并不好，因为某些服务没有包含在最初的发布中，而他们又会对状态进行变更。因此，我们的方法是在实例级别结合使用金丝雀发布与shadow
  traffic。出于这一原因，我们需要为在金丝雀发布阶段写入的数据进行标记，以用于生产环境。

InfoQ：在整个迁移过程中，对于所必须的技术变革来说，打造“自治的”团队具有怎样的重要性？

Deger：对于我们来说，打造自治的团队非常重要，因为我们相信自治的团队能够实现组织的伸缩性，同时保证团队的效率。一个具有自由度与责任感的文化是非常强大的工具。

我们之前的团队就已经实现了某种程度上的跨职能性，所缺乏的部分主要是仍然要将部署工作移交给运维团队。因此，我们尝试将原先的运维人员吸引到我们的产品团队中，让整个团队对服务的运行与改进负责。最终诞生了我们的座右铭：“我们现在都是工程师”。

尽管如此，我们仍需要密切留意团队中的各种“T型人才”是怎样为整个产品功能的做出贡献的，人们很可能会时不时地产生松懈倒退的表现。如果将有关基础设施的用户故事都分配给来自运维背景的工程师，他们就会成为团队中的“单点故障”。我们必须确保“谁创建的东西，就由谁负责运行”思想中的“谁”代表的是整个团队。从另一方面来说，许多开发者借此机会拓展了他们的技能，这是我们所乐于看到的。

InfoQ：我对于本次演讲中所提到的“原则”这一部分非常感兴趣。在这些迁移过程中，你与你的团队所学到的最重要的原则（或者是一系列原则）是什么？

Deger：我们围绕着“无共享”这一原则展开了各种有价值的讨论。当然，系统中一定会共享某些内容，因此对于该原则总是需要进一步解释。显然，共享的行为应当成为一个服务，而多个服务不应使用共享的数据存储源。这一原则的重要性在于它改变了我们原本所有的思想。我们以前所学到的知识总是教育我们要保持DRY，或是进行标准化。大批工程师都希望能够创建一个共享的库。但共享的库会使服务对这种特定的实现以及底层平台产生耦合。我们的目标不是对于它的效率进行优化，而是为了加快前进步伐。

举例来说，我们在系统中共享了一个统一的日志记录基础设施。这是一种宏观的需求，因为我们需要对于来自所有服务的事件进行关联。除了基础设施之外，事件的数据契约也是共享的。但是事件发布功能的最初实现则并非共享的，因为人们对于直接拷贝单一的类这一做法有很强烈的反对意见。很快，团队就可以在无需协作的情况下对于自己的实现版本按照自身需求进行改进了。在经过好几个月之后，整个实现终于稳定下来了。我们最终决定构建一个内部的OSS库，在其中包含所有改进内容。新的团队可以自己决定如何使用这个库。

另一个例子是我们的仪表板服务。第一个团队搭建了一个仪表板服务器，而第二个团队在同一个实例中添加了另一个仪表板。但两个团队在访问某个指标的时候，无意中使用了服务中的同一个全局状态。我们在两天后才发现了这一问题，因为我们观察到这两个仪表板中的数值每5分钟就会切换一次。这是一个关于耦合方面的糟糕例子。现在，每个团队都自己运行一个仪表板服务器。

第二个原则的争议较少，但非常实用，即AWS优先：“AWS平台服务胜于托管服务、自运行OSS以及自展开的解决方案。”我们需要决定在组织的技术栈中引入哪种平台服务，因此我们提醒自己，我们的目标是利用AWS的托管服务。因为我们希望避免那些繁重的负担，而专注于自身的领域并加快脚步。虽然我们有时仍然可以选择其他的方案，但必须要给出充分的理由。

在YouTube上可以找到“通往天堂之路：在云端构建微服务”这个演讲的视频，也可以在Deger的SlideShare帐号中下载对应的幻灯片。

查看英文原文：AutoScout24’s Journey to Microservices: Christian Deger on Transformation, Principles and Technology