滴滴业务研发的精益实践

桔妹导读：”精益生产“起源于丰田生产方式，它致力于在大量生产中实现多品种和高质量产品的低成本生产，随着在制造业取得巨大成功，精益思想也逐步渗透到了各行各业，其中在软件行业就演化出了很多新的理论，比如精益研发、DevOps等。精益生产坚信前置时间(Lead time)是提升产品质量、客户满意度和员工幸福感的最佳度量指标，而业务研发正好是处在前置时间中，并且占有重要的地位，所以本文将从从业务研发侧来聊聊精益实践。

1. 思考

说到精益就不得不提DevOps，它融合了精益和其他各种理论，从思想、方法论到实践无所不谈，我们不可能面面俱到，只能从自身的实际情况出发持续不断的优化，这也正是精益思想里表达的”为下游优化我们的工作“。在实际情况中，很多好的基础服务得不到推广，同时业务团队也不清楚怎么利用好基础服务，导致很多重复性工作和资源浪费。

我们通过分析DevOps各个环节，从实际需求入手，通过规范、引导、封装和创造基础服务来友好的支持业务需求，同时根据业务需求推动和优化基础服务的不足，达到一个良性循环，如果把业务团队和基础服务团队比作两个大的齿轮，为了让他们朝着一个方向转动，就需要一个介轮，而我们做的就是介轮的工作。下面我会从编码、测试、监控和生态四个方面来进行详细介绍。

2. 实践介绍

▍编码

定规范

在我们的实践中，第一条做的就是定规范，为什么把定规范放到这么重要的位置，这就像交通规则一样，没有规范，交通很容易瘫痪，更别说在上面行驶更快的汽车了。包管理就是我们实践的一个规范，我们遵循 SemVer 规范，从刚开始混乱的代码里抽离出一个个的库，并且按照 MAJOR.MINOR.PATCH 版本号规则来进行升级，同时业务在进行升级的时候自动更新到最新的兼容包，这样就可以实现 bugfix 和新功能等兼容升级能快速上线，而非兼容升级可以慢慢灰度。

得益于包管理的基础，我们开始抽象一些通用组件，慢慢形成了接下来要说的"搭架子"，也就是框架。

搭架子

通过整合所有基础服务的 SDK 和基础功能组件，就逐渐演化成了一个公司级的定制框架，我们叫她 NUWA (女娲)框架。她减少了很多重复性的工作，比如技术改造、功能复用、优化化升级等等，对业务来说都是透明的。在框架中最核心的部件就属 RPC 了，因为它是微服务治理最重要的抓手，但由于历史遗留问题，线上存在多套通信方式：HTTP、Thrift、GRPC 等等，同时也存在多语言的问题(目前主要是 Golang 和 PHP )，尤其 php - fpm + Nginx 方式，在 RPC Server 方面，几乎没有什么开源解决方案，通过各方面考虑，同时借鉴 grpc-gateway 方案，我们实现了如下解决方案：

方案同时支持了 GRPC 和 HTTP 两种通信方式，但放弃了 Thrift，这主要从三个方面考虑：对现有基础服务的兼容性（比如网关支持的协议有限）、更灵活的透传机制( Thrift 没有Header 头，无法透传一些非业务参数，比如 Traceid，当然我知道有改造办法，但成本比较大)、对未来技术的兼容性（开源的 Service mesh 把 HTTP 和 GRPC 作为一等公民）。

▍测试

由于我们处在业务层，相当于后端服务的最上层，所以在测试上面临的问题会更严重一些，因为依赖方会更多，不管是从 mock 和搭建环境上成本都是最大的，所以针对重构类的测试，我们开发了流量录制&回放，免去了 mock 和构建环境的成本，同时实现了更精准的测试。

我们知道在测试环境中，线上仿真环境一直是一个高成本环境，除了机器资源，调用闭环（环境之间调用隔离）也是一个难题，如何实现复用一套稳定环境（pre）的情况下构建出每人一套的环境，并能实现调用闭环，我们在原来仿真环境的基础上新增了一个 sim sidecar，它把全链路追踪中的 Traceid 当成了数据通道，通过解析 Traceid 实现路由分发，最终实现以上目标。