BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

微服务的概念还是偏大

| 作者 Jan Stenberg 关注 29 他的粉丝 ,译者 邵思华 关注 3 他的粉丝 发布于 2015年3月30日. 估计阅读时间: 2 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

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

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

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

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

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

查看英文原文Microservices Are Conceptually Too Big

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

有点像unix的设计哲学 by hao Iron

把一个功能做到极致,理解有误没?

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT