英文网站建设 江门,你访问的网站正在建设,网站数据没有更新,苏州高端网站制作公司首先根据 Socket.D 官网的副标题#xff0c;Socket.D 的自我定义是#xff1a;
基于事件和语义消息流的网络应用协议。官网定义的特点是#xff1a;
基于事件#xff0c;每个消息都可事件路由所谓语义#xff0c;通过元信息进行语义描述流关联性#xff0c;有相关的消息…首先根据 Socket.D 官网的副标题Socket.D 的自我定义是
基于事件和语义消息流的网络应用协议。官网定义的特点是
基于事件每个消息都可事件路由所谓语义通过元信息进行语义描述流关联性有相关的消息会串成一个流语言无关使用二进制输传数据支持 tcp, ws, udp。支持多语言、多平台断线重连自动连接恢复多路复用一个连接便可允许多个请求和响应消息同时运行双向通讯单链接双向互听互发自动分片数据超出 16Mb会自动分片、自动重组udp 除外接口简单是响应式但用的是监听与回调风格经典易用
Socket.D 是基于这些特性需求诞生的一种新型响应式网络协议。Socket.D 借鉴了很多其他协议发展过程中遇到的问题然后总结归纳进自己的实践当中。
基于 Socket.D 的一些主要特性分别做一下介绍并和 HTTP 之类的常见协议进行比较
Destination (URL) 显示连接地址Event 事件Multiplexed, Binary Protocol 多路复用的二进制协议Bidirectional Streaming 双向流Socket Resumption 连接恢复Message passing 消息传递模型Transport independent 与传输层解耦的应用层协议
一、两层路由能力
path 路由能力
Socket.D 是基于显示连接地址的可以实现像 http 或 websocket 一样的“频道”路由的效果。地址例
//模拟聊天场景的用户地址
sd:tcp://127.0.0.1:8602//模拟聊天场景的管理员地址
sd:tcp://127.0.0.1:8602/admin?uadminp1234event 路由能力
Socket.D 每个消息都有事件描述可以起到 path 或 topic 或 cmd 类似的路由效果。示例
//模拟消息中间件的发布指令
client.send(event.mq.publish, new StringEvent({userId:1}).metaSet(topic,demo));//模拟消息中间件的订阅指令
client.send(event.mq.subscribe, new StringEvent().metaSet(topic,demo));二、多路复用的二进制协议
现在 MultiplexingAsynchronousNon-blocking I/O 已经被说烂了基本上就是标配。这些特性意味着什么拿HTTP的发展史感受一下
从 HTTP1.0 到 HTTP3.0 在传输性能上的进步
在 HTTP1.0 时代每个 HTTP request 都要新建一个网络连接。网络连接不能复用HTTP1.1 时代一个网络连接仍然在一个时候只能负责一个 request但是整个 request/response 结束后连接可以得到复用。会有文章讲到 HTTP1.1 的核心是pipeline功能是也不是。pipelining 支持一个 TCP 连接上按照顺序连续发送多个 HTTP 请求而不需要等待前一个请求的响应但是它同时要求HTTP response也要按照请求的顺序逐个发送这对服务器提出了很多要求而且如果第一个响应很慢会拖累所有的后续响应(pipeling的队头阻塞所以事实上并没有得到多少运用。即使到今天大部分浏览器仍然是默认关闭HTTP pipelining功能的所以说HTTP1.1的主要突破还只是连接复用。HTTP2.0 是个飞跃开始支持 multiplexing一个TCP连接上可以同时承载多个request/response用这种方式替代1.1的pipelining提升HTTP的并行效果也自然不存在什么队头阻塞了。每一个request/response的信息流我们把它称作一个HTTP stream。这个时候一个HTTP client对于一个origin只需要建立一个TCP就够了。但是multiplexing带来了新的问题现在HTTP3.0也差不多了。2.0解决了1.1pipelining的队头阻塞问题但是却无法解决TCP本身的队头阻塞。而因为TCP/IP在内核协议栈中简直无法升级于是HTTP选择了QUIC作为新的传输层协议。 QUIC基于UDP在用户模式中实现了类似TCP的connection oriented的功能同时解决TCP的队头阻塞自带multiplexing等等。
所以HTTP/2具有的优点Socket.D 都有。另外Socket.D 是一个二进制协议也就是说在一个 Socket.D 连接上传输的消息体对数据格式没有任何要求应用程序可以为所欲为的压缩数据量的大小。
这样的二进制协议通常来说能给性能带来极大的提升但是产生的代价是网络中间件也会因为无法解读消息体中的数据丧失了在对具体应用流量进行监控日志和路由的能力。所以 Socket.D 通过把每个消息体分成 sid, event, data 和 metaString 的方式在保证高效传输的前提下也提供了暴露元数据给网络中间件的能力方便做语义处理同时还能路由消息。
frame: {flag, message: {sid, event, entity: { metaString, data}}}对于每个 data应用可以采用不同的序列化方法。metaString 则采用标准的 url queryString 的通用格式所有网络中间件通用。
data 一般作为应用本身需要传递的业务数据采取自定义的高效序列化方式且对网络基础设施不可见metaString 采用标准的 url queryString 的通用格式。在分布式传输的过程中这些中间件可以按需求对 metaString 进行读写然后调整路由。
三、双向流
上面提到HTTP这几年在传输性能上进步了很多。但说到底在应用层仍然仅支持client request/server response的交互模型。
这里一些同学可能有疑问比如
那HTTP/2推出的Server Push是什么
HTTP2.0推出了一个新的Server Push功能但这个功能通常只是用来提前将一些静态资源返还给用户而已。举个例子一个简单的网站有三个静态资源组成: index.html, index.css, index.js。 我们打开浏览器打开index.html就会发起一个HTTP request拿到index.html。在不使用server push的情况下我们要等浏览器解析出index.css 和 index.js之后才会再次向服务器发起请求。而运用server push服务器可以根据一些规则预知到浏览器也需要index.css和index.js并在客户端发送新的请求之前直接推送给该客户端。
所以这个功能的使用场景非常有限而且也不是一个真正双向的交互模式。
结论仅仅使用HTTP/2协议不在其基础之上再加一层其他协议的情况下是无法在应用层实现双向流的比如gRPC。
回到交互模式Socket.D 的几种模式
SendSendAndRequest - ReplySendAndSubscribe - Stream ReplyReplyReplyEndSession双向使用上面的发送与答复
通常来说越复杂的交互模式为了保存交互状态就需要占用更多的内存和计算资源。这也是为什么 Socket.D 会提供多种不同的 API。另外当 Socket.D 的 client 和 server 建立了长连接之后任何一方都可以是 Requester 或是 Responder。服务器也可以扮演 Requester 的角色首先发起 Request。
四、异步消息传递
Socket.D 还有另外一个非常重要的概念使之完全区分于类HTTP协议那就是异步消息传递。
不同于HTTP当中存在RequestResponse。Socket.D在网络传输上只有Frame这一个消息格式。有一个相同点是类HTTP协议通常拥有一个显式的destination (URL)使用起来会非常有亲切感和简单。
如果Requester的 Socket.D 消息R首先通过了一个网络中间件Broker那么请求者Requester并不关心该消息的最终目的地在哪里网络中间件可以全权负责路由模块的实现。该架构可以支持微服务也可以支持IOT场景等等。 这种架构很有意思不仅能在微服务中加入streaming支持还有如下特点
1.客户端也可以暴露服务
由于 Socket.D 的双向流特性和Broker建立连接的客户端即可以做Requester也可以做Responder比如图中的Device 1和Device 2虽然是移动终端或者IOT设备但仍然可以向其他设备或数据中心的主机提供服务
2.自动服务注册/发现
Socket.D 在成功建立连接时。如果该client想要暴露一个服务则在连接地址上给自己取个名字就像加入一个社交群让别人能At到你。连接成功建立之后Socket.D Broker可以直接通过记录网络连接状况来达到服务注册和发现的效果。通过’参数取名示例
sd:tcp://127.0.0.1:8602?demoapp3.基于消息 metaString 实现请求路由
前面说过Socket.D 是一个二进制协议但仍然可以在消息体中通过 metaString 来暴露信息给网络中间件。每个消息实体的 metaString 会带有‘’参数 告诉 Socket.D Broker 消息应该转发给谁从而实现路由效果。示例
client.send(/demo, new StringEntity().at(demoapp));与连接时给自己取名的 ‘’ 参数相乎应。取了名就能被“别人” at 到
4.暴露服务不需要Ip和Port
整个架构当中所有节点都只需要知道Broker的地址和服务端口即可。只要成功连接信息流就是双向的。Borker可以直接通过建立的Connection寻址服务节点所有的服务调用者都不需要知道服务暴露方的地址
而Broker又可以通过连接的 url 地址进行签权控制。
5.天生的中心化管理
管理微服务集群往往需要有一个中心化的控制中心在这个架构中 Socket.D Broker 就是自然而然的中心知道整个集群中所有的情况。
