成熟期转向求精，及用户规模维度的量变到质变逻辑

熬过[[竞争期系统数量质变的两个问题，及平台化、服务化应对]]、成为行业领头羊或行业整体进入成熟阶段后，市场地位已经比较牢固，业务创新的空间和竞争压力都不再那么激烈，业务重心从”求快求新”转向”求精”——比拼响应时间是否更快、用户体验是否更好、成本是否更低。这个阶段技术上该拆的也拆了、该平台化的也平台化了，大动作已经不多，更多是精细化优化，但有些优化目标本身可能牵动很多方面（比如要把响应时间从200ms降到50ms，可能要同时优化CDN、数据库、网络等多个环节），这类优化没有固定套路，只能按竞争对手的对比结果找出自己的短板逐项优化，具体手段可以从前面各阶段（堆功能、优化、架构拆分、平台化、服务化）里灵活借用。除了业务复杂性这条主线，用户规模是互联网技术演进的另一条主线，同样贯穿初创期到成熟期，用户量增大对技术的影响集中在两方面。性能：以MySQL为例，单台机器不管配置多高，能撑住的TPS/QPS基本封顶在万级（低则几千、高不过几万），用户量涨上去后必须上多台MySQL，而”从一台到多台”不是简单的数量增加，是本质变化——从集中式存储变成了分布式存储，分布式意味着要处理分库分表、读写分离、复制同步这一整套新增复杂度。可用性：用户1万时宕机1小时可能没什么感觉，用户100万时宕机10分钟投诉电话就被打爆，用户还会在朋友圈吐槽，很可能就断送了接下来发展下一个100万用户的机会；从收入角度看同理，1万用户宕机1小时可能只损失几千元，100万用户宕机10分钟可能就是几十万元的损失——可用性的容错空间随用户规模扩大而急剧收窄。业务复杂性和用户规模这两条主线，本质上都是同一个规律的体现：”量变带来质变”——不管在哪个发展阶段，一旦发现业务已经”快不起来”了，就说明当前的技术水平已经跟不上业务发展的需要，是技术该变革的信号；更理想的做法是在问题真正暴露之前，就能根据发展趋势提前预判下一个转折点、提前做好技术准备，这对技术人员的判断力要求非常高。

结构图：

flowchart TB
  A["成熟期：从求快求新转向求精<br/>优化无固定套路，按短板逐项优化"]
  B["用户规模维度：贯穿全生命周期"]
  B --> C["性能挑战：单机TPS/QPS封顶(万级)<br/>多机=集中式变分布式，复杂度质变"]
  B --> D["可用性挑战：容错空间随用户规模急剧收窄<br/>(1万用户宕机1小时≈无感<br/>100万用户宕机10分钟≈投诉电话被打爆)"]
  C --> E["共同本质：量变带来质变"]
  D --> E
  A --> E
  E --> F["信号：业务'快不起来'时<br/>=技术已跟不上业务需要<br/>理想状态是提前预判转折点"]