近期开始研究分布式架构,会涉及到一个最核心的组件:RPC(Remote Procedure Call Protocol).这个东西的稳定性与性能,直接决定了分布式架构系统的好坏.RPC技术,我们的产品中其实早就已经应用.但是产品中经常出现访问失败等错误,在没有细致研究的情况下,大家怀疑是选用的RPC组件不稳定引起.今天也借这个机会给这个组件正名一下吧. 选型的思路很简单,先baidu找业界最有名的RPC框架,看各种牛人的的对比分析,然后到github上搜索排名和评价靠前的组件,确定一个选型的大致

RPC(Remote Procedure Call,远程过程调用)框架是分布式服务的基石,实现RPC框架需要考虑方方面面.其对业务隐藏了底层通信过程(TCP/UDP.打包/解包.序列化/反序列化),使上层专注于功能实现:框架层面,提供各类可选架构(多进程/多线程/协程):应对设备故障(高负载/死机).网络故障(拥塞/网络分化),提供相应容灾措施. RPC节点间为了协同工作.实现信息交换,需要协商一定的规则和约定,例如字节序.压缩或加密算法.各字段类型.通信协议的应用随处可见,例如我们对可选信息或

Motan 是微博技术团队研发的基于 Java 的轻量级 RPC 框架,已在微博内部大规模应用多年,每天稳定支撑微博上亿次的内部调用.Motan 基于微博的高并发和高负载场景优化,成为一套简单.易用.高可用的 RPC 服务框架. Motan 功能特点:简单.易用.高可用 无侵入集成.简单易用,通过 Spring 配置方式,无需额外代码即可集成分布式调用能力. 集成服务发现和服务治理能力,灵活支持多种配置管理组件,如 Consul.ZooKeeper 等. 支持自定义动态负载均衡.跨机房流量调整等

1.背景 最近在搜索Netty和Zookeeper方面的文章时,看到了这篇文章<轻量级分布式 RPC 框架>,作者用Zookeeper.Netty和Spring写了一个轻量级的分布式RPC框架.花了一些时间看了下他的代码,写的干净简单,写的RPC框架可以算是一个简易版的dubbo.这个RPC框架虽小,但是麻雀虽小,五脏俱全,有兴趣的可以学习一下. 本人在这个简易版的RPC上添加了如下特性: * 服务异步调用的支持,回调函数callback的支持 * 客户端使用长连接(在多次调用共享连接) *

RPC框架:gRPC.Thrift.Wildfly.Dubbo 原文链接:http://www.open-open.com/lib/view/open1426302068107.html gRPC是Google最近公布的开源软件,基于最新的HTTP2.0协议,并支持常见的众多编程语言. 我们知道HTTP2.0是基于二进制的HTTP协议升级版本,目前各大浏览器都在快马加鞭的加以支持. 我们可以设想一下,未来浏览器支持HTTP2.0,并通过现有开源序列化库比如protobuf等,可以直接和各种语言的

Google 刚刚开源了grpc,  一个基于HTTP2 和 Protobuf 的高性能.开源.通用的RPC框架.Protobuf 本身虽然提供了RPC  的定义语法,但是一直以来,Google 只开源了Protobuf 序列化反序列化的代码,而没有开源RPC 的实现,于是存在着众多良莠不齐的第三方RPC 实现,不过我在项目中采用WCF搭配Protobuf是一个很不错的RPC实现,Google这个框架是是基于HTTP2的,这是他有特色的地方,带来诸如双向流.流控.头部压缩.单TCP连接上的多复用

接前一篇rpc框架之HA/负载均衡构架设计 继续,写了一个简单的thrift 连接池: 先做点准备工作: package yjmyzz; public class ServerInfo { public String getHost() { return host; } public void setHost(String host) { this.host = host; } public int getPort() { return port; } public void setPort(i

thrift.avro.grpc之类的rpc框架默认都没有提供负载均衡的实现,生产环境中如果server只有一台,显然不靠谱,于是有了下面的设计,这其实是前一阵跟北京一个朋友在qq群里交流的结果,分享一下: 主要思路: 1.rpc server端以多实例方式运行(多端口或多机部署均可),启动时每个实例向zk集群以临时节点方式注册(这样,遍历zk上/server下有多少个临时节点就知道有哪些server实例在线) 2.客户端自己实现一个连接池,连接池初始化时,从zk将在线的server实例信息同步

grpc是google在github于2015年开源的一款RPC框架,虽然protobuf很早google就开源了,但是google一直没推出正式的开源框架,导致github上基于protobuf的rpc五花八门,国内比较著名的有百度的sofa-pbrpc,但是遗憾的是soft-pbrpc没有对应的java实现版本.rgpc还有一个独立的官网:http://www.grpc.io/,目前已经支持的语言有 C, C++, Java, Go, Node.js, Python, Ruby, Objec

Motan 是一套高性能.易于使用的分布式远程服务调用(RPC)框架. 功能 支持通过spring配置方式集成,无需额外编写代码即可为服务提供分布式调用能力. 支持集成consul.zookeeper等配置服务组件,提供集群环境的服务发现及治理能力. 支持动态自定义负载均衡.跨机房流量调整等高级服务调度能力. 基于高并发.高负载场景进行优化,保障生产环境下RPC服务高可用. 微博的Motan RPC服务,底层通讯引擎采用了Netty网络框架,序列化协议支持Hessian和Java序列化,通讯协议

(#)背景 随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进. 单一应用架构 当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本. 此时,用于简化增删改查工作量的 数据访问框架(ORM) 是关键. 垂直应用架构 当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率. 此时,用于加速前端页面开发的 Web框架(MVC) 是关键.

RPC是指远程过程调用,也就是说两台服务器A,B,一个应用部署在A服务器上,想要调用B服务器上应用提供的函数/方法,由于不在一个内存空间,不能直接调用,需要通过网络来表达调用的语义和传达调用的数据: 比如说,一个方法可能是这样定义的:Employee getEmployeeByName(String fullName)那么: 首先,要解决通讯的问题,主要是通过在客户端和服务器之间建立TCP连接,远程过程调用的所有交换的数据都在这个连接里传输.连接可以是按需连接,调用结束后就断掉,也可以是长连接,

Atitit.js javascript的rpc框架选型 1. Dwr1 2. 使用AJAXRPC1 2.2. 数据类型映射表1 3. json-rpc轻量级远程调用协议介绍及使用2 3.1. 2.3.JavaScript客户端调用示例2 3.2. 2.4.直接GET请求进行调用2 4. atiri3 1. Dwr Dwr要自己一个method挑选了,麻烦的.. 2. 使用AJAXRPC 在调用RPC方法时,如果没有传递回调函数,则是同步调用:如果传递回调函数,则是异步调用. 2.1.1.1. 

thrift.avro.probobuf 这几个rpc框架的基本思想都差不多,先定义IDL文件,然后由各自的编译器(或maven插件)生成目标语言的源代码,但是,根据idl生成源代码这件事,如果每次都要手动敲命令,未免太无聊了,幸好这三种框架都提供了对应的maven插件来完成代码的自动生成,本文演示了这三种框架的maven插件用法. 一.maven-thrift-plugin <?xml version="1.0" encoding="UTF-8"?>

thrift是一个facebook开源的高效RPC框架,其主要特点是跨语言及二进制高效传输(当然,除了二进制,也支持json等常用序列化机制),官网地址:http://thrift.apache.org 跨语言通常有二种做法, 一是将其它语言转换成某种主流的通用语言,比如:delphi.net以前就是先将delphi转换成c#,然后再编译成IL,从而实现delphi在.net上的运行(好久没关注delphi了,不知道现在还是不是这种机制) 二是先定义一种规范文件(可以简单的理解为『母版』),然后

近期开始研究分布式架构,会涉及到一个最核心的组件:RPC(Remote Procedure Call Protocol).这个东西的稳定性与性能,直接决定了分布式架构系统的好坏.RPC技术,我们的产品中其实早就已经应用.但是产品中经常出现访问失败等错误,在没有细致研究的情况下,大家怀疑是选用的RPC组件不稳定引起.今天也借这个机会给这个组件正名一下吧. 选型的思路很简单,先baidu找业界最有名的RPC框架,看各种牛人的的对比分析,然后到github上搜索排名和评价靠前的组件,确定一个选型的大致

@import url(/css/cuteeditor.css); 源码地址:http://git.oschina.net/huangyong/rpc RPC,即 Remote Procedure Call(远程过程调用),说得通俗一点就是:调用远程计算机上的服务,就像调用本地服务一样. RPC 可基于 HTTP 或 TCP 协议,Web Service 就是基于 HTTP 协议的 RPC,它具有良好的跨平台性,但其性能却不如基于 TCP 协议的 RPC.会两方面会直接影响 RPC 的性能,一是

从14年开始就陆续看到新浪微博RPC框架Motan的介绍,时隔两年后,微博团队终于宣布开源轻量级RPC框架Motan,项目地址: https://github.com/weibocom/motan/ 项目文档介绍比较详细,搭建开发环境非常简单,如果只是使用而不需要源码的话,只配置maven依赖项目即可,按照示例几分钟就可以搭建起一个Hello world.当然这也是官方介绍中的优点之一. 我们来扩展一下官方的示例,并测试一下集群式部署.首先创建一个maven项目 1 公共部分 pom.xml <

原文:http://weibo.com/p/1001643875439147097368 课程大纲 1.RPC简介 1.1 什么是RPC 1.2 RPC与其他远程调用方式比较 2.Motan RPC框架 2.1 RPC服务框架 2.2 Motan RPC框架中的角色 2.3 Motan RPC的调用流程 3.Motan RPC中各角色介绍 3.1 注册中心 3.2 RPC Service 3.3 RPC Client 4.Motan实战 4.1 Motan的使用方式 4.2 使用Motan提供R

第一步:编写服务接口 第二步:编写服务接口的实现类 第三步:配置服务端 第四步:启动服务器并发布服务 第五步:实现服务注册 第六步:实现 RPC 服务器 第七步:配置客户端 第八步:实现服务发现 第九步:实现 RPC 代理 第十步:发送 RPC 请求 总结 附录:Maven 依赖 RPC,即 Remote Procedure Call(远程过程调用),说得通俗一点就是:调用远程计算机上的服务,就像调用本地服务一样. RPC 可基于 HTTP 或 TCP 协议,Web Service 就是基于 H

为什么会引入RPC: RPC采用客户机/服务器模式.请求程序就是一个客户机,而服务提供程序就是一个服务器.当我们讨论HDFS的,通信可能发生在: Client-NameNode之间,其中NameNode是服务器 Client-DataNode之间,其中DataNode是服务器 DataNode-NameNode之间,其中NameNode是服务器 DataNode-DateNode之间,其中某一个DateNode是服务器,另一个是客户端 如果我们考虑Hadoop的Map/Reduce以后,这些系统