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