这篇微服务架构入门指南，7岁小孩也能学会

全文共2641字，预计学习时长5分钟

图片来源：unsplash.com/@brookelark

“咱们的服务以可扩展的微服务架构为基础”，“咱们正准备转向微服务架构”……若是你是一名开发人员，确定常常听到上面两句话。但很多人都会很困惑——微服务架构究竟是个啥？别担忧！本指南会用现实生活中的例子让你深入理解微服务架构——好比，7岁的小朋友都能听懂的冰淇淋的例子！

一个大型冰淇淋机——一体化架构

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

大型冰淇淋机——一体化构架的应用

如今假设你是冰淇淋店老板，冰淇淋机虽小但五脏俱全，全部的部分都浓缩到一台机器里。幸运的是，顾客很是喜欢你的冰淇淋，生意越作越大。你会怎么作呢？你会买一个更大的冰淇淋机，能够在必定时间内完成更多的冰淇淋订单。一段时间后，你会发现别无选择了，由于机器制造公司造不出更大的冰淇淋机了。

没有更大的冰淇淋机了——扩展性达到极

这就是开发界所说的一体化架构。一开始的应用程序将全部不一样的部分合并到一个代码库中。随着资源需求的增长，你会租用更大的机器，但在某个时间点以后，你已经拥有了当前最大的机器，此时就会达到极限。

多买几个（一体化）冰淇淋机

你确定会想，能够多买几台冰淇淋机解决这个问题。没错！因此你决定不买最大的冰淇淋机了，而是多买几个小的。

这就是所谓的复制，即用多个应用程序来知足用户的需求。

如今，有了老天的眷顾和你的努力，人们愈来愈喜欢你的冰淇淋了。为了知足顾客需求，你最终仍是得把全部的冰淇淋机都升级到最大的型号。

一体化应用程序的多个实例——复制

修理坏掉的机器

当你刚刚开始生意时，雇用了一名技术人员，负责修理或升级机器。一切都很顺利。可是买了多台冰淇淋机后，你以为须要雇用更多的技术人员，由于你也不想让顾客吃不到冰淇淋。

如今根据顾客的需求，你决定销售一种新口味的冰淇淋：在冰淇淋勺里加入巧克力味冰淇淋。可是，因为每台机器的四个部分都相互依赖，技术人员很难添加新口味的冰淇淋。但经过某种方法技术人员成功了，不过新口味的冰淇淋一加进去，草莓漏斗就中止工做了，由于冰淇淋机的每一个部分都是相互依赖的，修改一个部分就破坏了另外一个部分。

一个更新破坏了其余部分——黄色表明巧

每台机器只有一个用途——微服务架构

因为扩展性的限制，你决定创建一个新的冰淇淋机结构。你要求机器制造商公司提供四台机器，一台只负责一个部分。一台冰淇淋勺机，一台坚果粉碎机，巧克力和草莓糖浆漏斗机各一台。如今，你将技术人员分配到独立的团队中，每一个团队只负责一台机器。

将大型机器、团队分离成独立的零部件机器和各自的技术团队——微服务架构

这就是微服务架构，其中一个大的一体化应用程序被划分为独立的模块，每一个模块又是一个单独的应用程序，专门执行特定的任务。

一体化架构VS微服务架构

· 可扩展性：你可能已经注意到了，在购买了最大的冰淇淋机以后，就不能再扩大规模了。而把大型机器划分为多个零部件机器（微服务架构）后，还能够继续为单个零部件机器设立多个微服务机器。

· 维护：因为在一体化冰淇淋机中每一个部分都是相互依赖的，所以上述例子中，添加新的口味就会破坏草莓漏斗。例如，若是应用程序的一个模块须要更改数据库模式，那么就可能会破坏应用程序的其余部分。可是，在微服务架构中，你已经为每一个零部件机器分配了独立的团队，每一个团队负责维护各自的零部件机器功能，因为零部件机器的独立性避免了冲突。这种独立的开发也有助于快速发挥机器的特性，由于相较于大型组织中团体间的沟通，团队内部沟通更加迅速。

· 成本：你可能会想，虽然多个大型冰淇淋机解决了扩展性问题，可是若是只想提升冰淇淋勺的产量而非其余部分该怎么办？在一体化冰淇淋机中，每次都必须买一整台机器，可是若是你选了微服务零部件机器，能够只买多个冰淇淋勺机(复制)。这样就能节省成本，由于你能够根据该服务上的请求负荷，增减单个服务器实例的数量。

· 安装时间：因为一体化冰淇淋机集成了全部部件，只要将其放在正确的位置就能使用了。然而，微服务零部件机器在使用以前须要链接，好比在冰淇淋的例子中就须要传送带。所以，微服务须要更多的时间和专业知识来安装，由于只有每一个独立的部分相互交流才能正常运行。

· 测试与部署：测试和部署一体化冰淇淋机很是困难，由于全部的部件都是相互依赖的，只有在每一个部件都集成好以后，才能够进行测试和部署。然而，在微服务零部件机器中，每一个零部件机器都是独立的，所以测试和部署单个部件会更加容易。

要不要一开始就使用微服务架构？

简而言之，不要！大多数专家建议，若是不须要微服务架构，那就不要用。为何不先用一体化冰淇淋机留住客户，等到难以维护或规模没法扩大以后再用微服务架构呢？等到这个时候，再把一体化机器分解为独立的微服务零部件机器。

微服务不老是“微”型的

你可能会以为，若是真到了为冰淇淋店准备微服务零部件机的阶段，那么这些机器确定会变成小型的零部件机。不是的！每一个微服务零部件机器自己就能够是一台大型机器，也能够是多台复制机器同时运行以知足用户需求。好比说，若是大多数顾客只喜欢原味冰淇淋，不加任何调料，那勺子机器可能有20个勺子在同时运行。

一样，微服务架构自己也能够是独立的应用程序，规模毫不小，须要大量的努力来维护和扩展。

总结

目前几家正在使用微服务架构的大型软件公司，都是从使用一体化应用程序开始的。一旦它们达到了可扩展性和可维护性的极限，它们就会将一体化机器分解为独立的部件或服务。

毫无疑问，微服务架构可让你针对不一样的服务使用不一样的技术，并更好地扩展和维护机器，但全部这些都具备很大的系统开销和复杂性，须要完备的专业知识。所以，从一个结构良好的一体化冰淇淋机开始，而不是直接从微服务架构开始老是好的，免得让本身陷入“意想不到的复杂性”之中。留言 点赞 关注
咱们一块儿分享AI学习与发展的干货
欢迎关注全平台AI垂类自媒体 “读芯术”在这里插入图片描述 添加小编微信：dxsxbb 便可进微信交流群