微博一崩溃，他就挨骂-技术圈

微博一崩溃，他就挨骂

小林coding

共 1745字，需浏览 4分钟

· 2021-10-22

大家好，我是小林。

最近，朋友被他们公司的系统搞得头大，跟我吐槽说真的不想再用单体应用的架构开发了。

他们每次功能发布和上线都得有一个上线负责人来收集上线列表，并协调所有相关的开发人员合并代码到主干，然后进行编译打包，修改工程依赖的 JAR 包版本。

而如果一次上线超过五个人参与，一旦有的人忘记提交代码、有的人忘记打包、有的人忘记修改工程依赖到最新版本等，那各种 bug 改都改不过来。

一次上线过程不仅要反复确认，耗费了大量精力，还严重影响整体的开发和部署效率，他感觉自己的头发都要愁没了。可领导又不同意换，说团队规模不够大、没必要花费很大精力去调整。

这给我带来了一些思考，中小团队的技术架构该如何演进？

不由想到之前大牛胡忠想在微博的经历，对了，就是那个微博系统一崩就被频繁艾特的男人。

他 2012 年加入微博，最开始微博首页信息流的后端团队规模很小，只有七八个人。当时他们也是想着快速迭代，业务就采用了单体应用的架构。因为求快，不同功能模块的代码耦合在一起，编译打包部署也都在一起。

后来随着业务规模扩大，团队也增长到二十多人，这时候单体应用架构开发的缺点同样暴露了出来，只要上线涉及到多人协同，bug 预警就响个没完。

而为了更好解决这些问题，当时胡忠想和团队做了很细致的技术调研，最后选定了服务化的解决方案。对原有的单体应用架构进行改造，把功能相对独立的模块拆分出去，部署为微服务，分别交给专门的更小的团队来维护。再到后来他们又引入了 Docker 容器化，以及 Service Mesh 等技术，都是为了更好地适应微博业务的高速发展。

总的来说，微博的信息流后端架构经历了单体应用 -> 微服务架构 -> 容器化应用 -> DevOps 的发展历程。相信这段经历，对所有中小团队和企业，都有一定的启示意义。

而老胡也因为亲历了微博的架构演进过程，对中小团队如何落地微服务体系有了更为深刻的理解，跟极客时间共同推出了《从0开始学微服务》专栏。

极客时间四周年，活动到手价 ¥89

新人首单仅 ¥59

在这个专栏里，老胡秉承着“实用至上”的思路，他并没有构建一个大而全的东西，而是一套可以快速落地的方法论。老胡更多在意的是他提供的方案中小团队是否可用，以及对方能否驾驭这些技术。

所以在这里，你不仅可以看到微服务架构的基础知识，更多的则是从微服务体系的角度，深入探讨如何将微服务落地，增加理论的实用性。

上面也说了，胡忠想，前微博技术专家（终于不用再因为微博崩了而挨骂了）。他不仅参与了微博后端架构从大的单体应用迁移到微服务架构的改造；还作为主要负责人之一，主导了微服务架构在公司多个业务线的推广和落地。所以谈到将微服务落地，他有绝对的发言权。

老胡的分享，由浅入深、由表及里，逐步带你探索微服务的世界，帮你从 0 开始构建微服务体系。具体来说，专栏分为四个部分：

第一部分，用最通俗的语言讲解微服务架构的基本原理，解答三个问题：什么是微服务？什么时候适合微服务改造？微服务架构到底是什么样的？
第二部分，结合在实际业务中的经验，讲述微服务架构改造过程中可能会遇到的问题和对应的解决方案，以及搭建微服务架构时，如何做技术选型。
第三部分，讲述微服务、容器化、DevOps 这三者之间的关系，以及在具体实践中如何运用这三种技术以给业务的架构带来质的飞跃。
第四部分，介绍下一代微服务体系可能的发展方向，并分享自己的看法。

说了这么多，直接上目录。

极客时间四周年，活动到手价 ¥89

新人首单仅 ¥59

说到底，不管你是一个什么级别的程序员，也不论你在一个什么体量的公司，服务化都是你迟早会遇到的难题。所以，你没理由闭塞视听。

再者说，掌握微服务架构后，你起码能知道领导为啥叫你这么做，也更容易理解公司的技术进程，这于你我的大局观构建都非常有益，强烈建议你入手看看。

👇点击「阅读原文」，免费试读

极客时间四周年，活动到手价 ¥89

新人首单仅 ¥59