Sniper 是我为部门设计的轻量级 go 业务框架。经过两年的平稳运行，至少在一定程度上印证了我当初的一些见解。现整理出来供大家参考。 涛叔：Sniper框架两周年回顾 项目源码可以从 github 获取 bilibili/sniper ? Sniper 起源于一项新业务。在转岗之前，我一直在 L 部门写 PHP 代码，遇到过如下问题： 基于 TCP 的 RPC 协议，我们都称之为 Weisai-RPC 手工维护 RPC 文档，难以及时更新 手写代码处理 RPC 入参，难以保证参数类型，如数字 1 和字符串 "1" 的区别 无法方便地查询一个请求对应的所有日志 服务拆分得很细，难以进行调用链路追踪 使用 JSON 做为配置，难改难认 难以监控服务运行状态 代码分层标准不统一 大约在 2018 年的六月底，我得知要去新的 C 部门做新业务。没有任何历史包袱，我马上着手准备，希望能全方位的解决上面提到的问题。 Go 语言 首先要解决语言选择的问题。PHP 是最熟悉的，但从过去的经验来看，无论从性能还是从代码可维护性方面考虑，PHP 都不是一个好的选择。当时有两种选择，一个是 Java，另一个是 go。平心而论，Java 是要比 Go 要成熟得多。但 Go 更加简单轻便，从 PHP 过渡成本更低。而且当时公司正在推动用 Go 重写原有的 Java 项目。自然就选了 Go。 我两年后又写了一管关于 go 与 php 对比的文章，大家可以参考一下 涛叔：go 是更好的 php RPC 协议 有了语言，接下来就要确定通信协议。首先不要使用 REST 风格接口。 REST 中看不中用。REST 的核心是资源和状态，所有的变更都对应状态的转变。 对于简单的场景，REST 看似完美，如： GET /user/123 表示查询。 但如果是发送一条短信呢？一种方案是使用 POST /sms 表示创建一条 短信资源 ，另一种方案则是 POST /sms:send 直接发送。 但不管哪种方式，都不如 RPC 调用直观，其原因有二： 一是 http 的方法（GET, POST, PUT, DELETE 等）太少，基本都是面向静态资源的，表达能力有限 二是将业务过程转成资源状态变化本身就比较烧脑，而且存在无法转化的场景 REST 还有一个比较大的问题就是 u...
评论