江苏龙网

  1. 首页 > 人文 > >

『读芯术』且慢！你并不需要微服务


全文共3736字 ， 预计学习时长11分钟
『读芯术』且慢！你并不需要微服务
本文插图
来源：Pexels
已经2020年了 ， 如果你还不知道微服务是什么 ， 那这篇文章可能不适合你 ， 去看看别的文章吧 。
但如果你已经遍闻微服务的丰功伟绩 ， 并且自己也想试试这一剂“灵丹妙药” ， 那就读下去吧 。 读上几分钟我便会让你对微服务大失所望 。写一篇关于微服务的文章的想法在笔者脑海中萦绕已久 ， 但直到最近同一些人进行了一番激动人心的谈话之后才动笔 。
笔者受邀参与了一次讨论会 ， 以寻求一个引人入胜的问题背后的答案 ， 即“微服务到底是什么？我们是否应当使用此架构寻求解决问题的方法？” 。解决第一个问题尚且容易 ， 但第二个问题就显得有些难以捉摸 。 谈话进行了几分钟之后 ， 几点问题已明确 。
· 支持微服务的用户都想将微服务架构运用于他们即将上市的产品中 ， 并试图寻求他人对于这一做法的肯定 。
· 这次讨论会的组成中有一大部分人都不具备科技背景 。 随着谈话内容越来越“科技化” ， 这部分人便显得无关紧要了 。
· 谈话间出现了长时间的停顿 ， 并且鲜有人提出问题；这说明在场的人大多不熟悉web services ， 更不要说微服务了 。不知道webservice的功能或是不明白微服务的优劣之处 ， 这怪不得他们 。 毕竟他们在各自的专业领域都比笔者有建树 ， 而且他们在毫不知悉微服务可能带来的影响的情况下仍然义无反顾地追随了这一潮流 。
『读芯术』且慢！你并不需要微服务
本文插图
来源：Pexels
早在2013年时 ， 笔者在YouTube上看了一个解释Netflix所提供的服务的架构的视频 ， 在那个视频里 ， 笔者第一次听说了“微服务”这个词 。 这一切信息都太过于庞杂 ， 于是笔者毫不犹豫地跳过了这些讲解 ， 因为那时只是想初步了解一些设计原则 。 但当自己的项目建议书中宣布使用微服务时 ， 我便对这一架构着了迷 。
那个项目的设计十分引人入胜 ， 时至今日它仍是笔者所使用过的最完美的代码库之一 。诚然 ， 模块化设计的广泛可能性使笔者远离了种种负担 。 而作为一个不愿意使用devops的开发者 ， 笔者却使问题又复杂了一些 。 五年之后 ， 笔者可能会与一群截然不同的人共事 ， 使用着全新的产品 。
如影随形的将是由设计拙劣的微服务以及业余的devops策略引起的种种问题 。 抽丝剥茧之后 ， 笔者认识到了微服务的脆弱性 ， 同时也对这一架构的整体性进行了审视 。 虽然为时已晚 ， 但总比不做好 。目睹微服务既扮红脸又扮白脸 ， 笔者便敦促自己对微服务提出一些反对意见 。 如果你是一名倾向于使用微服务的架构师或设计师 ， 笔者强烈建议你扪心自问以下几个问题 。
软件是否大到能被分解为微服务？
说实话 ， 并不是所有的软件都大到能够被分解为微服务 。 正如其名 ， 微服务是一系列小型的具有目的性的独立服务 。 在最理想的情况下 ， 每一项服务都能独立用作一个完整的应用 。
『读芯术』且慢！你并不需要微服务
本文插图
以上是对于微服务和一体化架构之间“每行代码成本”的假设性描绘 。 由于其对于人力和计算机相关成本要求较高 ， 即使是在较为简易的版本下 ， 微服务的成本也高于大型服务 。 而成本关乎每个人 ， 如果你不这么想 ， 也许不应该由你来做这个决定 。
诚然 ， 代码库在未来将会扩充 ， 并且会拓展出新的领域 。 但应当谨记 ， 在接近临界值时 ， 一个设计优良的代码库总能被转化为微服务 。
是否真的需要扩展应用程序的各个组件？
假设雇主想要设计一个能够管理一万名员工的人力资源管理应用 。 开发人员内心的科技热情立刻想出了解决方案——微服务架构 。


推荐阅读


上一篇：「钛媒体」三方应用公开支持华为HMS的底气从哪来？

下一篇：观察者网■苏宁业绩快报：营收2700亿 家乐福7年来首次季度盈利