一文说清楚 软件架构的来历 单体，垂直，SOA，微服务

一 概述

软件架构经过以下几个阶段：单体应用架构—>垂直应用架构—>分布式架构—>SOA架构—>微服务架构的演变。

1.1 单体应用架构

在企业发展的初期，一般公司的网站流量都比较小，只需要一个应用，将所有的功能代码打包成一个服务，部署到服务器上就能支撑公司的业务。这样也能够减少开发、部署和维护的成本。

比如，早起使用ssh，ssm构建的电商系统，里面包含的用户、订单、库存、物流等管理模块均在一个系统中。我们会将所有模块写到一个Web项目中，然后统一部署到一个Web服务器中。如下图所示：

或者单体引用：

 1.1.1 优点

• 架构简单，项目开发和维护成本低。
• 所有项目模块部署到一起，对于小型项目来说，维护方便。

1.1.2 缺点

• 所有模块耦合在一起，虽然对于小型项目来说，维护方便。但是，对于大型项目来说，却是不易开发和维护的。
• 项目的各模块之前过于耦合，如果一旦有一个模块出现问题，则整个项目将不可用。
• 无法针对某个具体模块来提升性能。
• 无法对项目进行水平扩展。

 1.2 垂直应用架构

随着企业业务的不断发展，发现单节点的单体应用不足以支撑业务的发展，于是企业会将单体应用部署多份，分别放在不同的服务器上。

垂直应用架构，就是将原来一个项目应用进行拆分，将其拆分为互不想干的几个应用，以此来提升系统的整体性能。

以电商系统为例，在垂直应用架构下，我们可以将整个电商项目拆分为：电商交易系统、后台管理系统、CMS管理系统等。

 我们将单体应用架构拆分为垂直应用架构之后，一旦访问量变大，我们只需要针对访问量大的业务增加服务器节点即可，无需针对整个项目增加服务器节点了。

 1.2.1 优点

• 系统进行了拆分，可根据不同系统的访问情况，有针对性的进行优化。
• 能够实现应用的水平扩展。
• 各系统能够分担整体访问的流量，解决了并发问题。
• 一个系统发生了故障，不影响其他系统的运行情况，提高了整体的容错率。

 1.2.2 缺点

• 分后的各系统之间相对比较独立，无法进行互相调用。
• 各系统难免存在重叠的业务，会存在重复开发的业务，后期维护比较困难

  1.3 分布式应用架构

我们将系统演变为垂直应用架构之后，当垂直应用越来越多，重复编写的业务代码就会越来越多。此时，我们需要将重复的代码抽象出来，形成统一的服务供其他系统或者业务模块来进行调用。此时，系统就会演变为分布式架构。
在分布式架构中，我们会将系统整体拆分为服务层和表现层。服务层封装了具体的业务逻辑供表现层调用，表现层则负责处理与页面的交互操作。

  1.3.1 优点

1.将重复的业务代码抽象出来，形成公共的访问服务，提高了代码的复用性。

2.可以有针对性的对系统和服务进行性能优化，以提升整体的访问性能。

 1.3.2 缺点

系统之间的耦合度变高，调用关系变得复杂，难以维护。

  1.4 SOA应用架构

在分布式架构下，当部署的服务越来越多，重复的代码就会越来越多，对于容量的评估，小服务资源的浪费等问题比较严重。此时，我们就需要增加一个统一的调度中心来对集群进行实时管理。此时，系统就会演变为SOA（面向服务）的架构。

 面向服务架构的例子：

单点登录（SSO）是一个典型的面向服务的架构，在互联网公司中被广泛使用。国内互联网巨头往往拥有多个系统，例如腾讯的QQ音乐、空间都可以使用同一个QQ号登陆。于是用户服务和认证服务被剥离开来，各个系统之间通过统一登录和管理用户信息，用户的体验得到了极大的提升。

  1.4.1 优点

使用注册中心解决了各个服务之间的服务依赖和调用关系的自动注册与发现;

  1.4.2 缺点

• 各服务之间存在依赖关系，如果某个服务出现故障可能会造成服务的雪崩;
• 服务之间的依赖与调用关系复杂，测试部署的困难比较大