协议驱动开发漫谈（一）

协议驱动开发漫谈（一）

在前面的文章中，我们都把注意力关注在了具体的工具使用上，没有从方法论和必要性上讨论过协议驱动开发（Schema Driven Development）这种开发模式。

面临的问题

我们开门见山，在没有引入SDD之前，我们面临的主要问题有哪些。

1. 我们缺乏强类型的接口定义和数据定义。 伴随着SDD的引入，我们一定会引入IDL，即Interface Definition Language。在以前，如果我们不仔细阅读源代码，我们很难知道一个API具体在做什么，如何传递消息和响应调用。更严重的问题是由于接口定义不是强类型的，我们无法添加协议校验，也就无从得知一个接口的修改会不会导致服务不可用，为服务的快速上线增加了难度和风险。
2. Restful无法提供RPC接口。 如果我们的后端服务提供的是RESTful的接口，会面临几个问题，其中之一就是内部服务之间的接口也必须是RESTful。但是RESTful接口调用更多的是面向资源的CRUD，而RPC接口更多的是面向Action来进行定义，并不能真正完全满足业务诉求。我借用Roy的一句话，即： The Representational State Transfer (REST) style is an abstraction of the architectural elements within a distributed hypermedia system. - Roy Thomas Fielding. 我会在一片专门的文章中介绍Restful和RPC的特点。
3. JSON的消息体体积很大，效率低下。 JSON的消息体是基于string，而RPC消息体是序列化后的二进制，大小区别可能会接近90%。这对于网络压力和高性能服务来说有很大的影响。

我们的方案

我们通过引入SDD（即协议驱动开发）来解决以上提到的问题。 我们希望通过定义强类型的接口和消息数据，在大多数场景中前后端的调用间实现RESTful接口，减少前后端开发的协同成本；在后端服务调用间，尽可能的实现RPC服务调用，减少因为接口变动导致的生产事故。

1. 支持IDL，当前支持protobuf，后期考虑增加基于facebook的thrift。
2. 支持基于IDL的接口变更检查，提早发现breaking change（规划中）。
3. 支持基于gRPC的代码生成能力。
4. 支持gRPC-gateway，方便开发设计API gateway。
5. 支持openAPI生成能力（规划中）。
6. 支持DevOps平台对接（规划中）。

在后续的文章中， 我会陆续介绍Skemaloop的每一个细分领域，帮助大家逐步了解DevX如何在你的项目中发挥作用，提高各位同学的工作效率和系统稳定性。