rpc

比特币源码解析：RPC详解 这篇文章主要分析rpc模块代码的一个整体逻辑，详细的代码讲解，请关注下一篇文章 在这里，我们暂时先抛开bitcoin代码，仅仅来谈RPC，提到RPC大家肯定首先会想到远程过程服务调用，既然是调用，那就肯定存在一个client端和一个server端，clent端与server端通过RPC这个黑盒通过http请求进行交互，那么就有一个问题，我自定义的json格式的字符串（这里拿json来进行举例）是无法在网络上流通的，所以，必然会涉及到一个json的序列化与反序列化的过程。综上所述，大致流程如下： image.png RPC详解 rpc命令的入口函数是从 bitcoin-abc/src/rpc/register.h 出发的，根据功能模块的不同，分了如下函数用来注册rpc命令： class CRPCTable ; //区块链RPC命令注册 void RegisterBlockchainRPCCommands (CRPCTable &tableRPC) ; //P2P网络RPC命令注册 void RegisterNetRPCCommands (CRPCTable &tableRPC) ; //其他工具RPC命令注册 void RegisterMiscRPCCommands (CRPCTable &tableRPC) ; //挖矿RPC命令注册 void

本文简单地介绍一下两种形式的C/S架构，先说一下他们最本质的区别，就是 RPC主要是基于TCP/IP协议的，而HTTP服务主要是基于HTTP协议的 ，我们都知道HTTP协议是在传输层协议TCP之上的，所以效率来看的话，RPC当然是要更胜一筹啦！下面来具体说一说RPC服务和HTTP服务。 OSI网络七层模型 在说RPC和HTTP的区别之前，我觉的有必要了解一下OSI的七层网络结构模型（虽然实际应用中基本上都是五层），它可以分为以下几层： （从上到下） 第一层：应用层。定义了用于在网络中进行通信和传输数据的接口； 第二层：表示层。定义不同的系统中数据的传输格式，编码和解码规范等； 第三层：会话层。管理用户的会话，控制用户间逻辑连接的建立和中断； 第四层：传输层。管理着网络中的端到端的数据传输； 第五层：网络层。定义网络设备间如何传输数据； 第六层：链路层。将上面的网络层的数据包封装成数据帧，便于物理层传输； 第七层：物理层。这一层主要就是传输这些二进制数据。 实际应用过程中，五层协议结构里面是没有表示层和会话层的。应该说它们和应用层合并了。我们应该将重点放在应用层和传输层这两个层面。因为 HTTP是应用层协议，而TCP是传输层协议 。好，知道了网络的分层模型以后我们可以更好地理解为什么RPC服务相比HTTP服务要Nice一些！ TCP(Transmission Control

问题描述：在vs2010上重新编译时，发现以下error： 1>------ 已启动生成: 项目: Test, 配置: Debug Win32 ------ 1> stdafx.cpp 1>c:/program files/microsoft sdks/windows/v7.0a/include/objidl.h(11280): error C2061: 语法错误: 标识符“__RPC__out_xcount_part” 1>c:/program files/microsoft sdks/windows/v7.0a/include/objidl.h(11281): error C2059: 语法错误:“)” 1>c:/program files/microsoft sdks/windows/v7.0a/include/objidl.h(11281): fatal error C1903: 无法从以前的错误中恢复；正在停止编译 ========== 生成: 成功 0 个，失败 1 个，最新 0 个，跳过 0 个 ========== 解决过程： 方法1： 把WindowsSDK的包含目录放在最前！ 操作：在项目上单击右键―》属性―》配置属性―》VC＋＋目录，修改“包含目录”，把　$(WindowsSdkDir)include　放在最前。重新编译。问题解决的。 方法2： 解决方法：

RPC 全称 Remote Procedure Call――远程过程调用。在学校学编程，我们写一个函数都是在本地调用就行了。但是在互联网公司，服务都是部署在不同服务器上的分布式系统，如何调用呢？ RPC技术简单说就是为了解决远程调用服务的一种技术，使得调用者像调用本地服务一样方便透明。 下图是客户端调用远端服务的过程： 1）客户端client发起服务调用请求。 2）client stub 可以理解成一个代理，会将调用方法、参数按照一定格式进行封装，通过服务提供的地址，发起网络请求。 3）消息通过网络传输到服务端。 4）server stub接受来自socket的消息 5）server stub将消息进行解包、告诉服务端调用的哪个服务，参数是什么 6）结果返回给server stub 7）sever stub把结果进行打包交给socket 8）socket通过网络传输消息 9）client slub 从socket拿到消息 10）client stub解包消息将结果返回给client。 一个RPC框架就是把步骤2到9都封装起来。 为什么需要RPC 1、首先要明确一点：RPC可以用HTTP协议实现，并且用HTTP是建立在 TCP 之上最广泛使用的 RPC，但是互联网公司往往用自己的私有协议，比如鹅厂的JCE协议，私有协议不具备通用性为什么还要用呢？因为相比于HTTP协议

enable作为模块驱动在Spring Farmework、Spring Boot、Spring Cloud使用，都是通过注解的形式以@enable作为前缀,一些常用注解如 | 框架 | 注解 | 模块 | | --- | --- | --- | | Spring Framework | @EnableWebMvc | Web MVC模块 | | Spring Framework | @EnableTransactionmanagement | Web MVC模块 | | Spring Framework | @EnableCacheing | Cacheing模块 | | Spring Framework | @EnableMBeanExport | JMX模块 | | Spring Framework | @EnableWebFlux | Web Flux模块 | | Spring Framework | @EnableAspectJAutoProxy | AspectJ模块 | | Spring Boot | @EnableAutoConfiguration | 自动装配模块 | | Spring Boot | @EnableWebManagementContext | Actuator模块 | | Spring Boot |

1. 寻找理想的集成技术 首先，我们要考虑的是，我们到底希望从这些技术中得到什么。 有时候，对某个服务做的一些修改会导致该服务的消费方也随之发生改变。但是，我们希望选用的技术可以尽量避免这种情况的发生。 1.2 保证API的技术无关性 保证微服务之间的通信方式的技术无关性是非常重要的。这就意味着，不应该选择哪种对微服务的具体实现技术有限制的集成方式。 1.3 使你的服务易于消费方使用 消费方应该很容易的使用我们的服务。理想情况下，消费方应该可以使用任何技术来实现，从另一方面来说，提供一个客户端库也可以简化消费方的使用。但是通常这种库与其他我们想要得到的东西不可兼得。例如，使用客户端库对于消费方来说很方便，但是会造成耦合的增加。 1.4 隐藏内部实现细节 我们不希望消费方与服务的内部实现细节绑定在一起，因为这会增加耦合。所以，所有倾向于暴露内部实现细节的技术都不应该被采用。 2.为用户创建接口 3.共享数据库 目前业界最常见的集成形式应该就是数据库集成了。使用这种方式时，如果其他服务想要从一个服务获取信息，可以直接访问数据库。如果想要修改，也可以直接在数据库中修改。 这种方式看起来非常简单，而且可能是最快的集成方式，这也是它这么流行的原因。 但是它有一些缺点。 如图，使用数据库集成来访问和修改数据信息 缺点一，首先，这使得外部系统能够查看内部实现细节，并与其绑定在一起

一、Java打日志的基础 以前自己自学的时候，排查问题只会写下面的代码： try { // doSomething } catch ( Exception e ) { e . printStackTrace (); } ---------- // 查看某个数据的值时： System . out . println ( xxxx ); 去到公司就发现上面的代码全不见了，剩下的是： LOGGER . info ( "begin to run Java3y:{}" , id ); ---- LOGGER . error ( "excepiton occurs when run Java3y {}, exception{}" , id , e . toString ()); 如果使用 e.printStackTrace(); 的话，打印在控制的信息分析不方便： 而我们将信息分等级和时间记录在服务器的磁盘上，有问题了就可以根据对应的信息去查找相关的日志(这样排查起来是十分方便的)： 我们再来看一下一般的日志长什么样的 例如：现在有人来反馈某某某用户好像收不到短信，给出发送时间和用户ID，我们就可以在日志上找出该用户在我们系统的发送状态（例如图上的：state:81，我们就认为是发送成功状态) 那么，问题来了，我们在哪打日志？《手册》上其实已经给出了答案： 谨慎地记录日志。生产环境禁止输出

客户端项目中不可避免的要用到进程间的通信，方式也多种多样。单就开发而言，RPC这种模式最方便来做进程间通信的手段。因为类似于本地函数的调用。实现这个机制需要满足以下内容: 接口定义。一个组件是否方便使用，主要是看接口的设计是否简洁合理。 满足本地函数调用的特点:函数未执行完不返回，只需要函数签名和函数参数这些信息。 是否支持一对多。 调用方需要继承RPCService类，构造函数需要传入连接名称，RPCService根据这个名字与被调方建立连接。通过Invoke方法调用远程方法。 Invoke 需要传入要调用的函数名和函数参数，目前支持int double string bool四种参数类型，具体可参考invoke_def.h中的定义。也可以在该文件扩展 GetParam 方法以支持更多参数类型。 要时当前类获取接受能力，还需要有以前步骤: DEF_PROCESS_INVOKE( 类名) 需要在当前类头文件中定义该类可以接受远程调用， BEGIN_INVOKE ( 类名 ) ON_INVOKE_3 ( 函数名 , int , QString , int ) END_INVOKE 以上定义类似MFC中消息路由，用来定义该类中那个函数可以被远程调用，参数为被调用函数名和函数参数类型。ON_INVOKE_数字，数字代表的是参数个数，目前最多支持3个参数的函数，已经满足大部分应用

bitcoin.conf是比特币核心程序bitcoind的配置文件，本文将介绍bitcoin.conf 的默认路径，并给出主要配置项的说明。 在linux下，bitcoin.conf的默认路径为 $HOME/.bitcoin/bitcoin.conf 在windows下，bitcoin.conf的默认路径为 %APPDATA%\bitcoin\bitcoin.conf 在mac下，bitcoin.conf的默认路径为 $HOME/Library/Application Support/Bitcoin/bitcoin.conf bitcoin.conf 。 在bitcoin.conf配置文件中，每行以key=value的形式声明配置项与值， # 之后的内容为注释。 testnet : 连接主网还是测试网： testnet=0 # 0 - 主网 1 - 测试网 regtest ：是否以私有链模式运行 regtest=0 # 0 - 否 1 - 是 proxy ：是否使用socks5代理 #proxy=127.0.0.1:9050 # 默认关闭 bind ：本地监听地址 #bind=<addr> # 注释此行，表示使用默认监听地址 whitebind ：本地白名单监听地址 #whitebind=<addr> # 注释此行，表示使用默认监听地址 addnode ：添加种子节点

微服务的特点 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责； 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但是五脏俱全。 面向服务：面向服务是说每个服务都要对外暴露服务接口API，并不关心服务的技术实现，做到与平台无关、与语言无关，也不限定什么技术实现，只要提供Rest接口即可。 自治：自治是说服务间互相独立，互不干扰； 团队独立：每个服务都是一个独立的开发团队； 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉； 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不再为PC、移动端开发不同接口。 数据库分离：每个服务都使用自己的数据源； 部署独立：服务间虽然由调用，但要做到服务重启不影响其他服务。有利用持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，容易维护。 微服务结构图 远程调用方式 常见的远程调用方式 RPC：Remote Process Call 远程过程调用，类似的还有RMI。自定义数据格式，基于原生TCP通信，速度快，效率高。比如早期的webservice和现在的Dubbo，都是RPC典型； Http:http其实是一种网络传输协议，基于TCP，规定了数据传输的格式，现在客户端浏览器与服务端通信基本都是采用http协议，也可以用来进行远程服务调用，缺点是消息封装臃肿