后使用快捷导航没有帐号？
查看: 23934|回复: 48
Zeroc Ice，Thrift，Avro 等RPC框架，对于电商和新型互联网应用的意义何在
论坛徽章:1018
Zeroc Ice，Thrift，Avro 等RPC框架，对于电商和新型互联网应用的意义何在
1、本周互动作业请在当前主题帖内进行发布，其他版块发起回复贴无效。
2、回复内容需符合主题帖讨论方向，灌水或者复制他人回帖，管理员及老师可以删除此贴，并判处作业不合格。
3、发起回帖需符合：1个回帖，字数不少50个字符的帖子。
注册会员, 积分 67, 距离下一级还需 133 积分
论坛徽章:1
电商和新型互联网应用一般来说需要多个系统或者功能模块的协作，当前软件面向服务（SOA）架构成为一种趋势，RPC框架的特性能够支撑SOA的实现。
中级会员, 积分 487, 距离下一级还需 13 积分
论坛徽章:13
有益于代码的模块化对于计算密集型的程序模块，可以利用多台电脑，实现计算能力的增强。服务更加弹性化。不同的服务，可以使用不同语言和技术。也可以让同一套系统，多个团队并行开发
新手上路, 积分 17, 距离下一级还需 33 积分
论坛徽章:1
我们是否需要REST的替代品？转自infoQ：q.com/cn/news/2014/01/rest-alternatives
SoapUI的缔造者Ole Lensmar最近被问起，是否认为REST即将步入暮年，以及是否需要寻找它的替代者。对此他表示：在近些年中，REST得以成为构建公用API的主要方法，并令任何其他API技术或方法都黯然失色。虽然在企业中依旧（非常）流行一些其他方法（主要是SOAP），但是API运动的早期参与者们已经抱有鲜明的立场：他们选择了REST方法，并以JSON作为推荐消息格式。接下来，Ole探讨了为何他认为REST比其他方法（例如SOAP和XML-RPC）更加成功。尽管如此，Ole也承认在一些领域中REST确实表现不佳，需要使用其他替代者来应对这些应用场景下的需求。这些领域包括：异步API：“面对用异步推送数据取代传统请求/响应模式的需求，RESTful设计并不适用。此外，底层技术（例如WebSockets、MQTT、AMQP、Stomp、pubsubhubbub/WebHooks等）常常与HTTP有很大不同，因此往往也就不能与REST准则良好匹配。”编配API：“传统REST API提供的资源粒度并不总是一项优势；将资源拖入移动仪表板或是复杂的单页Web应用，将需要许多API请求——这将同时增加客户端逻辑、带宽和服务器处理方面的开销。”SDK vs API：“大部分使用者最终都是在一些高级语言中调用API；诸如JavaScript、Python、Ruby、Java等等，因此许多API提供者都为这些语言提供了预建的客户端库（Google、Facebook等）。这些语言本身往往更加面向RPC，由SDK暴露出的代码层面的API也是如此——因此，要让后端API采用相似的方式工作，或许需要使用更加优化的二进制协议（见后文）或是与RPC更加类似的HTTP资源的使用（例如JSON-RPC）”二进制协议：“[……]面对IoT设备或SDK中的要求——例如传输优化后的消息——若干二进制协议正在获得更多的关注并得到运用”，例如Apache Thrift、Google Protocol Buffers和Apache Avro.“[值得一提的是]上面提到的若干异步API技术使用一种二进制格式——与带宽和来自其存留的设备或服务的处理约束有关。”
Ole以Evernote（在大陆地区的产品名为印象笔记）为例，它使用Thrift作为其底层协议，以应对实时请求（这大概也是Ole所指的超出REST能力的东西）。他提到了另一篇由Daniel Jacobson撰写的关于Evernote的RESTless设计的独立文章：[……]当我们面对大量未知的开发者时，REST API或许是个好的选择——然而当我们的API针对非常明确的用户、市场、行业或技术时，对于更加具体的解决方案的需求并不是毫无来由的——或许这甚至会使我们在性能、易用性或安全性方面领先我们的竞争者。在总结中Ole表示，万应灵药并不存在，特别是与API设计有关的领域。“幸运的是，对我们这些热忱的技术人员来说，构建和学习新东西，并尽可能让所有利益干系人都运用它，将使我们的世界（至少是我的）充满活力。所以我并不反对这种多样性，相反我很乐于见到这一切。”然而，虽然得到了一些人的赞同，但是也还有许多人对Ole的观点表示反对。例如John Sheehan说：我并不认为Evernote称得上是“放弃了REST”，因为他们自始至终都没有使用它，并且有充分的理由这样做。同时，Webhooks也可以是非常“REST”的（至少从对这一概念的通俗理解来看是这样）。Ole在异步这部分列出的警告，并不适用于大部分常见的实现。而Darrel Miller则试着区分REST和“pop REST”：从Daniel Jacobson对编配层的描述，我认为它与我在过去数年间一直采用的RESTful（以及超媒体驱动）API构建方式贴合地非常紧密。只不过因为人们开始识破“pop REST”的大肆宣传，并不意味着Fielding所定义的REST的属性已经发生了变化。实际上许多评论家相信，Ole没有真正将RESTful原则，与打着RESTful旗号但实际却并非如此的实践进行区分。各位读者对此怎么看？在Ole所列举出的全部领域中REST是否真的适用？如果不是的话，你推荐用什么来替代它？
高级会员, 积分 833, 距离下一级还需 167 积分
论坛徽章:7
1、可以提供系统服务注册，方便各种系统的服务管理
2、自带负载均衡
3、方便横向扩展
4、多源多语言调用
5、PRC方式相对于Rest方式效率更高
注册会员, 积分 192, 距离下一级还需 8 积分
论坛徽章:3
相对于webservice等基于http的调用方式，RPC有以下优点：1.轻量级。2.可基于tcp长连接。3.TPS较高。4.传输数据量小。等特点
高级会员, 积分 782, 距离下一级还需 218 积分
论坛徽章:21
RPC框架在一定程度上简化了socket编程，相比Zeroc Ice，Thrift和Avro只提供了基础的框架还没有到达应用平台的级别，而基于Zeroc Ice企业可以轻松构建SOA
金牌会员, 积分 1340, 距离下一级还需 1660 积分
论坛徽章:10
thrift是为了解决facebook系统中各系统间大数据量的传 输通信以及系统之间语言环境不同需要跨平台的特性。所以thrift可以支持多种程序语言，例如:&&C++, C#, Cocoa, Erlang, Haskell, Java, Ocami, Perl, PHP, Python, Ruby, Smalltalk. 在多种不同的语言之间通信thrift可以作为二进制的高性能的通讯中间件，支持数据(对象)序列化和多种类型的RPC服务。
注册会员, 积分 91, 距离下一级还需 109 积分
论坛徽章:2
目前公司使用dubbo框架，其他框架有机会还要继续学习。
目前觉得dubbo使用zk作为服务注册，可以动态的添加新服务，便于热部署。
在工作工程中，也有更好的分工，可以专人负责业务开发。
其他同事调用接口即可。降低开发难度，并且复用性好。
中级会员, 积分 299, 距离下一级还需 201 积分
论坛徽章:3
没有做过开发，不过还是谈谈自己的理解
1.简化开发
2.使用成熟的技术
3.架构统一服务化实战之 dubbo、dubbox、motan、thrift、grpc等RPC框架比较及选型 - CSDN博客
服务化实战之 dubbo、dubbox、motan、thrift、grpc等RPC框架比较及选型
前段时间项目要做服务化，所以我比较了现在流行的几大RPC框架的优缺点以及使用场景，最终结合本身项目的实际情况选择了使用dubbox作为rpc基础服务框架。下面就简单介绍一下RPC框架技术选型的过程。
该系列文章将讲述以下RPC框架的helloword实例以及其实现原理简述，由于每一种RPC框架的原理实现不同且都比较复杂，如果想深入研究还请自行到官网或者其他技术博客学习。
RPC框架职责
RPC框架要向调用方屏蔽各种复杂性，要向服务提供方也屏蔽各类复杂性：
调用方感觉就像调用本地函数一样
服务提供方感觉就像实现一个本地函数一样来实现服务
RPC框架是架构(微)服务化的首要基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节
RPC框架的职责是：让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务
对于不是很理解服务化的同学可以看看这两篇文章：
服务化的好处
服务架构的拆分原则
服务拆分原则：围绕业务功能进行垂直和水平拆分。大小粒度是难点，也是团队争论的焦点。
不好的实践
以代码量作为衡量标准，例如500行以内。
拆分的粒度越小越好，例如以单个资源的操作粒度为划分原则。
建议的原则
功能完整性、职责单一性。
粒度适中，团队可接受。
迭代演进，非一蹴而就。
API的版本兼容性优先考虑。
代码量多少不能作为衡量微服务划分是否合理的原则，因为我们知道同样一个服务，功能本身的复杂性不同，代码量也不同。还有一点需要重点强调，在项目刚开始的时候，不要期望微服务的划分一蹴而就。
微服务架构的演进，应该是一个循序渐进的过程。在一个公司、一个项目组，它也需要一个循序渐进的演进过程。一开始划不好，没有关系。当演进到一个阶段时，微服务的部署、测试和运维等成本都非常低的时候，这对于你的团队来说就是一个好的微服务。
服务架构的开发原则
微服务的开发还会面临依赖滞后的问题。例如：A要做一个身份证号码校验，依赖服务提供者B。由于B把身份证号码校验服务的开发优先级排的比较低，无法满足A的交付时间点。A会面临要么等待，要么自己实现一个身份证号码校验功能。
以前单体架构的时候，大家需要什么，往往喜欢自己写什么，这其实是没有太严重的依赖问题。但是到了微服务时代，微服务是一个团队或者一个小组提供的，这个时候一定没有办法在某一个时刻同时把所有的服务都提供出来，“需求实现滞后”是必然存在的。
一个好的实践策略就是接口先行，语言中立，服务提供者和消费者解耦，并行开发，提升产能。无论有多少个服务，首先需要把接口识别和定义出来，然后双方基于接口进行契约驱动开发，利用Mock服务提供者和消费者，互相解耦，并行开发，实现依赖解耦。
采用契约驱动开发，如果需求不稳定或者经常变化，就会面临一个接口契约频繁变更的问题。对于服务提供者，不能因为担心接口变更而迟迟不对外提供接口，对于消费者要拥抱变更，而不是抱怨和抵触。要解决这个问题，一种比较好的实践就是管理 + 技术双管齐下：
允许接口变更，但是对变更的频度要做严格管控。
提供全在线的API文档服务（例如Swagger UI），将离线的API文档转成全在线、互动式的API文档服务。
API变更的主动通知机制，要让所有消费该API的消费者能够及时感知到API的变更。
契约驱动测试，用于对兼容性做回归测试。
服务架构的测试原则
微服务开发完成之后需要对其进行测试。微服务的测试包括单元测试、接口测试、集成测试和行为测试等，其中最重要的就是契约测试：
利用微服务框架提供的Mock机制，可以分别生成模拟消费者的客户端测试桩和提供者的服务端测试桩，双方可以基于Mock测试桩对微服务的接口契约进行测试，双方都不需要等待对方功能代码开发完成，实现了并行开发和测试，提高了微服务的构建效率。基于接口的契约测试还能快速的发现不兼容的接口变更，例如修改字段类型、删除字段等。
服务架构的部署原则
测试完成之后，需要对微服务进行自动化部署。微服务的部署原则：独立部署和生命周期管理、基础设施自动化。需要有一套类似于CI/CD的流水线来做基础设施自动化，具体可以参考Netflix开源的微服务持续交付流水线Spinnaker：
最后一起看下微服务的运行容器：微部署可以部署在Dorker容器、PaaS平台（VM）或者物理机上。使用Docker部署微服务会带来很多优先：
一致的环境，线上线下环境一致。
避免对特定云基础设施提供商的依赖。
降低运维团队负担。
高性能接近裸机性能。
相比于传统的物理机部署，微服务可以由PaaS平台实现微服务自动化部署和生命周期管理。除了部署和运维自动化，微服务云化之后还可以充分享受到更灵活的资源调度：
云的弹性和敏捷。
云的动态性和资源隔离。
服务架构的治理原则
服务部署上线之后，最重要的工作就是服务治理。微服务治理原则：线上治理、实时动态生效。
微服务常用的治理策略：
流量控制：动态、静态流控制。
服务降级。
超时控制。
优先级调度。
流量迁移。
调用链跟踪和分析。
服务路由。
服务上线审批、下线通知。
SLA策略控制。
微服务治理模型如下所示：
最上层是为服务治理的UI界面，提供在线、配置化的治理界面供运维人员使用。SDK层是提供了微服务治理的各种接口，供服务治理Portal调用。最下面的就是被治理的微服务集群，集群各节点会监听服务治理的操作去做实时刷新。例如：修改了流控阈值之后，服务治理服务会把新的流控的阈值刷到服务注册中心，服务提供者和消费者监听到阈值变更之后，获取新的阈值并刷新到内存中，实现实时生效。由于目前服务治理策略数据量不是特别大，所以可以将服务治理的数据放到服务注册中心（例如etcd/ZooKeeper），没有必要再单独做一套。
服务最佳实践
介绍完微服务实施之后，下面我们一起学习下微服务的最佳实践。
服务路由：本地短路策略。关键技术点：优先调用本JVM内部服务提供者，其次是相同主机或者VM的，最后是跨网络调用。通过本地短路，可以避免远程调用的网络开销，降低服务调用时延、提升成功率。原理如下所示：
服务调用方式：同步调用、异步调用、并行调用。一次服务调用，通常就意味着会挂一个服务调用线程。采用异步调用，可以避免线程阻塞，提升系统的吞吐量和可靠性。但是在实际项目中异步调用也有一些缺点，导致使用不是特别广泛：
需要写异步回调逻辑，与传统的接口调用使用方式不一致，开发难度大一些。
一些场景下需要缓存上下文信息，引入可靠性问题。
并行调用适用于多个服务调用没有上下文依赖，逻辑上可以并行处理，类似JDK的Fork/Join, 并行服务调用涉及到同步转异步、异步转同步、结果汇聚等，技术实现难度较大，目前很多服务框架并不支持。采用并行服务调用，可以把传统串行的服务调用优化成并行处理，能够极大的缩短服务调用时延。
微服务故障隔离：线程级、进程级、容器级、VM级、物理机级等。关键技术点：
支持服务部署到不同线程/线程池中。
核心服务和非核心服务隔离部署。
为了防止线程膨胀，支持共享和独占两种线程池策略。
谈到分布式，就绕不开事务一致性问题：大部分业务可以通过最终一致性来解决，极少部分需要采用强一致性。
具体的策略如下：
最终一致性，可以基于消息中间件实现。
强一致性，使用TCC框架。服务框架本身不会直接提供“分布式事务”，往往根据实际需要迁入分布式事务框架来支持分布式事务。
微服务的性能三要素：
I/O模型，这个通常会选用非堵塞的，Java里面可能用java原生的。
线程调度模型。
序列化方式。
公司内部服务化，对性能要求较高的场景，建议使用异步非阻塞I/O（Netty） + 二进制序列化（Thrift压缩二进制等） + Reactor线程调度模型。
最后我们一起看下微服务的接口兼容性原则：技术保障、管理协同。
制定并严格执行《微服务前向兼容性规范》，避免发生不兼容修改或者私自修改不通知周边的情况。
接口兼容性技术保障：例如Thrift的IDL，支持新增、修改和删除字段、字段定义位置无关性，码流支持乱序等。
持续交付流水线的每日构建和契约化驱动测试，能够快速识别和发现不兼容。
现在流行的ＲＰC框架:
服务治理型
Protocol Buffers (google)
上图来自于dubbo。服务治理型RPC框架结构大多如此，大致分为服务提供者，服务消费者，注册中心，监控报警中心几大模块。
在服务化，或者微服务化过程中，首先考虑的问题就是性能问题，因为在服务化之后，会增加以下额外的性能开销：
客户端需要对消息进行序列化，主要占用CPU计算资源。
序列化时需要创建二进制数组，耗费JVM堆内存或者堆外内存。
客户端需要将序列化之后的二进制数组发送给服务端，占用网络带宽资源。
服务端读取到码流之后，需要将请求数据报反序列化成请求对象，占用CPU计算资源。
服务端通过反射的方式调用服务提供者实现类，反射本身对性能影响就比较大。
服务端将响应结果序列化，占用CPU计算资源。
服务端将应答码流发送给客户端，占用网络带宽资源。
客户端读取应答码流，反序列化成响应消息，占用CPU资源。
RPC框架高性能设计
要想提高效率，除了硬件的提升，主要考虑以下三个方面：
I/O调度模型：同步阻塞I/O（BIO）还是非阻塞I/O（NIO）。
序列化框架的选择：文本协议、二进制协议或压缩二进制协议。
线程调度模型：串行调度还是并行调度，锁竞争还是无锁化算法。
IO调度现在主流的就是netty。
高性能序列化目前性能最好的是ice,google 的 pb协议，FB的thrift协议等
线程没啥好说的，肯定多线程了。当然也可以是AKKA（java）
综上所述，服务化是现在大型互联网公司主流的架构模式，现在还有更流行的微服务，docker部署等等。
个人建议采用dubbox，集成其他各种协议，在该系列文章最后有各个协议的性能对比。
之所以建议采用dubbox是因为，dubbox有比价完善的服务治理模型，其包含ZK注册中心，服务监控等，可以很方便的为我们服务。
虽然dubbo本身不支持多语言，但是我们可以集成其他的序列化协议，比如thrift、avro，使其可以支持多种入门语言，让部门间的协作沟通更加灵活方便
当然，在实际使用过程中，尤其是集成其他协议的过程中，肯定需要对协议本身有比较深入的了解，才能正确的使用。
新浪微博开源的RPC框架
helloword示例直接去官网下载运行即可
github地址：
文档地址：
中文版官方文档：
helloWord示例，我就是根据这个文章做的，写得挺详细的：
dubbo 已经与12年年底停止维护升级，忽略
请参考我写的另一篇文章：
dubbox 是当当团队基于dubbo升级的一个版本。是一个分布式的服务架构，可直接用于生产环境作为SOA服务框架。
dubbo官网首页：
上面有详细的用户指南和官方文档，介绍的比较详细，这里不再赘述。
当当官方的github地址：
升级为spring4.X（及其他依赖组件）版本dubbox的github的地
参考资料【博客：菩提树下的杨过
的文章写得非常全面，介绍的已经非常详细了】：
# 各个RPC框架性能比较
个人笔记本配置：
person对象：
private int
private boolean
private int childrenC
测试数据，入参：
private int ageS
private int ageE
Person.PersonBuilder builder = Person.builder();
List&Person& list = new ArrayList&Person&();
for (short i = 0; i & 10; i++) {
list.add(builder.age(i).childrenCount(i).name("test" + i).sex(true).build());
return list;
各协议测试使用的配置
rpc getPersonList (yjmyzz.grpc.study.dto.QueryParameter) returns (yjmyzz.grpc.study.dto.PersonList) {}
&motan:basicService export="demoMotan:8002"
group="motan-demo-rpc" accessLog="false" shareChannel="true" module="motan-demo-rpc"
application="myMotanDemo" registry="registry" id="serviceBasicConfig"/&
&dubbo:protocol name="dubbo" serialization="kryo" optimizer="com.alibaba.dubbo.demo.SerializationOptimizerImpl"/&
&dubbo:service interface="com.alibaba.dubbo.demo.person.PersonService" ref="personService" protocol="dubbo"/&
TNonblockingServer + TFramedTransport
rgpc 100000 次NettyServer调用，耗时：53102毫秒，平均1883次/秒 【简单grpc】
rgpc 100000 次NettyServer调用，耗时：52138毫秒，平均1917次/秒 【简单grpc】
rgpc 100000 次NettyServer调用，耗时：51800毫秒，平均1930次/秒 【简单grpc】
rgpc 100000 次NettyServer调用，耗时：51313毫秒，平均1948次/秒 【简单grpc】
rgpc 100000 次NettyServer调用，耗时：56812毫秒，平均1760次/秒[2016-10-08 19:17:31] Dubbo service server started! 【dubbox.kryo】
rgpc 100000 次NettyServer调用，耗时：55133毫秒，平均1813次/秒[2016-10-08 19:18:42] Dubbo service server started!【dubbox.kryo】
rgpc 100000 次NettyServer调用，耗时：52280毫秒，平均1912次/秒[2016-10-08 19:20:01] Dubbo service server started! 【dubbox.kryo】
rgpc 100000 次NettyServer调用，耗时：44414毫秒，平均2251次/秒[2016-10-08 19:13:34] Dubbo service server started! 【dubbox.fst】
rgpc 100000 次NettyServer调用，耗时：44805毫秒，平均2231次/秒[2016-10-08 19:12:25] Dubbo service server started! 【dubbox.fst】
rgpc 100000 次NettyServer调用，耗时：46245毫秒，平均2162次/秒[2016-10-08 19:14:43] Dubbo service server started! 【dubbox.fst】
rgpc 100000 次NettyServer调用，耗时：12203毫秒，平均8194次/秒[2016-10-09 19:52:34] Dubbo service server started!【dubbox.thrift】
rgpc 100000 次NettyServer调用，耗时：14142毫秒，平均7071次/秒[2016-10-09 19:30:17] Dubbo service server started!【dubbox.thrift】
rgpc 100000 次NettyServer调用，耗时：13762毫秒，平均7266次/秒[2016-10-09 19:30:43] Dubbo service server started!【dubbox.thrift】
rgpc 100000 次NettyServer调用，耗时：44334毫秒，平均2255次/秒 【motan】
rgpc 100000 次NettyServer调用，耗时：37844毫秒，平均2642次/秒 【motan】
rgpc 100000 次NettyServer调用，耗时：39007毫秒，平均2563次/秒 【motan】
rgpc 100000 次NettyServer调用，耗时：38610毫秒，平均2590次/秒 【motan】
测试结果说明
使用的自己的笔记本电脑测试的，测试的方式可能不太专业，但能够说明问题。
通过上面结果可以看到，thrift的性能最好,而且是相当的好
网上其他人做的测试
影响RPC性能的因素主要有：
序列化性能
序列化的话，肯定是Google的PB协议和thrift最好，IO和线程的话，先流行的性能比较好的都是采用多线程非阻塞IO。
grpc是Google出品，使用了PB协议，但是由于它出现的比较晚，还不怎么成熟，而且采用http协议，非常适合现在的微服务，不过性能上差了许多，而且像服务治理与监控都需要额外的开发工作，所以放弃grpc。
thrift和grpc一样，性能优越，但是开发难度相比较于dubbox和motan也是高了一点点，需要编写proto文件（其实对于程序员来说这算不上难度）。像服务治理与监控也是需要额外的开发工作。
dubbo比较老了，直接弃用。
dubbox和后来的motan都比较适合我们的团队。dubbox后来经过当当的开发，引入了rest风格的http协议，并且还支持kryo/fst/dubbo/thrift等其他协议，而且其他团队也在使用dubbo，集成方便，服务治理监控功能齐全，所以最终采用dubbox。
其实我个人而言还是喜欢thrift，毕竟性嫩优越，在大型分布式系统中，哪怕一点点性能提升累计在一起也是很可观的。不过再具体选型的过程中还要结合团队目前的状况和团队其他开发人员的接受程度进行取舍。
本文已收录于以下专栏：
相关文章推荐
从14年开始就陆续看到新浪微博RPC框架Motan的介绍，时隔两年后，微博团队终于宣布开源轻量级RPC框架Motan，项目地址：
/weibocom/motan/
源码下载：
     所有session集中管理，根据session做标识，session对象用objectStream做序列化，缓存到redis中
2、环境搭建
     ①配置java...
本测试只是个人为了对rpc进行技术选型，测试可能不够严谨，对某些rpc的参数可能也不是最优，如果你知道更优的参数配置或者改进意见等，欢迎反馈给我。另外代码有些地方...
简单分布式架构
传输什么样的数据，用哪种协议
哪种方式数据交换的效率好
服务端如何处理请求
需要扩展服务端时
当你的服务超过最简单结构时，你想要
当然，你更想要简...
Spring Cloud与Dubbo共存方案总结
原创  周立 周立SpringCloud
假设有一个遗留的Dubbo系统，现在想改用Spring Cl...
孰优孰劣？Dubbo VS Spring Cloud性能测试大对决！
ImportSource
ImportSource
ImportSo...
最近一段时间不论互联网还是传统行业，凡是涉及信息技术范畴的圈子几乎都在讨论 微服务架构 。近期也看到各大技术社区开始组织一些沙龙和论坛来分享Spring Cloud的相关实施经验，这对于最近正在整理S...
需求场景在微服务架构中，服务的请求者以何种方式调用远程服务是一项核心问题。在Spring Cloud(Netflix)技术栈中，每个微服务是以HTTP REST接口的形式暴露的，这样在执行远程调用时，...
Thrift  是什么？
  Thrift源于大名鼎鼎的facebook之手，在2007年facebook提交Apache基金会将Thrift作为一个开源项目，对于当时的facebook来说创造th...
今天看項目時，看到同事处理---判断用户是否在该页处理数据（是否在于编辑状态），在数据库有一个栏位保存这个状态。。这个方法不错。。记录一下。     这就有一个问题--当页面关闭或不可预知的可能忘处理...
他的最新文章
讲师：宋宝华
讲师：何宇健
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)发布：dubboPlus - 支持thrift原生协议(dubbo扩展) - CSDN博客
发布：dubboPlus - 支持thrift原生协议(dubbo扩展)
基于dubbo2.5.3扩展高性能的、支持容错的、协议无关的RPC框架增加了对thrift原生协议支持，从而实现了跨语言调用（C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml）
经过完整测试，可用于生产。
项目源码：
本文已收录于以下专栏：
相关文章推荐
原文：/p/0b6e2c920014
随着现在互联网行业的发展，越来越多的框架、中间件、容器等开源技术不断地涌现，更好地来服务于业务，解决实现...
mongoDB 介绍（特点、优点、原理）
介绍：MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。
特点：高性能、易部署、易使用，...
JAVA jdk安装
http://blog.csdn.net/fenglailea/article/details/
zookeeper安装
http://blog.csdn....
Java_io体系之File、FileInputStream、FileOutputStream简介、走进源码及示例——05
1、File类简介：
        它既可以表示...
一个简单的电商网站说起，它可能包含如下的几个模块和功能，如首页、detail页、list页、下单页、支付页以及后台管理等页面和功能。随着业务的发展，单一应用架构带来的问题是：
1.代码越来庞大，业务越...
如何引用Zookeeper.dll
下载最新版本的Zookeeper
地址：/apache/zookeeper/
没有.NET代码
地址：htt...
项目要接入thrift，面对完全陌生的东西，学习的过程记录。
开发环境：
系统：Windows
工具：VS2012
最新版thrift 下载：http://thrift.apache....
/yjmyzz/archive//dubbo-pritimive-thrift-avro-support.html
原文地址：http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-协议参考手册
协议参考手册
推荐使用Dubbo协议
dubbo采用Thrift协议其实官网上已经说的很明白了。具体配置文件我在官网上没有发现。特此写下该文章，备忘。
1.写Thrift 的IDL,生成JAVA文件。copy到服务端和客户端，客户端只拷贝...
他的最新文章
讲师：宋宝华
讲师：何宇健
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)