grpc

什么是 RPC ？ RPC (Remote Procedure Call)即远程过程调用，是分布式系统常见的一种通信方法，已经有 40 多年历史。当两个物理分离的子系统需要建立逻辑上的关联时，RPC 是牵线搭桥的常见技术手段之一。除 RPC 之外，常见的多系统数据交互方案还有分布式消息队列、HTTP 请求调用、数据库和分布式缓存等。 其中 RPC 和 HTTP 调用是没有经过中间件的，它们是端到端系统的直接数据交互。HTTP 调用其实也可以看成是一种特殊的 RPC，只不过传统意义上的 RPC 是指长连接数据交互，而 HTTP 一般是指即用即走的短链接。 RPC 在我们熟知的各种中间件中都有它的身影。Nginx/Redis/MySQL/Dubbo/Hadoop/Spark/Tensorflow 等重量级开源产品都是在 RPC 技术的基础上构建出来的，我们这里说的 RPC 指的是广义的 RPC，也就是分布式系统的通信技术。RPC 在技术中的地位好比我们身边的空气，它无处不在，但是又有很多人根本不知道它的存在。 本地过程调用 RPC就是要像调用本地的函数一样去调远程函数。在研究RPC前，我们先看看本地调用是怎么调的。假设我们要调用函数Multiply来计算lvalue * rvalue的结果: 1 int Multiply(int l, int r) { 2 int y = l * r;

作者 | 雷卷 来源| 阿里巴巴云原生公众号 RSocket 分布式通讯协议是 Spring Reactive 的核心内容，从 Spring Framework 5.2 开始，RSocket 已经是 Spring 的内置功能，Spring Boot 2.3 也添加了 spring-boot-starter-rsocket，简化了 RSocket 的服务编写和服务调用。RSocket 通讯的核心架构中包含两种模式，分别是 Broker 代理模式和服务直连通讯模式。 Broker 的通讯模式更灵活，如 Alibaba RSocket Broker，采用的是事件驱动模型架构。而目前更多的架构则是面向服务化设计，也就是我们常说的服务注册发现和服务直连通讯的模式，其中最知名的就是 Spring Cloud 技术栈，涉及到配置推送、服务注册发现、服务网关、断流保护等等。在面向服务化的分布式网络通讯中，如 REST API、gRPC 和 Alibaba Dubbo 等，都与 Spring Cloud 有很好地集成，用户基本不用关心服务注册发现和客户端负载均衡这些底层细节，就可以完成非常稳定的分布式网络通讯架构。 RSocket 作为通讯协议的后起之秀，核心是二进制异步化消息通讯，是否也能和 Spring Cloud 技术栈结合，实现服务注册发现、客户端负载均衡，从而更高效地实现面向服务的架构

etcd 原理解析：读《etcd 技术内幕》这篇文章主要是原理性的内容，本文主要是实践角度，谈谈平时用到的一些操作和监控 高可用 etcd 是基于 raft算法的分布式键值数据库，生来就为集群化而设计的，由于Raft算法在做决策时需要超半数节点的投票，所以etcd集群一般推荐奇数节点，如3、5或者7个节点构成一个集群。 以上是etcd集群部署的基础概念，但是还需要注意以下问题： 选主过程 etcd 是高可用的，允许部分机器故障，以标准的3 节点etcd 集群，最大容忍1台机器宕机，下面以最简单的leader宕机来演示raft 的投票逻辑，以实际的运行日志来验证并理解。更多的场景可以看之前的原理解析 场景：正常运行的三台etcd：100、101、102。当前任期为 7，leader 为 101机器。现在使101 宕机 宕机前：101 为 leader，3 个 member 宕机后：102 成为新 leader，2 个 member 过程： 将 101 机器的 etcd 停止，此时只剩 2 台，但总数为 3 101停止etcd 的运行 102(91d63231b87fadda) 收到消息，发现101(8a4bb0af2f19bd46)心跳超时，于是发起了新一轮选举，任期为 7+1=8 91 d63231b87fadda [term 7 ] received MsgTimeoutNow

点击上方 蓝色字体 ，选择“标星公众号” 优质文章，第一时间送达 作者： 架构师笔记 来源： http://suo.im/5D3PnG 1.背景 1.1 线程模型的重要性 对于 RPC 框架而言，影响其性能指标的主要有三个要素： I/O 模型：采用的是同步 BIO、还是非阻塞的 NIO、以及全异步的事件驱动 I/O(AIO)。 协议和序列化方式：它主要影响消息的序列化、反序列化性能，以及消息的通信效率。 线程模型：主要影响消息的读取和发送效率、以及调度的性能。 除了对性能有影响，在一些场景下，线程模型的变化也会影响到功能的正确性，例如 Netty 从 3.X 版本升级到 4.X 版本之后，重构和优化了线程模型。当业务没有意识到线程模型发生变化时，就会踩到一些性能和功能方面的坑。 1.2 Netty 和 RPC 框架的线程模型关系 作为一个高性能的 NIO 通信框架，Netty 主要关注的是 I/O 通信相关的线程工作策略，以及提供的用户扩展点 ChannelHandler 的执行策略，示例如下： 图 1 Netty 多线程模型 该线程模型的工作特点如下： 有专门一个（一组）NIO 线程 -Acceptor 线程用于监听服务端，接收客户端的 TCP 连接请求。 网络 I/O 操作 - 读、写等由一个 NIO 线程池负责，线程池可以采用标准的 JDK 线程池实现，它包含一个任务队列和

KubeCon+CloudNativeCon，作为由云原生计算基金会（CNCF）发起的最盛大的会议，聚焦着全世界关注云原生领域的目光。 自2016年起，在欧洲、北美等地举办以来，本论坛受到了Kubernetes大牛、开发者、厂商等全球开源技术爱好者的强力追捧。 2018年11月13-15日，KubeCon+CloudNativeCon 2018论坛将首次亮相中国上海，这无疑是对中国技术实力的认可，同时，中国程序员们也将可以在上海跨国采购会展中心共同参与这场顶尖的国际技术盛会。 KubeCon+CloudNativeCon 2018中国论坛作为CNCF的旗舰论坛，得到了Liz Rice、Janet Kuo等大咖的大力支持与推荐。本论坛精彩日程现已出炉，看看你关注的议题和大咖！ 本次论坛为期三天，预计将吸引开发人员、架构师、技术负责人、首席信息官、首席技术官、媒体和分析师等2500多人到场，以主题演讲、分论坛以及展位等形式全方位地为大家打造一场精彩绝伦的技术盛宴。 KubeCon+CloudNativeCon 2018中国论坛将聚焦云原生领域的最新技术动态，CNCF的重点项目Kubernetes、Prometheus、OpenTracing、Fluentd、gRPC、containerd、rkt、CNI、Envoy、Jaeger、Helm等多个项目也将悉数亮相。另外

最近遇到 grpc 客户端报错 rpc error: code = Unavailable desc = transport is closing ，原因是连接长时间没有使用，被服务端断开，这种情况通过简单粗暴的重试策略可以解决，更加优雅的解决方案是增加保持连接策略 服务端 var kaep = keepalive.EnforcementPolicy{ MinTime: 5 * time.Second, // If a client pings more than once every 5 seconds, terminate the connection PermitWithoutStream: true, // Allow pings even when there are no active streams } var kasp = keepalive.ServerParameters{ MaxConnectionIdle: 15 * time.Second, // If a client is idle for 15 seconds, send a GOAWAY MaxConnectionAge: 30 * time.Second, // If any connection is alive for more than 30 seconds, send a GOAWAY

一、分布式链路追踪可以做什么？ 1.1：简单集群架构&微服务架构 先来看下最简单的网站集群架构图： 图1 在这个图里，存在从1~n个服务器，通过负载均衡器SLB进行请求分发，在每个服务器里，都做同一件事情。 现在来看下这个系统的具体业务逻辑（就是 图1 中每台服务器执行的逻辑，这里是假设其中一个业务接口的处理， 真实系统中可能存在n多业务接口 ）： 图2 图2 是对系统中某一个接口（API）的逻辑做了描述，假设处理流程就是请求一次Redis服务，然后做下处理，然后再请求下Memecached服务，在做下业务处理，后续可能还有其他各种业务逻辑，我们统称为逻辑块。 现在假设这个接口存在性能问题，那么找对应开发负责人排查是比较容易的，因为服务器只执行一套逻辑，瓶颈点一定发生在当前接口对应代码里的某个点，那么就找接口对应的负责人去排查优化即可。 但是当业务发展到一定的程度，比如上述单系统逻辑越来越复杂（业务接口越来越多，逻辑越来越复杂），就会造成很多我们不愿意看到的问题发生： ① 每一次微小的改动都需要整体走一次打包、发版的流程，对测试也是种负担，因为n多个人如果同时开发不同的功能，这时候就会对测试和发布流程造成很大的困扰。 ② 如果因为做某次活动，某一个接口可能引入大量请求，需要紧急扩容，那么只能对整体扩容（因为该接口与其他接口都处于同一个系统中）。 ③ 系统各模块高度耦合