神刀安全网

有人说微服务就是把大饼切成小饼,但Martin Fowler说微服务不仅如此

有人说微服务就是把大饼切成小饼,但Martin Fowler说微服务不仅如此

微服务架构被越来越多的系统架构使用到,甚至很多组织在无意识的情况下,也或多或少地使用到了微服务架构中的一些概念。就像Martin Fowler所说的,微服务架构其实由来已久,它作为SOA的其中一种实现方式已经被广泛使用了。只是到了最近,才用“微服务” (Microservices) 这么一个概念为其“正名”而已。在阅读了Martin Fowler的相关文章后,我觉得Martin Fowler的关于微服务的一些观念在国内比较少的被提出、讨论,所以这篇文章主要想提取Martin Fowler针对微服务架构的一些独特的观点,供大家讨论、参考。

微服务 vs 单一服务

当我们提及微服务,不可避免的,我们会讨论和微服务对应的架构形式:单一服务 (Monolithic)。注意,微服务和单一服务架构并没有孰优孰劣之分,只是根据其不同特点,应用的场景有所不同(这将在后文进行进一步的讨论)。为了方便展开讨论,我们先弄清楚微服务和单一服务架构的概念以及区别。

  • 单一服务:把所有功能都集中在一个应用系统。在部署时,单一架构的应用以整体的方式进行部署,也就是说在进行集群时,也是以应用的整体进行集群。
  • 微服务:应用系统由一些列功能独立的小规模服务组成。这些服务相互关联、沟通,从而支持应用系统的业务功能开展。由于这些服务的独立性,不同服务可能是基于不同开发语言进行开发的,数据的储存也是基于不同的方案。部署时,由于服务的粒度小,提供了更强的灵活性。
有人说微服务就是把大饼切成小饼,但Martin Fowler说微服务不仅如此

微服务的基本特点

由于不同人对微服务有不同的定义,业界很难形成统一的观点。Martin Fowler简化了定义流程,通过提出微服务的9个特点,如果应用架构符合了这些特点,那么可以认为是为服务架构(这里需要注意的是真实世界中并没有非黑即白的定义,可能你的架构部分具备微服务的特点,那么可以认为其已经体现了微服务的思想)。微服务的9个特点大家可以查看Martin Fowler的原文(参考文献#1),下面我将一些值得注意的特点提出来供大家参考、讨论。

  • 围绕业务来组织人员

在传统的IT企业架构中,人员的组织一般是按照职能进行划分的,例如:前端开发、后端开发、DBA、BA、测试等。这种组织形式往往以项目的方式运行,也就是当项目开展时,项目团队由各个职能部门的人员组成,在短期内以项目的方式协同工作,交付产品。虽然项目方式可以有效的交付产品,但是由于项目的临时性,项目结束后,相关人员会回到职能部门中,其在项目的成果往往不会被主动的进行改进、总结。换句话说,项目的一些成果没能被有效的沉淀下来,可以被以后类似的项目复用。

而在微服务架构下,人员的组织是基于业务进行划分的,例如:某一个团队负责用户注册功能,某一团队负责的是订单功能。这种划分方式体现的一个要点是:you build, you run it,即:谁开发,谁负责到底。这种方式带来最大的好处是:由于团队只需要考虑自己的业务领域,所以团队可以在某一个业务上进行很深的积累,最大限度的提升某领域的效率、功能。

  • 白痴的中枢 与 聪明的端服务

微服务的其中一种实现方式是基于ESB (Exterprise Service Bus),ESB一般提供复杂的功能,例如:消息传输、路由、协调、转换、业务规划等。ESB方式可以将不同服务有效地进行相互协同,以满足业务的需求。但是其最大的问题是ESB会成为整个应用系统的瓶颈(即使采取集群的方式也易产生雪崩效果)。

因此,在微服务架构中提倡了另一种方式:将ESB中复杂的功能,转移到每一个服务中去,从而实现“白痴的中枢”配上“聪明的端服务”,以去处ESB单点的隐患。

  • 异构技术的高容忍性

在单一服务架构中,所有的功能都必须根据既定的技术框架进行开发,例如:Java 8、MySQL等。但是,其实每一个功能由于其不同的特点,可能其它技术会更有利于该功能的实现,例如:某功能对数据一致性没有太高的要求,但是数据量巨大,那么可能NoSQL比关系数据库更适合该功能。因此,单一服务的功能可能会受到较多的技术限制,而无法高效的满足业务的需求。

在微服务架构中,由于服务的独立性,其技术可以根据业务的具体特点来进行独立的选择。另外,由于微服务对异构技术的支持,应用系统可以很方便的引入成熟的技术解决方案,帮助提高系统的开发效率。

  • 自动化

虽然微服务有上述的许多优点,但是它引入比单一服架构多得多的复杂性,例如:一个应用的正常运行依赖于30个服务,当其中一个服务出现问题,那么整个应用也将出现问题。在微服务架构下,单靠人手、人脑已经很难支撑应用的运行。因此需要在部署、测试、监控几个方面进入自动化,在事前、事中控制由于微服务的复杂性带来的风险。

微服务就是SOA吗?

很多人认为SOA的主要核心就是ESB,所以所有应用都应该基于一个标准以帮助应用在ESB上进行通信。但是实际上SOA的核心是功能的合理模块化以及重用,从而可以根据业务的需求,通过模块间的组合快速适应业务的变化。而微服务,其实是实现SOA目标的一种方式,是SOA的一个子集。

服务的粒度

服务粒度的大小也是微服务讨论得比较多的一个问题。这个问题很难有一个绝对的答案,最好的答案应该就是适合你的企业就好。以下有两个标准可以帮你评判服务的粒度是否适合:

  • 服务是否可以被独立的替换而不影响系统其它功能?
  • 服务是否可以被独立升级而不影响系统其它功能?

什么情况适合使用微服务?

如上文所说,单一服务以及微服务并没有孰优孰劣,它们适应不同的场景以及需求,以下是一个针对单一服务以及微服务特点的总结:

有人说微服务就是把大饼切成小饼,但Martin Fowler说微服务不仅如此

使用微服务必要的条件

如果你要使用微服务,确保你已经具备了以下条件:

  • 快速添加计算能力:通过灵活的计算能力调配,最大化微服务的伸缩性
  • 服务监控能力:应对微服务间复杂的网状关系
  • 快速的服务部署能力:适应Devops文化

参考文献


pstrike 2018.05.10 于常州

【尊重版权:转载之前请先联系我】

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 有人说微服务就是把大饼切成小饼,但Martin Fowler说微服务不仅如此

分享到:更多 ()