据说微服务构架将是IT软件构架的未来方向？

近几年，微服务构架迅速在整个技术 区蹿红，它被认为是IT软件构架的未来方向。

热度虽高，但对于很多中小公司来说微服务确实遥不可及，因为团队规模和能力又反过来制约了他们采用新技术的步伐。很多人对于微服务技术也都有着一些疑虑，比如：

1、微服务者技术虽然面试的时候总有人提，但作为一个开发，是不是和我关系不大？那不都是构架师的事吗？

2、微服务不都是大厂在玩吗？我们这个业务体量用得着吗？

3、微服务特别复杂，没个100人的研发团队是不是就无法落地？

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

如果你还不能具象的体会，那小编给你举个例子你就明白了——微博。

微博技术专家胡忠想曾说：

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

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

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

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

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

可以说，微博的信息流后端架构经历了单体应用 – 微服务架构 – 容器化应用 – DevOps 的发展历程。

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

那么决胜微服务你准备好了吗？

点击链接，了解更多课程详情！