通常跟微服务相对的是单体应用，即将所有功能都打包成在一个独立单元的应用程序。从单体应用到微服务并不是一蹴而就的，这是一个逐渐演变的过程。本文将以一个网上超市应用为例来说明这一过程。
10年前，小海研发了自己的电子商城网站。当时互联网技术还不发达。需求很简单：
只需要一个网站挂在公网，用户能够在这个网站上浏览商品、购买商品，另外还需一个管理后台，可以管理商品、用户、以及订单数据。
功能清单：
网站用户注册、登录功能
商品展示
下单
管理后台用户管理
商品管理
订单管理由于需求简单网站很快就做好了，总体架构图如下：
好景不长，各类电商网站紧跟着拔地而起，对小海的项目造成了冲击。
在竞争的压力下，小海决定开展一些营销手段：
开展促销活动。比如元旦全场打折，春节买二送一，情人节狗粮优惠券等等。
拓展渠道，新增移动端营销。除了网站外，还需要开发移动端APP，微信小程序等。
精准营销。利用历史数据对用户进行分析，提供个性化服务。
……
这些活动都需要程序开发的支持。小海拉了同学小红加入团队。小红负责数据分析以及移动端相关开发。小海负责促销活动相关功能的开发。
因为开发任务比较紧迫，小海小红没有好好规划整个系统的架构，随便拍了拍脑袋，决定把促销管理和数据分析放在管理后台里，微信和移动端APP另外搭建。通宵了几天后，新功能和新应用基本完工。这时架构图如下：
1.网站和移动端应用有很多相同业务逻辑的重复代码。
2.数据有时候通过数据库共享，有时候通过接口调用传输。接口调用关系杂乱。
3.单个应用为了给其他应用提供接口，渐渐地越改越大，包含了很多本来就不属于它的逻辑。应用边界模糊，功能归属混乱。
4.管理后台在一开始的设计中保障级别较低。加入数据分析和促销管理相关功能后出现性能瓶颈，影响了其他应用。
5.数据库表结构被多个应用依赖，无法重构和优化。所有应用都在一个数据库上操作，数据库出现性能瓶颈。特别是数据分析跑起来的时候，数据库性能急剧下降。
6.开发、测试、部署、维护愈发困难。即使只改动一个小功能，也需要整个应用一起发布。有时候发布会不小心带上了一些未经测试的代码，或者修改了一个功能后，另一个意想不到的地方出错了。为了减轻发布可能产生的问题的影响和线上业务停顿的影响，所有应用都要在凌晨三四点执行发布。发布后为了验证应用正常运行，还得盯到第二天白天的用户高峰期……
7.团队出现推诿扯皮现象。关于一些公用的功能应该建设在哪个应用上的问题常常要争论很久，最后要么干脆各做各的，或者随便放个地方但是都不维护。
尽管有着诸多问题，但也不能否认这一阶段的成果：快速地根据业务变化建设了系统。不过紧迫且繁重的任务容易使人陷入局部、短浅的思维方式，从而做出妥协式的决策。在这种架构中，每个人都只关注在自己的一亩三分地，缺乏全局的、长远的设计。长此以往，系统建设将会越来越困难，甚至陷入不断推翻、重建的循环。
是时候做出改变了！ 请继续阅读下一节。
