江苏龙网

  1. 首页 > 人文 > >

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


『读芯术』且慢！你并不需要微服务
本文插图
虽然这个举例有些极端 ， 但你懂我意思的!
使用微服务架构的主要优势之一便是能轻而易举地拓展各个组件 。 可能会存在大量需要单独拓展组件的应用程序 ， 但真的需要这么做吗？
事务是否横跨多个服务？
这一点可能是最难以抉择且最具战略意义的选择 。 跨越多个服务项目的事务对于整个架构都是负担 。 处理多项服务间的事务意味着服务之间的互锁 ， 一系列难以寻踪的死锁 ， 以及可能会危及服务项目甚至是工程师的竞态条件 。REST服务从定义上来说是无状态的 。 因此REST服务不应当参与涉及多于一项服务的事物 。 在高性能领域中 ， 完全无需二阶段提交（2PC） 。 而SAGA模式只会让工作雪上加霜 。由于微服务在去中心化数据管理方面的出色表现 ， 因此引入了最终的一致性问题 。
运用一体化架构 ， 可以通过一次操作升级一系列组件 。 微服务的更新需要多种资源 ， 而分布式事务并不受欢迎（理应如此） 。 因此 ， 现在 ， 开发人员需要意识到一致性问题 ， 并在酿成大错之前弄清楚如何检测不同步的情况 。 —马丁·富勒
跨服务的事务是否可能？
当然有可能 。
但是为了这么做在无状态的服务中实行一系列的动作是否值得？
不尽然！
『读芯术』且慢！你并不需要微服务
本文插图
来源：Pexels
服务之间是否需要频繁的交流？
对于传统的一体化服务来说 ， 每个微服务都由系统内的模块表示 。 各个模块间的沟通是在内存中进行的 ， 因此延迟几乎为零 。 而使用微服务则意味着 ， 沟通由内存事物变为了通过连接线进行的指令传输 。已经有许多通过尝试和测试的的方法了 ， 但这些方法都存在着延迟的问题 。 摒弃内存事务处理而使用基于网络的沟通会使延迟由纳米秒级变为微秒级 。 想象一下三项不同的业务同时在网络上进行交流 ， 而每次交流要花费100毫秒（在加载情况下这是完全现实的） ， 那么光交流就要花费300毫秒的时间 。更有些程序天生就与其组件以及服务紧密结合 。 添加一层交流可能会使得处理实时数据的程序发生毁灭性的灾难 。 想象一下 ， 在一场手术中或是航空交通管制中出现了沟通延误会发生什么样的后果 。
其他问题
· 复杂性增强——复杂性无法量化 ， 只能通过相对条件进行比较 。 虽然设计微服务的初衷就是将程序细化以减少复杂性 ， 但微服务的架构本身使用和维护起来却非常复杂 。
· 分布成本——微服务是带有反应分子数的分布式系统 。 但这一分布却有着代价 。 一体化架构服务往往部署于大型虚拟主机或是使用者选用的容器中 。 但运用微服务 ， （理想情况下）服务需要独立部署于多个虚拟服务器或容器中 。 虽然这些虚拟服务器或容器尺寸可以较小 ， 但数量却非常庞大 。 这一切还不包括协同工作和维护工作 。
· 利用Devops——这一问题仁者见仁智者见智 。 Devops是一种广为接受并且被证明行之有效的操作解决方案 。 但如果所在的组织规模尚小 ， 那建立一支Devops队伍只能是弊大于利 。 而没有一支全职负责的Devops队伍 ， 是无法维护和监视微服务的 。
· 紧密连结——有些程序天生就是成对紧密地连结在一起的 。 为了适应微服务架构而强行让它们分离 ， 其后果可能会是灾难性的 。
· 缺少经验——缺少经验不仅对于面向服务的架构是一个严重的问题 ， 对任何领域都是 。 但由于微服务抽象的定义 ， 在微服务领域缺少经验可能会造成更加严重的后果 。 如果部署微服务可能会导致你落于人后 ， 或是导致依赖性服务失效时的全面崩溃 ， 那你已经慢人一步了 。
· 端到端测试——典型的一体化架构程序可以让开发人员几乎同时测试并发布应用程序 。 而在没有可靠协调性的情况下 ， 具有相关的多种服务会延后程序的测试 。


推荐阅读


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

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