向 5 岁儿童解释清楚微服务 ！

“我们的服务由可扩展的微服务架构支持”，“我们计划切换到微服务架构”。

如果你是一名开发人员，那么你一定经常遇到这些术语，并且肯定会试图理解——什么是微服务？别担心！本文将通过真实的例子帮助你深入理解微服务架构。不用担心！我这篇文章中没有任何代码 ！

大型冰淇淋机——Monolith

暂时忘掉微服务，考虑一下一台冰淇淋机，它有四个部分——冰淇淋勺、坚果切碎机、巧克力漏斗和草莓糖浆漏斗。冰淇淋勺将一勺香草/芒果冰淇淋加到杯子里，顾名思义，坚果切碎机将切碎的坚果撒在冰淇淋勺上。巧克力或草莓漏斗将所需的液体糖浆倒在冰淇淋勺上。除了冰淇淋勺（来自勺子部分），所有配料都是客户可选的。

作为冰淇淋店的老板，您从一台小型冰淇淋机开始，这台机器上嵌入了所有这些部件。幸运的是，人们开始喜欢您的冰淇淋，您的业务也随之增长。您会怎么做？您可以选择购买一台更大的机器，可以在给定的时间内完成更多的冰淇淋订单。但是总有一天您会没有选择，因为冰淇淋机器制造商公司已经没有比您当前机器更大的机器了。

这就是软件开发世界中所谓的单体架构。你开发了一个应用程序，该应用程序的所有不同部分都合并在一个代码库中。随着需求的增加，你购买了性能更强大的机器，但在某个时间点上，总会达到一个极限，当你已经拥有了性能最强的机器之后，就没办法再扩展了。

购买更多 (Monolith) 冰淇淋机

您一定在想，通过购买多台冰淇淋机就可以避免这种情况。您说对了！因此，您决定不购买功能最强大的冰淇淋机，而是购买多台小型冰淇淋机。这就是所谓的克隆，对应于软件世界，就是您可以使用应用程序的多个实例来满足用户请求。

修理损坏的机器

创业之初，您聘请了一名技术人员，负责修复机器出现的问题或升级机器。一切都进展顺利。但当您购买了多台机器后，您觉得需要聘请更多技术人员，因为你永远不想对你的顾客“不可用”。

现在，应客户要求，您决定销售一种新的冰淇淋口味。您决定在冰淇淋勺中添加巧克力冰淇淋。但由于每台机器的所有四个部件都相互依赖，你的技术人员在添加新冰淇淋口味时遇到了困难。

但他们设法达到了目标，但是当他们完成新口味的整合后，草莓漏斗停止工作了，因为机器的部件是相互依赖的，修改一个部件会破坏另一个部件。

每台机器只有一个目的——微服务

由于可扩展性有限并且难以维护，您决定换一种思路。您要求机器制造商为这四个部分提供单独的零件机器。一台冰淇淋勺零件机器、一台坚果切碎机零件机器、两台漏斗零件机器，分别用于巧克力和草莓糖浆。现在，您将技术人员分配到独立的团队中，每个团队负责一台单独的零件机器。

这在软件世界里被称为微服务架构，其中，大型整体应用程序被划分为独立的模块，每个模块都独立作为一个应用程序，专注于执行特定的任务。

整体式架构与微服务

可扩展性： 您可能已经注意到，采用单体式冰淇淋机，到达一定程度后就无法再进行扩展。而使用单独的部件机器（微服务），只要业务需要，您几乎可以无限扩展，

维护： 在单体式冰淇淋机中添加新的冰淇淋口味会破坏草莓漏斗，因为其组成部件相互依赖。与此类似，如果单体应用程序的一个模块需要更改数据库模式，那么这样做可能会破坏应用程序的其他部分。但是，在微服务架构的情况下，您已为每台零件机器分配了单独的团队，每个团队负责他们控制的零件机器的运行，避免了由于零件机器的相互依赖性而产生的冲突。这种独立开发还有助于快速发布功能，因为大型组织中的团队内部沟通比团队间沟通更快。

成本： 您可能想知道通过拥有多台大型冰淇淋机是否解决了可扩展性问题，但请考虑这样一种情况：您只想增加铲子的输出，而不增加任何其他部件的输出。在单体式冰淇淋机场景中，您每次都必须购买整台机器，但如果您拥有微服务部件机器，那么您只需要购买铲子部件即可。这将节省您的成本，因为您可以根据具体服务的请求负载扩大或缩小每个独立服务的实例。

时间： 由于整体式冰淇淋机自带所有部件，您只需将其放在正确的位置并开始使用即可。但是，微服务部件机器在实际使用时需要通过传送带（在冰淇淋场景中）进行连接。与此类似，微服务架构中，不同服务之间需要相互通信才能完成工作，有网络开销。因此，微服务需要更多时间，

测试和部署： 单片冰淇淋机的测试和部署非常麻烦，因为所有部件都是相互依赖的，只有当每个部件都集成在一起时，您才能对其进行测试和部署。然而，在微服务部件机中，每个部件机都是独立的，因此测试和部署单个部件变得更容易。

我应该直接从微服务开始吗？

这个问题的简短答案是“不”！大多数专家建议，如果你不需要微服务架构，那么就不要这样做。不要过度设计 ！

微服务并不总是“微”的

您可能会觉得，如果您的冰淇淋店已经拥有独立的零件机器，那么这些机器就只是小型零件机器。不！每台零件机器本身都可以是一台大型机器，或者它可能有多个克隆机器并行运行以满足用户需求。

例如，考虑到大多数客户只喜欢冰淇淋而不喜欢配料，您的铲子零件机器可能有 20 个铲子并行运行。类似地，微服务本身可以是独立的应用程序，这使得它们不那么“微”，并且需要大量的努力来维护和扩展它们。

结论

目前正在使用微服务架构的几家大型互联网公司都是从单体应用开始的。一旦达到可扩展性和可维护性的极限，他们就会将单体应用拆分成独立的组件/服务。

毫无疑问，微服务架构允许您为不同的服务使用不同的技术，以便更好地扩展和维护，但所有这些都带来了开销复杂性，并且需要良好的专业知识。因此，从结构良好的整体式冰淇淋机开始永远是件好事，而不是直接从微服务架构开始并让自己陷入“意外复杂性”。

完全整理 | 365篇高质技术文章目录整理

一张图弄清楚缓存架构设计中的经典问题及解决方案

一张图总结系统设计中的33个黄金法则

主宰这个世界的10大算法

彻底理解cookie、session、token

专注服务器后台技术栈知识总结分享