rpc

花了半天的时间写了个简单的rpc框架，是因为我最初看dubbo源码的时候发现dubbo虽然看起来很庞大，但是隐隐约约总感觉，其实其绝大多数功能，都是基于可扩张性和服务治理的需要而编写的。我看过dubbo和grpc的源码，这两个都是非常优秀的rpc框架，但是为了让初学rpc的同学能够快速抓住rpc的核心，所以写了这篇文章，希望看过的同学，再次去看dubbo的源码的时候，能够抓住这个核心去看。 一：rpc协议的接口 RpcProtocol.java public interface RpcProtocol { void export(int port); Object refer(Class inrerfaceClass,String host, int port); } 这个接口类只提供两个接口，那是因为对于一个rpc框架来说，本质上就只需要两个接口，一个是consumer引用provider的服务，一个是provider接收到consumer的请求之后对外暴露服务。 下面是具体的实现。代码不复杂，可以直接复制到idea，慢慢调试 二：rpc协议的具体实现 RpcCore.java public class RpcCore implements RpcProtocol{ private Socket socket; private ObjectOutputStream

转载： 一、微服务介绍 1. 什么是微服务 在介绍微服务时，首先得先理解什么是微服务，顾名思义，微服务得从两个方面去理解，什么是"微"、什么是"服务"， 微 狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 ）。 而所谓服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。 2. 微服务由来 微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。 3. 为什么需要微服务？ 在传统的IT行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。到后面引入了SOA服务化，但是，由于 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高

远程过程调用底层实现机制： 1. 生成调用端 socket 程序动态代理对象； 2. 通过 proxy 调用业务方法； 3. 调用 socket 请求方法； 4.socket 发送调用请求； 5. 生成业务代理对像； 6. 调用具体方法； 7. 获取调用结果； 8.socket 返回调用结果； 9. 返回结果； RPC代码实现 windows中java中的controller调用linux系统中的service 1.在linux系统中新建service的接口与实现类 public interface LoginServiceInterface{ public String login(String name,String passwod); } public class LoginServiceImp implements LoginServiceInterface{ @override public String login(String name,String password){ return name + "登陆成功！" } } 2.新建一个框架把类发布服务 public class starter{ public static void main(String args[]){ Builder builder = new RPC.Builder(new

接block01 来自分割线4 , 调用NameNodeProxies.createNNProxyWithClientProtocol(InetSocketAddress address, Configuration conf, UserGroupInformation ugi, boolean withRetries)方法 private static ClientProtocol createNNProxyWithClientProtocol(InetSocketAddress address, Configuration conf, UserGroupInformation ugi, boolean withRetries) throws IOException { // 设置一个RPC protocol, 使用非默认的RpcEngine RPC.setProtocolEngine(conf, ClientNamenodeProtocolPB.class, ProtobufRpcEngine.class); // 获取配置文件中默认的RetryPolicy final RetryPolicy defaultPolicy = RetryUtils.getDefaultRetryPolicy( conf, DFSConfigKeys.DFS_CLIENT_RETRY_POLICY

首先来看一下, FileSystem(org.apache.hadoop.fs.FileSystem), 这是一个抽象类, 是所有文件系统的父类. 而我们要从HDFS(Hadoop Distributed FileSystem)下载数据, 应该获取一个 DistributedFileSystem 的实例,那么如何获取一个 DistributedFileSystem 的实例呢? FileSystem fs = FileSystem.get(new Configuration()); 在FileSystem中有3个重载的get()方法 // 1.通过配置文件获取一个FileSystem实例 public static FileSystem get(Configuration conf) // 2.通过指定的FileSystem的URI, 配置文件获取一个FileSystem实例 public static FileSystem get(URI uri, Configuration conf) // 3.通过指定的FileSystem的URI, 配置文件, FileSystem用户名获取一个FileSystem实例 public static FileSystem get(final URI uri, final Configuration conf, final String user

什么是 RPC?RPC原理是什么? 什么是 RPC？ RPC （Remote Procedure Call）—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。比如两个不同的服务 A、B 部署在两台不同的机器上，那么服务 A 如果想要调用服务 B 中的某个方法该怎么办呢？使用 HTTP请求 当然可以，但是可能会比较慢而且一些优化做的并不好。 RPC 的出现就是为了解决这个问题。 服务消费方（client）调用以本地调用方式调用服务； client stub 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体； client stub 找到服务地址，并将消息发送到服务端； server stub 收到消息后进行解码； server stub 根据解码结果调用本地的服务； 本地服务执行并将结果返回给server stub； server stub 将返回结果打包成消息并发送至消费方； client stub 接收到消息，并进行解码； 服务消费方得到最终结果。 下面再贴一个网上的时序图： RPC 解决了什么问题？ 从上面对 RPC 介绍的内容中，概括来讲RPC 主要解决了： 让分布式或者微服务系统中不同服务之间的调用像本地调用一样简单。 常见的 RPC 框架总结? RMI （JDK自带）： JDK 自带的RPC，有很多局限性，不推荐使用。

作者 | 刘军（陆龟）Apache Dubbo PMC 本文整理自架构师成长系列 2 月 18 日直播课程。 关注“阿里巴巴云原生”公众号，回复 “218” ，即可获取对应直播回放链接及 PPT 下载链接。 导读 ：Apache Dubbo 是一款开源的 RPC 框架，其提供了简单易用、高性能的 RPC 能力、灵活可控的扩展、强大的服务治理，目前已有 Java、Go、JS、Python 等多个语言支持；并且已经悄然衍进为 Cloud Native 基础设施。这一切成就都离不开 Dubbo 社区的建设，本文将由 Apache Dubbo PMC 刘军来介绍 Dubbo 社区在过去的一年取得的成绩及未来 Dubbo 社区的发展新规划。 非常感谢大家对 Dubbo 社区的关注，通过这篇文章我们将： 总结过去一年 Dubbo 社区取得的成绩，包括社区和框架演进两个方面； 展望未来 Dubbo 社区和框架的新的规划（roadmap）。 社区建设是推动 Dubbo 健康持续发展的一个非常重要的环节，我们需要与社区保持良性的互动、有活跃的贡献者、有积极的富有建设性的讨论，而整个 Dubbo 社区过去一年在这方面都做的不错；在框架演进上，我们主要发布了 2.7.0 - 2.7.5 共 6 个特性版本，功能层面涵盖编程模型、协议、服务治理、性能优化等多个方面；除了已经发布的功能外，我们在 Dubbo

导读 ：Apache Dubbo 是一款开源的 RPC 框架，其提供了简单易用、高性能的 RPC 能力、灵活可控的扩展、强大的服务治理，目前已有 Java、Go、JS、Python 等多个语言支持；并且已经悄然衍进为 Cloud Native 基础设施。这一切成就都离不开 Dubbo 社区的建设，本文将由 Apache Dubbo PMC 刘军来介绍 Dubbo 社区在过去的一年取得的成绩及未来 Dubbo 社区的发展新规划。 非常感谢大家对 Dubbo 社区的关注，通过这篇文章我们将： 总结过去一年 Dubbo 社区取得的成绩，包括社区和框架演进两个方面； 展望未来 Dubbo 社区和框架的新的规划（roadmap）。 社区建设是推动 Dubbo 健康持续发展的一个非常重要的环节，我们需要与社区保持良性的互动、有活跃的贡献者、有积极的富有建设性的讨论，而整个 Dubbo 社区过去一年在这方面都做的不错；在框架演进上，我们主要发布了 2.7.0 - 2.7.5 共 6 个特性版本，功能层面涵盖编程模型、协议、服务治理、性能优化等多个方面；除了已经发布的功能外，我们在 Dubbo 3.0 协议、服务自省和云原生等方向上也做了深入的探索，对这些方向的支持将是 Dubbo 接下来的重要工作方向，希望能通过这篇文章将其中更详细的思考和计划同步给大家。 社区回顾 回顾 Dubbo

服务间通信 　　　　服务间通信的几种方式： RPC、REST over HTTP(s)、消息队列。 　　　　 https://www.jianshu.com/p/2a01d4383d0b 　　　　 RPC 　　　　 https://blog.csdn.net/weixin_42672054/article/details/81708464#commentBox 　　创建WebService工程 　　1.RPC允许程序调用另一个地址空间的过程或函数，而不需要显式编码这个远程调用的细节。 　　　　在底层去看，RPC其实就是将流从一台计算机传输到另外一台计算机，无论是基于传输协议(http、tcp、udp等等)和网络IO(bio、nio)来实现。 　　2. RPC的基本特点如下： 通过网络传输的 跨终端、跨平台的 基于请求-响应的 只调用过程，不需关注细节 　　 　 　3.常见的RPC技术 　　　　 https://blog.csdn.net/chen213wb/article/details/80330356 WebService （现在基本不使用） 跨语言的，基于SOAP协议，基于xml数据或json数据 SOAP WebService： JAX-WS restful WebService： JAX-RS SpringCloud Spring的，基于Socket的

RPC：Remote Procedure Call Protocol（远程过程调用协议） 在分布式系统中，不同的应用或者服务部署在不同的服务器上，不同的服务器之间相互调用不在同一内存空间，也是不同进程之间的调用，为了解决此类问题，才有了RPC框架。那么RPC框架主要解决了哪些问题？往下看： 1、首先解决的是通讯的问题，客户端与服务端建立连接，可以是按需连接，也可以是长连接，建立连接后才能在这个连接中传输数据。 2、解决寻址问题，假如客户端要连接服务端，RPC框架必须知道服务端的IP及端口，当客户端需要连接的时候，RPC框架告诉客户端IP及端口。 3、客户端传参问题，当客户端与服务端建立连接后，客户端要调用服务端的方法，需要将参数编码并序列化传给服务端。 4、服务端接收到客户端传来的参数后，反序列化并解码参数，将数据处理完成后再编码并序列化传给客户端。 常用的RPC框架都有哪些呢？ 1、RMI：java自带的远程方法调用 2、hessian：基于HTTP的远程方法调用 3、Dubbo:淘宝开源的基于TCP的RPC框架 来源： https://www.cnblogs.com/C-F-Cooper/p/7397669.html