python 网站开发 环境,网站域名的所有权,原江苏省建设厅网站,那些域名可以做后缀做网站RPC序列化 任何一种序列化框架#xff0c;核心思想就是设计一种序列化协议#xff0c;将对象的类型、属性类型、属性值一一按照固定的格式写到二进制字节流中来完成序列化#xff0c;再按照固定的格式把数据一一读取出来#xff0c;通过这些数据信息创建出一个新的对象核心思想就是设计一种序列化协议将对象的类型、属性类型、属性值一一按照固定的格式写到二进制字节流中来完成序列化再按照固定的格式把数据一一读取出来通过这些数据信息创建出一个新的对象来完成反序列化。 public class Book implements Serializable {int id;String name;String title;String tag;String content;// 其他略
}有哪些序列化框架 如何选择RPC序列化框架 结论首选Hessian和Protobuf因为他们在性能、时间开销、空间开销、通用性、兼容性和安全性上都满足了我们的要求 安全性首要考虑如果序列化存在安全漏洞那么线上的服务就很可能被入侵JDK原生序列化存在漏洞兼容性序列化协议在版本升级后的兼容性是否很好是否是跨平台、跨语言等通用性能够对任意类型进行序列化和反序列化不会出现服务接口方法加一个某种类型的参数之后服务突然调用方不能正常调用的情况性能、效率序列化与反序列化过程是 RPC 调用的一个必须过程性能和效率势必将直接关系到 RPC 框架整体的性能和效率空间开销也就是序列化之后的二进制数据的体积大小。序列化后的字节数据体积越小网络传输的数据量就越小传输数据的速度也就越快在RPC调用中直接关系到请求响应的耗时
使用RPC框架的时候需要注意
避免对象构造得过于复杂属性很多并且存在多层的嵌套避免对象过于庞大大字符串超大数组等避免使用序列化框架不支持得类型作为参数传递防止对象有复杂得继承关系 子类进行序列化的时候会一步步往上把父类也序列化了如果父类中的某些字段不需要被序列化可以使用transient关键字修饰这些字段使其在序列化过程中被忽略。
小结 通信协议及操作系统的IO模型 在应用层常见的就是HTTP协议对于HTTP协议来说也有不少优缺点
共有协议通用便于跨系统的通信各语言适配完善解析库成熟有利于构建异构系统HTTP/1.1协议偏重体积偏大性能较低 HTTP/1.1是用AXCII码来表示的内存占用还是较大 但是如果自研协议也有不少优缺点
协议私有通信两端要一致需要自研协议的解析库可以做到协议精简性能和安全性更高 网络IO其实就是计算机内存和外部设备之间拷贝数据的过程对于单个进程是无法直接要到网卡的数据的但是Linux kernel可以在内核当中会存在一片内核缓冲区内核会给上层提供一些列的系统接口来刷走这片数据。 操作系统中的IO模型 同步阻塞IO同步非阻塞IOIO多路复用信号驱动IO异步IO 现在几乎都使用IO多路复用模型 小结 超时重试与时间轮算法 什么是超时重试 当其中某个提供者服务挂掉了之后直接把错误返回给用户是不太好的所以会有一个兜底的策略也就是超时重试可以去向其他的提供者再一次发起请求。 如何检测请求是否超时 客户端超时设置客户端在发送RPC请求时可以设置一个超时时间如果在规定时间内未收到响应则认为请求超时。通常在客户端发送请求后会启动一个定时器来监控超时一旦超时则可以进行相应的处理比如重试或者返回错误信息。服务端超时处理服务端也可以设置处理请求的超时时间如果服务端在规定时间内未能处理完请求并返回响应可以直接返回超时错误给客户端。中间件/代理层管理在RPC框架中通常会有中间件或代理层来管理请求的转发和响应这些中间件可以负责监控请求和响应的超时情况并进行相应处理。统一超时管理有些RPC框架会提供统一的超时管理机制用于集中管理请求的超时设置和处理。通过这种机制可以方便地对所有请求进行统一的超时处理确保系统的稳定性。
我们把所有的超时请求全都集中管理起来如下图所示 那么能否给出一种解决方案可以减少遍历的次数提高效率呢
时间轮算法 在时钟轮机制中有时间槽每个槽位代表一个时间时间指针按照时间单位走动将任务放到对应的时间槽位上当时间指针走到改槽位的时候就可以拿出来执行。 小结 熔断、降级、限流 怎么判断需要进行熔断 通过计算一段时间内服务的可用率/失败率 那么熔断工作什么时候开始的呢又是什么时候结束的 当可用率过低/失败率过高的时候会对服务进行熔断熔断的时候会设置一个熔断时间当超过熔断时间的时候系统会尝试调用一下这个服务如果调用成功了就可以结束熔断反之继续熔断。 为什么有了熔断降级还需要限流 在实际的生产环境当中服务发生的一系列问题很大可能是由于高并发而引起的这也就需要业务方要能够进行自我保护从而保证在搞并发的情况下系统依然可以稳定运行。 限流的作用是用来限制其请求的速率保护后台相应服务以免服务过载导致服务不可用的现象出现。 常见的限流算法
令牌桶算法 我们会有一个生成令牌的工具去不断生成令牌然后把令牌放入令牌桶当中如果桶中的令牌用完了就不能再访问了但是这个方法面临高并发的场景时就有可能只能把服务打挂掉。
漏斗算法 无论流量有多大我一次只放一定量的请求进来可以达到削峰的效果。
滑动窗口算法 限定在一定时间内我只接受多少请求多了的不接收。
小结
