网站导航

技术文章

当前位置:主页 > 技术文章 >
讨论微服务之前,你知道微服务的 4 个界说吗?
时间:2021-08-04 00:24 点击次数:
本文摘要:关于“什么是微服务”的问题,其实并没有一个统一的认识。这些年在差别的场所里和差别配景的朋侪都在探讨微服务。 但聊得越多,越发现大家聊的不是同一回事。和 DevOps 一样,“微服务”也是一个内在十分广泛的词。本文从“Microservice“这个观点的源头出发,总结了 4 个常用的微服务界说。

华体会体育app

关于“什么是微服务”的问题,其实并没有一个统一的认识。这些年在差别的场所里和差别配景的朋侪都在探讨微服务。

但聊得越多,越发现大家聊的不是同一回事。和 DevOps 一样,“微服务”也是一个内在十分广泛的词。本文从“Microservice“这个观点的源头出发,总结了 4 个常用的微服务界说。James Lewis 原始版的微服务 6 大特征这个版本起源于2012年,这里首先要注意年份,那时候还没有 Docker,而且 Netflix 的微服务化历程也在这个观点提出之前——2008年就开始了,那时候甚至连 DevOps 还没发现出来。

James Lewis 在波兰第 33 次 Degree in Kraków 集会上分享了一个案例,名称是 “Micro Services – Java, the Unix Way”。在这个分享里, James Lewis 分享了在 2011 年中到场的一个项目中所接纳的一系列实践,以 UNIX 的哲学重新看待企业级 Java 应用法式,而且把其中的一部门称之为“ Micro-Services ”。这个时候的微服务所用的单词和我们现在所用的 Microservices 这个单词有所差别。

一方面,接纳 Micro 作为形容词,是和 Monolithic 相对,而不是和 Macro 相对是源于操作系统这门大学课程。我们知道,现代的操作系统课程都是以 UNIX 作为案例举行解说的。

而这两个单词来自于“微内核”(Micro-Kernel)和“宏内核”(Monolithic kernel)的比力。而很是见的“微观经济学”和“宏观经济学”中的 Micro 和 Macro 两个相对应的单词。另一方面,服务要以复数形式泛起,表现的是一个以上。

由于汉语里单复数是同型的,所以我们在翻译的时候会泛起问题。因此,“微服务”在作为架构的形式泛起的时候,我们会用“微服务架构”称谓。单个的微服务从观点上为了和 SOA 以及其它领域的“服务”有所区分,会以“单个微服务”以示区别。

而“微服务”单独拿出来是被看作为一系列技术实践的总称。在这个分享里,James Lewis将所实践的“微服务架构”总结为 6 大特征:Small with a single responsibility —— “小到只有单一原则”。在这个特征里,关于微服务有多小有两个尺度:第一个尺度是如果一个类庞大的凌驾一个开发人员的明白规模,那么它就太大了,需要被继续拆分。

第二个尺度是:如果它小到可以随时抛弃并重写,而不是继续维护遗留代码,那么它就足够小。这个尺度有个很重要的原则就是 Rewrite over Maintain,即“重写胜于维护”。Containerless and installed as well behaved Unix services —— “去容器化而且作为 Unix Service 安装”。

在这个特征中,James Lewis 提倡接纳 Jetty 这样的工具集成到 Maven 里,可以很利便的调试或者部署,然后打包成一个可执行的 JAR 包并以 UNIX 守护历程的方式在系统启动时执行。特别是在 AWS 这样的公有云情况下,把这样的应用法式和虚拟机实例的初始化剧本联合在一起。使得应用法式的生命周期和虚拟机的生命周期绑定成为一体,由于守护历程在所有 Unix 系统中都是通用的,因此简化整体架构的开发和运维。

Located in different VCS roots ——“漫衍在差别的版本控制代码库里”。在这个特征中,James Lewis 提到了应用法式的分散,他认为一个“微服务”应该完全和另外一个服务实现彻底的隔离,这里固然是指的从开始的代码库就开始隔离了。他同样也要求开发人员看到相似性和抽象,并接纳单一的领域来指导开发团队的开发。

因此接下来他继续讨论了领域驱动设计领域驱动设计和康威定律的重要性。他认为界线上下文要足够的清晰,但可以有所重合。如果没有措施做到领域之间很清晰,就通过“物理上的手段”——分散差别的团队来做到这一点。

这不行制止的带来一些公共代码,但要把这些公共代码作为“库”和“基础设施即代码”来看待,就像你代码中用到的开源软件。并搭建一个 nexus 库来存储那些二进制依赖Provisioned automatically ——“自动初始化”。自动初始化的要点不在于如何自动化,因为差别的应用差别的平台有差别的初始化方式。这里的重点在于治理漫衍式应用的庞大性。

所以对于每个服务,能够接纳声明出这些初始化。例如:服务 A,需要一个 负载平衡,而且可以自动扩展。

服务 B,也是同样的声明方式。而这些声明可以用基础设施即代码技术很好的治理起来。

Status aware and auto-scaling ——“关注状态和自动扩展”。在这里,他认为这些应用应该是能够感知吞吐量的监控指标来自我举行扩展的。

对于一个现代的应用而言,这是一个基本的架构性要求,但这需要团队有一定的 DevOps 能力。因为这不光要求开发人员能够让应用无状态化,而且要求基础设施可以实时捕捉情况的变化。They interact via the uniform interface —— “它们通过统一花样的接口举行交互”。

在这里,James 建议大家接纳已经成熟的 HTTP 协议以及尺度的媒体类型举行接口交互,而不是接纳其它的方式。而且接纳HATEOAS(Hypermedia As The Engine Of Application State) 的方式构建 Restful API,使其成为一个超媒体的应用状态引擎。

这样就可以将状态和执行历程隔离区离开来,越发容易举行水平扩展。此外,它也构建了一个制止架构孵化的层,可以独立于客户端连续演进。在总结的时候,它特意提到了 UNIX 哲学。

这引用自Doug McIlroy 的一篇采访:Everybody started putting forth the UNIX philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface.” Those ideas which add up to the tool approach, were there in some unformed way before pipes, but they really came together afterwards. Pipes became the catalyst for this UNIX philosophy. “The tool thing has turned out to be actually successful. With pipes, many programs could work together, and they could work together at a distance.”从这段话里,我们看到了“微服务架构”和 UNIX 哲学之间的关联:职责独立:让多个法式(注意是 Programs 不是 Program)做好一件事。统一接口:文本流是统一的接口,每个法式都可以通过统一的接口举行消费。公共通信:接纳管道(pipe)的方式可以说,微服务架构自己是对 UNIX 哲学在企业级 Java 应用系统中的另一个案例。

可以说,虽然应用场景变了,但 UNIX 剖析庞大度的方式和保持简朴的理念并未改变。最后,James Lewis 把上述六点特征酿成了一个六边形的业务能力:Hexagonal Business capabilities composed of: Micro Services that you can Rewrite rather than maintain and which form A Distributed Bounded Context. Deployed as containerless OS services With standardised application protocols and message semantics Which are auto-scaling and designed for failure翻译过来就是:微服务可以通过重写而非维护一个漫衍式的界线上下文,且作为一个无应用容器的操作系统服务部署。并以尺度化的应用协议和消息语义,为失败设计且可自动扩展。

Martin Fowler & James Lewis 互助版的微服务 9 大特征由于在 James Lewis 之后,有许多差别的项目也接纳“微服务”作为它们的实践名称。然而,差别项目之间还是存在一些差异的,且每小我私家都根据自己的方式在实践“微服务”。因此,基于“求同存异”的原则,Jame Lewis 的同事 —— 台甫鼎鼎的 Martin Fowler 接纳一种归纳的方式来解决这个问题:他认为“界说”是一些“共有的特征”(Common characteristics)。Martin Fowler 继续接纳了 James Lewis 对这一系列实践的命名,而且做了修改,使之成为一个单独的名词 —— Microservices。

所以,他将微服务总结为以下9大特征:通过服务组件化围绕业务能力组织是产物不是项目智能端点和哑管道去中心化治理去中心化数据治理基础设施自动化为失效设计演进式设计这 9 大特征的中文版详细内容请参考这里,限于篇幅原因,本文不展开讨论。我们可以从中看出,Martin Fowler 试图将 James Lewis 的微服务界说举行一般化推广,使其不光可以在差别的语言架构和技术栈上使用。又可以兼顾敏捷、DevOps 等其它技术,成为一个架构的“最佳实践”荟萃。但这样一组实践本质上并没有太多的创新,只是把我们自己知道的许多架构和设计的原则联合在当前的技术栈上举行了一次整体的组合和应用。

恰逢一系列互联网公司的乐成事迹带来的新实践(连续交付、DevOps)和新技术(Docker)在履历了早期实践者(Early Adopter)实践积累后的效果井喷后。这样的最佳实践的集中反映虽然获得了技术人员的掌声。然而,这种界说对于妄图接纳“微服务架构“的人来说是一个很高的门槛。

如果这样的 9 个特征的总结是对”微服务架构“的界说。那么,为了要满足以上的 9 个界说,则需要花费很大的精神来举行革新,而且已经超出了技术升级和企业 IT 部门的职责规模。此外,即便我们知道其中每个特征所带来的收益,但却很难拿出案例和数据去佐证满足这 9 个特征的革新收益。

避开这 9 个特征的观点正交性不谈,即便这 9 个特征可以从既有的效果往返答”什么(What)是微服务“,但却没有给出“为什么(Why)要满足这些特征”和”如何(How)同时满足这些特征”。如果自己挖的坑填不了,就教给别人来填吧:Sam Newman 版微服务的两大特征和 7 个原则同样作为 Martin Fowler 的同事,Sam Newman 在其著作 “Building Microservice”(中文译名为“微服务设计”)的第一章就重新回覆了”什么是微服务架构“并回覆了”为什么要接纳微服务架构“的问题。Sam Newman 在书中是这么界说微服务的(《微服务设计》的翻译):微服务就是一些协同事情的小而自治的服务。

Sam Newman 自述的微服务的界说越发简朴,包罗了两个特征:“小” 和 “自治”。除了继续 James Lewis 关于微服务应该有多小的形貌以外(固然,巨细都是基于小我私家的主观判断),还缔造性的用康威定律来约束微服务的巨细,即“能否和团队结构相匹配”:如果你的团队维护单个服务很吃力,需要保持团队巨细稳定的情况下还对维护事情游刃有余,那么这个服务就需要继续被拆分。而“自治” 则很审慎的把 Martin Fowler 微服务界说的 9 大特征中的“去中心化”、“独立” 、”松散耦合“等字眼举行了统一。

并进一步解释到“一个微服务就是一个独立的实体”。而且从外部,也就是黑盒的角度来看每个切合”自治”的单个微服务所具有的特征,即:可以独立部署。通过网络通信。对消费方的透明。

尽可能降低耦合,使其自治。此外,他还接纳了更简朴的“黄金规则”来判断期”自治性”。即能否修改一个服务并对其部署,且不影响其他任何服务。

如果谜底是否认的,说明你的微服务还不够”自治“。从 Sam Newman 的界说中,我们可以推导出“微服务”的几个基本事实:微服务架构是一个漫衍式系统架构。

华体会app下载

微服务是微服务架构的基本单元。网络隔离是“须要的”解耦手段。

微服务的业务功效从观点上是完整的,并切合用户角度的“独立”认知。简而言之,以上的两个特征的表述主要是将微服务从逻辑架构上和部署架构上都看作是一个正交的原子功效单元。

而要做到这一点,则需要而要把整个应用系统正确的建模到这个条理,则需要参考许多的内部外部因素。此外,为了到达“小”和“自治”的目的,Sam Newman 还总结了 7 条原则用来在实施的时候和详细实践联合,划分是:围绕业务观点建模接受自动化文化隐藏内部实现细节让一切都去中心化可独立部署隔离失败高度可视察可以看出,Sam Newman 把 Martin Fowler 的 9 大特征用越发详细的术语来重新形貌,而且从逻辑上处置惩罚了 Martin Fowler 微服务 9 大特征中观点重复和不明确的部门,使其更简朴和明确而且越发可操作。例如把“去中心化的数据治理” 和 “去中心化治理”合并为“让一切都去中心化”等。

更重要的是,Sam Newman 提出了接纳微服务技术的主要利益,告诉了我们“为什么要用微服务”:技术异构性:接纳更合适的技术栈灵活的处置惩罚局部问题。弹性:这里的“弹性”是弹性工程学的观点,指的是局部失败会被隔离,使得整体不会失败。扩展:可以凭据系统的部门组件按需扩展。简化部署:这里简化部署不是指的是部署的拓扑结构,而是通过连续的小批量、小规模的部署来降低整体失败的风险。

与组织结构相匹配:微服务架构可以让组织的团队转化为合适的巨细,并接纳透明的制度来举行规范和复制。制止团队的人数增长而带来更多的治理层,使组织熵的上涨。

可组合性:由于各个微服务间不存在依赖关系,所以可以凭据用户界面的情况举行灵活的调整和复用,制止对单体应用举行整体的大规模调整。对可替代性的优化:由于风险和领域越发独立和隔离。因此,扬弃一个微服务并重写的成本并就变的十分低廉。

Chris Richardson 的“微服务架构模式”2017 年,Chris Richardson 使用 Microservices.io 域名开始推广自己的微服务理念。他是这样界说微服务的:Microservices – also known as the microservice architecture – is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The microservice architecture enables the continuous delivery/deployment of large, complex applications. It also enables an organization to evolve its technology stack.中文翻译过来,大意如下:微服务,也就是微服务架构。是一种用于把一个应用法式结构化为一个实现业务功效的松散耦合的服务荟萃的架构气势派头。

微服务架构使得在大型、庞大的应用法式中实现连续交付和连续部署成为可能。它使得组织可以演进自己的技术栈。在 Chris Richardson 接纳了较为简朴的架构界说和准确的目的界说相联合的方式来界说”微服务架构“:它一方面简朴的把微服务架构界说成一个实现业务功效的松散耦合的服务荟萃,另一方面又以十分详细的目的和效果(连续交付/连续集成)来约束这样一个松散耦合系统的效果:组织可以演进自己的技术栈。

Chris Richardson 将“单体架构”和“微服务架构”看做两种架构模式。而且在同样的上下文中对二者各自的优劣举行了比力。越发重要的是,Chris Richardson 接纳 AFK 扩展立方来拆分微服务从而回覆了“如何做微服务”的问题。值得注意的是,Chris Richardson 所接纳的例子虽然在同样的上下文中,但由于特征差别并不具备可比力性。

因此,他接纳了在“单体架构模式”(Pattern: Monolithic Architecture)的基础上形貌其局限性的方法引出了“微服务架构模式”(Pattern: Microservice Architecture)。严格的说,Chris Richardson 的“单体架构模式”是一种对现状的和举例,并没有给出其特征和方法的形貌,因此不能称之为模式。

而“微服务架构模式”则又是一系列模式的总和,如下图所示:从这个角度看,Chris Richardson 的这些模式并没有突破 Sam Newman 在《微服务设计》中总结出的实践。但相较于我们所知道的微服务的优点。

Chris Richardson 也列出了微服务的缺点:开发者的 IDE 对漫衍式系统的在线开发和调试相对于单体应用架构来说并不友好。测试越发难题。开发者必须实现跨服务的通信机制。不接纳漫衍式事务来跨服务构建业务是十分难题的。

需要举行跨团队的协调事情。部署越发庞大。更多的内存消费,对于 Java 应用来说,独立的部署意味着无法共享 JVM 的内存治理。

相较于之前的微服务界说而言, Chris Richardson 的微服务体系比力完整,而不仅仅是总结和枚举实践。Chris Richardson 的”微服务架构模式”不光回覆了“什么是(What)微服务”,也回覆了“为什么(Why)要用微服务”,“什么时候(When)用微服务”,“什么场景(Where)下”以及“如何(How)实现微服务”的问题。Chris Richardson 还编写了一套微服务的指南,可以在这里检察。比“什么是微服务”更重要的事本文总结了微服务常见的 4 个界说。

但比这些界说更重要的是你为什么要用微服务?你想从微服务中获得什么益处?你是否相识为了追求这些益地方带来的价格?如果不先明确这些问题,在不明白微服务架构或者技术所带来的的风险和成本。盲目的接纳所谓的微服务,可能带来的效果并不理想。

不外,在讨论这些问题之前,坐下来统一一下对微服务的明白,会提升我们讨论和实践微服务的效率。文/顾宇原文:https://insights.thoughtworks.cn/four-definitions-of-microservices/。


本文关键词:讨论,微,服务,之前,你,知道,的,个,界说,吗,华体会体育app

本文来源:华体会体育app-www.sh-shangda.com

如果您有任何问题,请跟我们联系!

联系我们

Copyright © 2007-2021 www.sh-shangda.com. 华体会体育app科技 版权所有 备案号:ICP备40378432号-8

地址:湖南省衡阳市珠晖区一程大楼9067号

在线客服 联系方式 二维码

服务热线

078-661562655

扫一扫,关注我们