我所在公司的项目是采用基于Restful的微服务架构,随着微服务之间的沟通越来越频繁,就希望可以做成用rpc来做内部的通讯,对外依然用Restful.于是就想到了google的grpc. 使用grpc的优点很多,二进制的数据可以加快传输速度,基于http2的多路复用可以减少服务之间的连接次数,和函数一样的调用方式也有效的提升了开发效率. 不过使用grpc也会面临一个问题,我们的微服务对外一定是要提供Restful接口的,如果内部调用使用grpc,在某些情况下要同时提供一个功能的两套API接口,这

微服务设计的原则是单一职责.轻量级通信.服务粒度适当,而说到服务通信,我们熟知的有MQ通信,还有REST.Dubbo和Thrift等,这次我来说说gRPC, 谷歌开发的一种数据交换格式,说不定哪天就需要上了呢,多学习总是件好事. 准备: Idea2019.03/Gradle6.0.1/Maven3.6.3/JDK11.0.4/Proto3.0/gRPC1.29.0 难度: 新手--战士--老兵--大师 目标: 实现四种模式下的gRPC通信 说明: 为了遇见各种问题,同时保持时效性,我尽量使用最新

背景 最近,上线的采集器忽然时有OOM.采集器本质上是一个grpc服务,网络设备通过grpc协议将数据上报后,采集器进行格式等整理后,发往下一个系统(比如分析,存储). 打开运行环境,发现特性如下: 每个采集器实例,会有数千个设备相连.并且会建立一个双向 grpc stream,用以上报数据. cpu的负载并不高,但内存居高不下. 初步猜想,内存和stream的数量相关,下面来验证一下. 优化内存 这次,很有先见之明的在上线就部署了pprof.这成为了线上debug的关键所在. import _

最近添哥一直反映,他手下的设备以grpc stream的方式向我服务端发送数据.偶然会收到错误.现象如下: 连接已经建立了一段时间,正常使用. 突然client.Send 返回 eof. 客户端有报错:connection reset by peer 在服务端找到错误:context canceled 这里不得不提一下,客户端上报到服务的网络环境并不是很好,而且服务端每个进程有数十万个协程在运行,处理上十万条grpc stream. 选取了几个设备在服务端与客户端tcpdump,通过七七四十九天

package: } ,) ), ), ) ) , ];]]] :] ].Err()]:] ].Kv.ModRevision         w.resuming = append(w.resuming, ws)     }     // strip out nils, if any     var resuming []*watcherStream     for _, ws := range w.resuming {         if ws != nil {             re

2019年12月12日13:05:16 声明:从网络中学习整理实践而来. 1.介绍fabric Fabric 是一个面向企业应用的区块链框架,基于 Fabric 的开发可以粗略分为几个层面: 1. 参与 Fabric 的底层开发,这主要是 fabric,fabric-ca 和 sdk 等核心组件. 2. 参与 Fabric 周边生态的开发,如支持如支持 fabric 的工具 explorer, composer 等. 3. 利用 fabric 平台开发应用,这就是利用 fabirc 提供的各种

Dapr是为云上环境设计的跨语言, 事件驱动, 可以便捷的构建微服务的系统. balabala一堆, 有兴趣的小伙伴可以去了解一下. Dapr提供有状态和无状态的微服务. 大部分人都是做无状态服务(微服务)的, 只是某些领域无状态并不好使, 因为开销实在是太大了; 有状态服务有固定的场景, 就是要求开销小, 延迟和吞吐都比较高. 废话少说, 直接来看Dapr是怎么实现有状态服务的. 先来了解一下有状态服务: 1. 稳定的路由 发送给A服务器的请求, 不能发给B服务器, 否则就是无状态的 2. 状

转载请声明出处哦~,本篇文章发布于luozhiyun的博客:https://www.luozhiyun.com 本文使用的Istio源码是 release 1.5. 介绍 Discovery Service主要为数据面(运行在 sidecar 中的 Envoy 等 proxy 组件)提供控制信息服务.Discovery Service为数据面提供的信息叫做xds ,这里的 x 是一个代词,在 Istio 中,xds 包括 cds(cluster discovery service).lds(li

作者 李腾飞,腾讯容器技术研发工程师,腾讯云TKE后台研发,SuperEdge核心开发成员. 杜杨浩,腾讯云高级工程师,热衷于开源.容器和Kubernetes.目前主要从事镜像仓库,Kubernetes集群高可用&备份还原,以及边缘计算相关研发工作. SuperEdge 介绍 SuperEdge 是 Kubernetes 原生的边缘容器方案,它将 Kubernetes 强大的容器管理能力扩展到边缘计算场景中,针对边缘计算场景中常见的技术挑战提供了解决方案,如:单集群节点跨地域.云边网络不可靠.边

基于XDS协议实现控制面板与数据面板通信分享 基于这段时间在同程艺龙基础架构部的蹲坑,聊一聊微服务治理的核心难点.历史演进.最新动态, 以上内容属自我思考,不代表同程艺龙技术水准.如理解有偏差.理解不透彻.现状梳理不清楚的请大家多指教. 大纲 微服务治理的核心难点 方案演进的法宝: 代理模式 2.1 集中式代理 2.2 客户端嵌入Sdk代理 2.3 主机独立进程 Service Mesh是模式三 3.1 目前现状 & 建议取舍 istio是一种开源的Service Mesh实现 4.1 关键能力

etcd中watch的源码解析 前言 client端的代码 Watch newWatcherGrpcStream run newWatchClient serveSubstream server端的代码实现 watchableStore syncWatchersLoop syncWatchers syncVictimsLoop moveVictims watchServer recvLoop sendLoop 连接复用 总结 etcd中watch的源码解析 前言 etcd是一个cs网络架构,源码

引言 在石墨文档的部分业务中,例如文档分享.评论.幻灯片演示和文档表格跟随等场景,涉及到多客户端数据同步和服务端批量数据推送的需求,一般的 HTTP 协议无法满足服务端主动 Push 数据的场景,因此选择采用 WebSocket 方案进行业务开发. 随着石墨文档业务发展,目前日连接峰值已达百万量级,日益增长的用户连接数和不符合目前量级的架构设计导致了内存和 CPU 使用量急剧增长,因此我们考虑对网关进行重构. 网关 1.0 网关 1.0 是使用 Node.js 基于 Socket.IO 进行修改

Gossip算法正如它的名字,小道消息只需要有人传播一次,那么过一段时间,所有人都会知道,就像新冠病毒一样,所以Gossip算法也有其它的别名"传染病扩散算法"."谣言传播算法"等等.在Fabric中Gossip算法用于区块的传播,即共识后将得到的区块广播给组织内和其它组织.本节会介绍Gossip算法的设计原理.数据结构和部分核心源码的实现,例如Push算法.Pull算法等. 1. 设计原理 Gossip协议可以抽象成广播,即发送节点向其它节点传播同样的消息.在节点

SkyWalking的OAP(Observability Analysis Platform,观测分析平台)是一个用于链路数据的分布式计算系统. 因为它巧妙的设计,使得在链路数据计算和聚合过程中,不需要考虑数据的一致性,也没有事务.分布式锁等概念. 在极端情况下,可能出现链路数据的丢失,但会最大限度保障OAP集群的可用性.咱们来看一下,它是如何设计的,为以后的系统设计和架构提供一些思路. 数据类型 在介绍分布式计算之前,咱们先了解一下需要计算的数据都有哪些类型: Record数据,即明细数据,如

转载自:https://mp.weixin.qq.com/s?__biz=MzU4MjQ0MTU4Ng==&mid=2247492144&idx=1&sn=a1cc13a6423fe50173856bfc898e8d77&chksm=fdbaed2dcacd643b0d3e5a8ff66053f3872077faf1c2a0624b9ea5db0eca82a6ff75034080fe&cur_album_id=1837018771652149250&scen

引子 前几天看到微信后台团队分享了TLS相关文章,正好gRPC里TLS数据加密是很重要的一块,于是整理出了这篇文章. 在gRPC里,如果仅仅是用来做后端微服务,可以考虑不加密.本文太长,先给个大纲. 1. HTTPS,HTTP/2介绍 2. TLS加密原理.实现库 3. HTTP/2协议协商机制 4. 自建数字证书(CA) 5. gRPC使用TLS 1. HTTP/1.x 目前绝大多数网站和APP都是建立在HTTP之上的,所有的数据都是明文传输,没有任何安全可言. 网图 2. HTTPS HTT

前置条件: 获取 gRPC-go 源码 $ go get google.golang.org/grpc 简单例子的源码位置: $ cd $GOPATH/src/google.golang.org/grpc/examples/helloworld 复杂些例子的源码位置: $ cd $GOPATH/src/google.golang.org/grpc/examples/route_guide 写一个gRPC的服务,一般分下面几步: 在一个 .proto 文件内定义服务. 用 protocol buf

grpc入门(一) 一.什么是grpc grpc是谷歌开源的一款高性能的rpc框架 (https://grpc.io),可以使用protocol buffers作为IDL(Interface Definition Language)文件,也可以作为底层的信息传输的格式(这也是本博文所介绍的方式). 以下内容属于笔者对 what is grpc? 的翻译,原文请见: https://grpc.io/docs/guides/index.html. grpc的客户端应用可以像访问本地方法一样调用其他机

grpc入门(二) 一. 目标 本博文要介绍的是编写 grpc入门(一)中所提到的四种rpc的方式,然后通过命令行和eclipse两种方式生成对应的java代码,关于grpc是什么东西本文不再赘述. 二. proto文件的编写 声明:如下所编写的proto文件没有实际的业务价值,只是为了技术而谈技术,望大神勿键下留情,如有错误之处,欢迎留言指正. protocol buffers的官网为:https://developers.google.com/protocol-buffers/, 以下的pr

一,从rpc接口的定义说起,下面给一个最简单的grpc示例--hello world 在这个rpc横行的世界里,实现一个rpc很重要的一件事就是定义一个好接口,一个好的接口定义会让你省去很多麻烦.熟悉protobuf的人应该知道它所用的结构体都是用.proto文件来描述的: // Copyright 2015 gRPC authors. // // Licensed under the Apache License, Version 2.0 (the "License"); // yo

接着上期讨论的gRPC unary服务我们跟着介绍gRPC streaming,包括: Server-Streaming, Client-Streaming及Bidirectional-Streaming.我们首先在.proto文件里用IDL描述Server-Streaming服务: /* * responding stream of increment results */ service SumOneToMany { rpc AddOneToMany(SumRequest) returns