00 开篇词 微服务,从放弃到入门

你好,我是胡忠想,微博技术专家。从2012年加入微博到现在,我一直在做微博首页信息流相关的业务研发,几乎亲历了微博后端架构的每一次重大升级。不仅参与了微博后端架构从大的单体应用迁移到微服务架构的改造;还作为主要负责人之一,主导了微服务架构在公司多个业务线的推广和落地。所以谈到将微服务落地,我有很多实战干货想和你分享。

不得不说,微服务是当下非常热门的话题。我平时工作之外和圈子里的朋友们交流,提到微服务等新技术,他们先是兴奋,后又无奈。兴奋的是他们看到了新技术带来的便利,无奈的是团队规模和能力又反过来制约了他们采用新技术的步伐。而他们也对微服务有着这样或那样的理解,但更多的是疑惑,比如说他们会问:

我特别理解这样的困惑,因为我也是这么一步步走过来的。的确,大公司动辄就是几百上千的研发人员,并且其中不乏顶尖选手。他们有经验、有能力,也有业务场景,所以在技术的选择上也会更为“冒进”。而对于大部分的中小团队来说,当微服务架构成为刚需的时候,他们更多的是彷徨和犹豫。

先给你讲讲我的经历吧。最开始,微博首页信息流的后端团队规模也不大,只有七八个人。当时我们就想着快速迭代,业务也就采用了单体应用的架构。因为求快,不同功能模块的代码耦合在一起,编译打包部署也都在一起。

后来业务规模不断扩大,团队人员也增长到二十多人,这时候单体应用架构的开发模式就开始暴露出问题了。那时候,每一次功能发布和上线都需要一个上线负责人来收集上线列表,并协调所有相关的开发人员合并代码到主干,然后编译打包,修改工程依赖的JAR包版本。

你应该可以想象我们那时的状况。如果一次上线超过五个人参与的话,就会经常出现各种问题:有的人忘记提交代码、有的人忘记打包、有的人忘记修改工程依赖到最新版本。一次上线过程需要反复确认,耗费了大量精力,严重影响了整体的开发和部署效率。

看到这,不知你是否大腿一拍,大声叫到:这不就是我们团队每天都在面对的问题嘛!

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

可以说,微博的信息流后端架构经历了单体应用 - 微服务架构 - 容器化应用 - DevOps的发展历程。而我也正是因为亲历了微博的架构演进过程,对于中小团队如何落地微服务体系有了更为深刻的理解。

所以,在这个专栏里,我会秉承着这个思路,不断提醒自己,这个方案中小团队是否可用,他们能否驾驭这些技术。我想,这是大部分中小团队的刚需,也是这个专栏的主要出发点。他们需要的不是一个大而全的东西,而是一套可以快速落地的方法论。

我希望在专栏里不仅跟你分享微服务架构的基础知识,更是从微服务体系的角度,和你深入讨论如何将微服务落地,帮你扫清最开始提到的那些疑惑。

那什么是微服务体系呢?在我看来,微服务发展到现在,已经不再单单局限于微服务架构本身,还与容器化、DevOps等新的理念相结合,成为当前移动互联网时代最先进的业务架构解决方案,能更好地迎合移动互联网业务快速迭代的要求

在接下来的三个月里,我将由浅入深、由表及里,逐步带你探索微服务的世界,帮你从0开始构建微服务体系。具体来说,专栏分为四个部分:

如果你刚刚接触微服务体系,希望我的专栏能带你快速入门微服务,具备搭建一套微服务基本架构的能力;如果你有过微服务架构的开发经历,希望可以帮你解决在实际开发过程中遇到的一些问题;如果你已经玩转了微服务的各个方面,希望你可以和我切磋,交流开发心得,畅谈下一代微服务的技术发展;即使你现在还没有用到微服务,但通过专栏的学习,希望你一样能够掌握微服务架构的思维的精髓,提升解决复杂问题的能力。

微服务是当下最火热的后端架构之一。不管你是一个什么级别的程序员,也不论你在一个什么体量的公司,服务化都是你迟早会遇到的难题。从我的经验来看,实践微服务的过程本身也是一个升级打怪的过程,这中间你会遇到基本上所有后端架构的问题。解决了这些问题,你自然也就理解了那些高深的概念,也就成为了一名架构师,成长和能力提升都是这个过程的附属品。

不说虚的,我希望这个专栏能给你在“微服务道路”上增加一块敲门砖,希望我讲的东西对你有所帮助、有所启发。用极客时间团队的话来说,我要为你交付结果,学完这个专栏,希望你可以厘清微服务的脉络,并在恰当的时候,也可以主导自己公司的服务化进程。

我邀请你在接下来的三个月时间里,跟我一起走进微服务的世界,感受学习和进步所带来的乐趣与成就!