这张是效率对比图 （从别人那A来的） 可以明显看出 pb的效率极高
可惜越是方便的东西 越是好用的东西 开始总不是那么顺手
pb需要编写 .proto文件 然后用google的编译器进行编译 (可以编译成很多语言 比如 c++和java等)
```
package tutorial
option java_package = "com.example.tutorial"
option java_outer_classname = "AddressBookProtos"
message Person {
required string name = 1
required int32 id = 2
optional string email = 3
enum PhoneType {
MOBILE = 0
HOME = 1
WORK = 2
}
message PhoneNumber {
required string number = 1
optional PhoneType type = 2 [default = HOME]
}
repeated PhoneNumber phones = 4
}
message AddressBook {
repeated Person people = 1
}
```
这是pb文件的写法 不详细描述 请翻墙看 https://developers.google.com/protocol-buffers/docs/javatutorial
刚开始走了很多歪路 因为其实百度 pb的资料 大多数都是从googl官网A下来 教你怎么编译的 然后有一些基础的写法 比如 required repeat optional 等 。。就是一些基础的用法 这并不能满足我们的需求
因为你如果要在java里面使用 （我用的最多的是给手机端写接口） ，那么你知道以上的并不能使用 需要知道更多的东西 比如 rpc 和 grpc 我之前一直不明白 看人家说的好高端
其实你只要涉及到写接口 那么你其实和rpc接触过很多很多 （请自行百度rpc）
RPC（Remote Procedure Call Protocol）—— 远程过程调用 协议
我粗鄙的理解就是 c/s 当远程的客户端（ios或者 android ）调用你部署在服务器上(可以是tomcat跑 或者 jetty 或者 。。。)的接口 那么就是 rpc 至于grpc 。。还是google吧 其实就是用pb来做序列化的 。。 其他还有一些变化
————————
我一直在用pb 然而ios的同事不会去用。。我也不知道该怎么和他说 (只会写pb的接口)所以就准备改成json的。然后碰到一系列蛋疼的问题 比如 乱码 比如 content-type 不是 application/json ，把我弄的欲仙欲死
现在开始说 换成json后出现的问题 首先是乱码 我在spring-mvc.xml里面已经配置了 消息转化器 并且 设置为 utf-8 然而还是 乱码 后来 web.xml里面也设置了字符过滤 还是不行
后来百度n多资料得知 其实是 spring框架内 StringHttpMessageConverter 类中，默认采用的字符集是 ISO-8859-1 。 而我接口返回的都是 string 自然而然乱码 。其实你只要封装一个类来做返回类型 就不会出现这样的问题 这种问题只有在string的时候才会出现
然而知道了问题的我 还是想返回string 因为感觉比较简洁 （其实不然。。。） ， 然后看解决方法
网上搜集的文章 http://blog.csdn.net/wangyangbto/article/details/48804155
http://blog.csdn.net/sen19910708/article/details/49933213
大致是两种 一种是重写那个 StringHttpMessageConverter 类 。
还有一种是 修改 spring配置里面的消息配置器 直接修改为 utf-8 (试过好像不行)
这个问题解决后 让ios测试接口 。。和我说协议不对 我一看
。。。 无语了。。然后开始找问题 。后来看到 原来你返回json 使用的是 @responsebody 这个注解 然而这个注解 会自动根据 浏览器 响应时候的 accept的第一个值作为 content-type。 如果你不指定的话
然后就只能在requestmapping上加上 @RequestMapping(value ="/test",produces="application/jsoncharset=UTF-8")
然后就不会出现这个问题了。。 但是难道每个都要这样写吗 我找遍了百度 好像还是不行
认命？ 其实可以写个 Inteceptor 然后在 spring配置里面加载 达到全局效果
————————————
暂时告一段落 其实 content-type的格式 不代表你所使用的技术 ios和我说 你怎么传回来的是 text/html 这都没人用了 如果你用这个 我还要json干嘛 其实这是误区 content-type只是你看的格式 不代表你传输中的序列化的格式 两者并无多大关系 不过他的网络协议框架 只会 json 那干后台的我们就只能改了。。
还有处理时间戳 办法很多 可以在字段上 注解 前提是你用的是 fastjson ， jackson也是可以的
关于 pb的 其他东西 https://github.com/jhunters/jprotobuf (这玩意好像是和百度有关系 好像是百度的人写的。。)不需要在写pb文件 可以直接实体类上 直接注解 达到一样的效果
文中提及了两个现象：
其实文章中也大致归结了原因，有两个：
最近负责了一个相对复杂的产品的设计，从一开始的设计原则就是：「面向未来服务拆分构建单体应用」，所以在最一开始结合产品功能进行和模块划分以及拓扑设计，按照如下规则：
当时考虑的点如下：
鉴权通过中间件实现，后续拆分成微服务之后，需要进一步前置到 Gateway，减少 Auth 服务的请求次数，因为该服务是整个系统最关键且不可降级的部分，所以需要尽量减少压力
除了上述限制以外，还引入了 Protobuf，吐出数据给客户端以及日志都会采用 pb 进行序列化，好处是方便字段管理，同时 pb 兼容生成 json，顺便也能降低书写成本，不用写一堆 json:"xxxx" 的 struct tag 。
文章随后又说到了从头构建系统的四种套路：
提到的第一种就是我这个项目提到的方法，但是随后 martin 说了一句：
嗯，其实就是他是对这种方案没有信心的，注释中提到因为他觉得不是任何一个系统都能拆分成微服务，这种上来就假设拆分成微服务的思路是有问题的。
当然啦，为什么我却用了这种方法呢，其实是因为我明确的知道这个系统可以拆分成微服务，基于经验。
当我们接触到一个自己并不是非常熟悉的系统或者领域的时候，确实不能在假设可以拆分成微服务的前提下，去设计系统，万一未来不能很好的划定边界，提早的拆分其实会给以后的灵活性大打折扣。
综上，新建立一个系统的时候，最好的方式不是从微服务开始，原因如下：
微服务架构本身是一件奢侈品，本身会带来的在研发，管理的成本就很高，应该把他作为 团队 逐渐变得非常复杂后，不得不考虑的一种架构方案，而不应该作为 start up 项目的推荐方案。
为什么说是「团队逐渐变复杂」而不是「系统逐渐变复杂」呢？因为如果是系统逐渐变复杂的情况下，无论是单体还是微服务，都需要你对于边界有个相对清晰的划分和理解，此时单纯的引入微服务架构，并不能解决根本的问题。只有当团队逐渐变复杂之后，微服务架构更多是通过服务之间物理上的隔离，提高了团队将整个项目变成大杂烩的门槛。
首发于 Medium： engineer-alex
