一、概述

每个技术的产生没有更好更坏之分，只是适用于不同的场景罢了。

二、单体架构（单一应用架构）

2.1、单体架构概念

将所有的业务场景的表示层，业务逻辑层和数据访问层打包放在一个工程中，最终经过编译打包，部署在一台服务器上。例如：典型的J2EE工程，把jsp,业务逻辑层的service,controller和数据访问层的dao,打包成wa包，部署在Tomcat或者Jetty或者其他容器上运行。

问题：数据库和应用程序部署到不同的服务器是单体架构吗？

单体架构关心的是否是整个应用部署同一个包，如果是则为单体架构，否则就不是。

2.2、单体架构应用场景及特点

业务场景简单,功能不复杂，研发人员较少。

公司处于创业初期：为了生存，需要的是快速开发出功能，然后到市场上试错。

性能要求及其苛刻：一些对性能要求比较高的系统，例如股票软件。

需求比较稳定的系统也不适合做成微服务，例如：公司内部OA，考勤系统等。

比如简单的网上超市，网站 页面包括 用户注册、登录功能、商品展示、下单。管理后台包括用户管理、商品管理、订单管理。需要快速开发出功能，发布到市场上，这种就直接使用单体架构即可。

传统架构其实就是SSH或者SSM，属于单点应用，把整个业务模块都在一个项目进行开发，分为MVC架构，会拆分成controller,service,dao层。

部署的时候首先所有功能集中在一个项目中打war包部署，通过集群(session共享集群)来提高服务器的性能。war包，图片服务器整合到war包，放到同一台服务器。

2.3、单体架构的优缺点 

优点:

部署简单 ：由于是完整的结构体，可以直接部署在一份服务器上即可；

技术单一 ：项目不需要复杂的技术栈，往往一套熟悉的技术栈就可以完成开发，前期开发的成本低,周期短,小型企业首选；

用人成本低 ：单个程序员可以完成业务接口到数据库的整个流程。

缺点：

业务越来越复杂，单体架构扩展性不足，业务扩展带来的代价越来越大；

用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限；

单体应用的业务都在同一个程序中，增删改业务修改，也会影响其他代码，给测试增加了难度。

阻碍技术创新

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

2.4、单体架构的后阶段

分层开发

分层的开发的目的：

为了解决容错性差，比如用户查询数据导致sql异常，会导致整个页面无法访问，从而导致整个服务器的宕机，此时，我们可以使用分层开发，每一个如果发生错误的话，在上一层可以进行异常捕获，这个错误就可以不让用户看到。

分层的开发的好处：提高系统的维护性，解决容错性问题，后面就总结出MVC设计模式(MVC架构解决方案)。分层开发，还可以把服务器分离部署（把数据库和应用程序分开部署）。

特点和好处：

MVC分层开发能够解决基本的容错性问题，数据库和项目部署分离。但是随着互联网的开发，网站的访问量的持续增加，单台的应用服务器已经无法满足用户的需求。

2.5、单体架构提高并发访问量

服务器集群:就是服务器集群就是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个机器坏了整个系统还是能正常运行。

随着业务的扩展，大部分公司会将单体应用进行集群式部署，并增加负载均衡器，还需要增加集群部署的缓存服务器和文件服务器，并将数据库读写分离，以应对用户量的增加带来的高并发访问量。

2.6、单体架构使用服务器集群及存在的不足

代码可读性，可维护性差；

面对海量用户，数据库会成为瓶颈，需要使用分库分表；

持续交付能力差，业务越复杂，代码越多熟悉成本高。

三、垂直架构

3.1、垂直架构概念

访问量逐渐增大，单体架构单加集群节点带来服务器性能越来越小。比如有的模块是计算密集型的，它需要强劲的 CPU ;有的模块则是 IO 密集型的，需要更大的内存。由于这些模块部署在一起，不得不在硬件 的选择上做出妥协。因此我们通常需要将应用拆成互不相干的几个应用，这就称之为垂直架构 。

3.2、垂直架构的优缺点

优点：

系统拆分实现了流量分担，解决了并发问题

可以针对不同模块进行优化

方便水平扩展，负载均衡，容错率提高

系统间相互独立

缺点：

服务之间相互调用，如果某个服务的端口或者ip地址发生改变，调用的系统得手动改变

搭建集群之后，实现负载均衡比较复杂

会员项目、订单项目、支付项目、优惠券等。项目与项目之间进行webservice、RPC远程通信等。每个项目中都有自己独立的数据库（redis等），

分布式架构拆分

会员：登录、注册、修改密码。

订单：下单，查询订单。

3.1、分布式架构特点

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

项目与项目之间的存在数据冗余，耦合性较大，比如上图中三个项目都存在客户信息。

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

3.2、分布式架构优缺点

优点：

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

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

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

缺点：

复杂应用的开发维护成本变高，部署效率逐渐降低。因为随着业务功能的不断膨胀，代码全量编译和部署一次所需的时间非常长。

团队协作效率差，部分公共功能重复开发，代码重复率居高不下。

系统可靠性变差。垂直架构将所有的应用模块都部署到一个进程中，如果某个应用接口发生故障，例如内存泄漏，会导致整个节点宕机。

四、SOA架构(面向服务架构)

HClient:将共同的业务逻辑进行拆分，拆分成独立的项目进行部署。

服务化：面向业务逻辑层开发。

项目：包含业务逻辑层和视图层。服务：只包含业务逻辑层，没有视图层。

重点术语剖析：

负载均衡器：分发高并发的网络请求，用户的访问被分派到不同的应用服务器。用户增加时，添加应用服务器即可。

缓存服务器：缓解数据库的数据以及数据库读取的压力。

五、微服务架构

5.1、微服务架构概念

微服务架构：将单体应用拆分为多个高内聚低耦合的小型服务，每个小服务运行在独立进程，由不同的团队开发和维护，服务间采用轻量级通信机制，独立自动部署，可以采用不同的语言及存储。

单体架构整个团队维护开发一个大工程及一个单库，到了微服务架构，用户请求经过API Gateway被路由到下游服务，服务之间以轻量级通信协议进行通信，服务通过注册中心发现彼此，每个服务都有专门的开发维护团队，每个服务对应独立的数据库，服务独立开发，独立部署和上线。

5.2、微服务架构的特点

将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。

微服务遵循单一原则（一个服务做一件事）。

微服务之间采用RESTful等轻量协议传输。

5.3、微服务架构的优缺点

优点：

服务拆分粒度更细，有利于资源重复利用，提高开发效率。

可以更加精准的制定每个服务的优化方案，提高系统可维护性。

微服务架构采用去中心化思想，服务之间采用RESTful等轻量协议通信，相比ESB更轻量。

适用于互联网时代，产品迭代周期更短。

单个微服务启动较快

技术栈不受限

缺点：

微服务过多，服务治理成本高，不利于系统维护。

分布式系统开发的技术成本高（容错、分布式事务等），对团队挑战大。