|
|
|
|
|
# 开篇词 | 微服务，从放弃到入门
|
|
|
|
|
|
|
|
|
|
|
|
你好，我是胡忠想，微博技术专家。从2012年加入微博到现在，我一直在做微博首页信息流相关的业务研发，几乎亲历了微博后端架构的每一次重大升级。不仅参与了微博后端架构从大的单体应用迁移到微服务架构的改造；还作为主要负责人之一，主导了微服务架构在公司多个业务线的推广和落地。所以谈到将微服务落地，我有很多实战干货想和你分享。
|
|
|
|
|
|
|
|
|
|
|
|
不得不说，微服务是当下非常热门的话题。我平时工作之外和圈子里的朋友们交流，提到微服务等新技术，他们先是兴奋，后又无奈。兴奋的是他们看到了新技术带来的便利，无奈的是团队规模和能力又反过来制约了他们采用新技术的步伐。而他们也对微服务有着这样或那样的理解，但更多的是疑惑，比如说他们会问：
|
|
|
|
|
|
|
|
|
|
|
|
* 微服务这技术虽然面试的时候总有人提，但作为一个开发，是不是和我关系不大？那不都是架构师的事吗？
|
|
|
|
|
|
|
|
|
|
|
|
* 微服务不都是大厂在玩吗？我们这个业务体量用得着吗？
|
|
|
|
|
|
|
|
|
|
|
|
* 微服务特别复杂，没个100人的研发团队是不是就无法落地？
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
我特别理解这样的困惑，因为我也是这么一步步走过来的。的确，大公司动辄就是几百上千的研发人员，并且其中不乏顶尖选手。他们有经验、有能力，也有业务场景，所以在技术的选择上也会更为“冒进”。而对于大部分的中小团队来说，当微服务架构成为刚需的时候，他们更多的是彷徨和犹豫。
|
|
|
|
|
|
|
|
|
|
|
|
先给你讲讲我的经历吧。最开始，微博首页信息流的后端团队规模也不大，只有七八个人。当时我们就想着快速迭代，业务也就采用了单体应用的架构。因为求快，不同功能模块的代码耦合在一起，编译打包部署也都在一起。
|
|
|
|
|
|
|
|
|
|
|
|
后来业务规模不断扩大，团队人员也增长到二十多人，这时候单体应用架构的开发模式就开始暴露出问题了。那时候，每一次功能发布和上线都需要一个上线负责人来收集上线列表，并协调所有相关的开发人员合并代码到主干，然后编译打包，修改工程依赖的JAR包版本。
|
|
|
|
|
|
|
|
|
|
|
|
你应该可以想象我们那时的状况。如果一次上线超过五个人参与的话，就会经常出现各种问题：有的人忘记提交代码、有的人忘记打包、有的人忘记修改工程依赖到最新版本。一次上线过程需要反复确认，耗费了大量精力，严重影响了整体的开发和部署效率。
|
|
|
|
|
|
|
|
|
|
|
|
看到这，不知你是否大腿一拍，大声叫到：这不就是我们团队每天都在面对的问题嘛！
|
|
|
|
|
|
|
|
|
|
|
|
当时我们为了解决这些问题，做了很细致的技术调研，最后选定了服务化的解决方案，对原有的单体应用架构进行改造，把功能相对独立的模块拆分出去，部署为微服务，分别交给专门的更小的团队来维护。后来我们又引入了Docker容器化，以及Service Mesh等技术，为了更好地适应微博业务的高速发展。
|
|
|
|
|
|
|
|
|
|
|
|
可以说，微博的信息流后端架构经历了单体应用 - 微服务架构 - 容器化应用 - DevOps的发展历程。而我也正是因为亲历了微博的架构演进过程，对于中小团队如何落地微服务体系有了更为深刻的理解。
|
|
|
|
|
|
|
|
|
|
|
|
所以，在这个专栏里，我会秉承着这个思路，不断提醒自己，这个方案中小团队是否可用，他们能否驾驭这些技术。我想，这是大部分中小团队的刚需，也是这个专栏的主要出发点。他们需要的不是一个大而全的东西，而是一套可以快速落地的方法论。
|
|
|
|
|
|
|
|
|
|
|
|
我希望在专栏里不仅跟你分享微服务架构的基础知识，更是从微服务体系的角度，和你深入讨论如何将微服务落地，帮你扫清最开始提到的那些疑惑。
|
|
|
|
|
|
|
|
|
|
|
|
那什么是微服务体系呢？在我看来，微服务发展到现在，已经不再单单局限于微服务架构本身，还与容器化、DevOps等新的理念相结合，成为**当前移动互联网时代最先进的业务架构解决方案，能更好地迎合移动互联网业务快速迭代的要求**。
|
|
|
|
|
|
|
|
|
|
|
|
在接下来的三个月里，我将由浅入深、由表及里，逐步带你探索微服务的世界，帮你**从0开始构建微服务体系**。具体来说，专栏分为四个部分：
|
|
|
|
|
|
|
|
|
|
|
|
* 第一部分，我会尽量用最通俗的语言去讲解微服务架构的基本原理，帮你解答三个问题：什么是微服务？什么时候适合微服务改造？微服务架构到底是什么样的？
|
|
|
|
|
|
|
|
|
|
|
|
* 第二部分，我会结合在实际业务中的经验，给你讲述微服务架构改造过程中可能会遇到的问题和对应的解决方案，以及搭建微服务架构时，如何做技术选型。
|
|
|
|
|
|
|
|
|
|
|
|
* 第三部分，我会给你讲述微服务、容器化、DevOps这三者之间的关系，以及在具体实践中如何运用这三种技术给业务的架构带来质的飞跃。
|
|
|
|
|
|
|
|
|
|
|
|
* 第四部分，我会给你介绍下一代微服务体系可能的发展方向，并分享我对此的看法。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
如果你刚刚接触微服务体系，希望我的专栏能带你快速入门微服务，具备搭建一套微服务基本架构的能力；如果你有过微服务架构的开发经历，希望可以帮你解决在实际开发过程中遇到的一些问题；如果你已经玩转了微服务的各个方面，希望你可以和我切磋，交流开发心得，畅谈下一代微服务的技术发展；即使你现在还没有用到微服务，但通过专栏的学习，希望你一样能够掌握微服务架构的思维的精髓，提升解决复杂问题的能力。
|
|
|
|
|
|
|
|
|
|
|
|
微服务是当下最火热的后端架构之一。不管你是一个什么级别的程序员，也不论你在一个什么体量的公司，服务化都是你迟早会遇到的难题。从我的经验来看，实践微服务的过程本身也是一个升级打怪的过程，这中间你会遇到基本上所有后端架构的问题。解决了这些问题，你自然也就理解了那些高深的概念，也就成为了一名架构师，成长和能力提升都是这个过程的附属品。
|
|
|
|
|
|
|
|
|
|
|
|
不说虚的，我希望这个专栏能给你在“微服务道路”上增加一块敲门砖，希望我讲的东西对你有所帮助、有所启发。用极客时间团队的话来说，我要为你交付结果，学完这个专栏，希望你可以厘清微服务的脉络，并在恰当的时候，也可以主导自己公司的服务化进程。
|
|
|
|
|
|
|
|
|
|
|
|
我邀请你在接下来的三个月时间里，跟我一起走进微服务的世界，感受学习和进步所带来的乐趣与成就！
|
|
|
|
|
|
|
