我想开发录制回放、故障模拟、动态日志、行链路获取等等工具,gRPC 调用是通过 HTTP POST

摘要NGINX 官方博客正式宣布 NGINX 支持原生的
gPRC,现在就可以从代码仓库拉取快照版本。该特性将会被包含在 NGINX OSS
1.13.10、NGINX Plus R15 以及 NGINX 1.13.9 当中。引言NGINX
官方博客正式宣布 NGINX 支持原生的
gPRC,现在就可以从代码仓库拉取快照版本。该特性将会被包含在 NGINX OSS
1.13.10、NGINX Plus R15 以及 NGINX 1.13.9
当中(博客原文链接:
已经能够代理 gRPC TCP 连接,用户可以用它:发布 gRPC 服务,并应用 NGINX
提供的 HTTP/2 TLS 加密机制、速率限定、基于 IP
的访问控制以及日志等功能。在单个端点上发布多个 gRPC 服务,使用 NGINX
检查方法调用,将各个方法调用路由到相应的服务上。对一组 gRPC
服务进行负载均衡,可以使用轮询算法、最少连接数原则或其他方式在集群上分发流量。什么是
gRPC?gRPC
是一种远程过程调用协议(gRPC官网:
3.x,基于Netty 4.x +,用于客户端和服务器端之间的通信。gRPC
紧凑小巧,跨多种编程语言,同时支持请求与响应式的交互方式和流式交互方式。gRPC
因其跨语言特性和简洁的设计变得越来越流行,其中服务网格的实现就使用了
gRPC。gRPC 通过 HTTP/2 传输数据,可以传输明文文本数据和 TLS
加密过的数据。gRPC 调用是通过 HTTP POST
请求来实现的,每个请求里包含了一个编码过的消息体(protocol buffer
是默认的编码方式)。gRPC
的响应消息里也包含一个编码过的消息体,并在消息尾部带上状态码。gRPC
不能通过 HTTP 进行传输,而必须使用 HTTP/2,这是因为要充分利用 HTTP/2
连接的多路复用和流式特性。通过 NGINX 来管理 gRPC 服务下面的示例对 gRPC
的 Hello World
快速入门教程进行了修改,用它来创建一个简单的客户端到服务器端应用。例子中提供了
NGINX
的配置信息,而把应用程序的实现留给读者,不过文中还是会给出一些提示。1、暴露简单的
gRPC 服务首先,在客户端和服务器端之间安插 NGINX,NGINX
为服务器端的应用程序提供了一个稳定可靠的网关。然后开始部署包含了 gRPC
更新包的 NGINX。如果要从源代码开始编译 NGINX,要记得把 http_ssl 和
http_v2 两个模块包含进去:$ auto/configure –with-http_ssl_module
—with-http_v2_moduleNGINX 使用一个 HTTP 服务器来监听 gRPC 流量,并使用
grpc_pass 指令来代理 gRPC 流量。像下面的配置那样,在 80
端口上监听未加密的 gRPC 流量,并把请求重定向到 50051 端口上:http {
log_format main ‘$remote_addr – $remote_user [$time_local]
“$request” ‘ ‘$status $body_bytes_sent “$http_referer” ‘
‘”$http_user_agent”‘; server { listen 80 http2; access_log
logs/access.log main; location / { # Replace localhost:50051 with the
address and port of your gRPC server # The ‘grpc://’ prefix is
optional; unencrypted gRPC is the default grpc_pass
grpc://localhost:50051; } }}要确保 grpc_pass
的地址是正确的。然后重新编译客户端,让它指向 NGINX 的 IP
地址和端口。在运行新的客户端时,可以看到与之前一样的响应消息,不过这时
NGINX 会终断和转发事务。这个可以从访问日志中看出来:$ tail
logs/access.log192.168.20.1 – – [01/Mar/2018:13:35:02 +0000] “POST
/helloworld.Greeter/SayHello HTTP/2.0” 200 18 “-”
“grpc-go/1.11.0-dev”192.168.20.1 – – [01/Mar/2018:13:35:02 +0000]
“POST /helloworld.Greeter/SayHelloAgain HTTP/2.0” 200 24 “-”
“grpc-go/1.11.0-dev”要注意,NGINX 不支持在同一个明文(非
TLS)端口上同时使用 HTTP/1 和
HTTP/2,如果一定要同时使用两种版本的协议,需要分别为它们创建不同的端口。2、发布基于
TLS 的 gRPC 服务Hello World 快速入门教程使用的是未加密的
HTTP/2,这样方便测试和部署,但要部署到生产环境就不能这么简单了。可以通过
NGINX 来增加一个加密层:创建一个自签名的证书对,然后修改 NGINX
服务器的配置如下:server { listen 1443 ssl http2; ssl_certificate
ssl/cert.pem; ssl_certificate_key ssl/key.pem; #…}让 gRPC
客户端使用 TLS,连接到 1443
端口,并禁用证书检查——这在使用自签名证书或未经信任的证书时是一个必要的步骤。例如,如果使用了
Go 语言编写的示例,就需要导入 crypto/tls 和
google.golang.org/grpc/credentials,并修改 grpc.Dial() 方法:creds :=
credentials.NewTLS( &tls.Config{ InsecureSkipVerify: true } )//
记得修改地址,使用新的端口conn, err := grpc.Dial( address,
grpc.WithTransportCredentials( creds ) )这样就可以加密 gRPC
流量了。在部署到生产环境时,需要将自签名证书换成由可信任证书机构发布的证书,客户端也需要配置成信任该证书。3、代理加密的
gRPC 服务有时候可能需要在内部对 gRPC
流量进行加密,那么就要修改服务器端应用程序的配置,把原先监听未加密(grpc)连接改为监听
TLS 加密(grpcs)连接。cer, err := tls.LoadX509KeyPair( “cert.pem”,
“key.pem” )config := &tls.Config{ Certificates: []tls.Certificate{cer}
}lis, err := tls.Listen( “tcp”, port, config )在 NGINX 的配置里,需要将
grpc-pass 配置成上游服务器的地址:# Use grpcs for TLS-encrypted gRPC
trafficgrpc_pass grpcs://localhost:50051;4、路由 gRPC
流量如果同时存在多个 gRPC
服务,并且每个服务是由不同的服务器应用程序提供的,那么该怎么办?如果能够将这些服务通过单个
TLS 端点暴露出来是不是更好?在 NGINX
里,可以对服务和它的方法稍作修改,然后使用 location 指令来路由流量。gRPC
的请求 URL 是使用包名、服务名和方法名来生成的。比如这个叫作 SayHello 的
RPC 方法:package helloworld;service Greeter { rpc SayHello
(HelloRequest) returns (HelloReply) {}}调用这个方法就会生成一个 POST
请求,URL 是
/helloworld.Greeter/SayHello,这个可以从日志中看出来:192.168.20.1 – –
[01/Mar/2018:13:35:02 +0000] “POST /helloworld.Greeter/SayHello
HTTP/2.0” 200 18 “-” “grpc-go/1.11.0-dev”要使用 NGINX
来路由流量,可以这样配置:location /helloworld.Greeter { grpc_pass
grpc://192.168.20.11:50051;}location /helloworld.Dispatcher { grpc_pass
grpc://192.168.20.21:50052;}location / { root html; index index.html
index.htm;}6、对 gRPC 流量进行负载均衡那么该如何增加 gRPC
服务的容量,以便提供高可用性?可以使用 NGINX 的 upstream 组:upstream
grpcservers { server 192.168.20.21:50051; server
192.168.20.22:50052;}server { listen 1443 ssl http2; ssl_certificate
ssl/certificate.pem; ssl_certificate_key ssl/key.pem; location
/helloworld.Greeter { grpc_pass grpc://grpcservers; error_page 502 =
/error502grpc; } location = /error502grpc { internal; default_type
application/grpc; add_header grpc-status 14; add_header grpc-message
“unavailable”; return 204; }}当然,如果上游监听的是 TLS 端口,可以使用
grpc_pass grpcs://upstreams。NGINX
支持多种负载均衡算法,其内置的健康检测机制可以检测到无法及时响应或发生错误的服务器,并把它们移除。如果没有可用的服务器,就会返回
/error502grpc 指定的错误消息。

摘要声网SDK 2.2版于2018年05月08日发布。声网 Agora.io 是为 App
开发者提供全球范围实时音视频通信服务的云服务商简介以下是来自声网官方网站的介绍:声网
Agora.io 是首家为 App
开发者提供全球范围实时音视频通信服务的服务商,在全球部署了近 100
个数据中心,搭建 SD-RTN™(Software Defined Real Time
Network)这个专为「实时」所设计的虚拟通信网,来极大优化全球范围内的实时传输。声网Agora.io
为开发者提供有质量保证 QoE 的实时云服务。声网 Agora.io 于 2014
年成立,隶属于上海兆言网络科技有限公司,总部位于硅谷,研发中心位于上海。团队
90% 均为全球技术工程师,包括苹果Apple 视频算法架构师、Vidyo
产品负责人、Polycom 工程总监等,平均行业经验 10
年以上,团队有年服务数千亿分钟音视频通话经验和千万级并发的互联网直播经验。更新内容声网Agora
语音通话+直播SDK、视频通话+直播SDK,以及录制SDK现已升级至2.2版本,请注意及时更新。Native
SDK新 增 功 能1.
音效混响进频道播放音效playEffect接口新增了一个publish参数,用于在播放音效时,远端用户可以听到本地播放的音效。2.
服务端部署代理服务器通过部署 Agora
提供的代理服务器安装包,设有企业防火墙的用户可以设置代理服务器,使用
Agora 的服务。3.
获取远端视频状态新增onRemoteVideoStateChanged接口,以获知远端视频流的状态。4.
直播添加视频水印在本地直播及旁路直播中增加水印功能,允许用户将一张 PNG
图片作为水印添加到正在进行的本地直播或旁路直播中。新增addVideoWatermark和clearVideoWatermarks接口,以添加或删除本地直播水印;LiveTranscoding接口中新增watermark参数,用于控制旁路直播中水印的添加。功
能 改 进1.
当前说话者音量提示改进enableAudioVolumeIndication接口的功能,无论频道内是否有人说话,都会在回调中按设置的时间间隔返回说话者音量提示。2.
频道内网络质量监测根据用户对频道内实时网络质量监测测的需求,在onNetworkQuality中改进了返回数据的准确度。3.
进入频道前网络条件监测为方便用户在进频道前检查当前网络是否能支撑语音或视频通话,在onLastmileQuality中,由通过恒定码率监测优化为根据用户设定的
Video Profile 的码率进行监测,提高返回数据的准确度。且在网络状态为
unknown 时,依然以 2 秒的间隔返回回调。4.
提升音乐场景下的音质提升了用户在播放音乐等场景下的音乐音质。5. 支持
Bitcode(此功能仅支持iOS)新增支持 Bitcode 功能。支持 Bitcode 的 SDK
包大小约为普通包的 2.5 倍;使用 Bitcode 开发的 App 在上传 App Store
后,App Store 会对其进行优化及瘦身,瘦身程度视 App
的代码量而定,代码量越大,瘦身程度越高。Web SDK新 增 功 能1.
获取版本信息支持获取当前使用的 SDK 版本信息。2.
设置小流参数新增设置小流参数接口,允许对小流参数进行配置。3. Firefox
浏览器屏幕共享新增 Firefox
浏览器屏幕共享功能,通过在createStream方法中增加 mediaSource
参数实现。4. QQ 浏览器支持新增对 QQ 浏览器的支持。录制 SDK修 复 问
题主要修复了以下问题:修复了日志 size
过大的问题;修复了录制过程中视频快进的异常问题;修复了某些间歇性故障;声网链接下载地址:

摘要阿里巴巴于近期正式开源了其自研的动态非侵入AOP解决方案:JVM-Sandbox。JVM-Sandbox即JVM沙箱容器,一种JVM的非侵入式运行期AOP解决方案。写在前面随着软件部署规模的扩大,系统的功能的细化,系统间耦合度和链路复杂度不断加强。若要继续保持现规模系统的稳定性,需要实现并完善监控体系、故障定位分析、流量录制回放、强弱依赖检测、故障演练等支撑工具平台。出于对服务器规模和业务稳定性的考量,这些配套工具平台要具备对目标应用具有无侵入、实时生效、动态可插拔的特点。要实现这些,多少都会触及到一块底层技术——动态字节码增强。如果每个工具都自己实现一套字节码增强逻辑,前期实现的门槛与后期维护成本高,且不同工具间相互影响造成不可预知的风险。如何屏蔽字节码增强技术的高门槛,降低研发运维成本,同时又能支持上层多个工具平台功能的快速实现和动态管理,成为阿里集团的目标。从去年开始潜心修行,创新的研发了一套实时无侵入的字节码增强框架。于是
JVM-Sandbox
诞生了!诞生历程2014年GREYS第一版正式发布,一路看着他从无到有,并不断优化强大,感慨羡慕之余,也在想GREYS是不是只能做问题定位。2015年开始根据GREYS的底层代码完成了人生的第一个字节码增强工具——动态日志。之后又萌生了将其拆解成录制回放、故障模拟等工具的想法。扪心自问,我是想以一人一个团队的力量建立大而全的工具平台,还是做一个底层中台,让每一位技术人员都可以在它的基础上快速的实现业务功能。我选择了后者。应用场景JVM-Sandbox
的目标群体Btrace
好强大,也曾技痒想做一个更便捷、更适合自己的问题定位工具,既可支持线上链路监控排查,也可支持单机版问题定位。有时候突然一个问题反馈上来,需要入参才能完成定位,但恰恰没有任何日志,甚至出现在别人的代码里,好想开发一个工具可以根据需要动态添加日志,最好还能按照业务
ID
进行过滤。系统间的异常模拟可以使用的工具很多,可是系统内的异常模拟怎么办,加开关或是用
AOP
在开发系统中实现,好想开发一个更优雅的异常模拟工具,既能模拟系统间的异常,又能模拟系统内的异常。好想获取行调用链路数据,可以用它识别场景、覆盖率统计等等,覆盖率统计工具不能原生支持,统计链路数据不准确。想自己开发一个工具获取行链路数据。我想开发录制回放、故障模拟、动态日志、行链路获取等等工具,就算我开发完成了,这些工具底层实现原理相同,同时使用,要怎么消除这些工具之间的影响,怎么保证这些工具动态加载,怎么保证动态加载
/
卸载之后不会影响其他工具,怎么保证在工具有问题的时候,快速消除影响,代码还原。如果你有以上诉求,那么你就是
JVM-Sandbox 的潜在客户。JVM-Sandbox
提供动态增强类你所指定的类,获取你想要的参数和行信息;提供动态可插拔容器,管理基于
JVM-Sandbox 的模块。JVM-Sandbox 能做什么?在
JVM-Sandbox(以下简称沙箱)的世界观中,任何一个 Java
方法的调用都可以分解为BEFORE、RETURN和THROWS三个环节,由此在三个环节上引申出对应环节的事件探测和流程控制机制。不仅如此还有LINE事件,可以完成代码行的记录。//
BEFORE-EVENTtry { /* * do something… */ //LINE-EVENT a(); //
RETURN-EVENT return;} catch (Throwable cause) { //
THROWS-EVENT}基于BEFORE、RETURN和THROWS三个环节事件以及LINE事件,可以完成很多类
AOP
的操作。可以感知和改变方法调用的入参可以感知和改变方法调用返回值和抛出的异常可以感知一个请求按顺序执行了哪些行可以改变方法执行的流程在方法体执行之前直接返回自定义结果对象,原有方法代码将不会被执行在方法体返回之前重新构造新的结果对象,甚至可以改变为抛出异常在方法体抛出异常之后重新抛出新的异常,甚至可以改变为正常返回JVM-Sandbox
都有哪些可能的应用场景线上故障定位线上系统流控线上故障模拟方法请求录制和结果回放动态日志打印安全信息监测和脱敏行链路计算和覆盖率统计JVM
沙箱还能帮助你做很多很多,取决于你的脑洞有多大了。JVM-Sandbox
在阿里集团的应用线上故障演练17 年故障演练平台在 JVM-Sandbox 基础上仅耗时
1
周即完成故障注入部分的系统重构。重构后的系统在挂载效率和挂载成功率方面有了明显的提升,极大的缩短的故障演练的时间,演练效率提升了数十倍。基于
JVM-Sandbox 改造后的故障演练平台,通用性强,所有基于 JVM
启动的系统均支持,极大的拓展了故障演练的范围,故障演练已达到集团级部署。与
16 年故障演练数据对比,17 年的故障演练平台,覆盖 BU 提升了 1.6
倍,覆盖应用提升了 5 倍,覆盖场景提升了 37 倍。依赖检测17
年强弱依赖自动化检测平台诞生。它提供了依赖检测、强弱分析、依赖扫描、故障注入等多种能力,底层能力基于
JVM-Sandbox 在 1
周内完成功能开发。利用其模块容器的特性,将前人开发的模块与新增模块一起挂载共同工作,完成平台功能。强弱依赖梳理方面,承载了淘宝的系统强弱依赖梳理工作,260+
个应用一键接入系统,并实现了 0
人工成本的自动化、智能化梳理。服务端录制隔离回放机制在 JVM-Sandbox
基础上开发了一个 SS 模块,相当于一个录音机 + 回放机,
在调用中间件的时候, 顺序录制下了我们的中间件请求,
并且存储这份‘磁带’到服务器上。当我们需要隔离回放的时候,
将这份‘磁带’找到, 并且在需要的时候直接从‘磁带’读取,
并不需要真实地请求我们的中间件,
这样就保证了我们的读、写接口也能做到可重复使用,从而实现服务端的隔离回放。线上录制隔离回放不仅极大的缩短的业务回归的耗时,把业务测试同学从繁琐的数据准备和接口自动化脚本的编写过程中解放出来,而且极大的拓展了覆盖范围,使回归的范围更贴近用户,且场景更丰富。精准回归服务端录制隔离回放机制诞生之后,虽然有效的提升了覆盖范围,降低了自动化脚本的人工投入,但是也带来了新的问题。线上录制的场景是海量的,单个系统都可以达到万级、十万级甚至百万级别的录制,这些录制的场景中,存在大量的重复场景,如何识别重复场景,实现有效、精准的回放,成为新的待解决问题。17
年在 JVM-Sandbox 的基础上,利用 LineEvnet
实现了行链路识别和标记,有效的提升了回放的精准度和效率。JVM-Sandbox
在阿里集团已经实现全网部署,在其上加载不同的模块实现了不同的功能,每个功能根据
BU
和应用的需要进行加载:强弱依赖检测功能:覆盖淘宝、天猫、业务平台、菜鸟、飞猪、ICBU、CBU
等 7 个 BU,240+
个应用;线上故障演练功能:覆盖集团客户体验事业群、淘宝网、云零售事业部、天猫、业务平台、飞猪、菜鸟、钉钉、阿里健康、CBU、集团安全、支付宝等
16 个 BU,391 个应用;服务端录制回放:覆盖淘宝网、钉钉 2 个
BU;精准回归:覆盖淘宝网、业务平台、钉钉 3 个
BU。通过上边的事例,想必大家对 JVM-Sandbox
是什么,核心功能是什么,还能做哪些事情,以及是否可以为阿里以外的同学提供服务等问题更感兴趣了,下面我们着重介绍这部分内容。开源和共建1、已开源,寻求更多的同学一起完善
JVM-Sandbox 的功能。Github
地址:
JVM-Sandbox
的功能;3、希望更多的同学想到跟多的应用场景,并能开源出来供大家使用。综上,JVM-Sandbox
是一个纯 java 编写的 AOP
解决方案。它为研发人员提供了一个快速实现字节码增强工具的平台。他的模块管理功能可以最大限度的复用模块、协同合作,减少重复投入。随着
JVM-Sandbox
的开源,我们期待更多的人加入到功能扩张和优化上,使其适配更多的开源中间件和
JVM。希望有更多的同学,发挥其聪明才智,开发更多、更好的上层模块,提供给自己和其他人的人使用。也希望能够利用好已有的模块,组装出新的工具平台和应用场景。JVM-Sandbox
建设和应用期待大家共同建设。

相关文章