gRPC 服务每隔两分钟规律性断连，根源是客户端 keepalive 发送频率（30秒）远高于服务端允许的最小间隔（120秒），导致服务端主动踢掉连接。核心约束是客户端 `keepalive_time_ms` 必须大于等于服务端 `permit-keepalive-time`，否则必然触发 `ENHANCE_YOUR_CALM` 错误。调参需先摸清网络中间件 idle timeout，确保客户端心跳周期小于该值，再让服务端容忍度匹配客户端频率，并显式开启空闲连接心跳。
通过动态分片和依赖分析，将CI全量测试从32分钟压缩至8分钟以内。动态分片基于历史执行时间加权分配用例，解决长尾任务瓶颈；依赖分析通过构建模块依赖图，仅运行受代码变更影响的测试，避免无关用例浪费。方案不依赖特定平台，并提供了冷启动、漏测兜底等落地细节与取舍建议。
运营侧限流阈值变更平均耗时4.2小时，核心矛盾是决策权与执行权分离。方案设计了一套三层DSL（活动-场景-规则），将业务语义从技术参数剥离，运营通过管理后台直接调整阈值，秒级生效。规则引擎采用Redis热加载与原子替换，权限模型按活动和操作类型细粒度隔离，将生效时间降至27秒，且零误操作。
凌晨Redis主从切换导致限流器失效，3秒内多放行近4000请求。问题根源是INCR异步复制导致数据丢失。解决方案分两层：Lua脚本在计数达阈值80%时写入兜底标记key；本地Caffeine缓存异常时接管限流，通过悲观估算控制误放率。压测显示方案将超限从3.2倍降至12%，上线后经历多次故障均未触发告警。
网关层做 gRPC 和 RESTful 协议转换，核心是把路由发现、序列化协商、错误码映射三条链路稳定整合。路由层通过 proto annotation 显式声明 HTTP 映射，用 descriptor 文件构建路由表，Envoy 配置精确控制匹配粒度。序列化层统一字段命名和枚举输出，流式响应需开启 streaming_json。错误码映射自定义 gRPC 到 HTTP 的转换表，用 ErrorInfo 承载业务错误码，保持响应体结构一致。
网关 502 故障暴露了 Tomcat 共用线程池的缺陷：一个慢接口拖垮整个服务。解决方案是实施接口级线程隔离，为不同接口分配独立线程池，并加入带超时的排队机制，避免请求直接失败。配合动态配置、分级监控和上下文传递，成功将故障限制在局部，保障核心链路稳定。
秒杀场景下，Apollo默认5分钟轮询间隔导致配置生效延迟3.2秒，引发数据库连接池打满、Redis CPU飙升。通过将轮询改为长轮询，结合本地缓存和即时生效机制，将平均延迟压至180ms，P99控制在600ms。改造涉及启用长轮询模式、优化限流器动态更新、按需刷新Namespace，并调整服务端线程池和重连策略以保障稳定性。
gRPC 四种服务端类型各有适用场景，选错代价高昂。Unary 适合一问一答，天然支持背压控制；Server Streaming 用于数据推送，但必须配合分页和超时机制防止内存溢出；Client Streaming 适合批量上传，需在收到 EOF 后统一事务处理；Bidirectional Streaming 用于实时双向通信，要严格管理协程生命周期。决策关键在于匹配业务的数据流向和速率特征，避免过度设计。
大模型生成 Playwright 测试用例的实际可用率约 60%，但算上审查和重写成本，净节省开发时间仅 29%。40% 的用例需重写，主要失败在 selector 失效、时序问题、断言质量差和逻辑错误。复杂业务场景下模型表现断崖式下跌，prompt 优化效果有限。团队转而采用分层策略，将模型定位为辅助工具，最终实现稳定且可预期的效率提升。
日均1.2TB日志写入场景下，引入Kafka作为缓冲层后，ES集群CPU使用率从72%降至31%，写入延迟P99从2.3秒收敛到180ms。Kafka利用零拷贝技术，以极低CPU开销实现高效数据转发，核心价值在于削峰填谷，避免ES因写入脉冲与合并操作叠加导致的性能断崖。整体资源账算下来，CPU净省29个核，磁盘成本因使用HDD而几乎可忽略，链路稳定性显著提升。