👋

最近把金融数据服务从零迁到了 Kratos 框架上。选择 Kratos 主要看中它清晰的分层约定：api 层放 proto 定义，internal 下按 biz / data / service 分层，依赖方向单一，团队协作时不容易把业务逻辑写散。

proto 先行的开发方式一开始不太习惯，但好处很快显现：接口契约明确，生成的代码天然带参数校验骨架，前后端联调基本不需要口头对齐字段。配置管理用 protobuf 定义 conf，配合本地 yaml，环境切换只改一个文件。

踩过的坑主要有两个：一是 wire 依赖注入在新增 provider 后忘记重新生成，报错信息不直观；二是中间件顺序影响链路追踪的 span 归属，建议把 tracing 放在最外层。整体而言，对于需要长期维护的中型服务，这套约定的收益远大于学习成本。

大盘图表的数据加工天然是流水线式的：先查原始行情，再补齐缺口，然后计算衍生指标，最后按前端需要的格式裁剪输出。早期版本把这些逻辑堆在一个大函数里，每加一个指标都要小心翼翼地改动，回归成本很高。

重构时引入了责任链：每个环节实现同一个 Handler 接口，只关心自己的输入输出，链条的组装放在装配层统一维护。新增指标只需要写一个新的 Handler 并注册进链，原有环节完全不动。

值得注意的一点是异常路径的处理：链上任何一环失败，都应该带上环节名向上返回，而不是静默降级，否则排查数据异常时会非常痛苦。我们最终约定每个 Handler 的错误都包一层环节标识，日志里一眼能看出断在哪。

这个博客就跑在一台小服务器的 OpenResty 上。静态站点的部署本身很简单：一个 server 块、一个 root 指令就能跑起来，但想让体验好一些，还有几件小事值得做。

首先是开启 gzip，文本类资源体积能降到原来的三分之一左右；其次是给静态资源加上合理的 Cache-Control，HTML 走短缓存、带指纹的资源走长缓存。HTTPS 证书用 acme 脚本自动续期，配好之后基本不用再操心。

最后留了个心眼：默认的 server_tokens 会暴露版本号，生产环境建议关掉。整套配置加起来不到五十行，小站点用 OpenResty 托管确实省心。