第一章 系统架构

      随着互联网的发展，网站应用的规模也在不断地扩展，进而促进了我们系统架构不断地优化迭代，从互联网初期到现在，系统架构大体上可以分为一下几个过程：单体应用架构—>垂直应用架构—>分布式架构—>SOA架构—>微服务架构，本章内容大概介绍下每个系统架构以及相对的优缺点。

        这些系统架构相对而言基于本人的了解描述！未更加深入的去进行一个阐述，想深入学习的话建议去看一些开源项目或者一些学习视频！

目录

1.1 单体应用架构

1.2 垂直应用架构

1.3 分布式架构

1.4 SOA架构

1.5 微服务架构

---

---

1.1 单体应用架构

        单体应用架构使我们接触必不可少的体系！一般项目的流量较小，只需要一个应用，将所有功能代码部署在一起就可以了，这样可以减少开发、部署和维护的成本。

        比如一个常见的电商管理系统，里面包含很多的用户管理、商品管理、订单管理或者各个功能板块的数据展示等等，我们将其做成一个web项目，让后部署到一个linux服务器上。

优点：

        1.项目架构简单，小型项目的话， 开发成本低

        2.项目部署在一个节点上， 维护方便

缺点：

        1.全部功能集成在一个工程中，对于大型项目来讲不易开发和维护

        2.项目模块之间紧密耦合，单点容错率低

        3.无法针对不同模块进行针对性优化和水平扩展

1.2 垂直应用架构

        随着公司的发展项目的运行访问流量逐渐增大，单一应用只能依靠增加节点来应对，但是并不是所有的功能板块都会有较大的一个访问量。

        还是以电商为例，用户访问量的增加可能影响较大的是用户、订单、物流等管理版块，但是商品管理等版块影响就比较小，那么我们肯定是想只增加用户、订单等版块，而不增加商品管理等影响较小的版块，此时单体应用的瓶颈就到了，垂直应用架构应运而生！

        所谓的垂直应用架构就是将一个应用拆分成相互不干扰的几个应用，分别部署用以提高效率。比如还是以上面电商为例我们可以这样拆分：

        1.电商系统(用户管理 商品管理 订单管理)

        2.后台系统(用户管理 订单管理 客户管理)

        3.CMS系统(广告管理 营销管理)

        这样拆分完毕之后，一旦用户访问量变大，只需要增加电商系统的节点就可以了，而无需增加后台和CMS 的节点。

1.3 分布式架构

        随着公司发展，垂直应用越来越多时候，重复的业务代码也就会越来越多。这时候我们将重复的代码单独抽取出来做成一个统一的独立的业务服务层服务。

        分布式架构就是将工程拆分成表现层和服务层两个部分，表现层只需要处理页面交互，业务逻辑都调用服务层的服务来实现。

 优点：

        抽取公共的功能为服务层，提高代码复用性

缺点：

        系统间耦合度变高，调用关系错综复杂，难以维护

1.4 SOA架构

        在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个 调度中心对集群进行实时管理。此时，用于资源调度和治理中心(SOA Service OrientedArchitecture， 面向服务的架构) 是关键。

优点:

        1.使用注册中心解决了服务间调用关系的自动调节

缺点:

        2.服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )

        3.服务关心复杂，运维、测试部署困难

1.5 微服务架构

        微服务架构更加强调服务的彻底拆分，某种程度上可以说是面向服务架构SOA的一个发展。将所有服务原子化拆分，单独部署！

优点：

        服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展

        微服务之间采用Restful等轻量级http协议相互调用

缺点：

        分布式系统开发的技术成本高（容错、分布式事务等）