本文属于专栏《构建工业级QPS百万级服务》

---

        提纲：

• 选择大概率能完成业务目标的工具
• 选择最适合的工具
• 制作最适合的工具

  ---

        本文所说的项目工具，泛指业务软件开发，所依赖的第三方提供的成熟的资源。包括但不限于开发语言、编辑工具、编译工具、三方库、方法论。使用项目工具的目的是为了按时高质量完成项目。

        第一阶段：选择大概率能完成业务目标的工具。这里为什么不是选择每个环节都用最优的工具，如果能做到，当然最好。但是一个人的知识是有局限的，而环境是不断变化的，做到每个环节最优，是需要大量精力，且需要承担风险的，另外不同的工具最擅长解决不同的问题，在工程初期，我们很难预估所有的关键问题在哪里。

        一个实践的例子是。在2020年的时候，我负责设计搭建一个新的服务，其中json解析的工具，我选择了RapidJson，而实际上性能显著提升的simdjson、yyjson在2019年、2020年相继出现了，从今天的角度回看，似乎我的选型是错误的。但是引入没有经过大量使用和验证的三方库，是有风险的，比如稳定性是否足够，在极端情况下的性能和正确性。这些都是需要花精力去验证的，项目中有很多依赖项，我的资源和时间不足以去做这么详细的论证，在大部分的工业软件中，我们也没法做到完美。选择大概率没问题的工具，适用于项目中大部分的环节。

        站在2024年2月的时间点，如果现在需要开发一个同样的服务，我是如何选择用什么库解析呢。首先目前各自的官网上，simdjson给的性能测试如图1，yyjson给的性能测试如图2。处于一个各自说自己好的情况，我相信测试结论，但是得到结论所使用的各自的应用版本和输入数据集不同，所以是各自有擅长的场景。截止2024年2月17日，simdjson在github的🌟是18.1k，而yyjson是2.8k，当然这不能说明simdjson比yyjson好，但是这能说明，大概率，在大部分场景simdjson比yyjson更好。

图1 

图2

        第二阶段：选择最适合的工具。选择大概率正确的工具，核心原因是因为资源和时间不够。但如果，我的服务大部分CPU都用在了json解析上，那大概率正确就不够了，在关键的环节，我们应该显著倾斜更多的资源。这个时候我们需要依赖我们的业务特性做详细的验证和测试，对含有大量的数字的json数据，与含有大量字符的json数据，不同库表现是不一样的。最好的办法是，积累大量的线上数据，做离线的情况下，做验证。有时候这种验证没有办法做，因为前置链路在架构设计初期，还没有数据，所以我们只能被迫回退到选择大概率能完成项目目标的工具。

        第三阶段：制作最适合的工具。市面上工具，是针对大部分问题的通用解决方案。不一定是每个业务的最优解，在深入解决业务关键问题的时候，认识到问题的本质，才能找到最合适的办法。比如在业务中，数据协议的作用是让上下游通过确定的协议解析网络的二进制数据，那就不要把视野局限在json协议上，自定义的二进制协议获取更快。比如业务中传输的一连串id，json格式为：{"UserIDs": "123,232,4434,2342"}。为了极致的性能我们的数据规格可以改为"4,123,232,4434,2342"，代表着，有4个id，分别是123,232,4434,2342。这里一共是1个2字节的数字，加上4个4字节的数字，解析的时候按字节解析。虽然我们自己设计的协议不通用，不易读，但是性能好，也就是在业务中，我们增加了程序复杂度，减少了资源成本。而这里没有最优，只有最适合。