Martin Fowler: 微服务手册

本文译自 Martin Fowler 对于微服务的介绍:Microservices Resource Guide
翻译:董干

虽然微服务已经火了很多年,这篇已经算是 14 年左右的 “老文”,但是作者非常细致的归纳和总结还是可能会给我们带来一些新的思考。

本文尝试还原微服务刚开始流行时的历史,同时也希望能给初入门的读者带来一些帮助。时过境迁,在本文翻译的2017年,微服务已经遍地开花,国内国外各大公司纷纷都有着自己的实践,我们也看到了更多相关的教程和分享。这篇也是希望能够抛砖引玉,希望大家能将看到的最新的动态和文章分享整合,共同聚合在这里,为微服务社区贡献我们的一份力量。

—— 译者注


“微服务” 作为一种对应用程序新的组织方式,从2014年开始成为一个火热的话题,吸引了很多关注。几年前,我曾遇到过这种风格,并和我的同事们讨论过。很多优秀的人觉得这种风格是一种应对一定量级复杂系统的比较有效的方式。但是,要从微服务化思考方式中受益,你首先需要了解什么是微服务,如何玩转微服务,以及为什么你通常还需要了解一些其他的。

本手册提供一些用来探寻更多微服务相关话题的有用资源。本文从个人角度挑选了一些能够给读者提供微服务架构风格方面的文章、视频、书籍和录音等资料。大部分选择会指引你浏览 martifowler.com 网站相关部分,但也会涉及到一些我认为有价值的外部资源。本文并不尝试成为一个完整的列表(仅仅是我选择的众多入门介绍中的一部分),但我建议以这里作为你的开始。

什么是微服务

简短地说,微服务架构风格是指一种将某应用程序以一种成套的微小服务进行开发的方法,这些微小的服务每个都在自己的进程中运行,并且互相之间通过一些轻量的机制进行通信,通常是 HTTP 资源 API。这些服务围绕业务功能进行组织,并且可以通过完全自动化的设施独立部署,且可以使用不同的语言和存储技术进行开发。这些服务存在一个可能由不同语言并使用不同的存储技术编写的最小化、中心化的管理设施

-- James Lewis and Martin Fowler

2013年晚些时候,听见身边的圈子都开始讨论起微服务,我开始担心可能还没有一个清晰的微服务概念的定义(与引发 SOA 很多问题的命运类似)。所以我开始和我的同事,微服务经验丰富的实践者 James Lewis 一起写下了下面这篇文章

微服务架构风格的共有特性

这篇文章开创了更多对微服务风格的关注,但我们希望它真正的价值为认识行业内见到的微服务架构的一些公共特征。

  • 通过服务组件化
  • 围绕业务功能进行组织
  • 产品而非项目
  • 重服务的端而非连接服务的管道
  • 去中心化治理
  • 去中心化数据管理
  • 自动化基础设施
  • 高容错设计
  • 面向进化的设计

我们也探讨了一些诸如 “微服务到底应该有多微” 和 “微服务和 SOA 之间有什么区别” 之类的问题。

“我们该不该使用呢?
…… 以及,究竟什么是微服务?”

ms-talk

在这个简短的介绍 (~25分钟)视频中,我挑选了一些最重要的能够决定性地区分微服务应用和单体应用的特征,并指出了在将一个微服务应用上线前哪些事情是相当重要的。

James Lewis 是微服务领域最有经验的顾问之一,在这个 Software Engineering Radio 录音 (1小时)中,他涵盖了这种风格的最关键的特征,包括部署的问题、服务大小、同 SOA 的比较以及社区中的知名人物等。

lewis

微服务和分布式对象

当我在写《企业级应用架构模式》时,我发明了分布式对象设计第一定律:“不要将对象变为分布式”。这导致一些人问我是否微服务违背了这个定律,如果是的话为什么我仍旧支持它。

微服务仅仅是 SOA吗

从一开始,很多人就想知道微服务和面向服务架构(SOA)之间的联系。James 和我在我们的文章里提到了一些Matt McLarty 更详细深入地在这里,解释了 SOA 的历史,将 SOA 和微服务对比为一种流行变迁而非技术变迁,并指出微服务热潮需要从 SOA 的命运中吸取一些教训。

我应该什么时候使用微服务?

和任何架构一样:

微服务提供了一些好处……

  • 强模块化边界:微服务加强了模块化结构,这在大规模团队中非常重要。
  • 独立部署:简单的服务部署起来更容易,并且由于它们都是自治的,当它们出错后也更不易引起整个系统出错。
  • 技术多样性 :使用微服务,你可以同时使用多种语言、开发框架和数据存储技术。

……但也有一些代价

  • 分布式:分布式系统很难,由于远程调用很慢,并且出错的风险很高。
  • 最终一致性:维护一个分布式系统的强一致性非常困难,意味着每个人都要管理最终一致性。
  • 运维复杂度:你需要一个成熟的、能够管理很多老是需要重新部署服务的运维团队。

(以上来自微服务的舍与得

我常常在想微服务费用,一种以我们必须使用减少开发效率去学习和掌握这种开发范式的代价为偿的费用。当系统变得越来越复杂,这个费用被这种风格减少了由于不断增加的系统复杂性给我们带来的开发效率损失而冲淡。但是这些代价仅仅值得我们花在为更复杂的软件而奋斗中。

productivity

这种微服务给较小应用带来的复杂性包袱通常使人们更愿意优先使用单体的策略。使用这种方法,即使你认为微服务本身带来的效益能偿还引入微服务的代价,你也从单体应用开始着手。当你意识到微服务值得引入的时候,你分解或抛弃原来的单体应用。Stefan Tilkov 对此持有不同意见,他认为实际应用中很难构建一个将来很容易拆解成不同部分的单体应用。然而,不管哪种方式,你都不应该在充分了解微服务这一领域前尝试微服务。

当微服务的概念像雪球一样越滚越大时,ThoughtWorks 的技术专家会开始担心很多项目仅仅因为这个概念火热而选择使用它,一种我们称之为 “不用微服务不舒服” 的疾病。

Scott Shaw,ThoughtWorks 澳大利亚的技术负责人,在这一录音中讨论了这种疾病,录音于 2015 年技术专家会的讨论中(18分钟)。

scott-shaw

从我们目前的经验看来,相比单体应用来说,我们更倾向于支持微服务,我们也清醒地认识到现在业界应用的时间还不够长到足以让我们作出一个完整的判断。

-- James Lewis 和 Martin Fowler

现在作出对微服务是否有效的深入评判还为时过早。你仅仅能在多年以后,经过多次开发团队迭代之后,才能知道一个软件系统能不能易于修改。有可能的是在周围的环境中,一些政治的和技术的原因可能会影响微服务的成功。正因如此,我不指望我们能立刻得到确定性的答案 —— 我们只能希望在不同的团队交流他们在实践微服务上的经验时收集到一些证据。

如何构建微服务

how-to-build-microservices

我的同事 Sam Newman 最近几年参与了很多我们在全球为微服务作出的努力。《微服务设计》这本书集合了很多我们遇到的以及我们从其他分享彼此经验的组织身上了解到的经验教训。因此,这本书是学习如何使用微服务的风格构建应用最佳的地方。

newman

测试

我一直是将测试过程集成进开发流程的坚实的支持者,致力于自测试代码

meta-image

Toby Clemson 汇集了上图中在构建微服务系统时各种各样需要考虑的测试,以及各种不同形式的测试如何提供不同的方式来验证系统的可靠性以及对问题的追踪。

多大合适?

“微服务” 这个名称有很多强调服务大小的意味在里面,一个很多实践者觉得很不幸的点。

安全

微服务引发了一系列的安全性问题。它对有不同鉴权需求潜在性地提供了可供精细化控制的能力。但是就像微服务方式的大部分优势一样,将所有都正确设置有一定的复杂度。Sam Newman 这本书的第9章涵盖了更多这一话题的细节。他在 microXchg 的演讲中给出了一些概述。你还能找到 Graham Lea 的一个方便的安全问题列表

演讲

sketch

在你上线微服务系统之前,你需要确保一些关键的前置条件就绪。

  • 服务器快速交付
  • 基本的监控
  • 快速的应用部署
  • Devops 文化

任何设计系统的组织都会不可避免地设计出一个和这个组织的沟通结构一一对照的系统。

—— Melvin Conway, 1968

微服务的一个重要特征是它们围绕着业务能力而构建。软件的体系架构总体来说是认为的设施,大多聪明的架构师都理解康威定律的力量。

都谁在使用微服务?

围绕微服务的讨论基于早期先行者们实践得出的经验(不论他们是否使用了微服务的名称)。幸运的是,很多早期微服务的使用者乐于将他们的经验分享出来,这里是其中一部分。

来自前线的经验教训

zhamak

我的同事 Zhamak Dehghani 讲述了 ThoughtWorks 实践微服务时学到的经验,我们经历了成功的项目,也经历了由于错误使用微服务架构而不得不挽救的项目。

Netflix 的经验

cockcroft

Netflix 是微服务架构的明星使用者之一,他们近年来经过重大的重新设计将系统改造为微服务架构。Adrian Cockcroft 领导了这次改动并在演讲迁移到微服务中总结了很多他们得到的经验。

早在00年代,Amazon 做出了一个现著名的从 Obidos 单体应用迁移到面向服务架构的转变,其新的架构包含了封装的数据库和小的 “两个pizza” 团队。尽管 Amazon 从来没有使用 “微服务” 这个叫法,微服务运动从他们的经验里得到了不少灵感。2006年 ACM Queue 对 Werner Vogels 的采访仍然是他们做的事情的最好还原。

vogels
Werner Vogels, Amazon's CTO, 2011年谈 Amazon 的服务化经验

对于我们来说,面向服务意味着将操作该服务的数据同业务逻辑封装在一起,对外只暴露公开的服务接口。在服务之外不允许直接对数据进行访问,服务之间不共享数据。

—— Werner Vogels

rea-talk

REA 组织是个澳大利亚关注于房地产的互联网公司,运营着 realestate.com.au 网站。在2010年代早些时候他们开始将单体应用替换为微服务方式,最终几年后部署运行着60多个微服务。Beth Skurrie, Evan Bottcher, 和 Jon Eaves 分享他们在这一过程的经验,描述了他们如何将单体应用瓦解,以及为何他们抛弃了集成测试改为接口约束测试,他们还因此开发了(并且开源了)有用的接口契约测试工具库 Pact

Soundcloud 从 Ruby On Rails 的单体应用迁移到微服务的方式。 Phil Calçado 通过一系列 Blog 文章描述了他们的经验。

  • 我们是如何最终使用微服务的,描述了他们渴望提升开发周期以及开发效率,最终引领他们转向微服务。
    这篇比其他几篇写的更晚,但是最好先读,接下来再读涉及到工程细节的三部分
  • Part 1 讲了在他们的单体“航母”上构建的微服务
  • Part 2 讨论了他们如何将单体应用拆散
  • Part 3 着眼于他们如何使用 Scala 和 Finagle 构建微服务

这里有一些有用的博客,描述了实践微服务时遇到的一些实际的经验教训。

Randy Shoup 讲述了他在 eBay 和 Google 时使用微服务上的经验。他聚焦于单体到微服务的通用的进化之路,并描绘了 Google 成熟的服务环境。另外值得一看的还有这篇后续采访,阐述了他的一些经验和教训。

Show Comments

Get the latest posts delivered right to your inbox.