什么是迷你服务Miniservices?

18-07-24 banq
                   

你真的在用微服务?其实还是在用Miniservices迷你服务呢?

毫无疑问,微服务是现代软件开发中最热门的趋势之一,每个人都在追随并正在使用,但他们真的在用微服务吗?经过进一步认真思考后你会发现,由于缺乏对事件驱动架构了解,很多号称在使用微服务的团队其实是在使用“miniservices(迷你服务、小服务)”。

你还真的使用微服务吗?
Martin Fowler对微服务架构的定义:

1.可独立部署和可扩展的可执行文件
2.有单个职责
3.松耦合

(banq注:按照这个定义第三条,微服务之间必须松耦合,但是这个松耦合松到什么程度?运行时通过服务注册中心相互发现,算不算是松耦合了?至少在云原生应用的规范中这个是满足了,那么从设计上看,尽管服务发现是动态的,但是服务调用还是通过接口耦合,这算不算松耦合?因此这种松耦合判断标准大家是有歧义的。松到只依赖对方接口算不算松耦合?其实这就是RPC,还是松到只依赖对方的JSON数据?这是REST方式,还是松到只依赖对方发生的事件?这就是事件驱动的pub-sub方式,本文观点认为真正微服务是应该基于最松散的事件驱动方式,否则就不是纯粹微服务,而是迷你服务)

Cloud Elements营销副总裁罗斯·加勒特告诉The New Stack,大多数团队都在努力尽可能地分布分散,但他们并没有像他们想象的那样使用尽可能多的微服务。

他说,微服务架构应该是一个基于消息的系统,微服务可以通过这个哑管道彼此异步通信,而现在很多现代开发人员都不熟悉这种消息通信层。很多迹象表明他们又回过头去使用HTTP了。

“HTTP作为一个请求/响应模型是简单的,它很好理解,每个人都能理解如何使用RESTful方式进行通信,”Garrett说,但如何解决Martin Fowler所要求的松散耦合呢? 因为在HTTP中,服务必须事先彼此了解(客户端和服务方都需要彼此了解),因此你必须围绕每个服务编写API接口代码。

Fowler认为这些服务应该完全独立存在,使用HTTP构建服务必须更多地了解它周围发生的事情才能进行通信(banq注:比如掌握JSON或API等知识),并且比定义一个微服务需要掌握更多。

“在真正的微服务架构中,每个服务都应该对其周围的服务没有任何意识,为了实现这一点,必须存在一个非常特殊的通信模式,即pub-sub(发布/订阅模型,不同于RPC同步的生产/消费模型),消息或事件被发布在消息队列中,这样其他人可以订阅消费使用它们,这是最松散的耦合,“加勒特解释道。

“然而,在应用程序开发中,并没有很多开发人员熟悉pub-sub这种消息队列集成模式,因此他们只能回归到使用REST API作为使服务之间通信的一种方式,然后因为他们使用REST,他们必须知道你的所有服务,这样你又失去了松耦合,“他继续说道。

Garrett说,开发人员会在将这些应用拆分成最小功能组件,这些组件仍然让你进行通信,但如果他们使用HTTP通信,则无法完全独立。

加勒特又说,好了,现在是时候接受“miniservices迷你服务”了,大多数公司其实都在使用它们,他说范围或大小并不重要,因为miniservice根本就不是纯粹的微服务。

“[miniservice就像一组微服务以一种小模式聚集在一起。”
- 罗斯加勒特

“这几乎就是一组微服务以一种小模式聚集在一起,因为他们必须彼此了解,”加勒特说。(banq注:迷你服务比微服务颗粒度更大些)

自称为API Handyman的Arnaud Lauret以这种方式划清界限:“miniservice似乎是一种实现微服务更简单、更实用的方式,例如,每个微服务必须处理自己的数据,而miniservices可以共享数据。“

“每个微服务必须处理自己的数据,miniservices可能会共享数据。”
- Arnaud Lauret

这一切都进入了事件驱动架构的世界,通过请求/响应模式对它们关心的事件作出响应。加勒特解释这些服务的动作行为就像:“我必须告诉你一些事情,但我不能只收到一个随机事件”,然后就会偏离微服务架构的样子。

他说,如果你问一个公司他们是否在使用微服务,答案总是“当然”。

“现在流行的更多是关于开发人员对集成模式和技术的理解,而不是人们建立小型服务的愿望,”加勒特说。“我会说,除非你已经使用HTTP作为这些服务进行通信的一种方式,否则你就是在做miniservices迷你服务。”

在架构之前的用例场景
无论你是在进行微型服务、小型迷你服务甚至是单体式系统,这些并不重要,它与你的架构决策的业务影响有关。如果你能够获得所需的解决方案而无需达到纯粹的微服务的话,那就无所谓了。

“不要将完美架构与商业价值混为一谈。”
- 罗斯加勒特

加勒特说,这一切都是为了做出正确的商业决策,理解你为什么要做出改变,以及理解你想要解决的问题。

IT分析公司Gartner的研究开发人员Gary Olliffe最近发表了题为“ 你不是Netflix:如何或何时在企业中使用微服务”的演讲。正如其名称所暗示的那样,Netflix是最具架构性的前瞻性思维之一公司,它们公司面临着特定的挑战,主要是可以通过微服务可以解决,但是,仅仅因为微服务适合他们,却不意味着微服务适合你。Netflix必须了解它们需要公开其服务的不同端点,并且在各种不同约束的不同设备上公开它们。微服务通常是这种情况的正确选择,但就是在这种情况下,他们仍在使用HTTP。

加勒特说这不是微服务的纯粹主义看法,而是微服务在功能上帮助他们正确实现了他们的目标。对我来说,关键点是我如何解决自己的特殊问题以及我有什么技能来解决它​​。“

LaunchAny数字化转型咨询公司创始人James Higginbotham 将这种对微服务的认可看作是朝着正确方向迈出的一步,他称之为“模块化单体”。

“看到模块化思维 - 以及松耦合和高凝聚 - 重新进入我们的软件设计是令人兴奋的。微服务是一个适合少数人的极端,它的教训可能适合许多人。“

“公司可以选择:构建模块化单体架构或使用微服务构建,团队可以有效地分配工作,但微服务架构的原则有助于管理复杂解决方案带来的挑战,“他说。“微服务的缺点是它们将复杂性推向了极端,诀窍是找到适当平衡的地方,反而可以利用复杂性来提高公司的效率。“

何时使用Miniservice vs. Microservice vs. Monolith
微服务工具提供商KintoHub的创始人兼首席执行官Joseph Cooper 分享了他在游戏行业后端解决方案编程方面15年的经验教训,他说他们有一系列独特的问题可以通过miniservices、微服务和单体架构的大杂烩方式来解决。

对于Cooper来说,miniservices就是将一个功能作为一个服务来执行。“miniservice是一个功能即一个服务,”他说。他举了一个例子,“当你使用lambda和Google函数,并且你想要确保最大化节约成本时,比如你不想启动一个完整的函数,而只是想启动你想要的函数。”

他说,当你有更高的复杂性时,miniservices是可靠的解决方案,比如图像处理,他说这是一个非常简单的程序,不需要与其他服务之间进行任何通信。

另一方面,“对于微服务来说,好处是你的产品中包含更多代码,它们可不节约成本(云计算厂商以计算运行时间多少为收费标准),因为您必须实时加载多个函数,或者必须让它们始终运行。“

他继续说道:“有时他们并没有serverless无服务器的味道,[你的服务]一直在运行 ,成本优势会丢失,但好处是在单个服务中提供更多函数,使他们更容易使用和理解。“

如果您的项目在多个代码库中有一个功能,则微服务是一种合理的解决方案,另一方面,Cooper表示,如果您正在运行一个电子商务网站或游戏,您可以在一个存储库中拥有十个或更多功能,有时一个需求功能feature可能需要更多功能配合才能完成,而miniservice更适合这种需求。

并且不要忘记迷你服务不仅仅是微服务发展趋势,而且已经是新兴的、真正现实的服务的解决方案。例如,钓鱼游戏EatMe.io将在一个房间内拥有多达一百名全球并发玩家,游戏在12个不同的亚马逊网络服务区域运行,这扩大了他们面临的最大挑战。除此之外,在15场比赛中,只有7场比赛栩栩如生。为了快速实验和迭代,他们将在整体上进行原型设计,然后分解为miniservices或微服务。

“基于单体monolith概念能更好建立概念证明,因为它更容易管理,然后在你的概念证明之后,你知道你的MVP [最低价值产品]是什么,那么你可以重新开始并用微服务构建它,“Cooper解释道。“有时候你不知道你的产品会是什么样子,如果你是直接在微服务上构建产品,那么你会投入太多时间进行概念验证。”

他还表示,如果游戏的新版本不再出现,但他们想维持当前版本,他们将利用miniservices在最大限度地节省成本。



Miniservices as a Realistic Alternative to Microse

                   

2