GRPC 和 http

把请求发给server，client接收数据 http过于复杂，写错一个单词整个请求都是错的
1）

协议 HTTP1.0

TCP是传输层协议，而HTTP是应用层协议
HTTP是要基于TCP连接基础上的

服务器地址 api.coolcar.cn
路径 /trip
参数
数据类型
数据编码 JSON
安全性 header with token
错误处理 http 标准状态码

2）

GRPC 优势

协议是 HTTP2.0
二进制 — 高效的传输
流式传输 不用等都做完再发过来，做多少传过来多少 —加速
多路复用 http底层是tcp，三次握手耗时，grpc复用连接(http1 必须等请求发完回来，才能发请求2，grpc可以一起发)
安全性提升

方法一律是POST
路径 服务器地址/ServiceName/MethodName
参数 body
安全性 http2协议本身的安全性 token放header里
数据 二进制流
数据结构 ProtoBuf 二进制数据使用ProtoBuf编码

proto环境安装后，proto文件可以转化成任何语言的文件，然后其他脚本引入文件就可以用了，比如按照约定的struct个每个值赋值，打印出来，或者把struct做成二进制流用proto.Marshal() 客户端proto.Unmarshal()进行二进制转成struct。还可以json.Marshal() 转换成json格式

proto buffer 里面结构体的所有字段都是可选的，字段不填服务也不会挂掉，不填就是0

使用场景

1、grpc主要用于后端服务器之间通信
2、浏览器，小程序最方便是发http请求，他没有能力与服务器建立tcp的连接

HTTP RPC REST三种风格的api

GRPC gateway

http设计之初是为了传输文本，传二进制乏力，所以用json，走gateway好
json转换成二进制流（protobuff 和 json 可以互转 用Mashal）
集群里面的内网和外网之间需要Gateway 或者 Web Proxy 这种反向代理转发来自外部信息

微服务

1、那么多微服务之间是怎么通信的？通过服务治理，统管网络请求
2、上百个服务地址在哪里呀？人工去嘛？当然不是，服务发现
3、出现热点事件，一大堆用户涌进来，顶不住怎么办？动态扩容
如果A服务器自己没事儿，给B发了巨量消息，B扛不住，告诉A你给我停 熔断，或者少发点 降级

因为系统复杂性，所以需要上面黄色特性
在黄色特性基础上弄蓝色特性，容易
因为我想没背景色的特性，所以用微服务，所以要用黄色特性来使系统能工作

怎么划分微服务，划分几个微服务

根据微服务间耦合少分开

WebSocket

1、只需要完成一次握手，两者就可以创建持久连接，两者都能主动发送和接收消息
应用场景：带实时的 应用场景介绍