什么是迷你服务Miniservices？
你真的在用微服务？其实还是在用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在最大限度地节省成本。