微服务的隐性红利:你不知道的8个好处

本文讲的是微服务的隐性红利:你不知道的8个好处【编者的话】微服务未必适用于所有公司,实施过程也并非易事。之前大家讨论是否采用微服务时的重点主要在于它的自主性、敏捷性、弹性和开发者的生产能力。但这并不是微服务的所有优点,本文中提到的这些额外的好处也是值得利用的。

微服务未必适用于所有公司,实施也并非易事。

作为构建分布式系统的一种方式,微服务可以做到只用hardened API提供服务。围绕特定、有界的上下文或责任范围,这些服务具有高内聚低耦合的特点。这些服务通常很简单,但却可以构成非常丰富和复杂的应用。采用基于微服务的新方式需要付出相当大的努力,特别是从monolithic架构迁移过来的例子就更加麻烦。微服务有很多优点都是众所周知,其中不乏敏捷性、弹性、可伸缩性、可扩展性和开发效率高。本文将指微服务不为人所知的一些优点,或者说是隐性的红利,实施者应该有意识的去利用。

在微服务背后最基本的利益驱动是清晰地分离关注点,将每项服务的注意力集中在应用的某些定义清晰(well-defined)的地方。这些服务能以低耦合的方式组合,并具有独立部署能力。许多人都被其能够频繁、低风险改动的性能吸引。Robert C. Martin这样描述单一职责原则(single responsibility principle):“将改变原因相同的聚一起,将改变原因不同的相分离。”明确的分离关注点,关注点间的耦合最小化,以及潜在的高变动率导致业务敏捷性和工程速度的提升。

Martin Fowler认为,比起迁移到微服务上去,持续交付和用代码处理基础设施更重要。一些人在实施过程中采取了这些方法,由此带来了有弹性,灵活性和生产力较高的积极影响。微服务的另一个好处是,它允许架构各部分的拥有者在构建大规模分布式系统时选择不同的机制,同时顾及到持久性机制的选择、一致性和并发。这给各服务更多自主权,有助于快速适用新技术,允许仅向一部分或者某一个服务提供定制方法。

好处

虽然很难实现,但基于微服务的方法还是给组织带来了很多好处,尽管有些并不明显。以下将列出一些不那么明显的好处,但足以说明采用微服务时付出的努力都是值得的。

好处1:无需许可的创新(Permissionless Innovation)

无需许可的创新即“他人在我们创造的通信结构之上进行创新的能力”,这个概念由IETF (Internet Engineering Task Force)的主席,Jari Arkko提出。如果一切成熟,接口用户的创新将震惊接口的设计者。这与那些整合前需要咨询gatekeeperblocker的委婉用法)的方法不同。
有一个简单的测试可以分辨“无需许可的创新”已经达到的程度,那就是跨团队会议(和队内会议不同)的流行程度。跨团队会议意味着服务接口的协调、耦合和粒度或功能问题。工程师们会尽量避免开会,这样的会议意味着需要整合的并不只是某服务的API。接受了”无需许可的创新 ”概念的团队应该具有高实验率和低跨团队会议率。

好处2:常规故障(Enable Failure)

计算机科学中,我们仍不知道如何构建能够稳定工作的复杂系统,而且不稳定性和系统的规模和复杂性成正比。尽管在关于微服务是否能够减少整体复杂性上有所争议,但微服务将会增加故障的次数,这个观点还是值得接受的。进一步来说,跨服务边界的故障将更难修补,因为外部调用堆栈本质上就比内部调用更加脆弱,而且调试任务会受限。 @ honest_update的一条推文有时会让人感到不舒服:“我们用微服务替代了monolith,搞得现在每次中断都像一次神秘谋杀。”

不可避免的、常规的故障会引起人们关于状态持久性、弹性、依赖管理、功能降低等方面的探讨。通过利用高速缓存、计量、流量控制、节流、减负荷和回退等技术,这些探讨可以减少特定故障的影响范围。在基于微服务的成熟架构中,个别服务的故障应该是意料之中的,但所有服务的级联故障应该不可能出现。

好处3:不再依赖小团队间的信任(Disrupt Trust)

在小公司或者代码基础较小的情况下,工程师们对部署工作心怀信任,因为他们可以查看每一个人的每一次交付。当团队规模和总速度增加时,“邓巴数字”(即150定律)就开始起作用了,这种信任也开始变得紧张。正如英国人类学家Robin Dunbar所定义的那样,这是个人通过直接接触可以维持的最大社交关系数量。

微服务可能会让团队信任面临新的问题。服务之间的边界变成一组API。用户不再影响API背后的设计、设计如何演变以及数据如何存在,而是要获取一组SLA(service-level agreement 服务层协议)来控制API的稳定性和运行特征。原来的信任可能会被自治权和问责制所取代。

Conway定律的定义者Melvin Conway说,“任何组织设计出的系统最终都会与该组织的沟通结构相匹配。”

微服务可以为组织提供一个高效模型,使其规模远大于个人接触范围的限制。

好处4:负责到底(You Build It, You Own It)

微服务宣扬“谁构建,谁负责”这样的模型。亚马逊CTO Werner Vogels在2006年与Jim Gray的谈话中这样描述该模型,这段对话在ACM Queue 上刊登过。“每一个服务都有一个对应的团队,这个团队对该服务完全负责,从琢磨功能,设计结构,实现,到运营。谁构建,谁运行。这让开发者们日复一日的与软件之间发生联系,也让他们日复一日地与用户发生着联系。用户们的反馈对推动服务质量来说至关重要。”

此番谈话之后的十年中,越来越多的软件工程师按照这个模型工作,也担上了更多责任,于此同时 ,随着微服务的发展,他们采取了一些方法去获得更高的自动化程度,并降低运营开销。 这些方法中就有持续部署、虚拟化或容器化,增强弹性,以及各种自修复技术。

好处5:加速关闭(Accelerate Deprecations)

在monolith架构中,很难安全关闭某一部分。但在微服务中,可以清晰提取出服务中的某列,建立起更有竞争潜力的新版本服务,或者构建一个与原版本完全不同但向后兼容重要接口的新服务。

在无需许可的情况下,服务的变更应该是常规化的。我们要努力将关闭不常用服务变得更简单。一种方法是,有足够高的资源竞争水平,这样才能保证在资源有限的团队中,可以把更多精力从衰败的服务中抽离出来,放到对用户来说更重要的服务中去。这种情况下,需要对这些不成功的服务负责的人,就变成了最在意这些服务的用户。被关掉服务的团队理所当然的认为这种情况实属无奈,尽管他们也参与了关闭服务的决定。而不希望遇到这种无奈情况的团队则会主动迁移或者终止依赖。听起来很残酷,但这是“快速失败”很重要的一部分。

好处6:端集中式元数据(End Centralized Metadata)

在亚马逊的早年,一小部分关系型数据库用来存储种鸽公司的关键交易数据。考虑到数据的完整性和性能利益,任何提交的架构更改都需要经过DB Cabal的审核通过。DB Cabal是由一群企业建模精英,数据库管理员和软件工程师组成的把关团队。有了微服务,用户不需要也不用再关心API背后的数据是如何持久存在的。事实上,置换持久机制这种事可能并不需要用户洞悉。

亚马逊的早期,少量的关系数据库被用于公司的所有关键的交易数据。在数据的完整性和性能的利益,任何提出的架构更改必须审查和批准的DB集团,一个守门组好心的企业建模、数据库管理员、软件工程师。与精卫,消费者不知道或关心数据如何坚持背后的一套API它们所依赖的,确实应该可以换出另一个持久化机制没有消费者注意或者需要被通知。

好处7:集中痛点(Concentrate the Pain)

采用微服务的组织可以按需以不同方式处理不同服务。这需要公司整体的数据分类模型保持一致,并与公司不同业务的完整性关键流程分类。这对服务建模来说是个挑战,毕竟服务要处理重要的数据和过程,实施控制对公司安全性和必要的合规性来说都非常重要。随着微服务的增长,最受规则限制的负担可以集中于一小部分服务上,从而放松了创新率更高的其他服务。

好处8:新的测试方式(Test Differently)

工程师们经常将实施微服务看做改变测试方式的契机。通常,他们会开始思考,在构建服务之前,怎样在设计阶段开始早期测试。所有权和范围的清晰定义有助于扩大覆盖范围。正如Yelp在阐述服务原则时所说,“你的接口是测试中最终要的部分。你的接口测试会告诉你用户真正看到的东西,但其他测试会告诉你怎样保证用户能够看到这些结果。”

采用诸如持续部署,烟雾测试和阶段部署等方法可以使测试保真度更高,同时降低生产问题出现时的修复时间。测试的效率更多的是由可以由修复问题的速度来描述,而不是发现问题的速度。

提示

以下指标可以判断你采用的微服务是否完整。如果发现有下列问题,那么你还没有做到真正的微服务:

  • 不同服务需要协调部署。
  • You ship client libraries。
  • 一个服务中的变动会引起其他服务中的变动或导致意料外的后果。
  • 多个服务共享持久存储。
  • 不能随意更改服务持久层。
  • 工程师需要精通其他团队服务的设计和架构。
  • 你拥有适用于所有服务的合规控制权。
  • 基础设施不可编程。
  • 不能一键部署和复原。

结论

微服务未必适用于所有公司,实施过程也并非易事。之前大家讨论是否采用微服务时的重点主要在于它的自主性、敏捷性、弹性和开发者的生产能力。但这并不是微服务的所有优点,本文中提到的这些额外的好处也是值得利用的。

原文链接:The Hidden Dividends of Microservices(翻译:马远征)

原文发布时间为:2016-08-29

本文作者:马远征

原文标题:微服务的隐性红利:你不知道的8个好处

时间: 2024-09-28 17:18:24

微服务的隐性红利:你不知道的8个好处的相关文章

《SpringBoot揭秘:快速构建微服务体系》—第1章1.4节微服务会带来哪些挑战

1.4 微服务会带来哪些挑战微服务给我们带来的并非只有好处,还有相应的一些挑战.服务"微"化之后,一个显著的特点就是服务的数量增多了.如果将软件开发和交付也作为一种生产模式看待,那么数量众多的微服务实际上就类似于传统生产线上的产品,而在传统生产模型下,为了能够高效地生产大量产品,通常采用的就是标准化生产.比如在汽车产业,在福特T型车没有出来之前,大多汽车企业的生产效率都不高,而福特在引入标准化生产线之后,福特T型车得以大量生产并以低成本优势快速普及.在其他行业也是同样的道理,个性化生产

Komad首席工程师Sean Kelly谈微服务谬见

Sean Kelly是Komad的首席工程师,在去年举行的波士顿Golang开发者见面会上,他做了一次关于微服务使用体验的闪电式演讲,之后他写了一篇文章.他以人们应该有所期待的内容作为开场: 我即将讲到一些有关微服务的谬论和误解,有些人坚定地认为对一个遗留的单体应用进行拆分就能挽救局面.我不希望这篇博文的观点变成"微服务==拙劣",如果阅读这篇博文的人有想不明白迁移到微服务是否真正适合他们的话,那么最好请他们离开. 当然,有关微服务的讨论都是从试图定义清楚微服务是什么或不是什么开始的.

《SpringBoot揭秘:快速构建微服务体系》—第1章1.3节微服务会带来哪些好处

1.3 微服务会带来哪些好处显然,随着系统复杂度的提升,以及对系统扩展性的要求越来越高,微服务化是一个很好的方向,但除此之外,微服务还会给我们带来哪些好处?1.3.1 独立,独立,还是独立我们说微服务打响的是各自的独立战争,所以,每一个微服务都是一个小王国,这些微服务跳出了"大一统"(Monolith)王国的统治,开始从各个层面打造自己的独立能力,从而保障自己的小王国可以持续稳固的运转.首先,在开发层面,每个微服务基本上都是各自独立的项目(project),而对应各自独立项目的研发团队

微服务的框架选择

从微服务说起 微服务架构(MSA)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦.你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则. 用通俗的话来讲,就是为了高度解耦软件之间的依赖性,使每个独立的模块都能够单独测试,单独运维,最大限度的提高软件的开发流程.从下图可以看一下微服务的软件生命周期. 软件从需求分析就可以适配模块,也就是说需求分析的过程就可以加入设计,从新的角度来说就是在哪个模块中进行升级开发,开发人员在开发完成后,通过持续集成,将开发的结

微服务的4大设计原则和19个解决方案

作者|郝炎峰 编辑|小智 本文将介绍微服务架构的演进.优缺点和微服务应用的设计原则,然后着重介绍作为一个"微服务应用平台"需要提供哪些能力.解决哪些问题才能更好的支撑企业应用架构. 注:本文转载自公众号 EAWorld,已获授权. 写在前面 微服务架构现在是谈到企业应用架构时必聊的话题,微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境. 微服务平台也是我目前正在参与的,还在研发过程中的平台产品,平台是以 SpringCloud 为基础

微服务的4个设计原则和19个解决方案

微服务架构现在是谈到企业应用架构时必聊的话题,微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境. 本文将介绍微服务架构的演进.优缺点和微服务应用的设计原则,然后着重介绍作为一个"微服务应用平台"需要提供哪些能力.解决哪些问题才能更好的支撑企业应用架构. 微服务平台也是我目前正在参与的,还在研发过程中的平台产品,平台是以SpringCloud为基础,结合了普元多年来对企业应用的理解和产品的设计经验,逐步孵化的一个微服务应用平台. 一.微

SoundCloud:我们最终是如何使用微服务的?

本文讲的是SoundCloud:我们最终是如何使用微服务的,[编者的话]很多的技术文章着重介绍的都是项目后总结出的最佳实践,本文从另外的角度,介绍项目中解决问题的整个探索过程,详细讲述了在最终使用微服务架构之前所做的种种分析和尝试,这对于正在尝试解决问题的技术人员来说有很大的启示作用. 微服务是近期的热点. 当我在SoundCloud工作时,负责从一个巨大的Ruby on Rails应用程序里迁移到众多的微服务上.我已经多次讲述这个过程的技术问题了,在演讲里,也在SoundCloud的工程师博客

通过Ruby on Rails和docker构建微服务架构之入门教程

说到时下的架构,免不了会涉及到微服务.而谈到微服务架构,又跟容器和Docker技术脱不了关系.虽然容器和Docker并不完全是一回事,但两者是密不可分的,而且二者之间也有共同之处:在大型复杂应用的构建和运营方面,二者都可以大大提高企业的效率.   微服务可不像一般的应用,可以通过apt-get工具进行安装,大家可能会问了:我们该如何才能像安装应用一样实现这种服务呢?在很大的程度上,这个问题的答案是否定的,我们无法轻松实现这种服务.更准确的说,至少目前我们还无法实现.在一个系统中,最难修改的就是架

微服务——分解应用以实现可部署性和可扩展性

本文描述了日渐流行的微服务架构模式.微服务背后大的理念是将大型.复杂且历时长久的应用在架构上设计为内聚的服务,这些服务能够随着时间的流逝而演化.微服务这个术语强烈建议服务应该是很小的. 社区中有些人甚至建议构建10-100代码行(LOC)的服务.但是,尽管很小的服务是我们想要的,但这不应该是主要的目标.你应该致力于将系统分解为服务,以解决下面所讨论的开发和部署问题.一些服务可能确实会很微小,但有些可能会非常大. 微服务架构的本质并不新鲜.分布式系统的理念历史非常悠久.微服务架构也很类似于SOA.