《分布式服务框架XXL-RPC》
XXL-RPC 是一个分布式服务框架，提供稳定高性能的RPC远程服务调用功能。拥有"高性能、分布式、注册中心、负载均衡、服务治理"等特性。现已开放源代码，开箱即用。
特性：
- 1、快速接入：接入步骤非常简洁，两分钟即可上手；
- 2、服务透明：系统完整的封装了底层通信细节，开发时调用远程服务就像调用本地服务，在提供远程调用能力时不损失本地调用的语义简洁性；
- 3、多调用方案：支持 SYNC、ONEWAY、FUTURE、CALLBACK 等方案；
- 4、多通讯方案：支持 TCP 和 HTTP 两种通讯方式进行服务调用；其中 TCP 提供可选方案 NETTY 或 MINA ，HTTP 提供可选方案 NETTY_HTTP 或 Jetty；
- 5、多序列化方案：支持 HESSIAN、HESSIAN1、PROTOSTUFF、KRYO、JACKSON 等方案；
- 6、负载均衡/软负载：提供丰富的负载均衡策略，包括：轮询、随机、LRU、LFU、一致性HASH等；
- 7、注册中心：可选组件，支持服务注册并动态发现；可选择不启用，直接指定服务提供方机器地址通讯；选择启用时，内置可选方案：“XXL-REGISTRY 轻量级注册中心”（推荐）、“ZK注册中心”、“Local注册中心”等；
- 8、服务治理：提供服务治理中心，可在线管理注册的服务信息，如服务锁定、禁用等；
- 9、服务监控：可在线监控服务调用统计信息以及服务健康状况等（计划中）；
- 10、容错：服务提供方集群注册时，某个服务节点不可用时将会自动摘除，同时消费方将会移除失效节点将流量分发到其余节点，提高系统容错能力。
- 11、解决1+1问题：传统分布式通讯一般通过nginx或f5做集群服务的流量负载均衡，每次请求在到达目标服务机器之前都需要经过负载均衡机器，即1+1，这将会把流量放大一倍。而XXL-RPC将会从消费方直达服务提供方，每次请求直达目标机器，从而可以避免上述问题；
- 12、高兼容性：得益于优良的兼容性与模块化设计，不限制外部框架；除 spring/springboot 环境之外，理论上支持运行在任何Java代码中，甚至main方法直接启动运行；
- 13、泛化调用：服务调用方不依赖服务方提供的API；
官方文档
技术交流
-
原因： 这是由于docker部署xxljob时将xxl-job-admin与自己开发的执行器程序分别部署到两个容器内，而容器内网络端口互不相通导致； 最简单而且实际可行的解决办法是使用宿主机网络，将端口映射到容器外去。如图所示 version: '3' services: xxl-job-admin-member-dev: #image: xuxueli/xxl-job-admin:2
-
XXL JOB 间断性报错 com.xxl.rpc.util.XxlRpcException: xxl-rpc request data empty 如何解决 如果觉得本文对你有帮助，可以一键三连支持，谢谢 传送门 Portal XXL JOB Portal XXL JOB 版本更新说明
-
使用本地网络进行连接，导致的无法注册。 报错信息 address：http://192.168.x.xxx:9999/ code：500 msg：xxl-rpc remoting error(connect timed out), for url : http://192.168.x.xxx:9999/run 解决方案 1.将自动注册转为手动注册 2.使用内网穿透工具 3.将手动注册地址填写为内网
-
原因很简单，之前用的xxl-job-core的版本是2.0.2，怎么调都不行。解决方法也很暴力，直接版本升级到2.3.0，把注解都替换成最新的，如下： 类上的JobHandler去掉，改到方法上用Xxl-Job注解； XxlJobLogger改为XxlJobHelper； 之前集成的 extends IJobHandler也不需要继承了。 改完这些之后，重启项目就注册成功了。 喜欢本文的朋友不要忘
-
liunx端口被占用xxl-rpc provider port[xxxx] is used. 提示：这里简述项目相关背景： 例如：项目场景：生产环境出现端口被占用。 解决方案： 1：打开liunx终端输入，netstat -tln | grep 被占用的端口 示列：netstat -tln | grep 9999 2：输入lsof -i : 被占端口 lsof -i:9999 3：输入kill -
-
@[TOC](xxl-job远程调度连接超时问题xxl-rpc remoting error(connect timed out), for url ) 目前公司项目采用了xxl-job定时调度任务，但是在维护的时候出现了一些BUG 因为代码有很多分支，分别部署在不同的服务器上，但是只部署了一个xxl-job-admin在其中一个服务器上，各个服务器上的项目部署成功后，执行器和定时任务都能注册成功
-
主要内容：1.RPC流水线工程,2.RPC 技术选型,3.如何设计 RPC1.RPC流水线工程 ① Client以本地调用的方式调用服务 ② Client Stub接收到调用后，把服务调用相关信息组装成需要网络传输的消息体，并找到服务地址（host:port），对消息进行编码后交给Connector进行发送 ③ Connector通过网络通道发送消息给Acceptor ④ Acceptor接收到消息后交给Server Stub ⑤ Server Stub对消息进行解码，
-
distributed RPC（分布式RPC） (DRPC) 的设计目的是充分利用Storm的计算能力实现高密度的并行实时计算。Storm topology（拓扑）接受若干个函数参数作为输入，然后输出这些函数调用的结果。 严格的来说，DRPC不能够算作Storm的一个特性，因为它是一种基于Storm 原语（Stream，Spout，Bolt，Topology）实现的设计模式。DRPC可以脱离Sto
-
问题内容： 您将使用哪种分布式锁定服务？ 要求是： 可以从不同的进程/机器看到的互斥（锁定） 锁定…释放语义 超时后自动释放锁-如果锁持有人死亡，它将在X秒后自动释放 Java实现 很高兴拥有：.Net实现 如果免费：死锁检测/缓解 易于部署，请参阅下面的注释。 我对诸如“可以通过数据库完成”或“可以通过JavaSpaces完成”之类的答案不感兴趣-我知道。我对现成的，现成的，经过验证的实现感兴趣
-
链接 Web API Controllers 动态WebApi层 集成OData 集成Swagger UI ASPNET Core 集成OData
-
随着分布式技术和微服务思想流行，技术公司逐步将服务拆分为独立运行的小模块，提高系统整体的健壮性，加快特性的演进速度。微服务通过定义完善的接口进行交互，解耦系统、敏捷迭代、方便服务治理。RPC是目前微服务最广泛的通信方式。然而，众多团队各自研发具备服务治理功能的RPC通信框架，一方面增加开发成本，消耗人力重复造轮子；另一方面不同序列化协议的RPC服务，无法互相通信，影响可用性。因此，通用的RPC通信
-
对服务开发者， MTransport 屏蔽了底层网络通信细节，从而更专注于业务自身逻辑实现。支持不同语言版本的代码实现， 保持通信协议的一致性，支持服务注册、服务发现、异步通信、负载均衡等丰富的服务治理功能。