专栏首页linjinhe的专栏不是银弹:关于微服务的一点思考

不是银弹:关于微服务的一点思考

在 reddit 上看到一篇文章(被标题吸引了) Monoliths are the future——作者在吐槽微服务。

And then what they end up doing is creating 50 deployables, but it’s really a distributed monolith.

作者说,他们改造后的 50 个微服务,其实就是 50 个分布式的单体服务。进行微服务改造后,他们原来的问题并没有解决或减少,反而带来更多新的问题。最后他们又改回去单体服务。

这篇文章其实是个标题党,内容本身没什么好看的。微服务改造失败,这大概率是作者所在的团队错误应用微服务的问题——微服务不是银弹

在过去的几年,微服务这个概念很火,容器、k8s、ServiceMesh 各种微服务基础设施如火如荼。使用微服务来构建应用程序似乎成了一种理所当然的标准——很少有人停下来思考:什么时候该用微服务?还有更重要的——什么时候不该使用微服务?

首先,当我们说起微服务的时候,我们是在说什么? 微服务是一种应用于组件设计(服务如何分组)和部署架构(服务如何部署和通信)的软件架构风格。它利用模块化的方式组合出复杂的大型应用程序:

  1. 各个服务功能内聚,实现与接口分离。
  2. 各个服务高度自治、相互解耦,可以独立进行部署、版本控制和容量伸缩。
  3. 各个服务之间通过 API 的方式进行通信。
  4. 各个服务拥有独立的状态,并且只能通过服务本身来对其进行访问。

其次,当我们实现微服务的时候,我们想要得到什么? 从上面对微服务特点的描述不难看出,实现微服务可以带来的好处有:

  1. 迭代升级更加敏捷:不同功能的服务可以独立变更,不相互影响。
  2. 服务容量更加弹性:可以根据具体的负载单独对某个服务进行扩容、缩容。
  3. 系统可用性更高:某个微服务故障不会导致整个服务故障。

然而,实现微服务是需要权衡利弊(trade-off)的。

程序员知道种种优势,却对代价一无所知。 —— Rich Hickey (Clojure设计者)

  1. 原来的单体服务如何切分?这是一个关键问题——切分得不好,就会像前面那篇文章的作者一样,遇到一个单体服务变成多个单体服务的问题。
  2. 服务切分后,API 会成倍增加。这会引入各种 API 的管理问题,比如各种健康监控、优先级、权限等。
  3. 本地调用变成远程调用会引入了网络延迟,进一步引入了分布式事务。
  4. 微服务请求如何自动路由?调用链路如何追踪?如何自动进行熔断降级,防止雪崩?

等等。引入微服务的代价就是——整个系统的复杂度大大提高。

在我的经历/经验中,从单体服务到微服务其实是公司内组织架构转变的结果。 遥想当年,有一个 web 程序,最开始只有一个组几个人在做,刚开始业务也比较简单,所以所有相关业务都在上面。 后来业务发展良好,开发人数持续增长,业务越来越多、越来越复杂,随后开发人员根据具体业务/功能被拆分成几个小组。 有很长一段过渡时间,所有的变更还是在这一个程序上进行。 这个程序调用量很大,而且可能因为业务 A 的 bug,影响了其他所有业务,每次变更都有不小风险。 这个程序部署的机器比较多,每次变更的时间都比较长。 开发人员越来越多,但是没能做到随时独立变更——每次上线都要进行协调,然后合并多个人的代码一起上线。有时候解决代码冲突就要花掉一整天的时间。上线的时候,如果发现某个功能有问题,需要进行回退——其他功能就算没问题也只能一起回退——业务多而复杂的时候,这种情况很容易出现,非常影响迭代速度。

这种情况下,亟需一种能解决组内自治、快速迭代、跨团队合作的软件架构——没错,就是微服务。

设计系统的架构受制于产生这些设计的组织的沟通结构。 — M. Conway

如果只是一个紧密的小团队,在引入微服务之前,要三思——不要只顾追求时尚,不要人云亦云,适合自己的才是最好的。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • LevelDB:读操作

    前面写了两篇文章介绍 LevelDB 的整体架构和接口使用。这篇文章,我们从代码的角度看看 LevelDB 的设计与实现,先从读操作开始。

    linjinhe
  • 设计数据密集型应用(10-11):大数据的批处理和流处理

    谈大数据批处理,绕不过的就是 MapReduce。MapReduce 是大数据处理的老祖宗了。

    linjinhe
  • LevelDB 完全解析(9):写操作

    以上,便是 LevelDB 的写入流程。写入队列 + 合并写操作,逻辑和代码都十分简洁。比较不足的是,整个写入过程都是单线程的。

    linjinhe
  • 小师妹对IT服务安全的思考

    目前国内外并没有任何标准或文献对IT服务安全进行规范。因此我写这篇文章的目的一是分享我自己对服务安全的思考,二是想听听各位在IT服务项目上积累了多年实践经验的前...

    FB客服
  • 纲举目张:带你看看微服务架构的前世今生

    资料来源:有群里的朋友给我的一些资料,以及自己百度和论坛、社区找来的一些资料,权当做一个总结式的简介。。。

    技术zhai
  • 微服务入门

    “微服务”最初是由 MartinFowler 在 2014年写的一篇文章 《MicroServices》中提出来的。 关于 Martin Fowler 的介绍,...

    王金龙
  • 一起玩转微服务(1)——概念

    随着各行各业公司的快速发展,业务规模的不断扩大,不可避免的造成原有架构不能够适应快速的增长和变化。这时,微服务就进入大家的视野,其实在微服务之前,很多的公司已经...

    cloudskyme
  • 看完这几点,你就会知道微服务为什么这么火爆了

    微服务体系的发展并不是一蹴而就的,经过了2014年前后的低潮期,微服务概念顶层的泡沫逐渐褪去,那些真正能够在企业落地的实践在一轮又一轮的大浪淘沙后被甄别、沉淀。...

    技术zhai
  • 2018年微服务将疯狂至死?带你领略不一样的思维历程!

    原文作者:Dave Kerr;原文地址:https://www.jdon.com/49261

    Java后端技术
  • 关于使用微服务架构的一些思考

    在单体应用时代,我们把所有的业务模块都写在一个系统内,随着新功能的增加,系统的代码库会越来越大,以至于想要知道该在什么地方做修改都很困难。虽然系统内划分了模块,...

    会跳舞的机器人

扫码关注云+社区

领取腾讯云代金券