首先，buf是一个什么样的工具？我提取了三个关键词：
Protocol Buffers- 底层的技术基础是Google的protobuf语言API Lifecycle- 目标是管理API接口的全生命周期，重点是初次发布与后续更新Team- 强调的是团队协作，解决人与人之间沟通的问题
要说清楚buf这个项目，就离不开API接口开发的历史演进。今天，我将挑选官方介绍的三个重点，让大家更好地了解buf要解决的问题。
两个角色：Producer & Consumer
对于一个API服务，有2种最重要的角色：
- Producer - API服务提供方，也叫被调用方
- Consumer - API服务的使用方，也叫调用方，往往具有多个
要调通一个API不难，但要做好，有很多问题需要解决，尤其如下三个问题：
- 理解成本：API接口怎么理解？提供文档或SDK就能满足吗？
- 迭代问题：Producer紧急修复了问题、更新了接口，怎么通知到各个调用方？
- 重复开发：多语言、多框架的情况下，怎么减少重复度高的编码工作，如定义数据结构？
关于API的设计与实现的细节，不同团队有自己的方案，我们来看看buf提供的亮点：
- Producer
- 遵循Best Practice来使用
protobuf的API - 分发API到各使用方，让对方及时更新
- 集中式地管理API文档
- 遵循Best Practice来使用
- Consumer
- 根据
protobuf定义，快速开发 - 用工具减少歧义
- 可生成的CLI/定制插件/mock服务/压力测试等特性
- 根据
以上特性看起来很酷，核心方向依旧是：提高Producer和Consumer的效率与协作。
方案1 - RESTful
官方对RESTful接口的概括如下图：
RESTful API虽然已经被公认为一种很好的API设计标准，但在实际开发过程中，各有各的理解。所以，RESTful更像是一种风格趋势，但无法形成标准，这就对Consumer在协作开发时带来了难度：
- 理解成本：标准不统一，调接口类似于黑盒测试
- 实现方式：不同调用方有自己的实现，对后续维护带来很大成本
我们可以通过以下两条路径进行改善：
- 内部统一框架：利用相关的工具，强制约束接口设计
- 自动生成SDK：调用方统一用SDK收敛
这两点从技术实现来看并不难，但挺考验研发团队的能力，一不小心就造了个很不好用的轮子。对于大部分开发者来说，更希望找一个成熟的、长期维护的方案。
方案2 - Protocol Buffers（无Buf）
接着，我们来看看社区中原生的Protocol Buffers的方案：
本方案最大的变化，就是有了一个协议的标准传输介质 - Protobuf Schema。它规范了Producer侧的接口实现，并且利用protobuf提供了跨语言的方案。
但是，从图中可以看出，传播Protobuf Schema依然是一个高频出现问题的地方：
- Producer - 设计与发布API没有支持，全靠人工、甚至是邮件沟通
- Consumer - 对
protobuf没有统一管理的手段，如版本依赖、SDK生成等
不过，Protobuf对API接口设计提供了很关键的基础能力 - 有了切实可落地的标准，并且实现了跨语言代码生成的基础。接下来，就是要解决 最后一公里 的问题了。
方案3 - Protocol Buffers（有Buf）
Buf方案，核心是对Protobuf Schema的管理与扩展
从Buf提供的核心能力来说，主要分为3块：
- 语法规范 - 从语法上规范API设计，遵循其
Best Practice - 代码生成 - 包括Producer与Consumer侧的代码自动生成
- 依赖管理 - 对各Consumer的依赖进行统一管理
我认为核心在于第一点：规范化、标准化的程度越高，自动化的能力自然就越强：
第二、三点，往往会根据团队情况，需要定制化。
其余能力是偏插件化的功能，就不重点讲了。
小结
今天，我们通过对3个API方案的介绍，对Buf套件有了初步的了解。如果用一句话概括：
Buf重点是通过对Protobuf Schema的规范化，提供代码生成、依赖管理等一站式的API接口管理方案，来保证开发效率与团队协作的收益最大化。
Github: https://github.com/Junedayday/code_reading
Blog: http://junes.tech/
Bilibili: https://space.bilibili.com/293775192
公众号: golangcoding
