随着互联⽹的发展，⽤户群体逐渐扩⼤，⽹站的流量成倍增⻓，常规的单体架构已⽆法满⾜请求压⼒和业务的快速迭代，架构的变化势在必⾏。下面咱们就一起来看看互联网架构的由单体架构到微服务架构的演变过程。
一、单体架构
在刚开始的时候，企业的⽤户量、数据量规模都⽐较⼩，项⽬所有的功能模块都放在⼀个⼯程中编码、编译、打包并且部署在⼀个Tomcat容器中的架构模式就是单体应⽤架构，这样的架构既简单实 ⽤、便于维护，成本⼜低，成为了那个时代的主流架构⽅式。这时候由于业务以及规模都比较小，所以无论服务以及DB都是使用单节点（all-in-one）的方式进行部署，这就是单体架构。下面我们来看一下这种架构下的优缺点
优点：
1、项⽬前期开发节奏快，团队成员少的时候能够快速迭代
2、架构简单：MVC架构，只需要借助IDE开发、调试即可
3、易于测试：只需要通过单元测试或者浏览器完成
4、易于部署：打包成单⼀可执⾏的jar或者打成war包放到容器内启动
缺点：
1、随着时间推移业务增加，功能不断迭代，项目会不断变得臃肿，业务耦合严重，随着项目团队增大，沟通成本高，项目启动慢
2、新增业务困难：在已经乱如麻的系统中增加新业务，维护旧功能，⼀脚踩进去全是不可预测 的问题。新⼈来了以后很难接⼿任务，学习成本⾼
3、核⼼业务与边缘业务混合在⼀块，出现问题互相影响
在这种架构下，就像我们在平时做开发的时候对类、方法等就没有什么设计，所有功能都往一个类中塞一个功能一个方法搞定，就会给人一种外面的人不想进去，里面的人想赶紧出来的感觉，而且除了问题排查巨困难。
随着业务量的不断增加，我们的单体（单节点部署）就会满足不了需求，这时候架构上也会对应做一些调整。比如：应用集群部署、负载均衡、缓存、读写分离等，这样能减少不少服务压力，也就是分流，既然一个服务器干不了，我们就多来几台服务器，一台做一部分事情。
二、垂直应⽤架构
为了避免单体架构上出现的那些问题，大家开始对应用按照业务做垂直划分，把原来的的一个单体架构拆成一堆单体应用，这时候就由原来的单应用变成了多应用部署，这就是垂直架构。下面我们也来看看做垂直划分之后的架构的优缺点
优点：
1、系统拆分实现了流量分担，解决了并发问题
2、可以针对不同模块进⾏优化
3、⽅便⽔平扩展，负载均衡，容错率提⾼
4、系统间相互独⽴，互不影响，新的业务迭代时更加⾼效
缺点：
1、服务之间相互调⽤，如果某个服务的端⼝或者ip地址发⽣改变，调⽤的系统得⼿动改变（也就是硬编码）
2、搭建集群之后，实现负载均衡⽐较复杂，如：内⽹负载，在迁移机器时会影响调⽤⽅的路 由，导致线上故障
3、服务之间调⽤⽅式不统⼀，基于 httpclient 、 webservice ，接⼝协议不统⼀
4、服务监控不到位：除了依靠端⼝、进程的监控，调⽤的成功率、失败率、总耗时等等这些监 控指标是没有的
这时候其实就开始出现了一种思想：分治。也就是分开来治理，为什么单体架构能存在那么些问题？归根结底还是在单体架构下一个应用要做的事情太多，所以的事情都交给一个服务来做，服务太忙了也太乱了。垂直架构下会把单体架构按照业务拆成多个应用进行部署，每个应用负责一部分业务功能。这样就能把压力都分开一点，每个应用承受一些。这就有点想我们设计模式中的组合模式了，一人干一点，谁也不太累。
三、SOA架构
SOA (Service-Oriented Architecture)，即⾯向服务的架构。其思想就是根据实际业务，把系统拆分成合适的、独⽴部署的模块，模块之间相互独⽴（通过Webservice/Dubbo等技术进⾏通信）。可以理解为拆分出来的每个系统都是一个个的组件，组件与组件之间都是通过服务进行调用。下面我们一起来看看SOA架构下的优缺点
优点：
1、分布式
2、松耦合
3、扩展灵活
4、可重⽤
缺点：
1、服务抽取粒度较⼤
2、服务调⽤⽅和提供⽅耦合度较⾼（接⼝耦合度）
在做了垂直划分以后，模块随之增多，维护的成本在也变⾼，⼀些通⽤的业务和模块重复的越来越多，为了解决垂直应用上出现的那些问题如：接⼝协议不统⼀、服务⽆法监控、服务的负载均衡等阿里巴巴搞了一个高效的JavaRpc框架（仅仅是soa架构框架的一个代表）Dubbo，它提供了三⼤核⼼能⼒：⾯向接⼝的远程⽅法调⽤，智能容错和负载均衡，以及服务⾃动注册和发现。
四、微服务架构
在SOA架构下虽然能解决大部分的问题，但是由于他自身的缺点，依然不那么尽如人意，其实主要还是在SOA架构下拆分粒度不是很细，因此大家又在SOA架构下进行了拓展，将服务粒度拆分得更细这就引出了微服务架构。这种架构模式下它拆分粒度更⼩、服务更独⽴。把应⽤拆分成为⼀个个微⼩的服务，不同的服务可以使⽤不同的开发语⾔和存储，服务之间往往通过Restful等轻量级通信。微服务架构关键在于微⼩、独⽴、轻量级通信。微服务架构强调的⼀个重点是“业务需要彻底的组件化 和服务化”。其实这时候就要求服务的拆分达到一个设计原则：单一职责原则。下面我们一起来看看微服务架构下的优缺点
优点：
1、业务聚焦
2、解耦
3、降低团队合作成本
4、复用性高、可维护性搞
缺点：
由于服务拆分粒度很细，技术成本高（容错、分布式事务等），对团队挑战大、服务治理成本高