全文共3736字，预计学习时长11分钟

来源：Pexels

已经2020年了，如果你还不知道微服务是什么，那这篇文章可能不适合你，去看看别的文章吧。

但如果你已经遍闻微服务的丰功伟绩，并且自己也想试试这一剂“灵丹妙药”，那就读下去吧。读上几分钟我便会让你对微服务大失所望。

写一篇关于微服务的文章的想法在笔者脑海中萦绕已久，但直到最近同一些人进行了一番激动人心的谈话之后才动笔。

笔者受邀参与了一次讨论会，以寻求一个引人入胜的问题背后的答案，即“微服务到底是什么？我们是否应当使用此架构寻求解决问题的方法？”。

解决第一个问题尚且容易，但第二个问题就显得有些难以捉摸。谈话进行了几分钟之后，几点问题已明确。

· 支持微服务的用户都想将微服务架构运用于他们即将上市的产品中，并试图寻求他人对于这一做法的肯定。

· 这次讨论会的组成中有一大部分人都不具备科技背景。随着谈话内容越来越“科技化”，这部分人便显得无关紧要了。

· 谈话间出现了长时间的停顿，并且鲜有人提出问题；这说明在场的人大多不熟悉web services，更不要说微服务了。

不知道webservice的功能或是不明白微服务的优劣之处，这怪不得他们。毕竟他们在各自的专业领域都比笔者有建树，而且他们在毫不知悉微服务可能带来的影响的情况下仍然义无反顾地追随了这一潮流。

来源：Pexels

早在2013年时，笔者在YouTube上看了一个解释Netflix所提供的服务的架构的视频，在那个视频里，笔者第一次听说了“微服务”这个词。这一切信息都太过于庞杂，于是笔者毫不犹豫地跳过了这些讲解，因为那时只是想初步了解一些设计原则。但当自己的项目建议书中宣布使用微服务时，我便对这一架构着了迷。那个项目的设计十分引人入胜，时至今日它仍是笔者所使用过的最完美的代码库之一。

诚然，模块化设计的广泛可能性使笔者远离了种种负担。而作为一个不愿意使用devops的开发者，笔者却使问题又复杂了一些。五年之后，笔者可能会与一群截然不同的人共事，使用着全新的产品。如影随形的将是由设计拙劣的微服务以及业余的devops策略引起的种种问题。抽丝剥茧之后，笔者认识到了微服务的脆弱性，同时也对这一架构的整体性进行了审视。虽然为时已晚，但总比不做好。

目睹微服务既扮红脸又扮白脸，笔者便敦促自己对微服务提出一些反对意见。如果你是一名倾向于使用微服务的架构师或设计师，笔者强烈建议你扪心自问以下几个问题。

软件是否大到能被分解为微服务？

说实话，并不是所有的软件都大到能够被分解为微服务。正如其名，微服务是一系列小型的具有目的性的独立服务。在最理想的情况下，每一项服务都能独立用作一个完整的应用。

以上是对于微服务和一体化架构之间“每行代码成本”的假设性描绘。由于其对于人力和计算机相关成本要求较高，即使是在较为简易的版本下，微服务的成本也高于大型服务。而成本关乎每个人，如果你不这么想，也许不应该由你来做这个决定。

诚然，代码库在未来将会扩充，并且会拓展出新的领域。但应当谨记，在接近临界值时，一个设计优良的代码库总能被转化为微服务。

是否真的需要扩展应用程序的各个组件？

假设雇主想要设计一个能够管理一万名员工的人力资源管理应用。开发人员内心的科技热情立刻想出了解决方案——微服务架构。

虽然这个举例有些极端，但你懂我意思的!

使用微服务架构的主要优势之一便是能轻而易举地拓展各个组件。可能会存在大量需要单独拓展组件的应用程序，但真的需要这么做吗？

事务是否横跨多个服务？

这一点可能是最难以抉择且最具战略意义的选择。跨越多个服务项目的事务对于整个架构都是负担。处理多项服务间的事务意味着服务之间的互锁，一系列难以寻踪的死锁，以及可能会危及服务项目甚至是工程师的竞态条件。

REST服务从定义上来说是无状态的。因此REST服务不应当参与涉及多于一项服务的事物。在高性能领域中，完全无需二阶段提交（2PC）。而SAGA模式只会让工作雪上加霜。

由于微服务在去中心化数据管理方面的出色表现，因此引入了最终的一致性问题。运用一体化架构，可以通过一次操作升级一系列组件。微服务的更新需要多种资源，而分布式事务并不受欢迎（理应如此）。因此，现在，开发人员需要意识到一致性问题，并在酿成大错之前弄清楚如何检测不同步的情况。—马丁·富勒

跨服务的事务是否可能？

当然有可能。

但是为了这么做在无状态的服务中实行一系列的动作是否值得？

不尽然！

来源：Pexels

服务之间是否需要频繁的交流？

对于传统的一体化服务来说，每个微服务都由系统内的模块表示。各个模块间的沟通是在内存中进行的，因此延迟几乎为零。而使用微服务则意味着，沟通由内存事物变为了通过连接线进行的指令传输。

已经有许多通过尝试和测试的的方法了，但这些方法都存在着延迟的问题。摒弃内存事务处理而使用基于网络的沟通会使延迟由纳米秒级变为微秒级。想象一下三项不同的业务同时在网络上进行交流，而每次交流要花费100毫秒（在加载情况下这是完全现实的），那么光交流就要花费300毫秒的时间。

更有些程序天生就与其组件以及服务紧密结合。添加一层交流可能会使得处理实时数据的程序发生毁灭性的灾难。想象一下，在一场手术中或是航空交通管制中出现了沟通延误会发生什么样的后果。

其他问题

· 复杂性增强——复杂性无法量化，只能通过相对条件进行比较。虽然设计微服务的初衷就是将程序细化以减少复杂性，但微服务的架构本身使用和维护起来却非常复杂。

· 分布成本——微服务是带有反应分子数的分布式系统。但这一分布却有着代价。一体化架构服务往往部署于大型虚拟主机或是使用者选用的容器中。但运用微服务，（理想情况下）服务需要独立部署于多个虚拟服务器或容器中。虽然这些虚拟服务器或容器尺寸可以较小，但数量却非常庞大。这一切还不包括协同工作和维护工作。

· 利用Devops——这一问题仁者见仁智者见智。Devops是一种广为接受并且被证明行之有效的操作解决方案。但如果所在的组织规模尚小，那建立一支Devops队伍只能是弊大于利。而没有一支全职负责的Devops队伍，是无法维护和监视微服务的。

· 紧密连结——有些程序天生就是成对紧密地连结在一起的。为了适应微服务架构而强行让它们分离，其后果可能会是灾难性的。

· 缺少经验——缺少经验不仅对于面向服务的架构是一个严重的问题，对任何领域都是。但由于微服务抽象的定义，在微服务领域缺少经验可能会造成更加严重的后果。如果部署微服务可能会导致你落于人后，或是导致依赖性服务失效时的全面崩溃，那你已经慢人一步了。

· 端到端测试——典型的一体化架构程序可以让开发人员几乎同时测试并发布应用程序。而在没有可靠协调性的情况下，具有相关的多种服务会延后程序的测试。

· 杂乱的数据契约——在单个团队内设计并持有数据契约和在团队之间分享这些数据契约是截然不同的。当使用微服务时，团队中的成员可能并非来自同一领域，更何况成员使用的编程语言还有可能不同。为了特殊需求设计数据契约既费时又浪费空间。

· 旧代码库——说实话，对大多数人来说，处理旧代码库几乎已成家常便饭。对大多企业来说则是主要的收入来源。日新月异的科技进步使得我们飞速前进，但同时，科技进步也使得我们与旧的代码库产生了越来越大的隔阂。

确定刚刚研发的RabbitMQ框架适用于存储在IBM AIX服务器的旧应用吗？

来源：Pexels

结论

本文的结论不是“绝对不要使用微服务”！

微服务时不时的便会为自己赢得一些殊荣，这一架构解决了一些开发员曾经以为无法解决的问题。Netflix使用微服务的故事启发了很多人。利用微服务的还不止Netflix，还有Uber、SoundCloud,以及商业巨头Amazon。而且这些成功并非仅限于面对消费者的应用程序。笔者亲眼目睹过一家美国医疗巨头的源代码，每次看到这些源代码，笔者都因其中的设计可能性而瞠目。

如果五年前你随了微服务的大流，笔者不会说你轻信潮流。因为那是个不同的时代，但需要对这一事实保持坦诚。而现在已经2020年了。我们肆意妄为造成的惨痛后果有目共睹。无谓的使用微服务只能把拙劣的代码变成拙劣的基础设施。

笔者向来看好一腔热血的程序员。笔者自己也是其中一员。程序员们崇尚自己的工作，并且总能出人意料地解决问题。但在做出决定的时候不能单凭一腔热血，盲目的决定会使自己和所在的组织付出沉痛的代价。微服务不应是默认程序架构。微服务不是什么万能灵药。谨记KISS原则和YAGNI原则。

科技的拥护者有自己所最爱的架构无可厚非。但是你与众不同的是在“正确的选择”和“你所偏好的选择”中做出与事实相符的决定的能力。