架构评审：零失误决策

▌ 技术引导 在高压系统开发中，零失误决策往往从架构评审开始，评审流程的每一个环节都可能成为系统崩溃的诱因。我见过太多人因为架构评审环节的疏忽，导致后续上线时出现不可逆的故障。架构评审不仅仅是概念上的对错，更是一场对细节、边界条件、性能瓶颈和数据流的全面体检。零失误决策的关键在于在评审阶段就锁定潜在风险点，比如中间件选型、分布式事务处理、缓存策略、资源隔离、并发控制等。评审时要带入真实场景，不能只看PPT。我踩过坑，比如没有评估缓存穿透问题，结果线上直接炸了。不要用“应该”来判断架构是否合适，而是用“会怎么样”来模拟后果。 评审时必须明确系统边界，谁负责什么模块、谁对接什么服务，像切蛋糕一样分清楚。我见过项目因为接口归属不清，导致多个团队重复开发，最后数据不一致。架构评审需要有输出文档，不能只停留在口头。文档要写清楚依赖关系、服务熔断机制、服务发现策略、监控指标、日志级别、数据库分库分表策略。这些不是写给别人看的，而是自己看的，用来做决策的依据。最痛的教训是在没有日志级别配置的情况下，线上排查浪费了三天时间。 架构评审必须带入真实的数据模型，比如用户行为日志、交易流水、设备状态等，不能只用理论模型。我曾在评审中忽略了数据分区策略，导致线上查询延迟飙升。评审要带入真实使用场景，比如秒杀活动、高并发登录、分布式事务、跨域请求、缓存失效等。这些场景不是假设，而是必须存在的。架构评审要带入真实性能测试，不能只看文档上的理论值。我用过负载测试工具压出系统瓶颈，结果发现是数据库连接池配置太低。 评审时要关注服务调用链的完整性，比如调用方是否有重试机制，服务方是否有限流熔断，中间件是否支持异步处理。这些细节在评审阶段没搞定，上线后几乎是必死的。我见过因为没有设置幂等性校验，导致重复下单。评审要关注服务的版本管理，比如是否支持灰度发布、是否允许降级、是否做了AB测试。这些不是锦上添花，而是救命稻草。评审要关注资源隔离，比如CPU、内存、网络、磁盘等资源是否做了隔离，否则一个服务故障可能拖垮整个集群。 架构评审的最终目标不是完美，而是最小化风险。我见过有人为了追求架构先进性，硬套Kubernetes、Service Mesh、Serverless这些概念，结果适得其反。评审要根据实际业务需求，而不是技术潮流。比如，如果业务只是简单的HTTP API，没必要用Kubernetes，更不用说Service Mesh。评审要基于真实可用性数据，比如系统可用性、响应时间、吞吐量、错误率，而不是模糊的指标。这些数据要来自真实测试，不能靠猜。 ▌ 技术参考 一 建立架构评审文档模板 架构评审必须有文档输出，否则评审结果只能留在口头。我习惯用Markdown格式写评审文档，结构包含服务依赖、数据模型、接口定义、部署策略、监控指标、资源限制、扩展方向、错误处理机制。文档中必须标明每个服务的QPS、延迟上限、错误率预期，不能用模糊词汇。比如，不能写“系统应该能扛住高并发”，而是写“系统在10万QPS下延迟控制在500ms以内，错误率不超过0.1%”。文档要包含每个模块的策略配置，比如Redis缓存的TTL、本地缓存的容量、数据库分库分表策略、是否启用ShardingSphere。 二 服务调用链完整性检查 服务调用链必须完整，否则系统会成为“弹弓”。我踩过坑，比如在调用链中没有设置超时熔断，导致某个微服务挂掉后整个系统瘫痪。检查调用链是否包含重试、限流、熔断、异步处理、事务回滚等策略。比如使用Resilience4j设置熔断阈值为5次失败，超时时间为1000ms，重试次数为3次。调用链中每个中间件都要有配置项，比如Nacos配置中心的命名空间、分组、数据加密方式。服务调用链必须支持分布式追踪，比如使用SkyWalking或Zipkin，设置采样率100%，并确保日志格式兼容。 三 数据模型与存储策略评估 数据模型必须清晰，存储策略必须匹配业务场景。我见过有人盲目追求NewSQL数据库，结果发现业务需要强一致性，最终不得不回滚到MySQL。数据模型评审要关注数据分区策略，比如使用ShardingSphere的分片键为user_id，分片算法为范围或哈希。存储策略要评估读写压力，比如使用Redis做缓存时，是否启用了持久化策略，比如RDB和AOF混合使用，配置文件中设置 save 900 1 和 save 3600 1，同时开启AOF重写策略。对于高并发场景，可以使用Redis Cluster，配置slots分片数为16384，每个节点最大内存为2GB，并设置集群模式为yes。 四 服务健康检查与监控指标 服务必须有健康检查和监控指标，否则上线后是“瞎子”。我踩过坑，因为服务没有设置健康检查，导致某个节点异常时系统没有感知。健康检查必须包含服务端口、数据库连接、缓存可用性、第三方服务依赖等。监控指标要细化到每个微服务，比如CPU使用率、内存占用、线程数、请求延迟、错误率、流量突增等。使用Prometheus + Grafana监控系统，每个服务的指标要暴露为/metrics端点，并设置采集频率为10秒。对于关键服务，设置告警策略，比如CPU超过80%时触发告警，延迟超过1s时触发告警，错误率超过0.5%时触发告警。 五 分布式事务处理方案对比 分布式事务是架构评审中必须关注的点，不能掉以轻心。我测试过Seata、Atomikos、JTA、TCC等方案，最终选择Seata作为主方案。Seata的TC（Transaction Coordinator）必须部署在独立服务器上，配置文件中设置 service.vgroupMapping.default_txgroup=seata-server，并确保TC的端口未被占用。对于高并发场景，Seata的AT模式比TCC模式更易用，但性能会有一定损耗，需要配置事务分组和资源分组，比如设置 transactionServiceGroup=default_txgroup。同时要评估数据库的事务隔离级别，比如使用REPEATABLE READ，避免脏读和幻读。 六 容器化部署与资源隔离配置 容器化部署必须配置资源隔离，否则一个服务异常会拖垮整个集群。我见过因为没有限制CPU和内存，某个服务占用过多资源导致其他服务无法启动。使用Docker时，必须设置--cpu-shares和--memory参数，比如 docker run --cpu-shares=512 --memory=2g。Kubernetes中要设置resources请求和限制，比如在Deployment YAML中设置 resources: requests: memory: 512Mi cpu: 500m limits: memory: 2Gi cpu: 1。同时要开启资源配额，比如在Namespace中设置 resourceQuota，限制CPU和内存的总量。 七 协议与通信方式选择 协议选择不能随意，必须匹配实际场景。我见过有人用HTTP协议做内部通信，结果因为延迟过高导致系统响应变慢。内部通信推荐使用gRPC或Thrift，因为它们的序列化效率更高。比如使用gRPC时，要配置protoc生成代码，设置--go_out和--go-grpc_out参数。对于跨域场景，使用HTTP协议且配置CORS策略，比如在Nginx中添加 add_header 'Access-Control-Allow-Origin' ''。通信方式必须支持幂等性校验，比如在gRPC中使用唯一ID，或者在HTTP中使用请求头X-Request-ID。 八 缓存策略与冷热数据分离 缓存策略必须明确，否则系统会因为缓存穿透、击穿、雪崩而崩溃。我用过Redis+本地缓存的组合策略，比如使用Caffeine做本地缓存，配置最大条目数为10000，刷新时间5分钟。Redis缓存要设置TTL，比如使用EXPIRE命令，或者在配置文件中设置 maxmemory-policy=lru淘汰策略。对于高并发场景，缓存还需要支持分布式锁，比如使用Redis的SETNX命令，或者Redlock算法。冷热数据分离必须考虑，比如使用HBase存储原始数据，使用Elasticsearch做冷数据查询。 九 服务降级与熔断策略 服务降级和熔断不能只写在文档里，必须配置到代码和环境变量中。我见过有人设置熔断策略，却在实际环境中没有启用，导致系统崩溃。熔断策略要配置在服务调用方，比如使用Resilience4j的CircuitBreaker，设置failureRateThreshold=50，waitDurationInOpenState=30s。降级策略要配置在服务启动时，比如启动参数中设置--disable-circuit-breaker=false，或者通过环境变量 DISABLE_CIRCUIT_BREAKER=false。 十 跨域请求与安全加固 跨域请求必须配置CORS策略，否则浏览器会拦截请求。我用过Nginx配置，比如在server块中添加 location / { add_header 'Access-Control-Allow-Origin' ''; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'DNT, X(CROS)等。同时要加安全加固，比如使用HTTPS，配置证书为Let's Encrypt，设置HSTS头为max-age=31536000。对于敏感数据，使用JWT做认证，配置签名密钥和令牌有效期，比如在config文件中设置 jwt.secret=your-secret-key 和 jwt.expiration=86400。 十一 服务版本管理与灰度发布 服务版本管理不能忽视，否则上线时会引发雪崩效应。我用过Argo Rollouts做灰度发布，配置环境变量 RELEASE_ENV=production，同时在Deployment YAML中设置 canary: weight: 50。每个版本要保持独立，不能混用。比如使用Git版本控制，每个版本对应一个commit hash，确保回滚时能快速找到对应版本。服务版本管理要包含依赖管理，比如使用Spring Boot的Spring Cloud版本控制，确保所有微服务使用一致的版本。 十二 网络策略与防火墙配置 网络策略必须明确，否则服务无法正常通信。我踩过坑，因为没有配置网络策略，导致服务无法访问其他微服务。Kubernetes中要配置NetworkPolicy，比如设置 ingress规则允许特定端口和IP段。防火墙配置要使用iptables或nftables，比如在CentOS中使用 iptables -A INPUT -p tcp --dport 80 -j ACCEPT，同时设置规则拒绝所有未授权访问。网络策略要包含服务发现策略，比如使用Consul做服务发现，配置服务注册地址为http://consul:8500，并设置健康检查端点为http://service-health-check。 十三 日志系统与数据收集策略 日志系统必须高效，不能因为日志堆积导致系统性能下降。我用过ELK（Elasticsearch + Logstash + Kibana）做日志收集，配置Logstash的input为file，output为elasticsearch。日志级别要分级，比如生产环境使用WARN和ERROR，开发环境使用DEBUG。日志收集要设置保留策略，比如在Kibana中配置索引生命周期管理，设置热数据保留7天，冷数据保留30天。同时要使用日志聚合工具，比如Fluentd，配置日志转发到Logstash，使用 。 十四 配置中心与管理策略 配置中心不能随意，必须支持动态更新和版本控制。我用过Nacos做配置中心，配置文件中设置 dataId=application.properties，group=DEFAULT_GROUP，并启用自动刷新策略。配置中心要支持环境隔离，比如使用不同的命名空间区分开发、测试、生产环境。配置管理策略要包含热更新和回滚，比如在Nacos中设置配置的版本号，并配置监听器在配置变化时重启服务。同时要使用Vault做敏感配置管理，设置环境变量 VAULT_ADDR=http://vault:8200，配置token为vault_token，并启用KV v2存储。 十五 数据库选型与连接池配置 数据库选型不能只看性能，还要看业务需求。我见过有人用PostgreSQL做主数据库，结果发现事务处理能力不足，最终换回MySQL。连接池配置要根据业务负载调整，比如使用HikariCP设置 maximumPoolSize=20，minimumIdle=5，maximumLifetime=30分钟。数据库分库分表要根据业务分片策略，比如使用ShardingSphere的分片键为user_id，分片策略为标准分片，分片算法为哈希。同时要配置主从复制，比如在MySQL中设置 slave_host=master，slave_user=repl，slave_password=secret，并开启binlog。 十六 安全认证与授权策略 安全认证不能只靠HTTP Basic Auth，必须使用更高级的方案。我用过OAuth2 + JWT，配置Spring Security的JWT配置文件，设置 secretKey=your-secret-key，tokenValidityInSeconds=86400。同时要使用RBAC做权限控制，比如在Spring Security中配置 @PreAuthorize("hasRole('ADMIN')") 控制接口访问。对于敏感接口，要使用HTTPS，配置证书为Let's Encrypt，并使用Strict-Transport-Security头。 十七 故障恢复与备份策略 故障恢复不能只依赖重启，必须有完善的备份策略。我见过有人没有做数据库备份，结果因为误操作导致数据丢失。数据库备份要配置定时任务，比如使用mysqldump设置 --single-transaction，每天凌晨执行一次，并上传到对象存储如S3。同时要配置服务自动恢复，比如在Kubernetes中设置 restartPolicy: OnFailure，并设置 livenessProbe和readinessProbe的检查周期。 十八 压力测试与性能调优 压力测试必须做，不能只看理论性能。我用过JMeter做全链路压测，设置线程数为100，循环次数为1000，持续时间30分钟，并监控JVM内存、GC情况、线程池状态。性能调优要从数据库开始，比如使用EXPLAIN分析SQL执行计划，优化索引或查询语句。同时要调整JVM参数，比如设置 -Xms2g -Xmx4g，调整GC算法为G1GC。 十九 审计日志与操作追踪 审计日志不能忽略，必须跟踪每个操作的来源。我用过Spring AOP记录每个API调用，设置日志级别为DEBUG，并在日志中包含用户ID、操作时间、操作类型、操作结果。操作追踪要使用分布式日志系统，比如使用SkyWalking设置采样率100%，并配置日志格式包含trace_id和span_id。审计日志要保存至少30天，并支持按时间、用户、操作类型查询。 二十 系统可用性与容灾方案 系统可用性必须有保障，不能只依靠单点部署。我见过有人没有做容灾，导致机房故障后系统无法恢复。容灾方案要包含异地部署、数据同步、服务切换等。比如使用Kubernetes的多集群部署，配置跨集群服务发现，设置负载均衡策略。同时要配置数据库主从同步，确保数据一致性。系统可用性要设置SLA，比如99.99%的可用性，并通过监控系统实时检测。