这篇微服务架构入门指南,7岁小孩也能学会
< 返回列表时间: 2019-07-14来源:OSCHINA
【围观】麒麟芯片遭打压成绝版,华为亿元投入又砸向了哪里?>>>
全文共2641字,预计学习时长5分钟

图片来源: unsplash.com/@brookelark
“我们的服务以可扩展的微服务架构为基础”,“我们正准备转向微服务架构”……如果你是一名开发人员,肯定经常听到上面两句话。但不少人都会很困惑——微服务架构到底是个啥?别担心!本指南会用现实生活中的例子让你深刻理解微服务架构——比如,7岁的小朋友都能听懂的冰淇淋的例子!

一个大型冰淇淋机——一体化架构
我们暂时先把微服务架构放到一边,回想一下冰淇淋机的四个部分——冰淇淋勺、坚果粉碎机、巧克力漏斗和草莓糖浆漏斗。冰激凌勺的作用是将一勺香草/芒果冰激凌舀到杯子里,坚果粉碎机顾名思义就是将碎坚果撒在舀出的冰激凌上。而巧克力或草莓漏斗的作用就是把美味的糖浆撒到冰淇淋上。可以看出,整个冰淇淋机里勺以外的配料部分都是顾客可以自由选择的。

大型冰淇淋机——一体化构架的应用
现在假设你是冰淇淋店老板,冰淇淋机虽小但五脏俱全,所有的部分都浓缩到一台机器里。幸运的是,顾客非常喜欢你的冰淇淋,生意越做越大。你会怎么做呢?你会买一个更大的冰淇淋机,可以在一定时间内完成更多的冰淇淋订单。一段时间后,你会发现别无选择了,因为机器制造公司造不出更大的冰淇淋机了。

没有更大的冰淇淋机了——扩展性达到极
这就是开发界所说的一体化架构。一开始的应用程序将所有不同的部分合并到一个代码库中。随着资源需求的增加,你会租用更大的机器,但在某个时间点之后,你已经拥有了当前最大的机器,此时就会达到极限。
多买几个(一体化)冰淇淋机
你肯定会想,可以多买几台冰淇淋机解决这个问题。没错!所以你决定不买最大的冰淇淋机了,而是多买几个小的。
这就是所谓的复制,即用多个应用程序来满足用户的需求。
现在,有了老天的眷顾和你的努力,人们越来越喜欢你的冰淇淋了。为了满足顾客需求,你最终还是得把所有的冰淇淋机都升级到最大的型号。

一体化应用程序的多个实例——复制
修理坏掉的机器
当你刚刚开始生意时,雇用了一名技术人员,负责修理或升级机器。一切都很顺利。但是买了多台冰淇淋机后,你觉得需要雇用更多的技术人员,因为你也不想让顾客吃不到冰淇淋。
现在根据顾客的需求,你决定销售一种新口味的冰淇淋:在冰淇淋勺里加入巧克力味冰淇淋。但是,由于每台机器的四个部分都相互依赖,技术人员很难添加新口味的冰淇淋。但通过某种方法技术人员成功了,不过新口味的冰淇淋一加进去,草莓漏斗就停止工作了,因为冰淇淋机的每个部分都是相互依赖的,修改一个部分就破坏了另一个部分。

一个更新破坏了其他部分——黄色代表巧
每台机器只有一个用途——微服务架构
由于扩展性的限制,你决定建立一个新的冰淇淋机结构。你要求机器制造商公司提供四台机器,一台只负责一个部分。一台冰淇淋勺机,一台坚果粉碎机,巧克力和草莓糖浆漏斗机各一台。现在,你将技术人员分配到独立的团队中,每个团队只负责一台机器。

将大型机器、团队分离成独立的零部件机器和各自的技术团队——微服务架构
这就是微服务架构,其中一个大的一体化应用程序被划分为独立的模块,每个模块又是一个单独的应用程序,专门执行特定的任务。
一体化架构VS微服务架构
· 可扩展性:你可能已经注意到了,在购买了最大的冰淇淋机之后,就不能再扩大规模了。而把大型机器划分为多个零部件机器(微服务架构)后,还可以继续为单个零部件机器设立多个微服务机器。
· 维护:由于在一体化冰淇淋机中每个部分都是相互依赖的,因此上述例子中,添加新的口味就会破坏草莓漏斗。例如,如果应用程序的一个模块需要更改数据库模式,那么就可能会破坏应用程序的其他部分。但是,在微服务架构中,你已经为每个零部件机器分配了独立的团队,每个团队负责维护各自的零部件机器功能,由于零部件机器的独立性避免了冲突。这种独立的开发也有助于快速发挥机器的特性,因为相较于大型组织中团体间的沟通,团队内部沟通更加迅速。
· 成本:你可能会想,虽然多个大型冰淇淋机解决了扩展性问题,但是如果只想提高冰淇淋勺的产量而非其他部分该怎么办?在一体化冰淇淋机中,每次都必须买一整台机器,但是如果你选了微服务零部件机器,可以只买多个冰淇淋勺机(复制)。这样就能节省成本,因为你可以根据该服务上的请求负荷,增减单个服务器实例的数量。
· 安装时间:由于一体化冰淇淋机集成了所有部件,只要将其放在正确的位置就能使用了。然而,微服务零部件机器在使用之前需要连接,比如在冰淇淋的例子中就需要传送带。因此,微服务需要更多的时间和专业知识来安装,因为只有每个独立的部分相互交流才能正常运行。
· 测试与部署:测试和部署一体化冰淇淋机非常困难,因为所有的部件都是相互依赖的,只有在每个部件都集成好之后,才可以进行测试和部署。然而,在微服务零部件机器中,每个零部件机器都是独立的,因此测试和部署单个部件会更加容易。
要不要一开始就使用微服务架构?
简而言之,不要!大多数专家建议,如果不需要微服务架构,那就不要用。为什么不先用一体化冰淇淋机留住客户,等到难以维护或规模无法扩大之后再用微服务架构呢?等到这个时候,再把一体化机器分解为独立的微服务零部件机器。
微服务不总是“微”型的
你可能会觉得,如果真到了为冰淇淋店准备微服务零部件机的阶段,那么这些机器肯定会变成小型的零部件机。不是的!每个微服务零部件机器本身就可以是一台大型机器,也可以是多台复制机器同时运行以满足用户需求。比如说,如果大多数顾客只喜欢原味冰淇淋,不加任何调料,那勺子机器可能有20个勺子在同时运行。
同样,微服务架构本身也可以是独立的应用程序,规模绝不小,需要大量的努力来维护和扩展。
总结
目前几家正在使用微服务架构的大型软件公司,都是从使用一体化应用程序开始的。一旦它们达到了可扩展性和可维护性的极限,它们就会将一体化机器分解为独立的部件或服务。
毫无疑问,微服务架构可以让你针对不同的服务使用不同的技术,并更好地扩展和维护机器,但所有这些都具有很大的系统开销和复杂性,需要完备的专业知识。因此,从一个结构良好的一体化冰淇淋机开始,而不是直接从微服务架构开始总是好的,省得让自己陷入“意想不到的复杂性”之中。 留言 点赞 关注
我们一起分享AI学习与发展的干货

欢迎关注全平台AI垂类自媒体 “读芯术”在这里插入图片描述
添加小编微信:dxsxbb
即可进微信交流群
热门排行