企业官网建设流程全解析

做了十来年 Java 后端，带过几个从零到上线的系统，也踩过不少"上线那天服务器就跪了"的坑。回头看，很多架构问题最后都能归到同一个话题——三高：高并发、高可用、高性能。这三个词几乎是后端面试的必考题，但真正带过项目的人都知道，它们不是三个孤立的知识点，而是同一件事情的三个侧面。这篇文章尽量用大白话把这几件事捋清楚，不堆术语，能落地的地方尽量给思路和代码。

一、什么是三高架构

先说结论：三高不是三个并列的目标，而是三个互相牵制的约束条件。

• 高并发：系统能不能扛住同时涌进来的大量请求，比如秒杀、大促、突发流量。
• 高可用：系统能不能在部分组件挂掉的情况下，整体依然对外提供服务，不至于一挂全挂。
• 高性能：单次请求的响应速度够不够快，资源利用率够不够高。

这三者经常是相互拉扯的关系。举个例子：为了高可用，你可能要做多副本、跨机房部署，这就带来了数据同步的开销，反过来又会拖慢性能；为了扛住高并发，你可能会加缓存、加异步队列，但缓存又带来了数据一致性的风险，一致性做得越强，性能往往就越差。

所以做三高架构，本质上不是"把三个指标都做到极致"，而是根据业务场景找一个合理的平衡点。支付类系统对一致性要求极高，可以在性能上做一定让步；而一个内容推荐系统，短暂的数据不一致完全可以接受，换来的是更好的并发能力。先想清楚业务对哪个维度更敏感，再决定往哪边倾斜，这一步比具体用什么技术方案更重要。

二、如何设计高性能系统

高性能说白了就是两件事：把没必要的等待去掉，把能复用的资源攒起来。具体拆开看有这么几个方向。

缓存分层。数据库是整个系统里最容易成为瓶颈的一环，能不查库就不查库。本地缓存（Caffeine/Guava Cache）解决高频小数据的读取，分布式缓存（Redis）解决跨节点共享的问题，两层配合使用，命中率能提升一大截。但缓存不是万能药，缓存穿透、击穿、雪崩这几个经典问题绕不开，后面数据库那节会细说。

异步化。凡是不需要用户同步等待结果的操作，都应该丢到异步里去做。比如下单成功后发短信通知、写日志、更新统计报表，这些完全可以通过消息队列解耦，主流程只需要保证核心链路（扣库存、创建订单）同步完成，其他都可以"事后处理"。这样做的直接效果是接口响应时间大幅下降，因为你把原本串行的操作并行化或者延后化了。

连接池化。数据库连接、HTTP 连接、线程，这些创建成本都不低，频繁创建销毁是隐性的性能杀手。用好连接池（HikariCP、Druid）、线程池，把"创建"这个动作的成本摊薄到整个生命周期里去。这里有个容易被忽略的点：线程池的参数不是抄来的模板越大越好，核心线程数、队列长度、拒绝策略要结合业务的 QPS 和响应时间实测调整，盲目调大线程数反而可能因为上下文切换开销让性能变差。

减少锁竞争。能用无锁结构就不用锁，比如用AtomicLong代替synchronized计数器，用ConcurrentHashMap代替加锁的HashMap。实在需要加锁的地方，尽量缩小锁的粒度，比如分段锁的思路，把一把大锁拆成多把小锁，减少线程互相等待的时间。

JVM 层面的调优也不能漏。GC 停顿是很多系统"偶尔卡一下"的元凶，选对垃圾回收器（G1 或者 ZGC，看你的堆大小和延迟敏感度）、合理设置堆内存大小、避免频繁的 Full GC，这些都属于高性能系统的基本功。日常开发中养成看 GC 日志的习惯，比出问题之后再排查要划算得多。

三、高并发下如何解决数据库性能问题

数据库几乎永远是高并发场景下第一个被打垮的环节，因为它是有状态的，没法像应用层那样简单地"加机器就完事"。

先从慢 SQL 和索引下手。这是投入产出比最高的一步，很多时候系统扛不住压力，根本原因不是架构问题，就是一条没走索引的 SQL 在拖后腿。用EXPLAIN看执行计划，把全表扫描的查询揪出来，该加索引加索引，该拆分复杂查询就拆分。这一步做扎实了，很多时候能省掉后面一大堆复杂的架构改造。

读写分离。大部分业务场景都是读多写少，把读请求分流到只读副本上，写请求留在主库，主库压力能明显降下来。需要注意主从同步延迟的问题，如果业务对实时性要求高（比如刚下单立刻查订单详情），要么强制读主库，要么在业务层做好容错。

分库分表。当单表数据量到达千万级、单库撑不住写入压力的时候，就要考虑水平拆分了。按什么字段分片（用户 ID、订单 ID 之类）要提前想清楚，分片键选不好，后面跨库查询、跨库事务会非常麻烦。这一步改造成本很高，建议不要一上来就搞，先把前面几步的优化空间榨干，实在扛不住了再动这个手术。

缓存的三个经典问题：

• 缓存穿透：查询一个数据库里根本不存在的数据，缓存和数据库都没有，请求直接打穿到数据库。解决办法是缓存空值，或者用布隆过滤器提前拦截明显不存在的请求。
• 缓存击穿：某个热点 key 突然过期，大量请求同时打到数据库上。解决办法是热点数据不设过期时间，或者用互斥锁保证只有一个请求去查库重建缓存。
• 缓存雪崩：大量 key 在同一时间集中过期，或者缓存服务整体宕机。解决办法是给过期时间加上随机值，避免同时失效，同时缓存服务本身要做高可用集群。

连接池调优也别忘了，数据库连接是有限资源，连接池配置不合理（比如设置得过大导致数据库本身压力过载，或者过小导致请求排队），同样会成为并发瓶颈。

四、如何实现系统的高可用性

高可用的核心思路是：假设任何一个组件都会挂，系统整体依然要能扛住。

去状态化 + 集群部署是基础。应用尽量做成无状态，会话信息放到 Redis 之类的外部存储里，这样任何一个节点挂了，请求转到其他节点照样能处理，配合负载均衡做健康检查，自动把有问题的节点摘掉。

限流、熔断、降级是三件套，专门应对流量洪峰和依赖故障。限流是保护自己，防止流量把系统打垮（常见算法有令牌桶、漏桶）；熔断是保护调用链路，当某个下游服务持续报错或者超时，就暂时切断对它的调用，避免故障扩散、拖垮整条链路（类似电路的保险丝）；降级是保底方案，核心功能优先保证可用，非核心功能在系统压力大的时候可以暂时关闭或者返回简化结果。Sentinel、Hystrix 这类框架把这几件事都封装好了，接入成本不高。

多机房 / 异地多活是更高级别的容灾手段，用于应对整个机房级别的故障（断电、光缆被挖断这种极端情况）。这个改造成本很大，涉及跨机房的数据同步和流量调度，一般是业务规模到了一定量级、单机房故障的代价已经无法接受时才会投入做。

优雅上下线容易被忽视但很实际。发布新版本的时候，如果直接把老实例杀掉，正在处理的请求会被中断。正确做法是先让负载均衡把流量切走，等实例上正在处理的请求都跑完了，再关闭进程，这就是常说的优雅停机。

监控和告警是高可用的"眼睛"。没有监控，故障发生了你都不知道，更别提及时处理。链路追踪（SkyWalking、Pinpoint）能帮你快速定位问题出在哪个环节，配合合理的告警阈值，做到故障发生的第一时间有人响应,而不是等用户投诉了才知道出问题了。

有条件的团队还会做混沌工程，主动在生产或者预发环境模拟节点宕机、网络延迟这些故障场景，验证系统的容错能力是不是真的靠谱，而不是"设计上应该没问题"这种自我安慰。

五、如何进行系统性能优化

性能优化最容易踩的坑是凭感觉优化，比如听说某个写法"性能更好"就直接改代码，改完发现根本没用，还引入了新的 bug。靠谱的做法是有一套方法论：

第一步，压测，找到真正的瓶颈在哪。用 JMeter、wrk 之类的工具模拟真实流量，观察系统在什么并发量下开始出现响应时间飙升或者错误率上升，别猜，用数据说话。

第二步，自上而下排查。从接入层（网关、负载均衡）到应用层（业务代码、线程池）再到数据层（数据库、缓存、消息队列），最后是基础设施（网络、磁盘 IO）。大部分性能问题最后会定位到数据层，但也不能一上来就默认是数据库的锅，用 Arthas、JProfiler 这些工具对 JVM 里的方法耗时做火焰图分析，能比较直观地看出时间到底花在哪一行代码上。

第三步，优化之后再压测验证，确认改动是不是真的有效果，避免"优化了寂寞"。

还有一个心态上的建议：不要过早优化。在业务量还没起来、瓶颈还没出现的时候，就为了"以后可能会有高并发"去做复杂的架构设计，往往会增加系统的复杂度和维护成本，却没有实际收益。性能优化应该是"按需驱动"，先把系统做对、做稳，再根据实际的压测数据和线上表现有针对性地优化。

六、常用的负载均衡算法

负载均衡是把请求合理分发到多个后端节点的机制，常见算法各有适用场景：

• 轮询（Round Robin）：请求按顺序依次分配给每个节点，实现简单，适合各节点性能相近的场景。
• 加权轮询（Weighted Round Robin）：给性能强的节点分配更高的权重，处理更多请求，适合节点配置不一致的集群。
• 随机 / 加权随机：按概率随机选择节点，效果和轮询类似，在节点数量较多时分布会比较均匀。
• 最小连接数（Least Connections）：把请求分配给当前连接数最少的节点，比轮询更能反映节点的实时负载情况，适合请求处理时长差异较大的场景。
• 一致性哈希（Consistent Hashing）：根据请求的某个特征（比如用户 ID）计算哈希值，映射到一个哈希环上固定的节点。它的好处是当某个节点增加或者减少时，只有少部分请求的路由会发生变化，非常适合有状态服务或者需要缓存亲和性的场景（同一个用户的请求尽量落到同一台机器，命中本地缓存）。
• IP Hash：按客户端 IP 计算哈希，保证同一个客户端的请求始终落到同一个节点，常用于需要会话保持的场景。

实际项目中这几种算法往往分层使用：比如 Nginx 层用加权轮询做初步分发，微服务内部用 Ribbon/LoadBalancer 结合最小连接数或者一致性哈希做更细粒度的调度。选哪种算法，归根结底还是看业务对"负载均匀"和"路由稳定性"哪个更看重。

七、高并发下如何保证数据的一致性

这是三高里最容易让人头疼的一块，因为一致性和性能天然是矛盾的。先明确一个前提：不是所有场景都需要强一致性，大部分互联网业务用最终一致性就够了，用户能接受"稍微延迟一会儿数据才同步过来"，换来的是好得多的并发能力和可用性。真正需要强一致性的，往往是涉及资金、库存这类不能出错的核心场景。

分布式事务是保证一致性的核心手段，几种主流方案各有取舍：

• 2PC / XA：数据库层面原生支持的两阶段提交，一致性强，但所有参与方在提交前都要持有锁，性能差、可用性也不好（协调者挂了会导致资源一直被锁着），现在生产环境用得已经不多。
• TCC（Try-Confirm-Cancel）：把一个操作拆成预留资源（Try）、确认（Confirm）、取消（Cancel）三个阶段，业务代码需要自己实现这三个接口，改造成本高，但性能和灵活性比 2PC 好很多，适合对一致性要求高、又不想牺牲太多性能的核心链路，比如支付扣款这类场景。
• Saga：把一个长事务拆成一系列本地事务，每一步都有对应的补偿操作，出错时依次反向执行补偿。适合流程长、步骤多的业务（比如下单-扣库存-发货这种链路），但补偿逻辑设计起来比较考验业务建模能力。
• 本地消息表 / 事务消息：在本地事务里把要发送的消息先记录到一张消息表，再通过定时任务或者 MQ 的事务消息机制保证消息一定会被投递出去，下游消费者消费消息完成后续操作。这个方案实现相对简单，是很多团队处理最终一致性问题时的首选。

幂等设计是配合分布式事务必须要做的事情。网络重试、消息重复投递几乎是分布式系统的常态，如果下游接口不是幂等的，一次重复调用就可能导致重复扣款、库存扣两次这种事故。常见做法是给每个请求生成唯一的业务流水号，处理前先检查这个流水号是否已经处理过，配合数据库唯一索引兜底。

分布式锁用来解决跨节点的资源竞争问题，比如秒杀场景下防止超卖。Redis 的SETNX加上合理的过期时间是最常见的实现方式，如果对可靠性要求更高，可以用 Redisson 封装好的可重入锁，或者用 ZooKeeper 的临时节点实现，ZooKeeper 的方案在一致性上更有保障，但性能不如 Redis。

举个具体例子帮助理解：一次转账操作，涉及"扣款方扣钱"和"收款方加钱"两个动作，分别落在不同的服务甚至不同的数据库里。用 TCC 的思路来做，Try 阶段先冻结扣款方的余额、预占收款方的入账记录，业务方确认双方状态都正常后进入 Confirm 阶段正式扣款加钱，如果中途任何一步失败，则执行 Cancel 阶段把冻结的余额解冻、撤销预占的记录。整个过程配合幂等校验和事务日志，才能在保证性能的前提下,把资金类操作的一致性做扎实。

写在最后

三高架构没有放之四海皆准的标准答案,更多时候是在做取舍：为了并发能力牺牲一部分一致性,为了可用性接受一定的性能开销,为了性能又要在一致性上打些折扣。真正做架构设计的时候,与其一上来就套用某个"标准三高方案",不如先想清楚业务的核心诉求是什么——是绝对不能错账,还是绝对不能中断服务,还是响应速度必须够快——找准了业务的痛点在哪,再对症选技术方案,才不会做出华而不实的过度设计。

以上是这些年做后端开发和一些分布式系统项目的一点心得,如果有理解不到位或者不同看法的地方,欢迎评论区一起探讨。