rpc

https://blog.csdn.net/cjf_wei/article/details/78763517 https://blog.csdn.net/zkp_java/article/details/81879577 RPC基本原理 大部分的RPC框架都遵循如下三个开发步骤： RPC通信过程如下图所示 通信过程包括以下几个步骤： 图中Your Code是用户实现的业务逻辑，接下来的FooService.Client和Foo.write()/read()是thrift根据IDL生成的客户端和服务端的代码，对应于RPC中Client stub和Server stub。TProtocol 用来对数据进行序列化与反序列化，具体方法包括二进制，JSON 或者 Apache Thrift 定义的格式。TTransport 提供数据传输功能，使用 Apache Thrift 可以方便地定义一个服务并选择不同的传输协议。 如下图所示为thrift的网络栈结构 来源： https://www.cnblogs.com/Lee-yl/p/11526174.html

I am trying to use the hessian j2me implementation @ http://hessian.caucho.com/ using java me sdk 3.0. http://hessian.caucho.com/doc/hessian-overview.xtp#Hessian%20Client%20for%20a%20cell-phone mentions the usage for j2me. The application builds without any errors/warning. But, the moment the line where MicroHessianOutput is instantiated is hit, a ClassFormatError ( java.lang.Error: ClassFormatError: 56 ) is thrown. Heres the trace : TRACE: <at java.lang.Error: ClassFormatError: 56>, startApp threw an Exception java.lang.Error: ClassFormatError: 56 - alert.AlertDemo.showOption(), bci=26 -

I use pyro for basic management of parallel jobs on a compute cluster. I just moved to a cluster where I will be responsible for using all the cores on each compute node. (On previous clusters, each core has been a separate node.) The python multiprocessing module seems like a good fit for this. I notice it can also be used for remote-process communication . If anyone has used both frameworks for remote-process communication, I'd be grateful to hear how they stack up against each other. The obvious benefit of the multiprocessing module is that it's built-in from 2.6. Apart from that, it's hard

文章目录 概要 1. Class Worker 1.1 Class Worker之onStart() 1.2 Class Worker之receive() 1.3 Class Worker之receiveAndReply() 1.4 Class Worker之onStop() 2. Object Worker 2.1 Object Worker之main() 2.2 Object Worker之startRpcEnvAndEndpoint() 总结 概要 上一篇文章 Spark RPC之Master启动并提供服务 介绍了standalone模式下Master端的实现，接着我们看下Worker端的实现，以及Worker如何向Master启动，注册及发送心跳 1. Class Worker 查看Worker，和Master一样，Worker也是RpcEndpoint的子类，所以接下来查看RpcEndpoint生命周期的四个方法: onStart -> receive(receiveAndReply)* -> onStop。 1.1 Class Worker之onStart() 如果配置spark.shuffle.service.enabled=true，启动独立的shuffle service。 启动Worker的webUI，默认端口8081。 本篇的第一个重要部分

随着分布式架构运用的越来越多,RPC框架成为了我们不得不掌握的知识,这里一步一步来手写一个简单的RPC框架,以博文作为记录及自我监督。 首先是技术选型,这边我选用的是当前比较流行的Netty+Zookeeper来实现,通过zookeeper的特性来实现服务注册与发现,通信则使用netty框架。 这里贴出github代码地址,想直接看代码的可以直接下载运行: https://github.com/whiteBX/wrpc 这里先来讲服务注册发现原理: 利用zookeeper的创建临时节点和watcher机制,可以做到在一个服务下注册多个服务器地址,并且在节点发生变动时通过watcher动态更新服务器列表,来达到在新增/修改/删除时自动注册发现/删除/更新服务器连接信息 .这里说一点,zookeeper的增删改操作会交由leader去处理,所以这里不用担心并发问题. zookeeper相关代码如下: public class ZKClient { /** * 获取zookeeper连接 * * @param connectString * @param sessionTimeout * @return */ public ZooKeeper newConnection ( String connectString , int sessionTimeout ) { ZooKeeper

上一篇实现了服务注册发现和基本的字符串通信功能,这一篇则是实现我们平常使用RPC框架的使用类来调用的功能。 实现consumer端通过接口类来调用远程服务, 主要核心在于使用动态代理和反射 ,这里就一步一步来实现。 这里贴出github代码地址,想直接看代码的可以直接下载运行: https://github.com/whiteBX/wrpc 首先来看consumer端代码,RPCConsumer完整代码如下: public class RPCConsumer { /** * url处理器 */ private UrlHolder urlHolder = new UrlHolder ( ) ; /** * netty客户端 */ private NettyClient nettyClient = new NettyClient ( ) ; /** * 远程调用 * * @param appCode * @param param * @return */ public String call ( String appCode , String param ) { try { // 从zookeeper获取服务地址 String serverIp = urlHolder . getUrl ( appCode ) ; if ( serverIp == null ) { System .

上一篇实现了服务的负载均衡，本篇带来链路追踪。 关于链路追踪，大部分都是参考了谷歌的dapper论文： https://bigbully.github.io/Dapper-translation/ 。 通过论文总结，其中span的核心元素为：traceId，name，spanId，parentSpanId，其他则根据自身业务需要来定义即可。 链路追踪核心原理为 通过一个全局的traceId作为依据，在调用服务时为每个服务分配spanId，并记录操作名name，在调用RPC服务时将带有这些属性的span随同请求一起传递，并在关键节点将span数据通过尽量小影响原服务性能的方式传递给我们自己的trace采集服务 ，采集服务存入数据并通过traceId以及spanId和parentSpanId的关系梳理出调用链并做图形化展示。这里给服务器传递span有很多中模式，其中包括： 直接通过RPC服务调用，写入本地磁盘通过另外的进程读取磁盘数据写入远程服务器，写入缓存传输，发送消息 等等方式，可以根据自己的需要选择，原则上是尽量少的影响服务本身性能。 本篇只带来客户端采集span的过程，trace服务器采集和分析展示链路的过程这里省略。 这里还是贴出github代码地址,想直接看代码的可以直接下载运行: https://github.com/whiteBX/wrpc 首先来看我这里的span定义

上一篇实现了服务的链路追踪,本篇带来限流。 关于服务限流，比较流行的是 1： 令牌桶算法 ：桶算法的升级版，实现简单，应对热点请求效果更理想。 2： 动态限流 ：根据实时的统计当前时间段请求响应时间来动态调整限流数量，实现复杂，但应对各种情况效果更好。 这里还是贴出github代码地址,想直接看代码的可以直接下载运行: https://github.com/whiteBX/wrpc 本篇带来令牌桶实现限流的实现，核心代码很简单，主要就下面一个类: public class ConsumerLimiter { /** * 存放限流器 */ private ConcurrentMap < String , RateLimiter > rateLimiterMap = new ConcurrentHashMap < String , RateLimiter > ( ) ; /** * 限流 * @param appCode * @return */ public boolean limit ( String appCode ) { RateLimiter rateLimiter = rateLimiterMap . get ( appCode ) ; if ( rateLimiter == null ) { rateLimiterMap . putIfAbsent ( appCode ,

上一篇实现了服务的限流,本篇来实现服务的熔断。 首先还是贴出github代码地址,想直接看代码的可以直接下载运行: https://github.com/whiteBX/wrpc 在现在的微服务架构下，由于服务众多，调用链路长，很可能其中某个服务有时会出现异常导致服务不可用，例如发布导致bug、机房网络问题等，这种时候如果没有一种保护机制的话，很容易引起服务雪崩。这个时候就引入了服务熔断，本篇就来实现一个简单的熔断器。 首先我们定义一下熔断的状态，如下图： 此图中标注了我们熔断器的三种状态： 全开 半开 关闭 。 他们的流转过程为： 初始时为关闭状态。 当遇到错误到我们预设的阈值比例后转换为全开状态。 经过一定时间后，熔断器变为半开状态。 半开状态时允许通过一个请求，此请求成功则转为关闭状态，失败则变为全开状态。 接下来看代码实现： public class CircuitUtil { // 达到默认请求基数才判断开启熔断 private static final int DEFAULT_FAIL_COUNT = 5 ; // 半开转换为全开时间（毫秒数） private static final long DEFAULT_HALF_OPEN_TRANSFER_TIME = 10000 ; // 默认失败比例值开启熔断 private static final double