Skip to content

README.md

Latest commit

 

History

History
281 lines (217 loc) · 27.3 KB

README.md

File metadata and controls

281 lines (217 loc) · 27.3 KB
Raw

标准 Web 应甚 架构暡板

代衚产品:䌁䞚官眑、博客、䞭小型 SaaS 后台、内郚工具站——也就是「90% 的项目真正需芁的架构」 䞀句话定䜍:䞀䞪把数据存奜、按权限读写、枲染成页面给甚户甚的系统。它䞍性感,䜆它胜扛䜏绝倧倚数䜠以䞺需芁「分垃匏」的场景。

1. 䞀句话定䜍

䞀䞪标准 Web 应甚 = 䞀䞪单䜓应甚 + 䞀䞪数据库 + (需芁时再加)䞀层猓存。

架构䞊最反盎觉的䞀点,恰恰是「没有那么倚花样」。圓代工皋垈最容易犯的错,䞍是把系统讟计埗倪简单,而是还没遇到问题就先把架构搞倍杂。这仜暡板的栞心立场只有䞀句话:绝倧倚数系统是死于过床讟计,而䞍是死于欠讟计。 它存圚的目的,是教䜠䞀件比「䌚䞊埮服务」曎隟的事——克制:看枅「单䜓 + 䞀䞪数据库 + 猓存」到底胜扛倚远(答案是:远埗超出䜠的想象),从而把宝莵的倍杂床预算,留到真正需芁的那䞀倩。

2. 䞚务本莚:它圚解决什么问题

绝倧倚数蜯件,本莚䞊就是圚做䞀件朎玠的事:把信息存䞋来,按规则读出来、改回去,呈现给对的人。

  • 䌁䞚官眑 / 博客:把内容存奜,枲染成页面给访客看(读远倚于写);
  • SaaS 后台 / 内郚工具:让甚户登圕后,按权限增删改查䞀些䞚务数据(订单、客户、工单、文章);
  • 工具站:接收蟓入,倄理后返回结果。

它取代的是「甚 Excel / 纞莚衚栌 / 来回发邮件」的笚办法。

价倌䞎成本从哪来:

  • 价倌:省䞋人工流蜬、集䞭管理、随时可查;
  • 成本:这类系统的最倧成本,埀埀䞍是服务噚,而是「䜠䞺䞍存圚的规暡付出的倍杂床」——倚䜙的服务、倚䜙的䞭闎件、倚䜙的运绎,郜是圚烧钱和制造故障。

关键事实:对 90% 的项目来诎,「胜䞍胜扛䜏流量」根本䞍是瓶颈,「胜䞍胜快速、䜎成本地把功胜做对、改对」才是。 这䞀条决定了:简单本身就是䞀种栞心竞争力。

3. 栞心需求䞎纊束

把需求拆成䞀类。这是架构垈最重芁的基本功:区分「功胜」和「莚量」。

功胜性需求(系统芁胜做什么):

  • 甚户讀证䞎授权:谁胜登圕、谁胜看/改什么。
  • 增删改查(CRUD):对栞心䞚务实䜓的基本操䜜。
  • 页面枲染:把数据变成甚户胜看的界面。
  • 倄理甚户䞊䌠(囟片、附件)。
  • 䞀些匂步/定时任务(发邮件、生成报衚、枅理数据)。

非功胜性需求 / 莚量属性(系统芁做埗倚奜):

莚量属性 目标 䞺什么对这类系统重芁
可改性 / 匀发速床 改䞀䞪功胜芁快、芁皳 这是这类系统真正的䞻战场——䞚务圚变,谁改埗快谁赢。
简单性 / 可绎技 䞀䞪新人几倩胜看懂党貌 简单 = 故障少、招人易、改起来䞍怕。这是被䞥重䜎䌰的莚量属性。
可甚性 99.9% 通垞就借 别䞀䞊来就远求 99.999%——那芁付出指数级的倍杂床代价。
响应延迟 垞规页面几癟毫秒内 借快即可,绝倧倚数场景䞍需芁极臎䌘化。
运绎成本 越䜎越奜 小团队的人力是最皀猺资源,运绎越简单,越倚粟力投圚䞚务䞊。

关键纊束(䞍可速越的蟹界):

  • 🔎 团队规暡小、预算有限、人力是倎号皀猺资源。 这是这类系统最重芁的纊束,它盎接决定了「越简单越奜」。
  • 🔎 䞚务需求圚持续变化。 架构芁服务「快速、安党地改」,而䞍是「䞀次讟计、氞䞍变曎」。
  • 🔎 真实规暡通垞远小于䜠的想象。 䜠䞍是倧厂,先别按倧厂的囟来画。
  • 倍杂床预算是有限的:每加䞀䞪组件,郜圚消耗团队理解、运绎、排障的粟力。

4. 架构党景囟

                        甚户(浏览噚 / 移劚端)
                              │
                              ▌
                    ┌──────────────────┐        静态资源(JS/CSS/囟片)
                    │       CDN        │◀───────  就近分发,别让应甚服务噚䌺候静态文件
                    └────────┬─────────┘
                             │ 劚态请求
                             ▌
                    ┌──────────────────┐
                    │   莟蜜均衡噚      │   ← 应甚层无状态,所以可以摆奜几台、随䟿加
                    └────────┬─────────┘
                             │
              ┌──────────────┌──────────────┐
              ▌              ▌              ▌
      ┌────────────┐ ┌────────────┐ ┌────────────┐
      │  应甚实䟋   │ │  应甚实䟋   │ │  应甚实䟋   │   ← 䞀䞪单䜓,内郚是经兞䞉层:
      │ ┌────────┐ │ │   (无状态)  │ │   (无状态)  │      衚现层 → 䞚务逻蟑层 → 数据访问层
      │ │衚现层  │ │ └────────────┘ └────────────┘
      │ ├───────── │        │                              ┌───────────────┐
      │ │䞚务逻蟑│ │        │   ① 先查猓存 ───────────────▶ │ 内存级 KV 猓存 │
      │ ├───────── │        │   ◀── 呜䞭就盎接返回 ──────── └───────────────┘
      │ │数据访问│ │        │   ② 未呜䞭才查库
      │ └────────┘ │        â–Œ
      └─────┬──────┘ ┌───────────────────────────┐
            └───────▶│        数据库(äž»)         │ ← 通垞是【第䞀䞪】也是最久的瓶颈
                     │   (倧倚数项目䞀䞪就借)    │
                     └─────────────┬─────────────┘
                                   │ (规暡倧了再加)读倍制
                                   ▌
                     ┌───────────────────────────┐
                     │      只读副本(读副本)      │ ← 读倚写少时,把读分流到这里
                     └───────────────────────────┘

       ┌─────────────────────────────────────────────────────────────┐
       │  旁路:匂步任务(发邮件、生成报衚 )                            │
       │  应甚 ──攟入──▶ [任务队列] ──▶ 后台工䜜进皋 ──▶ 写库 / 调倖郚服务 │
       └─────────────────────────────────────────────────────────────┘

       ┌─────────────────────────────────────────────────────────────┐
       │  旁路:甚户䞊䌠的囟片/附件 ──▶ [对象存傚] ──▶ 经 CDN 回源给甚户   │
       └─────────────────────────────────────────────────────────────┘

灵魂郚件就是䞭闎那䞪单䜓应甚 + 䞀䞪数据库。CDN、猓存、读副本、任务队列、对象存傚——这些党是「需芁时才加」的旁路,䞍是匀局标配。先把栞心那䞀䞪框做扎实,比早早画满䞀墙的框重芁埗倚。

5. 组件职莣

逐䞪诎明每䞪关键郚件做什么 + 䞺什么需芁它(没有「䞺什么」的郚件就是过床讟计)。

  • 单䜓应甚(内含经兞䞉层):䞀䞪可独立郚眲的皋序,内郚枅晰分䞺衚现层(倄理请求/响应、枲染)、䞚务逻蟑层(规则、流皋、事务)、数据访问层(䞎数据库打亀道)。䞺什么需芁:它是系统的党郚䞚务所圚。泚意:「单䜓」指的是郚眲圢态(䞀䞪䞜西䞀起发垃),䞍等于「代码䞀团乱」——内郚䟝然芁分层、暡块蟹界枅晰。单䜓让䜠圚䞀䞪进皋内就胜完成调试、事务、改劚,匀发䞎运绎成本最䜎。
  • 数据库(䞻库):系统的事实源(source of truth),存所有栞心䞚务数据,提䟛事务䞎区䞀臎。䞺什么需芁:䜠的数据埗有䞀䞪权嚁的、䞍䌚䞢、胜保证䞀臎的家。对绝倧倚数项目,䞀䞪关系型数据库就足以支撑埈久埈久。
  • 莟蜜均衡噚:把流量分发到倚台应甚实䟋。䞺什么需芁:让应甚层可以「倚摆几台」来扛量;䜆它胜成立的前提是应甚层无状态(见决策 5)。
  • CDN:把静态资源(JS、CSS、囟片)猓存到犻甚户近的节点。䞺什么需芁:静态文件没必芁每次郜让应甚服务噚䌺候;亀给 CDN,既快又卞蜜了倧量流量。这是性价比极高、可以蟃早就加的䞀项。
  • 内存级 KV 猓存:把「读埗倚、变埗少、算起来莵」的结果猓存圚内存里,挡圚数据库前面。䞺什么需芁:数据库通垞是第䞀䞪瓶颈,猓存胜把倧量重倍读挡䞋来。䜆它有真实代价(猓存䞀臎性),所以是『遇到读压力时才加』,䞍是匀局就䞊(见决策 3)。
  • 只读副本(读副本):数据库的只读拷莝,䞓闚承接读流量。䞺什么需芁:读倚写少时,把读分流到副本,给䞻库减压。同样是按需才加(见决策 4)。
  • 任务队列 + 后台工䜜进皋:把「慢的、胜晚点做的」事(发邮件、生成报衚、第䞉方调甚)从请求䞻铟路里挪出去匂步执行。䞺什么需芁:别让甚户䞺䞀封邮件的发送等圚那;把耗时操䜜匂步化,䞻请求才胜快。
  • 对象存傚:存甚户䞊䌠的囟片、附件等倧文件。䞺什么需芁:倧文件䞍该塞进数据库(撑爆、变慢、倇仜困隟);对象存傚䞓䞺「倧、䞍垞变、按 key 取」而生,再配 CDN 分发给甚户。

6. 关键数据流

挑䞀䞪最胜䜓现这类系统特点的场景:䞀次读、䞀次写。䜠䌚发现它朎玠埗让人安心。

场景䞀:读请求(䟋劂打匀䞀䞪诊情页)

1. 甚户请求某页面 ──▶ 莟蜜均衡噚 ──▶ 某䞪应甚实䟋
2. 应甚(䞚务逻蟑层)先问猓存:这条数据有没有现成的?
       ┌── 呜䞭 ──▶ 盎接拿来甚,跳到第 4 æ­¥(没碰数据库,最快)
       └── 未呜䞭 ──▶ 第 3 æ­¥
3. 应甚(数据访问层)查数据库 ──▶ 拿到数据 ──▶ 顺手写入猓存(䞋次就胜呜䞭)
4. 䞚务逻蟑层组织数据 ──▶ 衚现层枲染成页面/JSON ──▶ 返回甚户

这就是「猓存挡读」的党郚粟髓:让最频繁的读,倧郚分郜圚猓存这䞀层就被满足,数据库只圚猓存未呜䞭时才被惊劚。

场景二:写请求(䟋劂提亀䞀䞪衚单 / 曎新䞀条记圕)

1. 甚户提亀 ──▶ 莟蜜均衡噚 ──▶ 某䞪应甚实䟋
2. 䞚务逻蟑层:① 校验蟓入(合法吗?有权限吗?)
3.            ② 圚䞀䞪事务里写入数据库(这是事实源,必须对)
4.            ③ 让盞关猓存倱效(把刚被改掉的那条猓存删掉/曎新)
       ⚠ 顺序埈重芁:先写库(权嚁),再倱效猓存。吊则可胜读到脏数据。
5. (可选)④ 把「胜晚点做的副䜜甚」䞢进任务队列:发通知邮件、记审计日志、刷新报衚
6. 返回结果给甚户(甚户䞍必等第 5 步那些匂步掻儿做完)

䞀䞪芁点:① 写氞远以数据库这䞪事实源䞺准,猓存只是它的圱子——圱子芁圚数据变了之后及时倱效。② 胜匂步的副䜜甚就别卡圚䞻铟路䞊,甚户只等「必须同步完成的那郚分」。

7. 数据暡型䞎存傚选择

栞心实䜓通垞埈朎玠:甚户 ─ 角色/权限;若干䞚务实䜓(订单 / 文章 / 工单 / 客户)及其盞互关系;䞊䌠的文件;审计/操䜜日志。它们之闎是枅晰的、区关系的结构。

数据 存傚类型 䞺什么
甚户 / 权限 / 栞心䞚务实䜓 关系型 实䜓闎关系区、芁事务、芁区䞀臎;这正是关系型最擅长的,别舍近求远
热点读结果(诊情、列衚、配眮) 内存级 KV 猓存 读倚写少、胜容忍极短的䞍䞀臎,挡圚数据库前面省力
甚户䞊䌠的囟片 / 附件 对象存傚 文件倧、䞍垞变、按 key 取;塞进数据库䌚撑爆它、拖慢它、让倇仜变噩梊
静态资源(JS/CSS/囟片) CDN(蟹猘猓存) 䞍变、芁党球就近快取;䞍该消耗应甚服务噚
操䜜 / 审计日志 关系型(量倧后再考虑远加日志/列存) 早期䞀匠衚就借,别䞺「将来可胜埈倧」提前䞊䞓甚存傚
䌚话状态 倖郚共享存傚(猓存/库),䞍攟进皋内存 攟进皋内存䌚富臎䌚话黏连、扩䞍劚(见决策 5)

教孊点:默讀就甚䞀䞪关系型数据库,盎到䜠有具䜓证据衚明它䞍借甚。 「这数据将来䌚䞍䌚埈倧?」「䌚䞍䌚需芁党文搜玢?」——这些「将来可胜」䞍是现圚就匕入䞓甚存傚的理由。䞀䞪关系型数据库 + 合理的玢匕,胜陪䜠走过绝倧倚数项目的䞀生。 真遇到了再加,是廉价的;䞺没发生的事提前加,是昂莵的。

8. 关键架构决策䞎权衡 ⭐

(本暡板最倌钱的䞀节。这䞀节的每䞪决策,几乎郜指向同䞀䞪答案:先选简单的那条路。)

决策 0(凌驟于䞀切之䞊):先别问「怎么扩」,先问「现圚这䞪规暡,我真的需芁它吗?」

  • 这䞍是某䞀䞪技术岔路,而是莯穿党篇的元决策。过床讟计的代价是真实䞔立刻发生的:曎倚的组件 = 曎倚芁理解的䞜西、曎倚的运绎、曎倧的故障面、曎慢的匀发。而它换来的「未来可扩展性」埀埀是䜠这蟈子圚这䞪项目䞊郜甚䞍到的规暡。
  • 取向:默讀拒绝倍杂床,让需求来「迫䜿」䜠加䞜西,而䞍是䜠预刀着加。 加任䜕䞀䞪组件(猓存、队列、第二䞪服务、读副本)前,先回答:「我现圚有没有遇到非它䞍可的具䜓问题?」答䞍䞊来,就䞍加。这是本暡板最重芁的䞀条。

决策 1:服务端枲染(SSR)还是客户端枲染(CSR)?

  • 服务端枲染:服务噚盎接把 HTML 拌奜返回。䌘点是銖屏快、对 SEO 友奜(爬虫盎接看到内容),实现也曎盎接。代价是亀互性匱䞀些、服务噚芁承担枲染。
  • 客户端枲染:返回䞀䞪空壳 + 䞀堆脚本,圚甚户浏览噚里拉数据、拌界面。䌘点是亀互䜓验䞰富(像桌面应甚)。代价是銖屏慢、SEO 需额倖倄理、倍杂床曎高。
  • 取向:看产品圢态。 内容型(官眑、博客、电商诊情——芁被搜到、芁銖屏快)䌘先服务端枲染;重亀互的后台/工具(甚户登圕后长时闎操䜜、SEO 无所谓)适合客户端枲染。别因䞺「客户端枲染时髊」就给䞀䞪博客䞊重型前端——那是甚倍杂床换了䜠䞍需芁的䞜西。

决策 2:单䜓还是埮服务?

  • 埮服务:按䞚务拆成倚䞪独立郚眲的服务。䌘点是各服务可独立扩展、独立郚眲、技术匂构、团队可并行。䜆代价极其昂莵:分垃匏事务、服务闎通信䞎故障、数据䞀臎性、可观测性、郚眲猖排——䜠把「䞀䞪进皋内的凜数调甚」换成了「䌚倱莥、有延迟的眑络调甚」,倍杂床陡增。
  • 单䜓:䞀䞪可独立郚眲的皋序,内郚分层枅晰。䌘点是匀发、调试、事务、郚眲郜简单,小团队效率最高。代价是「敎䜓䞀起发垃」,以及单䞀代码库到极倧规暡后的协䜜摩擊。
  • 取向:先单䜓!几乎氞远先单䜓。 埮服务解决的是「组织规暡」问题(埈倚团队芁并行、互䞍阻塞),䞍是「技术先进性」问题。圚䜠只有䞀䞪小团队、䞚务蟹界还没皳定时䞊埮服务,是圚给自己凭空制造䞀套分垃匏系统的党郚苊隟,华享受䞍到它的奜倄。正确路埄是:先做䞀䞪内郚暡块枅晰的单䜓,等到组织/规暡真的把它撑䞍䞋了,再沿着已经枅晰的暡块蟹界拆分(见第 12 节)。

决策 3:什么时候才该加猓存?

  • 䞀匀始就加猓存:䌌乎「曎快」,䜆䜠匕入了猓存䞀臎性这䞪经兞隟题(数据改了猓存没倱效 = 甚户看到旧数据),凭空增加了䞀类 bug,而歀时䜠可胜根本没有读压力。
  • 等到出现读压力再加:数据库扛䞍䜏重倍读时,把「读倚写少、可容忍极短䞍䞀臎」的数据猓存起来。
  • 取向:读倚写少、䞔数据库确实匀始吃力时才加,而䞍是匀局标配。 猓存是「以䞀点䞀臎性倍杂床,换倧量重倍读的性胜」的亀易——没有读压力时,这笔亀易䜠是净亏的(只付了倍杂床,没换到收益)。

决策 4:什么时候才该做读写分犻(加读副本)?

  • 过早分犻:绎技䞻从倍制、倄理倍制延迟(刚写完去读副本可胜读到旧的),䞺䞍存圚的读量埒增运绎。
  • 适时分犻:圓读流量明星成䞺䞻库瓶颈、䞔䞚务胜容忍副本的埮小延迟时,把读分流到只读副本。
  • 取向:先靠玢匕和猓存顶䜏;它们郜䞍借了,䞔瓶颈确实圚『读』,再䞊读副本。 泚意它解决的是「读倚」,解决䞍了「写倚」——写倚是及䞀类问题(曎晚才䌚遇到,手段也䞍同)。别圚数据库还埈闲的时候就搞䞀䞻倚从。

决策 5:应甚层有状态还是无状态?

  • 有状态(把䌚话/数据存圚某台应甚实䟋的内存里):单机时方䟿,䜆䞀旊倚实䟋就出倧问题——甚户的请求必须次次回到「存了他状态的那台」(䌚话黏连),某台䞀挂甚户状态就䞢,而䞔根本没法自由地氎平扩展。
  • 无状态(应甚实䟋䞍保存任䜕䌚话状态,状态攟倖郚共享存傚):任䜕䞀台实䟋郜胜倄理任䜕请求。
  • 取向:应甚层必须无状态。 把䌚话等状态攟到倖郚共享存傚(猓存或数据库)。这是「莟蜜均衡 + 氎平扩展」胜成立的前提,也是少数『应该从第䞀倩就遵守』的纪埋之䞀——它䞍增加什么倍杂床,华䞺未来的扩展扫枅了最倧障碍。代价仅仅是每次取状态倚䞀次倖郚读,完党划算。

9. 规暡化䞎瓶颈

这䞀节回答:从几癟甚户到埈倚甚户,第䞀䞪䌚撑䞍䜏的地方圚哪?顺序非垞有规埋,记䜏这䞪顺序,䜠就䞍䌚圚错误的地方提前发力。

  • 第䞀䞪瓶颈,几乎氞远是数据库。(尀其是读) 砎解(按代价从䜎到高、䟝次尝试): ① 加玢匕——最䟿宜、最垞被応视的䌘化,埈倚「慢」其实是猺玢匕或党衚扫描; ② 加猓存——把热点重倍读挡圚库前(决策 3); ③ 加读副本——把读流量分流出去(决策 4); ④ 再䞍借,才考虑曎重的手段(见䞋)。

    关键:圚劚「分库分衚」这种栞歊噚之前,先老老实实把玢匕、猓存、读副本这䞉板斧甚满。 倧倚数项目甚䞍到第四步。

  • 第二䞪瓶颈,才是应甚层(CPU/内存䞍借)。 砎解:因䞺应甚层无状态(决策 5),盎接『倚摆几台 + 莟蜜均衡』氎平扩展即可——这是敎䞪架构里最蜻束的扩展,前提是䜠䞀匀始就守䜏了无状态纪埋。
  • 静态资源 / 垊宜压力:亀给 CDN(可以蟃早就䞊,性价比高)。
  • 慢操䜜拖环响应:把它们匂步化(任务队列),别卡圚甚户的请求䞻铟路䞊。
  • 最后,圚真的非垞倧之后,才蜮到分库分衚、按䞚务域拆服务这类重型挔进——而到那䞀步时,䜠早该有数据、有团队、有明确的瓶颈证据来支撑这䞪决定了,绝䞍是凭感觉提前䞊。

这䞪瓶颈顺序的实践意义:它告诉䜠『力气该按什么顺序花』。 圚数据库还没加玢匕时就去拆埮服务,等于跳过了最䟿宜的药,盎接䞊最莵、最痛的手术。

10. 安党䞎合规芁点

这类系统䞍性感,䜆安党的基本功䞀䞪郜䞍胜少——而䞔绝倧倚数事故郜来自基础没做奜,而非猺少高级防埡。

  • 讀证䞎授权分枅楚:讀证(䜠是谁)和授权(䜠胜干什么)是䞀件事。最垞见的挏掞是「讀证做了、授权没做细」——比劂把记圕 ID 䞀改就胜看到/改掉别人的数据(越权)。每䞀次数据访问郜芁校验「这䞪甚户有没有权限碰这条」。
  • 氞远䞍芁信任甚户蟓入:所有蟓入郜芁校验䞎蜬义,挡䜏泚入类攻击(让数据氞远只是数据,䞍䌚被圓成呜什/代码执行)。这是最叀老也最有效的纪埋。
  • 敏感数据芁保技:密码绝䞍明文存(甚单向䞍可逆的方匏保存);䌠蟓䞎静态存傚加密;别把密钥/口什写进代码或日志里。
  • 䌚话䞎凭证安党:防止䌚话被窃取/䌪造;敏感操䜜二次确讀。
  • 最小权限:应甚连数据库、连第䞉方,郜只给「干这件事所必需」的权限;䞀旊被攻砎,圱响面才小。
  • 别把安党寄望于「没人知道」:架构䞊讟枅楚蟹界(谁胜访问什么),而䞍是靠「这䞪接口比蟃隐蔜」。
  • 合规按需:涉及䞪人数据时,做到可删陀、可富出、明确告知甚途——䜆同样按实际涉及的范囎来做,别䞺甚䞍到的合规等级提前堆倍杂床。

11. 垞见误区 / 反暡匏

这䞀节是这仜暡板的粟华——几乎每䞀条郜是『过床讟计』或『跳过基本功』的具䜓圢态。

  • ❌ 䞀䞊来就䞊埮服务 → ✅ 先单䜓,内郚分层枅晰;埮服务是䞺「组织规暡」准倇的,䞍是䞺「星埗先进」(决策 2)。
  • ❌ 过早分库分衚 → ✅ 先把玢匕、猓存、读副本䞉板斧甚满;分库分衚是最后才劚的栞歊噚(第 9 节)。
  • ❌ 应甚层有状态,富臎䌚话黏连、扩䞍劚 → ✅ 应甚层无状态,状态攟倖郚共享存傚(决策 5)。
  • ❌ N+1 查询(圚埪环里䞀条条查库) → ✅ 䞀次性批量查询/连衚;这是这类系统最高频的性胜杀手,䞔垞被玢匕掩盖到流量倧了才爆。
  • ❌ 没有读压力就先加䞀层猓存 → ✅ 猓存是甚䞀臎性倍杂床换性胜,没压力时是净亏(决策 3)。
  • ❌ 给䞀䞪内容型站点䞊重型客户端枲染 → ✅ 内容型䌘先服务端枲染(銖屏 + SEO),别甚倍杂床换䜠䞍需芁的䞜西(决策 1)。
  • ❌ 把倧文件(囟片/附件)塞进数据库 → ✅ 攟对象存傚,数据库只存它的匕甚;吊则撑爆库、拖慢查询、倇仜变噩梊。
  • ❌ 把慢操䜜(发邮件、生成报衚)卡圚请求䞻铟路里 → ✅ 匂步化䞢进任务队列,甚户只等必须同步的郚分。
  • ❌ 「䞺了将来可胜的规暡」提前堆䞀堆䞭闎件 → ✅ 让真实需求迫䜿䜠加,而䞍是预刀着加(决策 0)。
  • ❌ 讀证做了、授权没做细(越权) → ✅ 每次数据访问郜校验「这䞪甚户胜䞍胜碰这条」(第 10 节)。

12. 挔进路线:MVP → 成长期 → 成熟期

架构是䌚长倧的。别拿成熟期的囟去套 MVP——䜆曎芁譊惕:倧倚数项目其实䞀蟈子停圚第䞀、二阶段,根本到䞍了第䞉阶段。

阶段 甚户/规暡量级 架构长什么样 歀时该操心什么
MVP 启劚 ~ 几䞇 䞀䞪单䜓 + 䞀䞪数据库,就这么简单。可胜连莟蜜均衡郜还䞍需芁。 把功胜做对、把暡块蟹界划枅楚;抵制䜏䞀切「先进架构」的诱惑
成长期 几䞇 ~ 蟃倧 还是单䜓,䜆匀始按需加旁路:CDN(早加)、猓存(有读压力时)、读副本(读成瓶颈时)、任务队列(有慢操䜜时);应甚层倚摆几台 + 莟蜜均衡 沿着第 9 节的瓶颈顺序,哪疌治哪;守䜏无状态;别䞀次性党加
成熟期 埈倧,䞔组织也变倧 只圚真正撑䞍䜏、䞔团队规暡也芁求并行时,才沿着早已枅晰的暡块蟹界,把单䜓拆成几䞪服务;数据库做曎重的分片 成本、容灟、组织协同;歀时䜠应已有充分的数据和瓶颈证据来支撑每䞀步

挔进的黄金法则:让单䜓陪䜠走到它真的走䞍劚䞺止——这䞪「真的走䞍劚」,通垞比䜠以䞺的晚埗倚。 拆分是「被规暡逌出来的结果」,䞍是「䞀匀始就规划奜的蓝囟」。而第 1 阶段就划枅的暡块蟹界,正是将来胜吊平滑拆分的关键——所以『先单䜓』䞍等于『䞍讟计』,恰恰盞反,它芁求䜠把蟹界想埗埈枅楚,只是先䞍拆匀郚眲而已。

13. 可倍甚芁点

  • 💡 简单是芁䞻劚争取的、最被䜎䌰的架构属性。 每䞀䞪䜠没加的组件,郜是䜠䞍甚理解、䞍甚运绎、䞍䌚出故障、䞍䌚拖慢匀发的䞜西。「我胜䞍胜䞍加这䞪?」应该是䜠的默讀提问。
  • 💡 过床讟计的代价是真实䞔即时的,而它换来的「可扩展性」埀埀氞远甚䞍到。 先问「我现圚这䞪规暡,真的需芁它吗?」——这䞀䞪问题胜垮䜠省䞋倧半的麻烊。
  • 💡 沿瓶颈的真实顺序花力气:数据库(玢匕→猓存→读副本)圚前,应甚层氎平扩展圚后。 别跳过最䟿宜的药盎接䞊最莵的手术。
  • 💡 「单䜓䌘先」䞍是因䞺它萜后,而是因䞺它把『分垃匏系统的党郚苊隟』掚迟到了䜠真的莟担埗起、也真的需芁的那䞀倩。 埮服务解决的是组织问题,䞍是技术问题。
  • 💡 无状态是䞀条几乎零成本、华䞺未来扫枅最倧障碍的纪埋——倌埗从第䞀倩就遵守。 它让「加机噚」成䞺最蜻束的扩展手段。
  • 💡 让需求来驱劚架构挔进,而䞍是让䜠的预刀来。 真遇到问题再加是廉价的,䞺没发生的事提前加是昂莵的。

🎯 随堂检验

参考原型䞎延䌞阅读

本暡板基于以䞋经兞方法论䞎官方架构文档敎理。

📖 方法论 / 官方文档:

📌 䞀句话记䜏标准 Web 应甚:它教的䞍是「怎么把系统做倍杂」,而是「怎么忍䜏䞍把它做倍杂」——绝倧倚数系统死于过床讟计,而克制,恰恰是最隟、也最倌钱的架构胜力。