rpc

分布式RPC框架 dubbo常见问题： 1. 问dubbo的工作原理：服务注册，注册中心，服务生产者，消费者，代理通信，负载均衡 2. 问网络通信，序列化： dubbo协议，长连接，NIO，hessian序列化协议 3. 问负载均衡策略，集群容错策略，动态策略：dubbo跑起来后一些功能是如何运转，怎么做复制均衡，怎么做容错，怎么生成动态代理？ 4. 问dubbo SPI机制：是否了解SPI机制？如何基于SPI机制对dubbo进行扩展？ 5. dubbo服务治理，超时，降级，重试等。 1. 为什么要进行系统拆分？ 项目大了，代码多了，很多代码冲突，代码合并维护困难。改一个地方，回归测试工作量很大。 大项目发布上线依赖很多外部东西，发布特别麻烦。 2. 如何进行拆分？ 系统拆分需要经过多轮拆分，不可能一次就拆分好了。考虑多少个人维护多少个服务。 3. 拆分后为什么要用 Dubbo, 不用 Dubbo 可以吗？ Dubbo 和 Thrift 有什么区别？ 可以不用。可以用纯基于Spring MVC，纯http接口相互通信，但是维护成本很高。 Dubbo已经在RPC做得很好了，成熟的RPC框架，本地就是进行接口调用，Dubbo代理调用请求，跟远程网络通信，处理负载均衡，超时重试等等功能。 4. 说一下的 Dubbo 的工作原理？注册中心挂了可以继续通信吗？说说发起一次 RPC 请求的流程

My application uses Microsoft RPC for interprocess communications. When two processes are run on the same machine and one process tries to call a method declared as (IDL notation): error_status_t rpcMethod( [in] pipe byte parameter ); this call fails with RPC_S_CANNOT_SUPPORT ("The requested operation is not supported") and never reaches the server side and the push()/pull() primitives of the supplied pipe are never called. This is only reproduced on Vista when using ncalrpc protocol and not otherwise. I also found the following in the Event Viewer logs: Application ("my program exe file name

RPC（Remote Procedure Call）：远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的思想RPC 是一种技术思想而非一种规范或协议，常见 RPC 技术和框架有： 应用级的服务框架：阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。 远程通信协议：RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。 通信框架：MINA 和 Netty。 目前流行的开源 RPC 框架还是比较多的，有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的 gRPC、Twitter 的 Finagle 等。 下面重点介绍三种： gRPC：是 Google 公布的开源软件，基于最新的 HTTP 2.0 协议，并支持常见的众多编程语言。RPC 框架是基于 HTTP 协议实现的，底层使用到了 Netty 框架的支持。 Thrift：是 Facebook 的开源 RPC 框架，主要是一个跨语言的服务开发框架。 用户只要在其之上进行二次开发就行，应用对于底层的 RPC 通讯等都是透明的。不过这个对于用户来说需要学习特定领域语言这个特性，还是有一定成本的。 Dubbo：是阿里集团开源的一个极为出名的 RPC 框架，在很多互联网公司和企业应用中广泛使用

一、什么是 NFS ？ 　　NFS 是 Network File System 的缩写，即网络文件系统。一种使用于分散式文件系统的协定，由 Sun 公司开发，于 1984 年向外公布。功能是通过网络让不同的机器、不同的操作系统能够彼此分享个别的数据，让应用程序在客户端通过网络访问位于服务器磁盘中的数据，是在类 Unix 系统间实现磁盘文件共享的一种方法 　　它的主要功能是通过网络让不同的机器系统之间可以彼此共享文件和目录。 NFS 服务器可以允许 NFS 客户端将远端 NFS 服务器端的共享目录挂载到本地的 NFS 客户端中。在本地的 NFS 客户端的机器看来， NFS 服务器端共享的目录就好像自己的磁盘分区和目录一样。一般客户端挂载到本地目录的名字可以随便，但为方便管理，我们要和服务器端一样比较好。 NFS 一般用来存储共享视频，图片等静态数据。 二、 NFS 挂载原理 　　NFS 是通过网络来进行服务端和客户端之间的数据传输。两者之间要传输数据就要有想对应的网络端口来进行传 输。 NFS 服务器到底使用什么网络端口来传输数据的， NFS 服务器端其实是随机选择端口来进行数据传输。那 NFS 客户端又是如何知道 NFS 服务器端到底使用的是哪个端口呢？其实 NFS 服务器时通过远程过程调用（ remote procedure call 简称 RPC ）协议 / 服务来实现的

SPI配置的默认实现 cache=com.alibaba.dubbo.cache.filter.CacheFilter validation=com.alibaba.dubbo.validation.filter.ValidationFilter echo=com.alibaba.dubbo.rpc.filter.EchoFilter generic=com.alibaba.dubbo.rpc.filter.GenericFilter genericimpl=com.alibaba.dubbo.rpc.filter.GenericImplFilter token=com.alibaba.dubbo.rpc.filter.TokenFilter accesslog=com.alibaba.dubbo.rpc.filter.AccessLogFilter activelimit=com.alibaba.dubbo.rpc.filter.ActiveLimitFilter classloader=com.alibaba.dubbo.rpc.filter.ClassLoaderFilter context=com.alibaba.dubbo.rpc.filter.ContextFilter consumercontext=com.alibaba.dubbo.rpc.filter

什么是 RPC？ 初步印象 　　RPC的语义是远程过程调用，在一般的印象中，就是将一个服务调用封装在一个本地方法中，让调用者像使用本地方法一样调用服务。而具体的实现是通过调用方和服务方各自的 stub 基于TCP长连接进行数据交互达成。 　　上面的解释似云里雾里，仅仅了解到这种程度是远远不够的，还需要更进一步，以相对 底层 和 抽象 的视角来理解RPC。 三个特点 　　广义上来讲，所有本应用程序外的调用都可以归类为RPC，不管是分布式服务，第三方服务的HTTP接口，还是读写Redis的一次请求。从抽象的角度来讲，它们都一样是RPC，由于不在本地执行，都有三个特点： 　　需要事先约定调用的语义(接口语法) 　　需要网络传输 　　需要约定网络传输中的内容格式 　　以一次Redis调用为例，执行 redis.set("rpc", 1) 这个调用，其中： 　　set 及其参数 ("rpc", 1) ，就是对 调用语义 的约定，由redis的API给出 　　RedisServer会监听一个服务端口，通过TCP传输内容，用异步事件驱动实现高并发 　　底层库会约定数据如何进行编解码，如何标识命令和参数，如何表示结果，如何表示数据的结尾等等 　　这三个特点都是因为 调用不在本地 而不得不衍生出来的问题，也因此决定了RPC的形态。所有的RPC解决方案都是在解决这三个问题

摘自： https://www.cnblogs.com/mayou18/p/9829876.html 聊聊微服务的服务注册与发现 来源：阿里中间件团队分享 更多文章请关注 MAYOU18 聊起微服务的服务注册与发现，很多人立马就会脱口而出 zk、etcd、consul、eureka 这些组件，进而聊到 CAP 如何取舍，性能如何，高可用和容灾是怎么实现的。 引言 聊起微服务的服务注册与发现，很多人立马就会脱口而出 zk、etcd、consul、eureka 这些组件，进而聊到 CAP 如何取舍，性能如何，高可用和容灾是怎么实现的。 在这之前，站在组件使用者的角度，我想先问这么几个问题： 注册的 IP 和端口怎么确定 ？ 实现服务治理还需要注册哪些信息 ？ 如何进行优雅的服务注册与服务下线 ？ 注册服务的健康检查是如何做的 ？ 当服务有节点退出或新的节点加入时，订阅者能不能及时收到通知 ? 我能方便地查看某个应用发布和订阅了哪些服务，以及所订阅的服务有哪些节点吗 ？ 看完这些问题后，您也许会发现，对于服务注册与发现，首先应该关注的是服务注册发现本身的功能，然后才是性能和高可用。 一个好的服务注册发现中间件，应该是能完整地满足服务开发和治理的基础功能，然后才是性能和高可用。如果没有想清楚前面的功能，再高的可用性和性能都是浮云。最后，安全也同样重要。 服务端的性能如何 ？