我的征尘是星辰大海。。。
The dirt and dust from my pilgrimage forms oceans of stars...
-------当记忆的篇章变得零碎，当追忆的图片变得模糊，我们只能求助于数字存储的永恒的回忆
作者:黄教授
手机视频列表
超四成企业从微服务回归单体
视频
音频
原始脚本
42%企业从微服务回归单体，本质不是倒退，是架构回归常识。 最近看到一个很有意思的行业数据，如今超四成企业正在把落地已久的微服务架构。 重新改回单体架构。 很多人觉得这是技术倒退，但结合我的落地实践与行业观察来看，这根本不是退步，而是架构褪去盲目跟风，回归场景适配的本质。 所有技术架构没有高低优劣，唯一的评判标准就是是否匹配自身的业务体量、流量特征、团队规模和性能要求。 曾经微服务几乎成为互联网项目的标配。 被奉为最优架构方案。 但绝大多数人只看到了它的优势，却忽略了它严苛的前置适用条件。 脱离场景的盲目落地，只会徒增系统复杂度和运维成本。 结合实战经验，我总结出微服务不可或缺的四大核心适用场景，缺一不可。 第一，必须具备大体量、波动性极强的业务流量。 微服务的核心价值之一是解决超大流量的承载与缓冲问题。 它可以将整套系统拆解为独立的业务节点，如同景区、公园排队的之字形回廊。 通过各服务独立的消息队列缓存突发请求，避免单一链路阻塞导致整个系统崩溃，杜绝请求丢失。 这种架构最大的优势是弹性伸缩能力。 这也是云服务架构的核心精髓。 像 Zoom 后台的电子邮件产品，流量特征极其极端，高峰期瞬间请求量爆炸式增长，低谷期资源闲置严重。 依托 K8S 和微服务架构，企业可以在流量高峰快速扩容节点。 分摊压力，流量低谷及时缩容释放资源。 要知道，云厂商租用成本远高于自建机房硬件成本，厂商本身自带利润溢价。 如果无法利用微服务的弹性伸缩实现资源按需分配、降本增效，上云加微服务就是纯粹的资源浪费。 反之，如果业务流量固定、体量小。 单台服务器即可稳定承载，根本无需拆分多节点多服务，微服务的所有优势全部归零，只剩下冗余开销。 第二。 必须适配中大型团队的并行开发、持续迭代的业务模式。 很多人忽略了一个关键，微服务是为大规模团队协作而生的架构。 它的核心设计逻辑是服务私有化，权责到人。 一个独立微服务由专属小团队全权负责，团队拥有完全的开发、迭代、运维权限。 各服务通过 RPC HTTP 完成通信，内部的编程语言、数据库、算法逻辑、技术栈完全独立，互不干扰。 团队可以独立更新版本、迭代功能、修复 bug 实现不停机、无缝更新、无阻塞业务扩展。 单个服务的迭代升级不会影响整体系统运行。 完美适配互联网业务高速迭代的需求。 但如果是小型团队，业务模型固定，几乎长期无迭代更新，微服务就是彻头彻尾的杀鸡用牛刀。 微服务带来的弊端是实打实的跨服务网络通信。 序列化、反序列化会产生巨大性能开销。 多节点部署、服务治理、链路追踪、分布式事务会让运维复杂度指数级上升。 小团队维护一套微服务架构，投入的人力物力成本远远大于架构带来的收益。 第三，业务系统对实时性、超低延迟没有极致严苛的要求。 这是区分微服务与单体架构的核心性能标尺，也是金融、实时交互类系统极少使用微服务的关键原因。 直观的行业对比体验。 思科的某视频会议系统采用多进程 IPC 进程间通信，性能远优于微服务 RPC 通信。 而彭博社的金融交易系统更是极致的单体架构。 整套系统运行在一个巨型进程中，所有逻辑均为进程内调用。 单体架构的优势无可替代，无网络开销，无跨进程通信损耗。 延迟极低，响应极致高效。 而微服务每一次跨服务调用都会产生网络延迟、协议解析、数据编解码等额外开销。 链路越长，性能损耗越严重。 对于视频会议、高频金融交易、实时指令交互这类对延迟零容忍的场景，微服务的架构缺陷会被无限放大，完全不适用。 微服务只适合允许轻微延迟、非实时核心的业务场景。 综上，当下大量企业弃微服务回归单体，从来不是技术倒退。 而是行业终于摆脱了架构崇拜。 微服务的本质是以性能损耗、架构复杂度、运维成本为代价，换取超大流量弹性。 大型团队协作效率、高速业务迭代能力。 如果你的业务流量平稳、体量偏小、团队精简、迭代缓慢、追求低延迟。 模块化单体架构永远是最优解。 只有同时满足大波动流量、需弹性降本、大规模团队协作、高频持续迭代、容忍轻微延迟这几个条件。 微服务才有落地的真正价值。 架构选型的终极真理始终不变，复杂的技术永远服务于复杂的业务，简单的业务就该用最简单的架构。
修正脚本
42%的企业从微服务回归单体，本质不是倒退，是架构回归常识。 最近看到一个很有意思的行业数据，如今超四成企业正在把落地已久的微服务架构重新改回单体架构。 很多人觉得这是技术倒退，但结合我的落地实践与行业观察来看，这根本不是退步，而是褪去盲目跟风，架构回归场景适配的本质。 所有技术架构没有高低优劣，唯一的评判标准就是是否匹配自身的业务体量、流量特征、团队规模和性能要求。 曾经微服务几乎成为互联网项目的标配。 被奉为最优架构方案。 但绝大多数人只看到了它的优势，却忽略了它严苛的前置适用条件。 脱离场景的盲目落地，只会徒增系统复杂度和运维成本。 结合实战经验，我总结出微服务不可或缺的四大核心适用场景，缺一不可。 第一，必须具备大体量、波动性极强的业务流量。 微服务的核心价值之一是解决超大流量的承载与缓冲问题。 它可以将整套系统拆解为独立的业务节点，如同景区、公园排队的之字形回廊。 通过各服务独立的消息队列缓存突发请求，避免单一链路阻塞导致整个系统崩溃，杜绝请求丢失。 这种架构最大的优势是弹性伸缩能力。 这也是云服务架构的核心精髓。 像 Zoom 后台的电子邮件产品，流量特征极其极端，高峰期瞬间请求量爆炸式增长，低谷期资源闲置严重。 依托 K8S 和微服务架构，企业可以在流量高峰快速扩容节点。 分摊压力，流量低谷及时缩容释放资源。 要知道，云厂商租用成本远高于自建机房硬件成本，厂商本身自带利润溢价。 如果无法利用微服务的弹性伸缩实现资源按需分配、降本增效，上云加微服务就是纯粹的资源浪费。 反之，如果业务流量固定、体量小，单台服务器即可稳定承载，根本无需拆分多节点多服务，微服务的所有优势全部归零，只剩下冗余开销。 第二，必须适配中大型团队的并行开发、持续迭代的业务模式。 很多人忽略了一个关键，微服务是为大规模团队协作而生的架构。 它的核心设计逻辑是服务私有化，权责到人。 一个独立微服务由专属小团队全权负责，团队拥有完全的开发、迭代、运维权限。 各服务通过 RPC HTTP 完成通信，内部的编程语言、数据库、算法逻辑、技术栈完全独立，互不干扰。 团队可以独立更新版本、迭代功能、修复 bug 实现不停机、无缝更新、无阻塞业务扩展。 单个服务的迭代升级不会影响整体系统运行。 完美适配互联网业务高速迭代的需求。 但如果是小型团队，业务模型固定，几乎长期无迭代更新，微服务就是彻头彻尾的杀鸡用牛刀。 微服务带来的弊端是实打实的跨服务网络通信。 序列化、反序列化会产生巨大性能开销。 多节点部署、服务治理、链路追踪、分布式事务会让运维复杂度指数级上升。 小团队维护一套微服务架构，投入的人力物力成本远远大于架构带来的收益。 第三，业务系统对实时性、超低延迟没有极致严苛的要求。 这是区分微服务与单体架构的核心性能标尺，也是金融、实时交互类系统极少使用微服务的关键原因。 我们来看直观的行业对比。 思科的某视频会议系统采用多进程 IPC 进程间通信，性能远优于微服务 RPC 通信。 而彭博社的金融交易系统更是极致的单体架构。 整套系统运行在一个巨型进程中，所有逻辑均为进程内调用。 单体架构的优势无可替代，无网络开销，无跨进程通信损耗。 延迟极低，响应极致高效。 而微服务每一次跨服务调用都会产生网络延迟、协议解析、数据编解码等额外开销。 链路越长，性能损耗越严重。 对于视频会议、高频金融交易、实时指令交互这类对延迟零容忍的场景，微服务的架构缺陷会被无限放大，完全不适用。 微服务只适合允许轻微延迟、非实时核心的业务场景。 综上，当下大量企业弃微服务回归单体，从来不是技术倒退。 而是行业终于摆脱了架构崇拜。 微服务的本质是以性能损耗、架构复杂度、运维成本为代价，换取超大流量弹性、大型团队协作效率、高速业务迭代能力。 如果你的业务流量平稳、体量偏小、团队精简、迭代缓慢、追求低延迟，模块化单体架构永远是最优解。 只有同时满足大波动流量、需弹性降本、大规模团队协作、高频持续迭代、容忍轻微延迟这几个条件，微服务才有落地的真正价值。 架构选型的终极真理始终不变，复杂的技术永远服务于复杂的业务，简单的业务就该用最简单的架构。
英文翻译
42% of enterprises are returning from microservices to monoliths. This is not a regression in essence, but a return to common sense in architecture. Recently, I came across a very interesting industry statistic: now over 40% of companies are reverting their long-established microservices architectures back to monolithic architectures. Many people see this as a technological regression, but based on my practical experience and industry observations, this is not a step backward. Instead, it’s about shedding blind trend-following and letting architecture adapt to the reality of the scenario. All technical architectures have no inherent superiority or inferiority. The only evaluation criterion is whether they match the business scale, traffic characteristics, team size, and performance requirements. At one point, microservices became almost standard for internet projects and were hailed as the optimal architectural solution. But most people only saw their advantages while ignoring the stringent prerequisites for their adoption. Blindly implementing microservices without considering the context only increases system complexity and operational costs. Based on hands-on experience, I have summarized four indispensable core scenarios for microservices—all of which must be present. First, the business must have massive and highly volatile traffic. One of the core values of microservices is handling and buffering extremely large traffic volumes. It breaks the entire system into independent business nodes, much like the zigzag queues at scenic spots or amusement parks. Each service uses its own message queue to cache burst requests, preventing a single-link blockage from crashing the entire system and avoiding request loss. The biggest advantage of this architecture is elastic scaling. This is also the core essence of cloud-native architectures. For example, the email product behind Zoom has extremely extreme traffic patterns: explosive request surges during peak times and severe resource idleness during troughs. Leveraging K8s and microservices, companies can rapidly scale up nodes during traffic peaks to distribute pressure and quickly scale down during troughs to release resources. Keep in mind that the rental cost of cloud vendors is much higher than the hardware cost of self-built data centers, and vendors inherently include a profit premium. If you cannot use the elastic scaling of microservices to allocate resources on demand, reduce costs, and improve efficiency, then moving to the cloud plus microservices is pure waste. Conversely, if business traffic is stable and small, and a single server can handle it reliably, there is no need to split into multiple nodes and services. All the advantages of microservices become zero, leaving only redundant overhead. Second, the business model must support parallel development and continuous iteration by medium-to-large teams. Many overlook a key point: microservices are an architecture designed for large-scale team collaboration. Its core design logic is service privatization and clear ownership. Each independent microservice is fully managed by a dedicated small team, which has complete authority over development, iteration, and operations. Services communicate via RPC/HTTP, while internal programming languages, databases, algorithm logic, and technology stacks are completely independent and do not interfere with each other. Teams can independently update versions, iterate features, and fix bugs without downtime, enabling seamless updates and unimpeded business expansion. Iteration and upgrades of a single service do not affect the overall system operation. This perfectly suits the high-speed iteration needs of internet businesses. But for small teams with a fixed business model that rarely requires updates, microservices are overkill—like using a sledgehammer to crack a nut. The drawbacks of microservices are substantial: cross-service network communication, serialization/deserialization incur significant performance overhead. Multi-node deployment, service governance, distributed tracing, and distributed transactions dramatically increase operational complexity. For a small team to maintain a microservices architecture, the investment in manpower and resources far outweighs the benefits. Third, the business system must not have extreme requirements for real-time performance and ultra-low latency. This is the core performance metric that distinguishes microservices from monolithic architecture, and it is also the key reason why financial and real-time interaction systems rarely use microservices. Let's look at an intuitive industry comparison. Cisco's video conferencing system uses multi-process IPC (inter-process communication), which performs far better than microservices' RPC communication. Meanwhile, Bloomberg's financial trading system is an extreme example of monolithic architecture. The entire system runs in one giant process, with all logic as in-process calls. The advantages of monolithic architecture are irreplaceable: no network overhead, no cross-process communication latency. Extremely low latency, highly efficient responses. In contrast, every cross-service call in microservices introduces extra overhead such as network latency, protocol parsing, and data encoding/decoding. The longer the chain, the worse the performance loss. For scenarios like video conferencing, high-frequency financial trading, and real-time command interaction—where zero tolerance for latency exists—the architectural flaws of microservices are magnified and completely unsuitable. Microservices are only appropriate for business scenarios that tolerate slight latency and are not real-time core. In summary, the current trend of many companies abandoning microservices and returning to monoliths is never a technological regression. Instead, the industry has finally broken free from architectural worship. The essence of microservices is to trade performance loss, architectural complexity, and operational cost in exchange for the ability to handle massive traffic, enable large-team collaboration, and support rapid business iteration. If your business has stable traffic, a small scale, a lean team, slow iteration, and demands low latency, a modular monolithic architecture will always be the optimal solution. Only when all the following conditions are met simultaneously—massive volatile traffic needing elastic cost reduction, large-team collaboration, high-frequency continuous iteration, and tolerance for slight latency—does microservices truly deliver value. The ultimate truth of architecture selection remains unchanged: complex technology must always serve complex business, and simple business should use the simplest architecture.
back to top