单体架构 VS 微服务架构

一、单体应用架构

单体架构，是指将开发好的项目打成war包，然后发布到tomcat等容器中的应用。

特点：

1、所有的功能集成在一个项目工程中。

2、所有的功能打一个war包部署到服务器。

3、应用与数据库分开部署。

4、通过部署应用集群和数据库集群来提高系统的性能。

优点：

项目架构简单，前期开发成本低，周期短，小型项目的首选。

 

缺点：

(1):复杂性高
一个百万行级别的单体应用为例，整个项目包含的模块非常多，模块的边界模糊，依赖关系不清晰，代码质量参差不齐，混乱地堆砌在一起……整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个BUG都会造成隐含的缺陷。

(2):技术债务
随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。“不坏不修（Not broken，don’t fix）”，这在软件开发中非常常见，在单体应用中这种思想更甚。已使用的系统设计或代码难以修改，因为应用程序的其他模块可能会以意料之外的方式使用它。

(3):部署频率低
随着代码的增多，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致我们需要重新部署整个应用。全量部署的方式耗时长、影响的范围大、风险高，这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错概率比较高。

(4):扩展能力受限
单体应用只能作为一个整体进行扩展，无法结合业务模块的特点进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更大的内存。由于这些模块部署在一起，我们不得不在硬件的选择上做出妥协。

(5):阻碍技术创新
单体应用往往使用统一的技术平台或方案解决所有问题，团队的每个成员都必须使用相同的开发语言和框架，想要引入新的框架或技术平台会非常困难。例如，一个使用Struts 2构建的、100万行代码的单体应用，如果想要换用Spring MVC，切换成本无疑是非常高的。

 

二、垂直应用架构

垂直应用顾名思义，就是层级之间的排列是垂直的，为什么是垂直的？

我们原先的服务，都是单节点的，假如是单节点的，那么，当我们初期，应用开始不大的时候，我们的单节点足够了，可是，当我们的网络访问量达到了非常高的情况下，我们的单节点将变得非常的拥堵，这个时候，我们需要将所有的访问给拆分开，放到多台机器上，以便不同的机器，提供不同的服务，这些个分散的服务，原先都是集中在一起的，那么现在，就是被垂直的切割开了，部署怎么部署呢，实际上市这样的：我们将本来一个大的服务，拆成许多个小的服务，这样，我们可以将许多个war包分开部署，这样，就达到了，将整个大的服务，拆分为多个小的服务，部署在不同的节点上，就是拆分功能，达到分开部署，每个单节点是一个服务，这样，就有多个服务后台了吧，每个节点就可以提供不同的服务了吧

特点：

1、以单体结构规模的项目为单位进行垂直划分项目即将一个大项目拆分成一个一个单体结构项目。

2、项目与项目之间的存在数据冗余，耦合性较大。

3、项目之间的接口多为数据同步功能，如：数据库之间的数据库，通过网络接口进行数据库同步。

优点：

1、解决高并发问题（如果用户中心访问的人数过多，我们只需要对用户中心进行单一的集群部署）

2、方便水平扩展，容错(用户中心出现问题，商品系统，后台系统还可以正常访问)

3、通过垂直拆分，原来的单体项目不至于无限扩大。

4、不同的项目可采用不同的技术。

缺点：

1、系统之间太过于独立(彼此之间有联系，有需要互相调用的，怎么办。应用之间的交互，已经达到了不可避免的地步)

2、重复开发工作(每个独立的项目都会出现重复性的的代码)