应用架构种类 - 垂直拆分

解耦提升系统稳定性
最新推荐文章于 2025-06-20 10:32:39 发布
原创 最新推荐文章于 2025-06-20 10:32:39 发布 · 373 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文阐述了解耦的重要性，即通过垂直拆分业务、代码、数据库和研发团队来提高系统稳定性，避免因部分故障导致整体系统崩溃。垂直拆分是架构演进中持续进行的过程。

一、为什么要解耦

因为耦合在一起的系统，一挂全挂。所以解耦的目的是提高系统的稳定性。

二、如何快速解耦：

垂直拆分。

三、垂直拆分的范畴：

  1. 业务
  2. 代码
  3. 数据库
  4. 研发团队

四、阶段

垂直拆分在架构演进的各个阶段，会持续进行

应用架构设计方法和原则
银行信息系统架构详解
10-29 676
在此过程中，分析应用相关的业务功能和应用组件，构建业务活动与应用的关系，建立映射，进而通过领域建模，识别核心领域功能、领域模型，分析应用架构的风格，并初步梳理应用架构对技术架构和数据架构的风格要求。这时候，我们得到了初步的应用架构，接着可以进一步分析现状应用架构和目标应用架构，此时不用关注如何实现这个过渡，重点是明确当前和未来，进而我们可以通过架构委员会，对应用架构进行整体的评估，并且可以邀请相关的业务和技术专家参与。服务设计主要包括服务识别、服务筛选、服务目录、服务分类、服务接口等。
单体到微服务：电商平台架构的演变与可扩展性探索
热门推荐
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
10-14 10万+
可扩展性是软件架构中至关重要的特性，它确保系统能够在需求增长和规模扩大的情况下保持高效运行。为实现可扩展性，首要考虑模块化设计，将系统分解为独立、低耦合的模块，使得扩展时能够有针对性地进行修改而不影响整体。同时，水平扩展和垂直扩展是两种常见的扩展策略，前者通过增加节点或服务器来分担负载，后者则通过提升单节点性能来处理更多请求。弹性设计是实现可扩展性的关键，系统需要能够动态地分配和释放资源，以适应负载的波动。采用服务化架构，将系统拆解成小型服务单元，有助于独立开发和扩展。
应用架构种类 - 集中式架构,垂直拆分,分布式服务,服务治理,微服务
永远sayYES的博客
08-24 233
比较 参考 https://blog.youkuaiyun.com/sinat_42338962/article/details/84642665
系统架构演变--集中式架构-垂直拆分-分布式服务-SOA(服务治理)-微服务
Armymans的博客
11-29 7942
一.系统架构演变 1.1. 集中式架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。 存在的问题： 代码耦合，开发维护困难 无法针对不同模块进行针对性优化 无法水平扩展 单点容错率低，并发能力差 1.2.垂直拆分 当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求...
垂直拆分与水平拆分
黄复贵的博客
07-19 2312
垂直拆分：垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表通常我们按以下原则进行垂直拆分: 把不常用的字段单独放在一张表。 把TEXT，BIGINT等大字段拆分出来放在附表中。 经常组合查询的列放在一张表中（联合索引）。 垂直拆分的表在查询的时候用JOIN关键字连接起来即可。水平拆分：水平拆分是指数据表行的拆分，当表的行数超过200万行时，查询就会变得更慢，这时可以把一张的表的数据拆成多张
垂直拆分/水平拆分，解决方案
架构路上的博客
02-07 862
1.垂直拆分 单个数据库最大连接数是151，可以通过 show variables like ‘max_connections’ 查看。 随着用户量越来越大，单个数据库已经无法支撑系统正常使用。这个时候我们就需要对数据库层面进行优化。假设我们现在有订单，用户，商品等功能。我们可以对其进行垂直拆分。 垂直拆分： 将不同的业务拆分到不同数据库中。降低业务对统一数据库的压力。 注意： 禁止跨库 join 查询。（非常影响性能） 优点： 1.拆分后业务清晰，拆分规则明确。 2.系统之间容易扩展和整合。 进行
架构师之路——数据库垂直拆分
qq_41134008的博客
04-13 216
需求背景： 当数据库的数据量非常大时，水平切分和垂直拆分是两种常见的降低数据库大小，提升性能的方法。 水平切分： 将一个库（表）上的数据拆分到多个库（表）上，降低单库（表）大小。 各库的特点： 1、每个库（表）的结构都一样 2、每个库（表）的数据都不一样，没有交集 3、所有库（表）的并集是全量数据 垂直拆分： 将一个属性较多，一行数据较大的表，将不同的属性拆分到不同的表中，降低单库（表）大小。 各...
架构拆分-如何让笨重的系统架构变灵巧.docx
10-24
垂直拆分是从业务功能的角度对系统进行拆分，将原本紧密耦合的功能模块分离成独立的子系统，以便于管理和扩展。例如，将用户管理、商品信息、订单处理等功能模块拆分成不同的子系统。 - **引入服务调用治理**：解决...
关于架构设计-追忆寻梦.pptx
09-01
2. 应用架构：关注数据交互和应用形态，如SOA、微服务等，是实现业务架构的具体技术手段。 3. 技术架构：涉及操作系统、中间件、基础设施如多机房、高可用性和异地灾备等，是支撑业务和技术架构的基础设备和工具。 ...
软件架构的发展经历了从单体结构、垂直架构、SOA架构到微服务架构的过程剖析
10年老JAVA大数据技术人的专栏
08-26 1012
3、项目之间的接口多为数据同步功能，如：数据库之间的数据库，通过网络接口进行数据库同步。1、基于SOA的架构思想将重复公用的功能抽取为组件，以服务的方式给各各系统提供服务。2、项目与项目之间的存在数据冗余，耦合性较大，比如上图中三个项目都存在客户信息。1、将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。1、将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。1、项目架构简单，前期开发成本低，周期短，小型项目的首选。1、项目架构简单，前期开发成本低，周期短，小型项目的首选。
多案例分析，从垂直拆分和水平拆分谈谈架构本质问题
spark_dev的博客
04-09 2002
从垂直拆分和水平拆分谈谈架构本质问题前言一、架构的本质二、横拆纵拆案例1.大数据数据仓库架构2.微服务架构3.分库分表4.冷热分离5.ES索引性能优化，冷热分离设计6. 电商读写分离架构7. 秒杀架构总结 前言 架构有很多中，大数据架构，微服务架构，秒杀架构，butong数据库分库分表，读写分离等，他们有哪些共性的东西？ 本文从垂直拆分和水平拆分角度，专注谈谈架构共性的东西，提高大家以不变应万变的能力 一、架构的本质 架构设计的本质，是解决耦合性问题，解决耦合性问题的方法是，进行解耦，如何解耦，通过..
垂直拆分
不求前途凶吉，但求落幕无悔！
04-09 367
概述 垂直拆分更多时候就应该在数据表设计之初就执行的步骤，然后查询的时候用jion关键起来即可; 垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表 拆分方式 通常我们按以下原则进行垂直拆分: 把不常用的字段单独放在一张表; 把text，blob等大字段拆分出来放在附表中; 经常组合查询的列放在一张表中; 优缺点 如果一个...
如何基于「盘古开发框架」开发垂直分层单体应用
码农大熊的博客
04-17 414
本文介绍如何基于盘古开发框架开发一个单体分层架构的应用。文中所述仅为搭建一个单体应用的基本框架，增加配置中心、数据持久化、缓存等能力请参考开发指南的相关章节。
系统设计的垂直拆分和分平拆分
liu236000的博客
06-14 268
https://blog.youkuaiyun.com/second60/article/details/80019446
垂直拆分、水平拆分、分库分表策略、主从复制、读写分离
qq_36929638的博客
08-30 4108
垂直拆分就是要把表按功能模块划分到不同数据库中，如果你的系统是分布式微服务的架构，那就更好理解了，一般一个微服务对应这一个或多个数据库。比如电商系统一般都会有用户中心、订单、商品等等。用户中心数据库存的都是用户信息相关的，商品数据库存的都是商品相关的数据，订单数据库则是存的订单相关的。...
深入浅出 -- 系统架构之垂直架构
xiaoli8748的专栏
04-04 833
将一个大型应用拆分成多个相互独立的小型应用成为解决单体应用的一种方案，这就是垂直架构（也成为“竖井式架构”）。垂直架构相较于单体架构而言，进行了部分解耦，但是不够彻底，在各个子系统相互依赖的代码和模块中，存在重复代码拷贝和模块功能重复开发的情况。优点：对系统进行了拆分，实现了流量分担，解决了并发问题，可以正对不同模块进行优化，方便水平扩展、负载均衡，容错率提高。当业务复杂度增加、访问量逐渐增大出现高并发时，单体架构无法满足需求，可以根据业务功能对系统进行拆分，以提高访问效率。
垂直服务化拆分-分布式服务架构
zcf_0923的博客
04-07 3713
转载自： http://www.oschina.net/question/260548_158110?nocache=1491549674568 这是我加入公司后，公司架构的演变，但本身也有些问题想听听大家的想法。 加入这家公司后，在公司业务发展的同时，技术架构也逐渐在发生变化，垂直应用架构无法应对，所以我们进行了垂直服务化拆分。 最初我们跟很多公司一样，将核心业务拆分出多个服务应
常见高并发架构深度解析
qq_20294455的博客
06-20 382
其次，由于服务的粒度更细，单个服务的代码量较少，便于维护和升级；例如，Nginx 作为一款高性能的反向代理服务器和负载均衡器，支持多种负载均衡算法，能够根据服务器的性能、负载情况动态分配请求，有效提升系统的并发处理能力。通过引入消息队列，可以将这些请求暂存到队列中，由消费者异步处理，从而避免了同步操作带来的线程阻塞，释放系统资源，提高系统的吞吐量。微服务架构是一种更细粒度的分布式架构，它将一个大型的应用拆分成多个独立的小型服务，每个服务都专注于完成一项特定的业务功能，并且可以独立开发、部署和扩展。
聊聊高可用的 11 个关键技巧
公众号：微观技术
04-07 3687
大家好，我是Tom哥大型互联网架构设计，讲究一个四件套组合拳玩法，高并发、高性能、高可用、高扩展。如果能掌握这四个方面，应付大厂面试以及日常工作中的架构方案设计基本不是什么难题。今天，Tom哥就带大家学习下高可用都有哪些设计技巧？一、系统拆分有句古话 "牵一发而动全身"。面对一个庞然大物，如果没有一个合理的分工分层。任何一个小小失误都会被无限放大，酿成巨大灾难。万物相通，回到我们的软件架构。早前的系统都是单体系统，比如电商业务，会员、商品、订单、物流、营销等模块都堆积在一个系统。每到节假日搞个大促活动，系统
应用的架构有哪些
最新发布
08-22
<think>嗯，用户这次明确询问常见的应用系统架构类型，结合对话历史和提供的引用材料，需要系统化梳理主流架构模式。用户之前已经接触过架构设计原则和模式，但这次聚焦在"类型"上，说明ta可能想获得体系化的分类认知。 从引用[2]提到的单体架构痛点，引用[3]的内核设计，引用[4]的CS/BS对比来看，用户提供的材料正好覆盖关键架构类型。需要特别注意两点：一是引用[4]详细对比了CS和BS架构特性，这是基础知识点；二是用户上次回答中提到的微服务、事件驱动等模式需要延续性说明。 考虑从三个维度展开架构分类：部署形态（如CS/BS）、结构范式（如分层/微服务）、演进阶段（如单体到分布式）。在描述时要突出技术实现差异，比如引用[3]提到的"内核包含业务模型"对应分层架构的核心层设计。 准备在回答时强调实际案例，如电商平台用微服务（呼应引用[5]的订单流）、OA系统用单体（引用[2]的初期优势）。对于CS/BS架构，直接引用[4]的8项特性对比，但转化为更简洁的表格呈现。 最后生成的问题要引导用户思考架构选择逻辑，比如"如何根据团队规模选择架构"这个问题就串联了引用[2]（团队扩张导致单体臃肿）和引用[5]（微服务治理成本）的矛盾点。</think>以下是常见的应用系统架构类型及其核心特性总结，结合系统设计原则与工业实践： --- ### 一、基础架构类型 | **架构类型** | **核心特征** | **典型场景** | **优缺点** | |--------------------|---------------------------------------------|--------------------------|-------------------------------------------| | **单体架构** | 所有功能集成在单一进程/代码库 | 小型系统、初期项目 | ✅ 部署简单<br>❌ 扩展性差、维护成本高[^2] | | **分层架构** | 按职责分层（表现层/业务层/数据层） | 传统企业应用（如Spring MVC）| ✅ 职责分离<br>❌ 层间耦合影响性能 | | **C/S架构** | 客户端(Client)与服务器(Server)分离部署 | 桌面软件、游戏 | ✅ 客户端体验优<br>❌ 升级维护困难[^4] | | **B/S架构** | 浏览器(Browser)与服务器交互 | Web应用（如在线银行） | ✅ 跨平台访问<br>❌ 界面灵活性受限[^4] | > **关键对比**： > - C/S架构需安装客户端，适合高交互场景；B/S架构通过浏览器访问，更适合轻量化服务[^4]。 --- ### 二、现代分布式架构 | **架构类型** | **核心技术** | **适用场景** | **核心优势** | |--------------------|-------------------------------------------|--------------------------|-----------------------------------------| | **微服务架构** | 服务独立部署+API网关+服务注册发现 | 复杂系统（如电商平台） | ✅ 高内聚低耦合<br>✅ 独立扩展[^1] | | **事件驱动架构** | 消息队列（Kafka/RabbitMQ）+ 事件溯源 | 实时数据处理（如物流跟踪） | ✅ 解耦生产消费<br>✅ 高吞吐异步处理[^5] | | **无服务器架构** | FaaS（如AWS Lambda）+ 事件触发器 | 突发流量场景（如秒杀） | ✅ 按需付费<br>❌ 冷启动延迟 | | **Service Mesh** | Sidecar代理（如Istio）+ 服务治理 | 大规模微服务集群 | ✅ 细粒度流量控制<br>✅ 熔断限流 | --- ### 三、架构演进路径 ```mermaid graph LR A[单体架构] -->|业务增长| B[垂直拆分] B -->|复杂度提升| C[微服务化] C -->|规模扩张| D[Service Mesh] D -->|事件驱动| E[流式架构] ``` > **演进逻辑**： > 1. 初期用单体快速验证业务（引用[2]） > 2. 用户量增长后按业务域拆分微服务（如订单/支付服务） > 3. 引入事件驱动处理实时数据流（引用[5]） --- ### 四、选型决策关键因素 1. **业务需求** - 高实时性 → 事件驱动架构 - 快速迭代 → 微服务 2. **团队规模** - 小团队：避免过早微服务化（运维成本$\propto$服务数量） 3. **技术生态** - 云原生场景：优先无服务器/Service Mesh > **警示**：BS架构需关注浏览器兼容性（如IE淘汰影响）[^4]，微服务需解决分布式事务难题。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值