关注点
对于微服务所用的通讯协议，我们希望有以下几点特性：
- 语意清晰
需要有微服务的DSL定义，清晰描述如何调用，入参出参，并能据此自动生成调用代码。否则，当系统架构越来越复杂，微服务数量越来越多的时候，选用HTTP之类的schemaless协议，将是一场灾难 - 向后兼容
接口需要增加字段时，必须向后兼容 - 支持多语言
支持多语言是必要的，毕竟大多时候，不同团队之间的语言很难统一 - 性能足够好
一次客户端请求可能会带来数十次的微服务调用，因此微服务的协议必须性能足够好 - 社区活跃
活跃的社区，大多数坑都已经踩过，也都有成熟的解决方案，可以节省大量排查问题的时间
性能对比
权衡
从以上图表来看，这几种rpc性能差距不算大。thrift几乎没有官方文档，社区不活跃，dubbo主要受众是java。rpcx生态略弱，没有大厂背书。
对于Go生态而言，相比之下grpc的文档更为丰富，社区更为活跃，且grpc基于http2实现，扩展起来更加方便。譬如我们基于nginx中转grpc服务的话，那么很多通用逻辑譬如缓存日志监控鉴权之类的都可以在nginx层面处理了，服务本身尽可能简单，只负责业务逻辑的实现即可。
服务定义
给个简单定义
syntax = "proto3";
package com.company.base;
option go_package="example";
service Example{
rpc Hello(HelloReq) returns (HelloRes){};
}
message HelloReq {
string name=1;
}
message HelloRes {
string msg=1;
}服务管理
- 集中式
当微服务数量越来越大，统一管理protobuf就愈发重要，不同人对于微服务的理解可能不同，那么实现上也会千奇百怪，如果我们可以在protobuf定义上进行统一管理，那么就能从根源上避免服务拆分设计不合理的问题。
基于uber/prototool可以很容易实现，它主要提供了以下的工具链：
- lint：自动提示命名错误
- format：自动格式化
- compile：自动生成代码
- ……
服务分层
对于微服务，我们应该预先划分好层次，避免服务互相依赖，举个例子如下：
原则是：
- 数据层和数据聚合层管理数据库
- 应用层和应用聚合层不允许直接操作数据库
- 只允许上层调用下层，下层不允许依赖上层
说人话
Talk is cheap, show me the protobuf！
该系列接下来的文章将会尝试基于grpc做一些微服务拆分说明
届时会把相关protobuf定义放在 hnlq715/proto 这个仓库，欢迎关注。
