服务演变之路
单体应用架构
在刚开始的时候，企业的用户量、数据量规模都⽐较⼩，项⽬所有的功能模块都放在⼀个⼯程中编码、编译、打包并且部署在⼀个Tomcat容器中的架构模式就是单体应用架构，这样的架构既简单实用、便于维护，成本⼜低，成为了那个时代的主流架构⽅式。这时候由于业务以及规模都⽐较⼩，所以⽆论服务以及DB都是使⽤单节点（all-in-one）的⽅式进⾏部署，这就是单体架构。
优点：
1、项⽬前期开发节奏快，团队成员少的时候能够快速迭代
2、架构简单：MVC架构，只需要借助IDE开发、调试即可
3、易于测试：只需要通过单元测试或者浏览器完成
4、易于部署：打包成单⼀可执行的jar或者打成war包放到容器内启动
缺点：
1、随着时间推移业务增加，功能不断迭代，项⽬会不断变得臃肿，业务耦合严重。
2、新增业务困难：在已经乱如麻的系统中增加新业务，维护成本高，新⼈来了以后很难接手任务，学习成本高。
3、核⼼业务与边缘业务混合在⼀块，出现问题互相影响
垂直应用架构
为了避免单体架构上出现的那些问题，开始对应⽤按照业务做垂直划分，把原来的的⼀个单体架构拆成⼀堆单体应⽤，这时候就由原来的单应⽤变成了多应⽤部署，这就是垂直架构
