📚 课程目录第1章发证系统架构全景

1、发证系统架构全景：从单体到微服务的演进之路，理解性能瓶颈的根源

大家好，我是老赵。今天咱们聊聊发证系统的架构演进。说实话，我见过太多团队一上来就搞微服务，结果性能没上去，反而把自己搞崩了。你想想看，连单体时代的瓶颈都没摸清楚，直接上分布式那不是找死吗？

这一章，我带大家从最原始的单体架构开始，一步步走到微服务。不是为了讲历史，而是让你看清楚——每个阶段的性能瓶颈，到底是怎么来的。

1.1 单体架构：简单粗暴，但能撑多久？

早期发证系统，基本都是单体应用。一个 WAR 包丢到 Tomcat 里，所有功能揉在一起：用户管理、模板管理、证书生成、存储、通知……全在一个进程里跑。

核心特征：

所有模块共享同一个数据库连接池
证书生成和业务逻辑在同一个线程里执行
部署简单，一台服务器搞定

我2015年接手过一个省级CA发证项目，就是这种架构。刚开始每天几千张证书，跑得挺欢。后来业务量涨到每天5万张，问题就来了——生成一张证书要3秒，高峰期请求排队，用户直接超时。

为什么会这样？说白了，单体架构有三大硬伤：

瓶颈类型	具体表现	根因
计算瓶颈	证书生成（RSA/ECC签名）占满CPU	签名操作是CPU密集型，与业务线程争抢资源
IO瓶颈	数据库连接池耗尽，查询变慢	所有模块共用连接池，证书存储和业务查询互相阻塞
内存瓶颈	JVM堆内存频繁GC，STW时间过长	证书对象和模板对象同时驻留堆内存，老年代回收频繁

我曾经踩过的坑： 在单体架构下，我们尝试用多线程并发生成证书。结果呢？线程数一多，数据库连接池先爆了，接着是CPU上下文切换飙升，最后整个应用挂了。教训就是——单体架构的扩展能力是有天花板的，别硬撑。

1.2 垂直拆分：把证书生成单独拎出来

既然单体扛不住，那就拆。最直接的做法——把证书生成服务单独部署。这就是垂直拆分，也叫「按业务功能拆分」。

我个人习惯把这种架构叫做「大单体+小服务」模式。核心业务还在单体里，但证书生成这种重计算任务，单独拉出来做成一个服务。

// 垂直拆分后的调用示意（伪代码）
// 单体应用调用证书生成服务
public class CertServiceClient {
    private final RestTemplate restTemplate;
    
    public Cert generateCert(CertRequest request) {
        // 通过HTTP调用独立的证书生成服务
        ResponseEntity<Cert> response = restTemplate.postForEntity(
            "http://cert-gen-service/api/generate", 
            request, 
            Cert.class
        );
        return response.getBody();
    }
}

这个阶段，性能瓶颈开始转移：

网络IO成为新瓶颈：每次生成证书都要走一次HTTP调用，延迟从3ms变成30ms+
证书生成服务自身压力集中：所有请求都打到一个服务上，它自己又成了新的单体
数据一致性变复杂：单体里的事务边界被打破，需要引入补偿机制

我的建议： 垂直拆分是性价比最高的第一步。别一上来就搞服务网格、事件驱动。先把最重的计算任务拆出去，你就能解决80%的性能问题。剩下的20%，等业务量再翻10倍再说。

1.3 水平拆分：按证书类型分而治之

垂直拆分之后，证书生成服务还是扛不住。我记得有一次双十一大促，SSL证书的申请量暴涨了20倍，单节点直接被打穿。

怎么办？水平拆分——按证书类型（SSL、代码签名、邮件证书）或者按用户ID哈希，把请求分散到多个节点。

水平拆分的核心逻辑：

每个节点只处理特定范围的请求
节点之间无状态，可以独立扩缩容
引入负载均衡器（Nginx/HAProxy）做请求分发

这个阶段，性能瓶颈又变了：

新瓶颈	原因	影响
负载均衡层	所有流量先经过LB，LB成为单点	LB故障导致全站不可用
数据分片	证书存储需要按相同规则分片	跨分片查询变得复杂，需要引入中间层
配置管理	多个节点的配置需要统一管理	配置不一致导致证书生成失败

1.4 微服务架构：彻底解耦，但引入新问题

到了这一步，你其实已经走在微服务的路上了。真正的微服务架构，是把发证系统拆成多个自治的服务：

证书模板服务：管理证书模板的元数据
证书生成服务：负责签名和证书组装
证书存储服务：对接多种存储后端（数据库、对象存储、HSM）
通知服务：发送证书到用户邮箱或回调
审计服务：记录所有操作日志

每个服务独立部署、独立扩缩容、独立选型。听起来很美，对吧？但我要泼一盆冷水——微服务不是银弹，它只是把性能瓶颈从「计算」转移到了「通信」。

我曾经踩过的坑： 一个客户把发证系统拆成了12个微服务，结果证书生成链路变长了——从原来的1次RPC变成了5次RPC。每次生成证书都要经过模板查询、签名请求、存储写入、通知发送……链路上任何一个服务慢一点，整体延迟就爆炸。最后我们不得不引入异步消息队列和缓存，才把延迟降下来。

1.5 架构演进全景图

下面这张图，是我自己总结的发证系统架构演进路线。你可以看到，每个阶段都有它的性能瓶颈，而瓶颈的根源其实就三个字——「不平衡」。

1.6 理解瓶颈根源：三个核心维度

看了上面的演进图，你会发现一个规律——每次架构演进，都是在解决上一阶段的瓶颈，但同时又引入了新的瓶颈。那么，性能瓶颈的根源到底是什么？我总结为三个维度：

资源争抢：CPU、内存、IO、网络，这些资源在任何架构下都是有限的。谁抢到谁就能快，抢不到就排队。
链路失衡：一个请求经过的链路越长，出现慢节点的概率就越大。微服务架构下，一个慢服务会拖垮整条链路。
数据一致性：分布式环境下，保证数据一致性需要额外的开销（锁、事务、补偿），这些开销本身就是性能杀手。

核心观点： 性能优化的本质，不是消灭瓶颈，而是管理瓶颈。你要做的，是让瓶颈出现在你能控制、能扩展的地方，而不是让它出现在你无能为力的地方。