# 前言
整理下多年的系统设计经验，抛砖引玉，助力大家系统设计能力的提升。
# 法则一：卓越架构是演进来的，不是设计来的
新手最容易陷入的诱惑是追求“`宏篇大作`”,一份在项目启动之初就构想得尽善尽美的设计。

但是这是一个陷阱。真正的老手知道，**业务总是不断变化的，大部分业务的生命周期很短的**，其实设计太好太完美的系统，可能发挥不出来，业务就已经黄了，徒耗费精力。

架构演进的根本动力，源于不断变化的业务需求。技术终究是为业务服务的。
一个典型的系统架构演进路径是：
- 初期为了快速验证业务，采用简单的单体架构；
- 随着用户增长，为了提升处理能力和可用性，自然过渡到集群架构；
- 当业务版图扩大，为解决重复建设和能力复用问题，最终走向大型中台化架构。

这一法则的反常识之处在于，**它要求我们抑制过度设计的冲动**，哪位大师有句名言：`过度设计师万恶之源`。
在业务增长初期，不要急于重构。得益于现代云服务的弹性，有时最务实的方案仅仅是升级服务器或数据库配置。看似“简单粗暴”，却恰恰是演进式架构智慧的体现。这里送给大家一句话：`能用钱解决的问题都不是问题`。

# 法则二：微服务正在变成“小泥球”

单体架构因代码腐化、业务逻辑交织，常被诟病为“大泥球”。
微服务通过“分而治之”看似解决了问题，但真正的敌人并非单体模式本身，而是无序和混乱。

许多团队拥抱微服务后，却发现自己只是将一个“大泥球”砸成了一堆“微服务小泥球”，**将一个大屎山变成了一些小屎堆**。

如果服务内部模块划分不清，调用关系混乱，甚至出现“`下层服务过于理解业务逻辑`”、“`存在下层调用上层的问题`”，那么每个微服务都会变成新的耦合瓶颈。

**微服务不等于解耦，它只是将编译时的依赖，转化成了运行时更难追踪的网络调用**。

真正的解决方案是架构规范。通过明确的架构分层来规避“小泥球”。
- **接口层**：对外进行服务暴露。
- **应用层**：负责服务的编排和组合。
- **领域层**：负责核心领域业务逻辑的实现。
- **基础层**：为各层提供资源服务。

必须严格遵守“上层调用下层”的单向依赖原则，服务粒度由内向外、由细到粗。
真正的解耦，源自于深入服务内部的严格划分与清晰边界，而非仅仅采用了某种流行的架构模式。

# 法则三：数据库驱动 or 领域驱动

接到产品经理提的需求后，你的第一反应是什么？
> 当然是在心里骂他一句

如果是打开数据库设计工具开始设计数据表，那么你很可能陷入了“数据驱动”的陷阱。
这种自下而上的方式，会将你的系统锚定在最不稳定的因素——数据结构上，最终导致系统僵化。

**领域驱动设计（DDD）** 要求我们进行一次范式转变：**设计的起点不是数据表，而是业务领域本身**。
我们必须先建立领域模型，划分限界上下文，然后才进行微服务拆分和技术实现。因为它确保了每个微服务都是特定业务领域的忠实实现，职责单一且内聚（`低耦合高内聚`，这六字真言不用多少了吧）。

它使我们从技术实现思维改为业务价值思维。领域模型应是系统中最为稳定和通用的部分，接口层与应用层则像护城河一样，屏蔽外部变化对核心业务的冲击。

我们必须牢记，软件设计的核心是业务领域，技术永远是实现其价值的手段。

# 法则四：数据库并非唯一选择，为特定场景匹配特定存储
> 当你拿着锤子，你看什么都像钉子，真的

对许多人而言，这把锤子就是关系型数据库，导致看所有问题都像钉子。然而，现代系统的数据形态千差万别，试图用一种存储方案包打天下，大概率都要失败。

高级架构师的职责，是为不同类型的数据和业务场景，匹配最合适的存储方案。这是一种“因地制宜”的艺术，要求我们对数据存储有深刻的理解。

- **事务性数据**：需要强ACID保证的业务，选择RDBMS/SQL数据库是理所当然的。
- **非结构化文档**：对于JSON文档或非强事务性数据，NoSQL数据库提供了更好的灵活性。
- **文件、图像、视频**：这类复杂的二进制对象，应交由对象存储（如MinIO）管理。
- **全文搜索**：面对海量数据的全文检索需求，搜索索引（如ElasticSearch）是最佳选择。
- **图谱关系数据**：处理节点、边和关系的复杂网络数据，图形数据库（如Neo4j）比较好。
- **监控与IoT数据**：对于带时间标签的时间序列数据，时序数据库（如InfluxDB、OpenTSDB）比较好。

# 法则五：放弃强一致性，拥抱最终一致性
> 你负担不起强一致性所需的成本

初级工程师往往追求理论上的完美，比如在所有场景下都实现数据的强一致性。
而资深架构师则懂得，在现实世界，尤其是在分布式系统中，这种追求是不切实际的，成本非常高。

CAP理论大家应该都知道。它定义了分布式系统的三个核心指标：`一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）`。
在任何真实的分布式网络中，网络分区（P）都是一个无法避免的客观存在，我们必须容忍它。因此，CAP理论的铁律并非三选二，而是在必须保证P的前提下，在一致性（C）和可用性（A）之间做出一个选择。

绝大多数面向用户的互联网业务，可用性的优先级远高于实时强一致性。

因此，务实的选择是“放弃强一致支持”，转而拥抱最终一致性。

这意味着我们允许系统在极短的时间内存在数据状态的短暂不一致，但保证它最终会通过异步消息、补偿任务等机制达到一致。

我们要学会接受“不完美”，学会**权衡的艺术**。
# 总结

牛逼的架构设计，并非遵循僵化的教条，而是充满了对**业务的理解**、对演进的接受和在矛盾中寻求最佳**平衡的艺术**。

**抓住当前业务发展阶段的主要矛盾，深刻理解业务，根据业务需要设计出最适合 且 具有可拓展的架构，才是我们能力的提现**。


新手最容易陷入的诱惑是追求“宏篇大作”,一份在项目启动之初就构想得尽善尽美的设计。

系统设计中5个非常重要的原则

整理下多年的系统设计经验，我提出5条最具颠覆性、最反直觉的系统设计原则。抛砖引玉，帮助大家建立起更具有拓展性的系统架构。

十倍工程师

后端

架构设计

职业发展

系统架构设计经验分享：架构演进源于业务需求变化，避免过度设计；警惕微服务变"小泥球"，注重架构规范；采用领域驱动设计，聚焦业务价值；根据场景选择合适存储方案；分布式系统优先考虑最终一致性而非强一致性。掌握这些原则，打造适应业务发展的弹性架构。

关系型数据库

对象存储

数据存储

软件设计

数据结构

SQL数据库

数据库

服务器

NoSQL

JSON

AI驱动 智领未来

tencentdb-catalog

对象存储COS新用户低至1元！


4核4G3M云服务器 新用户低至38元/年！

ctsdb

ES特惠专场，新客首购1折起！


文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

系统设计中5个非常重要的原则-腾讯云开发者社区-腾讯云

系统设计中5个非常重要的原则

系统设计中5个非常重要的原则

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐