grpc
服务端：
定义一个业务逻辑服务，定义服务内的接口函数，参数，响应。
结构体 服务，实现接口函数，逻辑
new一个grpc服务，将逻辑服务注册到grpc服务
并起一个机器的tcp8081端口，绑到grpc服务上来
客户端：
先用grpc.dail建立连接，连接8081端口。用连接建立该服务客户端client，调用对应的服务函数即可互通
总结：用grpc起服务，用grpc客户端连接服务并调用服务内函数。
通过内部通信协议实现接口两端互通
pb二进制传输协议，http2协议（浏览器是http1协议，所以不向浏览器直接暴露调用。可以通过代理转换协议，浏览器可以直接调用，如grpc-web。
剩下的问题就是如何自己去实现服务发现。服务寻址都是可插件化的，用户按需实现。服务寻址包括服务发现、负载均衡、服务路由、熔断器等部分。
webservice，顾名思义这也是一种提供service的形式，只是它是通过http（web）来提供service而已。你可以基于http来提供你想提供的任意的服务，可以是rpc，也可以是restful。
thrift做后端rpc，nginx做web服务器， python后端php前端
理论而言，如果浏览器http可以直接通信grpc服务的话，grpc服务端是不是也可以直接作为web服务端来提供服务，而不需要nginx等来作为web服务器
grpc与ws的配合：
ws作为web调用前线，ws服务作为中转，grpc靠双向流接收ws发送请求并返回流给ws。ws利用自己的全双工响应到web客户端前端。
单单使用WS服务，多台集群支持是不是也能支持业务？那结合这样做的好处是啥？
小马想：如果多台机器的话如何保持不同机器连接之间的互通，比如A连接在机器a,B连接在机器b,如何A向B推送消息（A机器没有B的连接），利用全局的MQ支持广播，A通知B服务，B收到消息向b发消息。
如果我们将WS只做为转发层（保持着机器的连接并处理连接关系），grpc作为业务逻辑支撑层则可以任意拓展多台支持，而不必依赖于WS的机器数量（一台机器等于一个WS服务+业务逻辑，这是个机器数和业务机器的相关耦合）。而且这样在性能上或者服务治理上是不是也会更清晰呢？
网友评论