正文
先给你讲讲我的经历吧。我 2012 年加入微博，最开始微博首页信息流的后端团队规模也不大，只有七八个人。当时我们就想着快速迭代，业务也就采用了单体应用的架构。因为求快，不同功能模块的代码耦合在一起，编译打包部署也都在一起。
后来业务规模不断扩大，团队人员也增长到二十多人，这时候单体应用架构的开发模式就开始暴露出问题了。那时候，每一次功能发布和上线都需要一个上线负责人来收集上线列表，并协调所有相关的开发人员合并代码到主干，然后编译打包，修改工程依赖的 JAR 包版本。
你应该可以想象我们那时的状况。如果一次上线超过五个人参与的话，就会经常出现各种问题：有的人忘记提交代码、有的人忘记打包、有的人忘记修改工程依赖到最新版本。一次上线过程需要反复确认，耗费了大量精力，严重影响了整体的开发和部署效率。
看到这，不知你是否大腿一拍，大声叫到：这不就是我们团队每天都在面对的问题嘛！
是的，当时我们为了解决这些问题，做了很细致的技术调研，最后选定了服务化的解决方案。对原有的单体应用架构进行改造，把功能相对独立的模块拆分出去，部署为微服务，分别交给专门的更小的团队来维护。再到后来我们又引入了 Docker 容器化，以及 Service Mesh 等技术，为了更好地适应微博业务的高速发展。
可以说，微博的信息流后端架构经历了单体应用 -> 微服务架构 -> 容器化应用 -> DevOps 的发展历程。而我也正是因为亲历了微博的架构演进过程，才对中小团队如何落地微服务体系有了更为深刻的理解。
