微服务的概念还是偏大

  • Jan Stenberg
  • 邵思华

2015 年 3 月 29 日

话题:架构语言 & 开发微服务

微服务的概念有些偏大,它将对组织级别的因素进行的优化与对技术因素所做的优化概念合并在一起,但对于每种类型中所产生的问题,对应的解决方案未必能够适合另一种问题。Phil WillsQCon 伦敦大会上所进行的一场演讲中,提倡了独立的服务和单一职责应用程序的思想,而不是微服务。

Wills 是The Guardian公司的高级软件架构师,他表示,选择使用微服务的最终目的是希望能够生产出更实用、更可靠的软件,并且能够更快地进行交付。或者借用Dan North 在这次大会上刚刚做完的一场演讲中的话来说:要能够可持续地交付商业影响,同时将交付周期最小化。

在 2008 年,Wills 和他的团队完成了一个项目。这是一个全新的庞大系统,虽然这个系统在许多方面都获得了成功,但他们很快发现,要将一些实验性的特性发布到生产系统上的成本太高。部分原因在于,对系统进行任何变更都要面临着一些纯粹由组织的复杂性带来的问题。有一段时期,他们甚至专门设置了一个发布经理的职位,让他进行各种必需的沟通工作,以实现每两周一次发布。为了解决这一问题,他们在系统中加入了一些占位符,可以在其中插入一些他们称之为微应用的东西,以替换系统中的某些部分。但是这种实现无法做到将各个部分完全分解,让它们的故障不影响其它部分。这就意味着每个独立的部分仍然有可能造成整个系统的停机。

对于 Wills 想象中的正确方案来说,独立的产品是一个关键的因素。这种产品的特征包括:它们具有一种稳定的、定义良好的界面,它们能够进行独立部署,并且必需自行管理数据存储系统。但这只能实现他们的整体目标中的一部分。Wills 在将整体分解为小部分的过程中受益匪浅,他提出了单一职责应用这一术语,专注于让服务保持适应性,并且因为服务足够小而容易理解。这种应用的一个特征在于,它有一个关键指标,可以用以衡量该应用是否完成了预定的任务。另一个特征是它们必须彼此隔离,不允许影响其它应用程序的性能。

Wills 在结语中表示,他看到一个优秀的团队如何创建出一个庞大的整体系统,但也看到了一个优秀的团队如何创建出由大量微服务所组成的系统。而他的聪明之处在于他更倾向于后者,这一点也使他感到十分自信。

查看英文原文Microservices Are Conceptually Too Big

架构语言 & 开发微服务