请设计一个支持百万级用户访问的工程管理系统（类似PMIS）的高可用架构，并阐述其安全防护措施，包括身份认证、访问控制、数据加密等。
答案
1) 【一句话结论】采用微服务+分布式+多活部署架构，结合纵深安全防护体系，实现百万级并发下的高可用与安全。
2) 【原理/概念讲解】
首先，高可用架构的核心是“冗余+故障转移”，比如服务器集群、数据库主从复制，确保单点故障不影响整体服务。百万级并发处理需“分布式拆分+缓存+异步”，将业务拆分为工程管理、进度跟踪、资源调度等微服务，用Nginx/HAProxy做负载均衡，将请求分发到多个实例；通过Redis集群缓存热点数据（如用户信息、工程状态），减少数据库压力；异步任务（如进度更新、通知推送）通过Kafka处理，避免阻塞主流程。
安全防护方面，身份认证用OAuth2.0+JWT（用户登录后获取令牌，后续请求携带令牌验证）；访问控制用RBAC（基于角色的访问控制），根据用户角色（如项目经理、施工员）分配权限，限制操作范围；数据传输用TLS 1.3加密，数据库存储数据用AES-256加密，防止数据泄露。
3) 【对比与适用场景】
| 方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 负载均衡（Nginx） | 高性能HTTP服务器 | 轻量级，灵活配置 | 中小规模，灵活扩展 | 需手动配置，扩展性一般 |
| 负载均衡（Kubernetes Ingress） | 容器化负载均衡 | 自动化管理，支持多种协议 | 微服务架构，容器化部署 | 需K8s环境，学习成本 |
| 安全认证（JWT） | JSON Web Token | 无状态，跨域 | 单点登录，API认证 | 密钥管理复杂，易被劫持 |
| 安全认证（OAuth2.0） | 授权框架 | 分层授权，安全 | 第三方登录，资源访问 | 需授权服务器，流程复杂 |
4) 【示例】
架构图描述（文字）：前端（Nginx负载均衡）→ 微服务集群（工程管理、进度跟踪、资源调度等）→ 缓存集群（Redis）→ 消息队列（Kafka）→ 数据库集群（MySQL主从+分片）→ 安全网关（WAF+防火墙）。
请求流程示例：用户访问工程管理系统，Nginx负载均衡分发到微服务实例，微服务从Redis缓存获取用户信息（若缓存未命中，查询数据库），通过OAuth2.0验证JWT，RBAC检查权限，返回数据。
5) 【面试口播版答案】
面试官您好，针对百万级用户访问的工程管理系统高可用架构设计，我的核心思路是采用“微服务+分布式+多活部署”的架构，结合纵深安全防护体系。首先，业务拆分为工程管理、进度跟踪、资源调度等微服务，通过Nginx/HAProxy实现负载均衡，确保请求分发到多个实例，避免单点故障。数据库层面采用主从复制+分片，主库写，从库读，同时部署多活数据库节点，实现故障自动切换。缓存使用Redis集群，缓存热点数据（如用户信息、工程状态），减少数据库压力。异步任务通过Kafka处理，比如进度更新、通知推送，避免阻塞主流程。安全方面，身份认证采用OAuth2.0+JWT，用户登录后获取令牌，后续请求携带令牌验证；访问控制采用RBAC模型，根据用户角色（如项目经理、施工员）分配权限，限制操作范围；数据传输用TLS 1.3加密，数据库存储数据用AES-256加密，防止数据泄露。整体架构通过多活部署和冗余设计，确保高可用，同时通过纵深安全防护，覆盖身份、访问、数据等层面，满足百万级并发下的安全需求。
6) 【追问清单】
- 问题1：微服务之间的通信如何保证高可用和低延迟？
回答要点：使用gRPC或HTTP/2协议，结合服务发现（如Consul/Etcd），确保服务实例的动态发现和负载均衡，同时通过熔断降级（Hystrix/Spring Cloud Circuit Breaker）防止故障扩散。 - 问题2：百万级并发下，缓存雪崩如何处理？
回答要点：设置合理的缓存过期时间，采用“热点数据预热”策略，部署多个Redis实例并使用Redis Cluster，避免单点故障。 - 问题3：数据库分片的具体策略是什么？
回答要点：按工程ID分片（如按工程编号的哈希值），每个分片对应一个数据库实例，确保读写分离，同时通过数据库代理（如ProxySQL）管理分片路由，提高查询效率。 - 问题4：安全防护中，如何防止JWT令牌被劫持？
回答要点：令牌存储在客户端浏览器（但需注意XSS风险），使用HttpOnly和Secure标志，同时设置令牌有效期（如1小时），定期刷新令牌。 - 问题5：容灾方案如何设计？
回答要点：异地多活部署（如北京和上海节点），数据实时同步（如数据库主从+CDC），应用集群自动切换（如通过ZooKeeper管理状态），确保故障时业务快速恢复。
7) 【常见坑/雷区】
- 坑1：架构设计过于复杂，忽略业务实际需求，比如过度拆分微服务导致管理成本高，或者未考虑工程管理系统的业务特点（如数据量大、实时性要求）。
- 雷区2：安全措施停留在表面，比如只说“使用加密”，而不提密钥管理（如使用KMS管理密钥）、令牌安全（如防止重放攻击）。
- 坑3：高可用设计只考虑硬件冗余，忽略软件层面的故障转移，比如数据库主从复制但未配置自动故障切换，或者负载均衡器故障时无备用方案。
- 雷区4：未考虑百万级并发下的性能优化，比如未使用缓存、异步处理，导致数据库压力过大，或者未进行压力测试，导致实际并发时性能下降。
- 坑5：安全防护未覆盖所有环节，比如只关注前端安全，而忽略后端API的安全（如SQL注入、XSS），或者传输层未使用TLS，导致数据在传输中被窃取。