从单机起步，慢慢摸索亿级Web系统的分布式集群搭建之路

主要参考自网络技术社区多位资深工程师的经验分享与总结,如知乎高赞回答、CSDN博客专家系列文章等）

从单机起步,慢慢摸索亿级Web系统的分布式集群搭建之路，这个过程就像一个人开个小店，慢慢做成一个跨国连锁集团，中间会遇到各种各样的问题，一步一步解决，系统也就慢慢庞大了。

第一阶段：单机时代，一切都很简单

最开始,你的网站可能就是个简单的应用程序，比如一个博客或者一个小型电商网站，你把所有东西都放在一台服务器上：网站程序、数据库、文件（比如用户上传的图片）都在这一个“大盒子”里，这时候，访问量不大，这台服务器完全够用。

遇到的问题： 随着用户慢慢增多，你会发现网站越来越慢，有时候甚至会卡死，因为这单一台服务器要处理所有的活：接收用户请求、跑程序逻辑、查询数据库、发送文件，CPU、内存、硬盘I/O都快到极限了，这就好比一个小卖部，顾客一多，只有一个店员，结账、取货、回答咨询全是他，肯定忙不过来。

第二阶段：服务分离，找几个帮手

为了解决单机压力大的问题,最先想到的办法是“分工”，把不同的活儿交给不同的服务器去做，这是走向分布式的第一步。

• 应用与数据分离： 这是最关键的一步，买一台专门的服务器来跑数据库，原来那台服务器就只负责处理网站程序逻辑，这样，计算压力和存储压力就分开了，相当于小卖部雇了个专门的仓库管理员，店员只负责前台销售。
• 引入缓存： 你会发现，很多用户都在查询同样的热门商品信息或者文章内容，每次都去问数据库，数据库压力很大，这时候可以引入一个叫“缓存”的东西（比如Redis），它就像店里的一个热门商品展示架，把最常被问到的商品信息放在最显眼、拿取最快的地方，用户再来问，先看展示架有没有，有就直接拿，不用每次都跑去仓库（数据库）翻找，极大减轻了数据库负担，加快了响应速度。
• 静态资源分离： 网站上的图片、视频、CSS、JS这些文件变化不频繁，但很占带宽，可以用专门的服务器（比如Nginx）来存放和分发这些静态文件，甚至可以把它们放到更专业的云存储CDN上，让用户从离他最近的节点下载，速度飞快，这就好比把宣传单页和商品海报的印刷分发工作外包给专业的印刷厂和配送网络，店里只专注于核心交易。

第三阶段：应用集群化，应对高并发

分工之后,系统能力强了不少，但万一负责程序的那台服务器宕机了，整个网站还是得挂，如果访问量再上一个台阶，一台应用服务器又不够用了。

• 负载均衡： 这时候，就需要“应用集群”，你部署多台一模一样的应用服务器，然后在它们前面放一个“调度员”——负载均衡服务器（比如用Nginx或硬件负载均衡器F5），所有用户的请求先到达这个调度员，由它根据每台应用服务器的忙闲程度，把请求合理地分发给其中一台去处理，这样，即使一台应用服务器坏了，其他的还能继续服务，保证了系统的可用性（高可用），就像开了几家分店，有一个总接待台，把客人引导到人最少的分店去。
• Session问题： 应用一多，新问题就来了，用户A第一次登录被分到了1号服务器，他的登录信息（Session）存在了1号服务器上，但他下一次请求如果被调度员分到了2号服务器，2号服务器不认识他，就会要求他重新登录，这肯定不行，解决办法有几种：比如让所有服务器都把Session信息集中存到一个地方（比如Redis里），这样无论分配到哪台服务器，都能认出用户；或者用一种叫“粘性Session”的策略，让一个用户的一次会话始终由同一台服务器处理。

第四阶段：数据库成为瓶颈，读写分离与分库分表

应用层可以轻松扩展了,但最底层的数据库还是只有一个，当写操作（如下订单、发评论）和读操作（如查商品、看文章）都非常频繁时，这个唯一的数据库就成了最大的瓶颈。

• 读写分离： 既然读操作远多于写操作，很自然的想法就是“主从复制”，搞一台主数据库（Master）专门负责接收写操作，然后复制好几台从数据库（Slave）专门负责读操作，应用程序写数据时找主库，读数据时找从库，这样就把数据库的压力分摊了，这就像公司里，重要文件的修改必须经过总经理（主库），但员工查阅文件可以去找各个部门的档案管理员（从库）。
• 分库分表： 当数据量爆炸式增长，比如用户表有几个亿的记录，商品表几千万，即使读写分离，单台服务器也存不下、查不动了，这时候就必须“分库分表”，按用户ID的哈希值，把用户数据拆分到不同的数据库服务器上（分库），每台服务器上的用户表也拆分成多个小表（分表），这就像一个大仓库装不下所有货了，不得不建立几个区域仓库（分库），每个仓库里再建多个货架（分表）来存放，这是分布式系统中最复杂、挑战最大的环节之一，需要仔细设计拆分规则。

第五阶段：微服务与更多细化挑战

系统越来越庞大,所有的业务代码都挤在一个应用里（单体架构），牵一发而动全身，开发和部署都变得极其困难。

• 服务化/微服务： 把一个大系统按业务功能拆分成一个个小的、独立的服务，比如用户服务、商品服务、订单服务、支付服务，每个服务可以由独立的团队开发和维护，有自己的数据库，服务之间通过明确的接口（如HTTP API、RPC）进行通信，这样系统更灵活，更容易扩展和维护，这就好比把一个大集团拆分成多个专业化子公司，各自独立运营，通过合同协作。
• 新的挑战： 微服务带来了新的复杂度，服务多了，如何管理它们之间的调用关系？一个服务挂了会不会引起连锁反应（雪崩）？这就是服务治理和熔断机制要解决的问题，分布式事务也变得非常棘手，比如下单扣库存和支付必须同时成功或失败，在多个服务下保证这一点很难，往往需要最终一致性方案替代强一致性。

这条路走过来,核心思想就是：当单点成为瓶颈时，就通过“拆分”和“冗余”来解决问题。 从垂直拆分（应用、数据库分离）到水平拆分（应用集群、分库分表），再到业务拆分（微服务），每一步都是为了解决当前阶段最突出的矛盾，要引入缓存、负载均衡、消息队列等各种中间件作为辅助工具，搭建亿级系统没有一步到位的银弹，都是在业务发展的驱动下，不断遇到问题、解决问题、架构持续演进的过程。