软件架构的演进过程

2023-12-26 11:25:27

软件架构的发展经历了由单体架构、垂直架构、SOA架构到微服务架构的演进过程,下面我们分别了解一下这几个架构。

一,?单体架构

? ?一个归档包(例如war格式或者Jar格式)包含了应用所有功能的应用程序,我们通常称之为单体应用。架构单体应用的方法论,我们称之为单体应用架构,这是一种比较传统的架构风格。

图片

架构说明:

全部功能集中在一个项目内(All in one)。

架构优点:

架构简单,前期开发成本低、开发周期短,适合小型项目。

架构缺点:

  1. 复杂性高

整个项目包含的模块非常多,模块的边界模糊,依赖关系不清晰,代码质量参差不齐,整个项目非常复杂。每次修改代码都心惊胆战,甚至添加一个简单的功能,或者修改一个BUG都会造成隐含的缺陷。

② 技术债务逐渐上升

随着时间推移、需求变更和人员更迭,会逐渐形成应用程序的技术债务,并且越积越多。已使用的系统设计或代码难以修改,因为应用程序的其他模块可能会以意料之外的方式使用它。

③ 部署速度逐渐变慢

随着代码的增加,构建和部署的时间也会增加。而在单体应用中,每次功能的变更或缺陷的修复都会导致我们需要重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高,这使得单体应用项目上线部署的频率较低,从而又导致两次发布之间会有大量功能变更和缺陷修复,出错概率较高。

④ 扩展能力受限,无法按需伸缩

单体应用只能作为一个整体进行扩展,无法结合业务模块的特点进行伸缩。

⑤ 阻碍技术创新

单体应用往往使用统一的技术平台或方案解决所有问题,团队的每个成员都必须使用相同的开发语言和架构,想要引入新的框架或技术平台非常困难。

总结:

全部功能集成在一个工程中,对于大型项目不易开发、扩展和维护。

技术栈受限,只能使用一种语言开发。

系统性能扩展只能通过扩展集群节点,成本高。

二,垂直架构

图片

架构说明:

按照业务进行切割,形成小的单体项目。

垂直MVC项目主要有表现层,业务逻辑层,数据访问层组成的MVC架构,整个项目打包放在一个tomcat里面。适合于 访问量小,用户数不多的业务。

架构优点:

技术栈可扩展(不同的系统可以用不同的编程语言编写)。

架构缺点:

① 这是一个大而全的项目,项目的部署效率很低,代码全量编译和部署一次发布需要很长时间,更重要的是 如果某个功能出错有问题,所有的功能都需要再重新打包编译,部署效率极低。

② 团队协作难度高,如多人使用 git 很可能在同一个功能上,多人同时进行了修改,作为一个大而全的项目,可能个人只是需要开发其中一个小的模块的需求,却需要导入整个项目全量的代码。

总结:

功能集中在一个项目中,不利于开发、扩展、维护。

系统扩张只能通过集群的方式。

项目之间功能冗余、数据冗余、耦合性强。

三,?SOA架构

SOA 全称为 Service-Oriented Architecture,即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。

站在功能的角度,把业务逻辑抽象成可复用的服务,通过服务的编排实现业务的快速再生,目的:把原先固有的业务功能转变为通用的业务服务,实现业务逻辑的快速复用。

图片

架构说明:

将重复功能或模块抽取成组件的形式,对外提供服务,在项目与服务之间使用ESB(企业服务总线)的形式作为通信的桥梁。

ESB

简单 来说 ESB 就是一根管道,用来连接各个服务节点。为了集 成不同系统,不同协议的服务,ESB 做了消息的转化解释和路由工作,让不同的服务互联互通;

图片

架构优点:

重复功能或模块抽取为服务,提高开发效率。

可重用性高。

可维护性高。

架构缺点:

各系统之间业务不同,很难确认功能或模块是重复的。

抽取服务的粒度大。

系统和服务之间耦合度高。

从单体应用到SOA架构的转变:

图片

四, 微服务架构

图片

微服务架构:

其实和 SOA 架构类似,微服务是在 SOA 上做的升华,微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”,原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

架构说明:

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

抽取的粒度更细,遵循单一原则。

采用轻量级框架协议传输。

API 服务网关

API网关是一个服务器,是系统的唯一入口。从面向对象设计的角度看,它与外观模式类似。API网关封装了系统内部架构,为每个客户端提供一个定制的API。它可能还具有其它职责,如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。API网关方式的核心要点是,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。通常,网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

架构优点:

服务拆分粒度更细,有利于提高开发效率。

可以针对不同服务制定对应的优化方案。

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

架构缺点:

粒度太细导致服务太多,维护成本高。

分布式系统开发的技术成本高,对团队的挑战大。

以上就是今天給大家分享的架构演变过程,大家在使用的过程中可以根据自己的业务灵活的选择

文章来源:https://blog.csdn.net/weixin_45766875/article/details/135214112
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。