单体应用架构(Monolithic Architecture)
1968 年的软件危机产生了软件工程,并且催生了面向对象的高级语言,例如 1972 的 C 语言,同时产生了我们的单体式的技术架构。
单体应用架构是一种传统的应用架构模式,也是至今为止,一直被大规模使用的一种方式,是将应用程序作为一个整体部署和运行在同一的运行环境中,应用中的各个功能模块紧密地耦合在一起。
单体应用架构图
特点:集中管理、统一部署、紧耦合。
优点:复杂度低、简单、性能好、开发测试快。
缺点:可扩展性差、维护困难、灵活性差、由于紧耦合导致的可靠性问题。
适用场景
小型项目或初创公司的产品。
需求稳定、功能复杂度低、变动较少的系统。
需要快速开发和交付。
垂直应用架构(Vertical Architecture)
在 1980s 时代,大型应用和超大型应用开始兴起,特别是操作系统和数据库的出现和广泛应用,数百万行代码量的系统较为普遍。随着业务的发展、单体架构越来越臃肿,系统代码量日益膨胀,在同一系统上协作的开发人员越来越多。基于单体架构的协作效率越来越低,系统故障率越来越高。将一个大型应用拆分成多个相互独立的小型应用成为解决单体应用的一种方案,这就是垂直架构(也称为“竖井式架构”)。垂直架构根据业务属性将一个大的单体应用拆分成多个模块或子系统,子系统之间没有直接关联。
垂直架构相较于单体架构而言,进行了部分解耦,但是不够彻底,在各个子系统相互依赖的代码和模块中,存在重复代码拷贝和模块功能重复开发的情况。
垂直应用架构
特点:相对于单体架构,系统独立、业务更加模块化、代码和数据冗余、独立部署运维。
优点:相对于单体架构,模块更加独立性、灵活性提高,每个团队负责一个独立系统,提升了开发效率。
缺点:相对于单体架构,会存在代码冗余、资源利用率低、系统复杂性增加。
适用场景
业务功能明确且相对独立的系统。
需要快速迭代和交付的项目。
多团队协作的大型项目。
面向服务架构(Service-Oriented Architecture, 简称SOA)
面向服务架构,它是将应用程序结构化为一组相互通信的服务。每个服务代表一个业务能力或一组相关功能,可以通过标准化的接口和协议 访问。核心理念是将复杂的应用分解成一系列松耦合的服务,这些服务可以独立部署、管理和重用。
ESB-SOA架构图
特点:松耦合、自治、抽象、可重用性、无状态、服务发现、服务可组合。
优点:系统间相互独立,可以更好地共享、重用和组装功能,快速构建复合型应用。
缺点:需要实现交互远程的协议,增加了性能开销;由于是中心化,容易形成单点故障和服务依赖;提高维护、安全和监控的挑战。
适用场景
基于遗留系统已有可复用的能力,分层组装的方式来构建上层业务应用。
业务的横跨范围大。
技术栈差异大。
微服务架构(Micro-Service Architecture,SOA的一种变体)
微服务架构,就是将一个应用按照一定的拆分规则(业务领域拆)拆分成多个不同的服务,每个服务都能独立地进行开发、部署、扩展。服务与服务之间通过http,消息,rpc等方式进行调用和通信。SOA架构强调的是异构系统之间的通信和解耦合,是一种粗粒度的拆分。而微服务架构强调的是系统按业务边界做细粒度的拆分和部署
微服务-SOA架构图
特点:独立部署,灵活扩展、资源的有效隔离。
优点:业务和代码高内聚、复用性高、按需扩展、资源隔离、技术栈独立。
缺点:数据一致性问题、链路变长、性能变低,定位问题难度提高。
适用场景(不适用于公司资金不充裕的公司)
大型复杂、快速迭代、并发高、需要高可用性、技术栈复杂。
偏底层的业务,复用性高。
云原生应用。
无服务架构(Serverless)
无服务架构(Serverless Architecture)即无服务器架构,也被称为函数即服务(Function as a Service,FaaS),是一种云计算模型,用于构建和部署应用程序,无需关心底层服务器的管理。在无服务器架构中,开发人员编写单独的函数或函数集合,这些函数以事件驱动的方式触发,并在需要时自动扩展,而无需自己管理服务器基础架构。
无服务架构图
特点:冷启动、 无状态、运行时间有限制。
优点:自动扩展和弹性、按需计费、简化运维、快速部署、多语言支持、高可用性和容错性、避免资源浪费。
缺点:冷启动时间、资源限制、难以维护状态(无状态)、监控和调试难度高、不适用于所有用例。
适用场景
系统架构总示例图
服务网格架构(Service Mesh)
服务网格是一个专用的基础设施层,用于处理微服务之间的通信。它提供了一系列功能,如服务发现、负载均衡、故障恢复、监控、权限控制等,以确保微服务之间的通信既安全又可靠。服务网格通常实现为一组轻量级的网络代理,这些代理与应用程序一起部署,但对应用程序来说是透明的。
服务网格示例图
服务网格内部具体实现示例图
特点:以非侵入的方式为运行在集群中的微服务提供流量管理、安全加固、服务监控和策略管理等功能;对应用无感,属于网络代理的基础设施层。
优点:屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控制等等),服务只用关注业务逻辑;技术栈无关,服务可以用任何语言编写;对应用透明,Service Mesh组件可以单独升级。
缺点:Service Mesh组件以代理模式计算并转发请求,一定程度上会降低通信系统性能,并增加系统资源开销;Service Mesh组件接管了网络流量,因此服务的整体稳定性依赖于Service Mesh,同时额外引入的大量Service Mesh服务的运维和管理也是一个挑战。
适用场景
有独立良好的运维技术团队。
以微服务实现为主。
技术栈多,功能和场景复杂,需要集中发布管控。
技术团队多、资金充足的大型项目。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· 单线程的Redis速度为什么快?
· SQL Server 2025 AI相关能力初探
· AI编程工具终极对决:字节Trae VS Cursor,谁才是开发者新宠?
· 展开说说关于C#中ORM框架的用法!
2023-12-05 华为数字化转型实践PPT
2022-12-05 AIoT智能物联网管控平台
2020-12-05 Chrome使用技巧
2019-12-05 一文读懂工业大数据 (转)