6 张图带你搞懂微服务

虽说[微服务]早已是一个老生常谈的话题了，在 [infoq 或者 [thoughtworks] 上可以找到很多案例，不过可惜的是其中相当比例的案例是失败的案例，究其原因，除了[技术门槛]之外，主要是因为很多人脱离了实际情况，只是为了微服务而微服务。本文通过一个例子带领大家从头到尾体验一下微服务的演化过程，不仅要做到知其然，更要做到知其所以然。（转载自乐字节）

假设我们正在开发一个在线购物项目，其主要功能包括商城、推荐、评论、用户等，它是一个典型的[单体架构]：不同团队的技术人员工作在同一个版本库上，系统功能按模块划分，不同模块之间通过本地函数调用，通常操作同一个数据库。

在项目早期，单体架构往往能很好的适应快速迭代的需求，不过随着项目的发展，项目本身会变得复杂，其弊端不可避免的出现，比如下面列举的一些情况：

因为大家都工作在同一个版本库上，所以可能会遇到：商城模块完成了新功能，准备上线，结果推荐模块刚提交了还没来得及测试的代码，于是不得不推迟上线。

不同的需求采用不同的技术栈：负责评论模块的同事想用 PHP