软件架构的演变过程

软件架构的演变过程

文章目录

• • 1. 什么是软件架构
  • 2. 架构的分类
  • 3. 软件架构演变过程
  • • 3.1单体架构(all in one)
    • • 3.1.1优点
      • 3.1.2缺点
    • 3.2分布式架构(垂直架构)
    • • 3.2.1特点
      • 3.2.2优点：
      • 3.2.3缺点：
    • 3.3SOA架构
    • • 3.3.1特点
      • 3.3.2优点
      • 3.3.3缺点
    • 3.4微服务架构
    • • 3.4.1特点
      • 3.4.2优点
      • 3.4.3缺点
      • 3.4.3缺点

1. 什么是软件架构

单体项目的尴尬之处：当项目中的某个模块的使用人数激增，例如618当天，下单的人数一定会非常多，但是因为下单和评论、售后是同一个项目，会导致下单卡顿的同时，评论和售后也会一起卡顿。

于是乎，就有了微服务的概念。每个项目可以理解为只完成特定的模块功能，比如刚才的下单和评论、售后、就可以分开三个项目。

软件架构是一个系统的草图。

软件架构描述的对象是直接构成系统的抽象组件。

各个组件之间的连接则明确和相对细致地描述组件之间的通讯。

在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。

在面向对象领域中，组件之间的连接通常用接口来实现。

总结成一句话，软件架构是对一个系统进行宏观上的设计。

其实软件架构非常类似于建筑设计规划，城市总体规划等，其实就是架构，只是应用的场景不同。盖一座小房子，可以拍脑袋干起来，但是当你要盖一座大楼，如果没有一个建筑设计规划，可以想象搭建最后是什么样？打个比方，在建造一个桥梁之前，需要先由桥梁工程师先对桥梁进行整体设计，比如说整个桥梁由哪些组件构成，组件和组件如何结合到一起，各个组件使用什么材质，整个桥梁可以抗多少级地震，多少级台风，多少吨承重，这些都属于架构。

2. 架构的分类

架构可以分为：业务架构、应用架构、数据架构和技术架构，整体逻辑关系如下：

业务（逻辑）架构：使用一套方法论对产品（项目）所涉及到的需求的业务进行业务边界划分，简单的讲就是根据一套逻辑思路进行业务的拆分，总体原则是对业务进行业务边界的划分，比如做一个企业订购服务网站，你需要把商品类目、商品、订单、订单服务、支付、退款很清晰的划分出来，而业务架构不需要考虑诸如我用什么技术开发、我的并发大怎么办、我选择什么样的硬件等等。

应用架构：应用是介于业务语言与技术语言之间，是对整个系统实现的总体上的架构，他需要指出系统的层次、系统开发的原则、系统各个层次的应用服务，例如，上述系统中可以分为、数据层（资源层）、数据服务层、中间构建服务层、业务逻辑层、表现层，并写明每个层次应用服务。应用架构是要说明产品架构分哪些应用系统，应用系统间是如何集成的，考虑两个事情：第一、考虑的是子系统间的关系。第二、考虑将可复用的组件或模块进行下沉，沉淀到平台层，为业务组件提供统一的支撑。

数据（持久化）架构：对存储数据（资源）的架构方法论，其架构原则同应用架构大同小异，即考虑到各个系统应用场景、不同时间段的应用场景对数据进行诸如数据异构、读写分离、数据库或NOSQL的策略、缓存的使用、分布式数据（数据库）策略等等。 数据架构主要解决三个问题：第一，系统需要什么样的数据；第二，如何存储这些数据；第三，如何进行数据架构设计。

技术架构：应用架构本身只关心需要哪些应用系统，哪些平台来满足业务目标的需求，而不会关心在整个构建过程中你需要使用哪些技术。技术架构是应接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚。技术架构解决的问题包括：如何进行纯技术层面的分层、**开发框架的选择、开发语言的选择、**涉及非功能性需求的技术选择。

总体来看，首先需要熟悉业务，形成业务架构，根据业务架构，做出相应的数据架构和应用架构，最后通过技术架构落地实施。业务架构是战略，应用架构是承上启下，一方面承接业务架构的落地，另一方面影响技术架构的选型。如何针对当前需求，选择合适的架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。

没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往是空中楼阁。

3. 软件架构演变过程

一个成熟的系统架构并不是一开始就设计的非常完美的，世上没有完美的架构，也不是一开始就具备高性能、高可用、安全性等特性，而是随着用户量的不断增加、业务功能的扩展逐步完善演变过来的。在这个过程中，架构也因此也不断的演进、升级、迭代。从单体架构，到分布式架构，到SOA，以及现在火热的微服务架构。如果一个软件开发人员，不了解软件架构的演进，会制约技术的选型和开发人员的生存、晋升空间。这里我列举了目前主要的四种软件架构以及他们的优缺点，希望能够帮助软件开发人员拓展知识面。

3.1单体架构(all in one)

单体架构是最简单的架构风格，也就是把所有的功能模块打包到一起然后再进行部署，采用了单体架构的项目被称之为单体应用。

3.1.1优点

开发简单，测试简单，部署简单

3.1.2缺点

l 项目复杂性高，代码严重耦合，代码维护困难 单体架构的系统存在代码严重耦合的问题，以一个百万行级别的单体应用为例，整个项目包含的模块非常多、模块的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起。可想而知整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个Bug都会带来隐含的缺陷，修改一处代码，可能会影响一大片的功能无法正常使用。 l 欠下一屁股技术债务 随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。“ 不坏不修”，这在软件开发中非常常见，在单体应用中这种思想更甚。已使用的系统设计或代码难以被修改，因为应用程序中的其他模块可能会以意料之外的方式使用它。 l 部署频率低 随着代码的增多，构建和部署的项目时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错率比较高。 l 局部功能的修改需要整个系统重新发布， 牵一发而动全身 单体架构的系统变更对部署影响大，并且这个问题是所有的单体架构系统都存在的问题。系统作为一个单体部署，每次发布的部署单元就是一个新版本的整个系统，系统内的任何业务逻辑调整都会导致整个系统的重新打包，部署、停机、再重启，进而导致了系统的停机发布时间较长。每次发布上线都是生产系统的重大变更，这种部署模式大大提升了系统风险，降低了系统的可用性。 l 可靠性差(连坐) 某个应用Bug，例如死循环、内存溢出等，可能会导致整个应用的崩溃 l 扩展能力受限 单体应用只能作为一个整体进行扩展，无法根据某个业务模块的需要进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更大的内存。如果任何一个模块存在性能问题，那么都需要考虑多部署几个完整的实例的集群，或者再加上负载均衡设备，才能保证整个系统的性能可以支撑用户的使用。 l 影响开发效率 单体架构的系统影响开发效率。如果一个使用 Java 的简单单体项目代码超过 100 万行，那么在一台笔记本电脑上修改了代码后执行自动编译，可能需要等待十分钟以上，并且内存可能不够编译过程使用，这是非常难以忍受的。或者说因为别的模块出现问题，导致整个系统无法运行，这也是非常难以忍受的。 l 系统(应用、项目)启动慢 单体架构模式打包后的部署结构可能过于庞大，导致业务系统启动很慢，进而也会影响系统的可用性。这一条也是所有单体架构的系统都有的问题。 l 阻碍技术创新，技术栈受限 单体应用往往使用统一的技术平台或方案解决所有的问题，团队中的每个成员都必须使用相同的开发语言和框架，要想引入新框架或新技术平台会非常困难。

综上所述，单体架构模式比较适用于规模较小的系统和规模较小的团队，特别是需要快速推出原型实现，以质量换速度的场景。

3.2分布式架构(垂直架构)

分布式和集群：

分布式：多个人完成一件事情 集群：多个人做同样的事情 比如说你开了一家饭店，饭店里有一个厨师，这个厨师又得配菜又得炒菜，这时候万一这个厨师生病了来不了了干不了活，这个时候你的饭店是不是就不可用了，对外提供不了吃饭服务了。这个时候呢你又招了一个厨师，这两个厨师都做的是一模一样的菜，那这两个厨师之间的关系就是集群。为了让厨师能专注的去炒菜，这个时候呢你又招了一个配菜员，配菜员和厨师之间的关系就是分布式。

针对单体架构的不足，为了适应大型项目的开发需求，许多公司将一个单体架构系统业务垂直拆分为若干个子系统，系统之间通过远程接口调用来完成用户的业务处理，每个系统可分布式部署，这种架构称为分布式架构。也就说将一个大系统拆分为多个子系统。

httpclient相互调用。

3.2.1特点

(1) 按业务垂直拆分成一个一个的单体系统，此架构也称为垂直架构。 (2) 系统与系统之间的存在数据冗余，耦合性较大，如上图中三个项目都存在客户信息。 (3) 系统之间的接口多为实现数据同步，如上图中三个项目要同步客户信息。

3.2.2优点：

(1) 通过垂直拆分，每个子系统变成小型系统，功能简单，前期开发成本低，周期短。 (2) 每个子系统可按需灵活的进行伸缩。 (3) 每个子系统可采用不同的技术。

3.2.3缺点：

(1) 子系统之间存在数据冗余、功能冗余，耦合性高。 (2) 按需伸缩粒度不够，对同一个子系统中的不同的业务无法实现，比如订单管理和用户管理。

3.3SOA架构

SOA是一种面向服务的架构，基于分布式架构，它将不同业务功能按服务进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。

3.3.1特点

(1) 基于分布式的架构思想，将重复公用的功能抽取为组件，以服务的方式向各个子系统提供服务。 (2) 各个系统与服务之间采用WebService、HttpClient、RPC等方式进行通信。 (3) ESB企业服务总线作为系统与服务之间通信的桥梁。(ESB可以读取xml中的配置信息，做到多端同步)

3.3.2优点

(1) 将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。 (2) 可以针对不同服务的特点按需伸缩。 (3) 采用ESB减少系统中的接口耦合。

3.3.3缺点

(1) 系统与服务的界限模糊，会导致抽取的服务的粒度过大，系统与服务之间耦合性高。 (2) 虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。

3.4微服务架构

基于SOA架构的思想，为了满足移动互联网对大型项目及多客户端的需求，对服务层进行细粒度的拆分，所拆分的每个服务只完成某个特定的业务功能，比如订单服务只实现订单相关的业务，用户服务实现用户管理相关的业务等等，服务的粒度很小，所以称为微服务架构。

3.4.1特点

(1) 服务层按业务拆分为一个一个的微服务。 (2) 微服务的职责单一。 (3) 微服务之间采用RESTful、RPC等轻量级协议传输。 (4) 有利于采用前后端分离架构。

https://www.jianshu.com/p/2accc2840a1b

3.4.2优点

(1) 服务拆分粒度更细，有利于资源重复利用，提高开发效率。 (2) 可以更加精准的制定每个服务的优化方案，按需伸缩。 (3) 适用于互联网时代，产品迭代周期更短。

3.4.3缺点

(1) 开发的复杂性增加，因为一个业务流程需要多个微服务通过网络交互来完成。 (2) 微服务过多，服务治理成本高，不利于系统维护。

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

3.4.3缺点

(1) 开发的复杂性增加，因为一个业务流程需要多个微服务通过网络交互来完成。 (2) 微服务过多，服务治理成本高，不利于系统维护。