作为一名开发者，你肯定经常听到像“我们采用了可伸缩的微服务架构”、“我们正在计划切换到微服务架构”之类的话，然后你寻思着：微服务到底是什么？不用担心，这篇文章将通过真实世界的比喻来解释什么是微服务架构。但请注意，这篇文章只讲跟微服务架构有关的东西，没有代码！
大冰激凌机——单体
我们暂且把微服务搁在一边，先来看看冰激凌机。冰激凌机由四个部件组成——冰淇淋勺、坚果粉碎器、巧克力漏斗和草莓糖漏斗。冰淇淋勺往杯子里添加香草或芒果冰激凌，坚果粉碎器将碎坚果撒在冰激凌上，巧克力或草莓漏斗把液体糖浆倒在冰激凌上。对于顾客来说，除了冰激凌勺之外，其他都是可选的。
假设你是冰激凌店的老板，一开始你有一台小冰激凌机，这个冰激凌机配备了所有上述的四个部件。顾客很喜欢你家的冰激凌，你的生意越来越红火。那么接下来你会怎么做？你会买一台更大的冰激凌机，这样就可以在同样的时间内做出更多的冰激凌。按照这样的节奏发展下去，终有一天你会没办法再扩大规模，因为工厂生产不出更大的冰激凌机了。
在软件开发领域，这个就是所谓的单体架构。一个包含了所有组件的应用程序，代码都存放在一个代码基库里。随着需求的增长，你租用了越来越大的机器，但到了某个时刻肯定会达到极限，因为你租不到比目前更大的机器了。
购买更多的冰激凌机
你一定会想到通过购买更多的冰激凌机来解决这个问题。没错！你放弃了购买更大的冰激凌机的想法，而是购买更多小型的冰激凌机。
这就是所谓的“克隆”，你使用多个应用程序实例来处理用户请求。
因为上天的眷顾，也因为你自己的努力，顾客开始对你家的冰激凌爱不释手了。为了满足他们的需求，你最终不得不把所有的冰激凌机都升级到更强大的型号。
修理坏掉的机器
在刚开店的时候，你只聘请了一名负责维修和升级机器的师傅，这没有问题。但在购买了多台机器之后，你觉得有必要聘请更多的师傅，因为你不希望有机器坏了影响生意。
现在，有顾客希望你家的店能够增加不同口味的冰激凌。你决定在冰激凌勺里增加巧克力冰激凌。但因为冰激凌机的四个部件相互依赖，维修师傅忙得团团转。等他们好不容易加好了新口味的冰激凌，草莓糖漏斗却坏了，因为部件之间相互依赖，动了其中一个就会影响到其他部件。
每台机器各司其职——微服务
因为伸缩性受到了限制，你决定搭建新的基础设施。你要求工厂把原先冰激凌机的每个部件独立成单独的机器——一个冰激凌勺机，一个坚果粉碎机，两个漏斗机（一个可以流出巧克力，一个可以流出草莓糖）。现在，你把维修师傅分成几组，每一组负责不同的机器。
这就是所谓的微服务架构，大单体被拆分成多个独立的模块，每个模块都是一个应用程序，负责处理不同的任务。
单体与微服务
伸缩性：你可能已经注意到了，在购买了最大型的冰激凌之后，你就没办法再扩大规模了。但有了单独的部件机器（微服务）之后，你可以购买更多的部件机器。
可维护性：为了给冰激凌机增加新口味的冰激凌，却不小心弄坏了草莓糖漏斗，因为一个大单体系统的不同部分通常是相互依赖的。举个例子，一个应用程序的某个模块需要修改数据库结构，而这样做可能会影响到应用程序的其他功能。不过，在微服务架构里，不同的机器由不同的团队负责，每个团队管好自己管控的机器，避免了冲突。这种独立的开发模式也加快了发版的速度，因为在一个大型的组织里，团队内的沟通比团队间的沟通效率更高。
成本：你可能会想，多买几台大冰激凌机不就能解决伸缩性问题吗？但也请试想一下，如果你只想增加冰激凌口味并保持其他部分不变，但你却不得不为此购买整套机器。但在微服务机构中，你可以只买冰激凌勺机。这样就节约了很多成本，因为你可以根据每个服务的请求量来增加或者减少单个服务的实例数量。
就绪时间：大冰激凌机已经把所有的部件都集成好了，只要把它放在正确的地方启动它就可以了。但是，独立的部件机器在使用之前需要使用传送带把它们连接在一起。因此，微服务需要更多的时间和专业知识才能让它运行起来。
测试和部署：大冰激凌机的测试和部署相对困难，因为所有的部件相互依赖，需要每个部件都集成好了才能测试和部署。但对于部件机器来说，因为每种机器都是独立的，所以测试和部署也相对容易。
该不该从一开始就采用微服务？
简单地说就是——不需要！大多数专家建议，如果你不需要微服务架构，就不要用它。你完全可以一直使用大冰激凌机，直到无法维护和伸缩。到了那个时候，你可以把大单体机器拆分成单独的微服务部件机器。
微服务并不都是“微型”的
你可能会想，到了冰激凌机都变成单独的部件机器之后，这些部件机器应该都很小。但事实上并非如此！微服务本身也可以很大，或者单个服务可以有多个同时运行的实例来处理用户请求。例如，你可能会有 20 台冰激凌勺机，因为大部分顾客可能只需要冰激凌，不需要浇头。
同样的，微服务也可以作为独立的应用程序，它们不一定是“微型”的，而且需要大量的维护和伸缩成本。
结论
一些正在采用微服务架构的大型软件公司最早都是从一个大单体开始的。他们在达到了伸缩性和可维护性极限之后才将单体拆分成单独的组件或服务。
毫无疑问，在采用微服务架构时，你可以使用不同的技术来开发不同的服务，具备了更好的伸缩性和可维护性，但这是以复杂性为代价的。因此，刚开始可以采用设计良好的单体，而不是一上来就直接奔着微服务去，避免让自己置身于微服务的复杂性泥潭之中。
原文链接
Beginner’s Guide to Microservices: Explaining it to a 5 Year Old
（文章转载自InfoQ）
