微服务：从放弃到入门的三个月
近几年，微服务架构迅速在整个技术社区窜红，它被认为是 IT 软件架构的未来方向。我与同行交流时，提到微服务等新技术，他们先是兴奋，后又无奈。兴奋的是他们看到了新技术带来的便利，无奈的是团队规模和能力又反过来制约了他们采用新技术的步伐。这中间，我也发现大家对微服务有着不同的理解，但更多的是一些疑虑。不知道你是否也有这样的困惑，比如：
- 微服务这技术虽然面试的时候总有人提，但作为一个开发，是不是和我关系不大？那不都是架构师的事吗？
- 微服务不都是大厂在玩吗？我们这个业务体量用得着吗？
- 微服务特别复杂，没个100人的研发团队是不是就无法落地？
我特别理解这样的困惑。的确，大公司动辄就是几百上千的研发人员，并且其中不乏顶尖选手。他们有经验、有能力，也有业务场景，所以在技术的选择上也会更为冒进。而对于大部分的中小团队来说，当微服务架构成为刚需的时候，他们更多的是彷徨和犹豫。
那中小团队应该如何应用微服务呢？或者换句话说，中小团队的技术架构应该如何演进呢？
先给你讲讲我的经历吧。我2012年加入微博，最开始微博首页信息流的后端团队规模也不大，只有七八个人。当时我们就想着快速迭代，业务也就采用了单体应用的架构。因为求快，不同功能模块的代码耦合在一起，编译打包部署也都在一起。
后来业务规模不断扩大，团队人员也增长到二十多人，这时候单体应用架构的开发模式就开始暴露出问题了。那时候，每一次功能发布和上线都需要一个上线负责人来收集上线列表，并协调所有相关的开发人员合并代码到主干，然后编译打包，修改工程依赖的JAR包版本。
你应该可以想象我们那时的状况。如果一次上线超过五个人参与的话，就会经常出现各种问题：有的人忘记提交代码、有的人忘记打包、有的人忘记修改工程依赖到最新版本。一次上线过程需要反复确认，耗费了大量精力，严重影响了整体的开发和部署效率。
看到这，不知你是否大腿一拍，大声叫到：这不就是我们团队每天都在面对的问题嘛！
是的，当时我们为了解决这些问题，做了很细致的技术调研，最后选定了服务化的解决方案。对原有的单体应用架构进行改造，把功能相对独立的模块拆分出去，部署为微服务，分别交给专门的更小的团队来维护。再到后来我们又引入了Docker容器化，以及Service Mesh等技术，为了更好地适应微博业务的高速发展。
可以说，微博的信息流后端架构经历了单体应用 -> 微服务架构 -> 容器化应用 -> DevOps的发展历程。而我也正是因为亲历了微博的架构演进过程，才对中小团队如何落地微服务体系有了更为深刻的理解。