【2026 年架构大反转：42% 的企业在把微服务改回单体，这不是倒退？】 点击链接打开👉 https://m.toutiao.com/is/OkfnYpQJ8yk/ OkfnYpQJ8yk` :0pm Axw:/ W@m.DH 复制此条消息，打开「今日头条APP」或「今日头条极速版APP」后直接查看~ 这是一篇很有趣的这个技术文章，我有一点点亲身经历，虽然我对这些也不是很深的理解，但是。我试图这样来理解，就是微服务架构，它为什么流行？我在祖母这个她的email这。这个系统里面使用了微服务。所以我的理解是就我的一点点实践经验来总结的，也许是不太准确的。就是说他实际上把这个呃，我形象的把它称之为相当于说排列队列中的容器式。就是说。在一个系统中，它实际上有很多的处理环节，比如说是流水线。那么，流水线的这个处理能力以及它的这个呃就是能容纳的这个。比如说消息队列或者说信息流吧。实际上，能力是不一样的，就各个环节，而且是随着这个呃用户的请求。实际上，这个。它各个服务直接微服务，你可以把它看作是多个处理的环节。他的能力。它的容量是不同的。那么，怎么样能够做到说有一定的伸缩性，能够把这个叫做啊？用户的处理不至于堵塞，而又能够最大效率的去利用这个资源。实际上就是伸缩性了skating了。因为你在呃用户服务请求高峰的时候，你能够灵活的掌握说呃资源资源的调度。这里面有两个因素，就是一个就是说当用户的请求多的时候，你要能够说迅速的扩容，所以k8s这种东西。它能够迅速的把微服务我。请求来不及处理某一个环节，某一个服务来不及处理，我就多加几个节点嘛，计算节点多加一点。相当于说。我可以自由的支配我的计算资源，当请求减少的时候，我又可以灵活的迅速的呃，在云端的这种。虚拟机数量减少又可以节省我的资源开销。这个就是很形象的一个，我有一个很形象的一个比喻，不叫比喻吧，就是大家生活中都看到的一个现象，就比如说呃，我们那个。博物馆门前，这个访问或者公园门前排长队，但是这个队伍很长的时候有没有注意到一个现象？就是说。他会在。用很多的栏杆把它队伍。给它围成一个之字形，就这样子循环的这样子，为什么要这样做呢？实际上就是说呃。把这个排队的人呢，容纳在这个小小的广场上，而不是排一个长列，而是排一个之字形的，这样的一个列。就是来回这样，这就是说这是一个形象的比喻，就是说你一个微服务，实际上当你的请求太多的时候，你可能会被阻塞。那你阻塞的时候最忌讳的就是说数据丢失，因为没有任何一个呃存储的数据结构。去能够说。存储那么多的数量而不丢失，这个在计算机里面很难处理这件事情，但是如果把它放到微服务里面。你相当于说这些待处理的流水线的数据，可以等于是把它们先容纳在这个微服务的队列里面。这些就是我的理解，就是说它可以相当于是一种临时的内存中的数据库一样，把这些数据先缓存起来，因为下游的处理来不及嘛。然后它也可以说每个节点，如果说它是成为这个整个系统的瓶颈的话，就灵活的呃添加新的服务节点。所以这个就是他的灵活处理，这种复杂的任务，队列的一个。架构，而且另一方面就是说这个博主也讲了，其实很大一个原因是因为每一个处理环节可能都是一个很复杂的一个。呃，细节那么其实这些细节是不需要说公布给其他的。就是这个所谓实行这个web rpc或者说http hpc的一个很重要的就。里面使使用什么语言处理，使用什么算法处理，使用什么数据库去处理，这些通通都是呃。甚至于使用什么计算机架构，这些通通都是其他节点，不需要关心，也不用关心它，可以自己灵活的去。更换它的这个呃处理的方式，这当然这个并不是微服务本身的这个特性，所有的。这个web rpc都具有这种通用性，灵活性，扩展性。这。当然，也算是微服务的一个核心特征吧。然后另外一个就是使用一个巨量的单个程序去高效处理，这个我也有一个实际的这个。呃，亲身体验就是在bloomberg，就是彭博社，他当年就是说使用一个巨量的几个g的那种。呃，大的一唯一一个进程去处理所有的请求，这样的速度是绝对是最快的，因为它所有的通信都是在进程内的。就不存在进程间了，就比那个。那个还要高效，因为在以前在cisco的一个组里面，他们是呃视频会议是。四个进程，或者说四个服务之间使用各种各样的ipc，就是等于进程间通讯，这个效率肯定比web rpc快的多了。但是对于单个服务器的资源，肯定是有上限的限制，因为你。四个进程都在同一台机器里面，那你内存物理内存物理存储都是一个呃有上限的，没办法扩展。但是这个是一个最快的比较快的一种解决方法，而bloomberg那个彭博社那就更加夸张了，他就说连连。进程加进程间rpc都不要，它就直接就是一个巨量的monolith的这样一个呃进程。所有的逻辑都是在同一个进程内。写的这当然维护起来是一个巨量的挑战。

你写的很好，就是说我想把它作为一个小的这个感想，技术分享，再去你重新，就是组织一下语言。其实强调的就是说，核心是什么呢？微服务。它对应的场景是什么呀？必须有这几个，一个是说大的容量，大的流量吧，大的请求数量。如果数量不到的话，你这个就是等于是杀鸡用牛刀了。是不是？就是你业务这个规模没到那个程度，就没有意义。第二个就伸缩性，这点好像你没有强调这个伸缩性。实际上这个在 Zoom 里面它是非常强调这个事情的，因为这个你没有或者说其他这个东西一下子它会请求非常多，一下子又可能少了，那你云服务的这个很关键的一个就是说要降低它的运维成本，而降低运维成本很大程度是要靠这个灵活的伸缩，而微服务恰好满足这点。因为不去自建数据中心的一个，租数据中心的很大的一个优点就在于你的这个架构或者整个资源的利用是可以随时灵活的伸缩的。否则的话，租数据中心是非常贵的，比你自建数据中心成本当然是硬件成本是要贵不少的，因为这这个数据中心这个云服务厂商是要有利润的嘛。如果你不去利用到这个伸缩性的话，你肯定是不合算的。而且这个灵活性，这个安全性，这个有很多的这种挑战。再一个就是说是很重要一点，大家都没有提到这个，这个微服务的这个架构是一定是一个很大规模的团队开发才有意义。什么意思呢？就是说一个组，小组就是一个团队，就一个一个微服务，他就 own it owner，他就是说他的所有权，然后他们内部怎么去迭代，怎么去，就是独立发展的。它，而且是不停的要扩展的，才有意义去使用微服务。因为它的扩展不影响到这个这个叫做生产进度，生产不用停机，因为它可以无缝的去扩容，无缝的去架构更新，不停的。开发，如果你这个东西就是固定的话，你根本没必要去用微服务了。如果是就这么一个团队的话，也没有必要用微服务去多个这个这个完全不同的逻辑，有这么大的灵活性。因为它的开销实际上是相当大的，因为全部使用 web RPC 的话，本身这个通讯开销就很大，然后你又就像那个博主讲的，他，你需要多个虚拟机，多个运行节点，然后是这种部署起来也是相当复杂的。那你原本，如果说你的业务量一台服务器就能搞定，你怎么可能去搞微服务弄它三台五台的这个服务器去做这个事情呢？是不是？就是核心就是说几件事情，一个是业务量有足够大，而且这种业务的伸缩，就是说它不是固定的。如果是固定的话其实也没必要用微服务，它就是因为这个业务量是忽大忽忽小，这个这个服，用户的请求是一下子有高峰有低谷，然后你使用云服务去做这个是事情，你必须要去考虑要节约这个事情。如果你自己的数据中心，你你你你可能策略也不一样。这个，然后就是说团队是有一定规模的，然后是不停的在迭代的，就是业务逻辑是不停的发展的，就业务需求是不停的变化的。如果是一劳永逸的话，其实也没有必要去用微服务去做这个事情。而且就是说它的这个系统的这个响应性啊，就是说这个滞后性或者是实时性，没有非常严格的要求。就说有，你像以没有服务或者其他的某些服务，它不是说对实时性那么高的。也许是可以这样做的。如果是某些金融服务，或者说是视频会议等等等等，这个微服务可能就不适合这么做了，因为这个微服务之间的这个滞后，这个延迟啊， overhead 相当高啊，你虽然是满足了这个