【软件架构】

软件架构

软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件体系结构是构建计算机软件实践的基础。

以上是百度百科对于软件架构的一词的解释。任何一套软件系统都离不开软架构，就比如一座高楼大厦的建造离不开其设计图纸 。随着互联网的不断发展，互联网项目的用户访问量在不断地增加，早期的架构已经不能满足如今开发的要求。因此软件的架构一直在变，以适应开发的需求。软件架构的发展经历了由单体架构、垂直架构、SOA架构到微服务架构的演变过程。下文主要对以上提到的四种重要的软件架构进行简要概述。

单体架构

简介

一个归档包（例如war格式或者Jar格式）包含了应用所有功能的应用程序，我们通常称之为单体应用。架构单体应用的方法论，我们称之为单体应用架构，这是一种比较传统的架构风格。简单来说，单体即一个项目，该项目内的所有模块和所有代码都写在一个项目里面。

上图的商城项目就是单体项目的一个简单的例子，其软件基础架构大致如下图所示：

单体项目也是要进行分层开发的。上图所示的软件结构称为B/S结构，Server端是要进行分层开发的。

架构简析

优点总结为如下：
架构简单，前期开发成本低、开发周期短，适合小型项目。
缺点总结为如下：
① 高复杂性
项目的模块众多，模块和模块之间边界模糊且依赖关系不清，代码质量参差不齐，这导致了项目复杂度骤增，加大了代码维护的难度。
② 技术债务逐渐上升
随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。已使用的系统设计或代码难以修改，因为应用程序的其他模块可能会以意料之外的方式使用它。
③ 部署速度逐渐变慢
应用的构建和部署的时间会随着代码量的增加而不断增加。对于单体应用，其每次功能的变更或缺陷的修复都会导致我们需要重新部署整个应用。这种全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低，从而又导致两次发布之间会有大量功能变更和缺陷修复，出错概率较高。
④ 扩展能力受限，无法按需伸缩
单体应用只能作为一个整体进行扩展，无法结合业务模块的特点进行伸缩。
⑤ 阻碍技术创新
统一的技术平台或方案使单体应用想要引入新的框架或技术平台非常困难。

总的来说

对于单体应用来说，其全部功能集成在一个工程中，这增加了大型项目开发、扩展和维护的难度；单一的技术栈，也必定导致了单体应用只能使用一种编程语言进行开发；此外，单体应用的系统性能只能通过扩展集群节点进行扩展，成本高。也正是由于这些因素，单体架构也随着技术的发展而逐渐被淘汰。

---

分层架构

简介

如上图所示，垂直架构其实就是按照业务的维度对对应用的功能进行划分，将一个大的单体项目划分成若干合适的小的单体项目，其中每个小的单体项目进行能够单独地开发，并独立运行。
就比如在上图中，我们可以将与用户相关的模块放在用户管理系统中，将订单相关的模块放在订单管理系统中等等。

根据上图所示，一个较大的单体项目可以先根据业务进行垂直划分成若干个小的单体项目，然后将这些小的单体项目依次进行分层划分，使每个小的单体项目自身划分成表示层、业务层和持久层等等。

但是，经过划分的系统本质上仍然属于一个子系统，将该项目部署运行时其内部的各个模块依然会被打包在一个归档包中，部署的效率让然十分低下。

架构简析

架构说明：
按照业务进行切割，形成小的单体项目。垂直MVC项目主要有表现层，业务逻辑层，数据访问层组成的MVC架构，整个项目打包放在一个tomcat里面。适合于访问量小，用户数不多的业务。
优点总结如下：
技术栈可扩展（不同的系统可以用不同的编程语言编写）。这就克服了单体架构单一技术栈的缺点。
缺点总结如下：
① 这是一个大而全的项目，项目的部署效率很低，代码全量编译和部署一次发布需要很长时间，更重要的是 如果某个功能出错有问题，所有的功能都需要再重新打包编译，部署效率极低。
② 团队协作难度高，如多人使用 git 很可能在同一个功能上，多人同时进行了修改，作为一个大而全的项目，可能个人只是需要开发其中一个小的模块的需求，却需要导入整个项目全量的代码。

总的来说

对于垂直架构来说，所有的功集中在一个项目中并且项目之间功能冗余、数据冗余、耦合性强，这些特点使项目开发、扩展和维护的难度大大增加。此外，只能通过集群的方式对系统进行扩充。

---

SOA架构

简介

SOA 全称为 Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。在操作系统进程，一个服务通常独立存在。要注意的是，此处所说的粗粒度即功能划分的细致程度，当粗粒度较大时，同一功能所抽象出的服务往往较大，服务的数量相对应的会比较小，反之，则划分出的服务相对较小，服务的数量会相对较大。
为了把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。从功能入手，我们能够把业务逻辑抽象成可复用的服务，通过服务的编排实现业务的快速再生。

架构简析

架构说明：
将重复功能或模块抽取成组件的形式，对外提供服务，在项目与服务之间使用ESB（企业服务总线）的形式作为通信的桥梁。

如图5，从物流管理系统和CRM系统共有的功能中抽取出相同的部分，该部分按照其能够满足的业务特点再细分成与用户相关的用户服务和与订单相关的订单服务。物流管理系统和CRM管理系统通过企业服务总线调用这两种不同的服务，并根据系统自身的需求特点，来实现特定功能的模块。这种方式实现了服务的重复使用。

什么是ESB?
简单 来说 ESB 就是一根管道，用来连接各个服务节点。为了集 成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通；
下面是SOA架构的示意图:

架构优点：
① 重复功能或模块抽取为服务，提高开发效率。
②可重用性高。
③可维护性高。
架构缺点：
① 各系统之间业务不同，很难确认功能或模块是重复的。
② 抽取服务的粒度大。
③ 系统和服务之间耦合度高。

如图7，是从单体应用到SOA架构的转变：

---

微服务架构

简介

微服务架构是在SOA架构上的改进，微服务架构把“业务需要彻底的组件化和服务化”作为重点之一，将原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些服务使各应用之间实现交互和集成。

架构简析

架构说明：
①将系统服务层完全独立出来，抽取为一个一个的微服务。
②抽取的粒度更细，遵循单一原则。
③采用轻量级框架协议传输。

什么是API服务器？
API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
如图 9，服务提供方(provider)启动的时候把自己的地址上报给服务注册中心（如上图所说的API网关），这就是服务注册。服务调用方(consumer)订阅服务变更通知，动态地接收服务注册中心推送的服务地址列表，服务调用方根据接收到的服务地址列表远程调用相应的服务。

优点总结如下：
①服务拆分粒度更细，有利于提高开发效率。
②可以针对不同服务制定对应的优化方案。
③适用于互联网时代，产品迭代周期更短。

缺点总结如下：
①粒度太细导致服务太多，维护成本高。
②分布式系统开发的技术成本高，对团队的挑战大。