公开的未来 Java 版本发布和支持周期图,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 指定的错误消息。

摘要北京时间 3 月 21 日,Oracle 官方宣布 Java 10 正式发布。这是 Java
大版本周期变化后的第一个正式发布版本,非常值得关注。引言北京时间 3 月 21
日,Oracle 官方宣布 Java 10 正式发布。这是 Java
大版本周期变化后的第一个正式发布版本(详见这里),非常值得关注。你可以点击以下地址即刻下载:
9 月,Oracle 将 Java 大版本周期从原来的 2-3
年,调整成每半年发布一个大的版本。而版本号仍延续原来的序号,即 Java
8、Java 9、Java 10、Java
11…..但和之前不一样的是,同时还有一个版本号来表示发布的时间和是否为
LTS(长期支持版本),比如 Java 10 对应 18.3。如下示例:/jdk-10/bin$
./java -versionopenjdk version “10” 2018-03-20OpenJDK Runtime
Environment 18.3 (build 10+46)OpenJDK 64-Bit Server VM 18.3 (build
10+46, mixed mode)需要注意的是 Java 9 和 Java 10 都不是 LTS
版本。和过去的 Java
大版本升级不同,这两个只有半年左右的开发和维护期。而未来的 Java
11,也就是 18.9 LTS,才是 Java 8 之后第一个 LTS 版本(得到 Oracle
等商业公司的长期支持服务)。这种发布模式已经得到了广泛应用,一个成功的例子就是
Ubuntu Linux 操作系统,在偶数年 4 月的发行版本为
LTS,会有很长时间的支持。如 2014 年 4 月份发布的 14.04 LTS,Canonical
公司和社区支持到 2019 年。类似的,Node.js,Linux kernel,Firefox
也采用类似的发布方式。Java
未来的发布周期,将每半年发布一个大版本,每个季度发布一个中间特性版本。这样可以把一些关键特性尽早合并入
JDK 之中,快速得到开发者反馈,可以在一定程度上避免 Java 9
两次被迫推迟发布日期的尴尬。下图为 2017 年 JavaOne 大会时,Oracle
公开的未来 Java 版本发布和支持周期图。Java 10 新特性这次发布的 Java
10,新带来的特性并不多。根据官网公开资料,共有 12 个 JEP(JDK Enhancement
Proposal 特性加强提议),带来以下加强功能:JEP286,var
局部变量类型推断。JEP296,将原来用 Mercurial 管理的众多 JDK
仓库代码,合并到一个仓库中,简化开发和管理过程。JEP304,统一的垃圾回收接口。JEP307,G1
垃圾回收器的并行完整垃圾回收,实现并行性来改善最坏情况下的延迟。JEP310,应用程序类数据
(AppCDS)
共享,通过跨进程共享通用类元数据来减少内存占用空间,和减少启动时间。JEP312,ThreadLocal
握手交互。在不进入到全局 JVM 安全点 (Safepoint)
的情况下,对线程执行回调。优化可以只停止单个线程,而不是停全部线程或一个都不停。JEP313,移除
JDK 中附带的 javah 工具。可以使用 javac -h 代替。JEP314,使用附加的
Unicode
语言标记扩展。JEP317,能将堆内存占用分配给用户指定的备用内存设备。JEP317,使用
Graal 基于 Java 的编译器,可以预先把 Java
代码编译成本地代码来提升效能。JEP318,在 OpenJDK
中提供一组默认的根证书颁发机构证书。开源目前 Oracle 提供的的 Java SE
的根证书,这样 OpenJDK
对开发人员使用起来更方便。JEP322,基于时间定义的发布版本,即上述提到的发布周期。版本号为$FEATURE.$INTERIM.$UPDATE.$PATCH,分别是大版本,中间版本,升级包和补丁版本。部分特性说明1.
var 类型推断。这个语言功能在其他一些语言 (C#、JavaScript) 和基于 JRE
的一些语言 (Scala 和 Kotlin) 中,早已被加入。在 Java
语言很早就在考虑,早在 2016 年正式提交了 JEP286
提议。后来举行了一次公开的开发者调查,获得最多建议的是采用类似 Scala
的方案,“同时使用 val 和 var”,约占一半;第二多的是“只使用
var”,约占四分之一。后来 Oracle 公司经过慎重考虑,采用了只使用 var
关键字的方案。有了这个功能,开发者在写这样的代码时:ArrayList myList =
new ArrayList()可以省去前面的类型声明,而只需要var list = new
ArrayList()编译器会自动推断出 list
变量的类型。对于链式表达式来说,也会很方便:var stream =
blocks.stream(); … int maxWeight = stream.filter(b -> b.getColor()
== BLUE) .mapToInt(Block::getWeight) .max();开发者无须声明并且 import
引入 Stream 类型,只用 stream 作为中间变量,用 var
关键字使得开发效率提升。不过 var
的使用有众多限制,包括不能用于推断方法参数类型,只能用于局部变量,如方法块中,而不能用于类变量的声明,等等。另外,我个人认为,对于开发者而言,变量类型明显的声明会提供更加全面的程序语言信息,对于理解并维护代码有很大的帮助。一旦
var 被广泛运用,开发者阅读三方代码而没有 IDE
的支持下,会对程序的流程执行理解造成一定的障碍。所以我建议尽量写清楚变量类型,程序的易读维护性有时更重要一些。2.
统一的 GC 接口在 JDK10 的代码中,路径为
openjdk/src/hotspot/share/gc/,各个 GC 实现共享依赖 shared 代码,GC
包括目前默认的 G1,也有经典的 Serial、Parallel、CMS 等 GC 实现。3.
应用程序类数据(AppCDS)共享CDS 特性在原来的 bootstrap
类基础之上,扩展加入了应用类的 CDS(Application Class-Data Sharing)
支持。其原理为:在启动时记录加载类的过程,写入到文本文件中,再次启动时直接读取此启动文本并加载。设想如果应用环境没有大的变化,启动速度就会得到提升。我们可以想像为类似于操作系统的休眠过程,合上电脑时把当前应用环境写入磁盘,再次使用时就可以快速恢复环境。

摘要2018 音视频技术沙龙·深圳站丨又拍云 Open Talk
NO.41一、活动介绍随着移动互联网的普及和智能终端设备的广泛应用,短视频、在线教育、
在线狼人杀、直播竞答等各类形式的音视频形式的应用越来越广泛,技术的不断升级正在提升应用的体验。本期又拍云
Open Talk
,将会结合一线的实践案例,与众多音视频开发者探讨新一代音视频技术的实践和发展趋势。又拍云
Open Talk
是由又拍云发起的系列主题分享沙龙,秉承又拍云帮助企业提升发展速度的初衷,从
2015 年开启以来,Open Talk 至今已成功举办 40 期,辐射线上线下近 70,000
技术人群。不管是从某个“主题”出发,并从横向拓展技术干货分享,还是以某个“品牌企业”为主,从纵深丰富演讲内容,活动都场场爆满。截止目前,又拍云
Open Talk 已经举办 40 期活动,分别在北京、上海、广州、深圳、杭州等12
座城市举办,覆盖美拍、唱吧、美联集团、唯品会、哔哩哔哩、华为等诸多知名企业,往期的活动的讲稿及视频详见:
年 06 月 10 日( 周日
)14:00-17:30三、活动地点广东省深圳市南山区深圳虚拟大学园 R3-B
栋一楼触梦社区四、活动议程13:00-14:00签到14:00-14:40高毅 /
资深语音技术专家 《智能设备语音处理与交互实践》14:40-15:20凌建发 /
又拍云 PrismCDN 项目负责人 《低延时的 WebP2P
直播实践》15:20-15:30茶歇15:30-16:10刘鹏 / 糗事百科视频软件工程师 《直播
SDK 的技术实践》16:10-16:50张波 / 虎牙直播运维研发架构师
《基于CDN推流日志的主播上行实时监控及其自动化解密》16:50-17:30自由交流五、嘉宾介绍分享嘉宾一:高毅,
资深语音技术专家电子科技大学硕士,计算机软件与理论工程师职称,中国计算机学会专业会员。曾任中兴通讯中心研究院多媒体平台部音频处理工程师;摩托罗拉系统有限公司DSP部门高级工程师,PCR产品线音频功能架构师,成都团队
Audio Tech Lead,全球 common audio team
成员。长期从事语音通讯系统,智能音箱,智能电视等语音交互项目研发,译著《语音增强——理论与实践》,拥有多篇专利(包括4篇PCT专利)和论文。分享主题:《智能设备语音处理与交互实践》分享嘉宾二:凌建发,又拍云
PrismCDN 项目负责人先后任职于诺基亚等通信公司,目前主要负责又拍云
PrismCDN 项目的设计与开发工作,对 P2P
、流媒体技术有较深入的研究。PrismCDN 是在 CDN 的基础上完美融合 P2P
及流媒体技术,高效整合利用零散闲置的上行带宽资源构建内容分发网络服务。分享主题:《低延时
WebP2P 直播技术实践》主题简介:本次分享将介绍又拍云 PrismCDN 项目中,将
WebP2P 技术应用于直播场景的开发实践。相比传统嵌入式的 P2P网络,基于
WebRTC 开发的 WebP2P
网络具有无插件、低延时、高分享率的优势,能够覆盖更多的应用场景。分享嘉宾三:刘鹏,糗事百科视频软件工程师曾任职于酷狗,负责繁星直播播放器的研发,酷狗移动端音视频构架的重构;现任糗事百科视频开发工程师,负责短视频、直播音视频
SDK的研发,熟悉 RTMP、RTP/RTCP 等流媒体协议,熟悉 android
framework。分享主题:《直播 SDK
的技术实践》主题简介:本次分享将会介绍直播 sdk
研发过程中碰到的各种坑,以及一些小技巧。分享嘉宾四:张波,虎牙直播运维研发架构师目前主要负责虎牙直播运维体系的建设,主要针对
web
和后台类程序的发布、监控、运维自动化相关的运维系统的设计和开发。分享主题:《基于CDN推流日志的主播上行实时监控及其自动化解密》​本次分享将会介绍虎牙直播针对主播推流在
CDN
环境下的优化的小技巧和过程中碰到的各种坑。往期讲稿/视频回顾
“付费票” 的参会者可以凭票参与现场 “圆点机械键盘” 的抽奖,奖品数量总共 2
台。七、主办方又拍云是国内知名企业级云服务商、国家高新技术企业,持有工信部颁发的
CDN 牌照;致力于为客户提供一站式的在线业务加速服务,以场景化 CDN
为核心,为客户提供对象存储、HTTPS/SSL 证书、多媒体处理(WebP
自适应、H.265 自适应、窄带高清等)、影像识别、文字识别、短视频 SDK、直播
SDK、连麦 SDK
等服务,打造了安全可靠的全站加速、海外加速、图片应用、短视频应用、直播应用、音频应用等场景化解决方案。又拍云拥有
6 个数据处理中心、300 多个国内CDN节点、15 个海外CDN节点、5000
台服务器、5TB 保有带宽,日均请求超过 1000
亿次。八、协办方IT趣学社致力于互联网技术分享和交流,打造最全面的互联网/IT行业会员网络,汇聚互联网/IT高端技术精英,促进行业交流,实现资源共享。IT趣学社成功举办多次互联网/IT精英技术沙龙/峰会,邀请国内国外互联网/IT顶尖专家分享最热的技术,每场沙龙参会嘉宾、沙龙晚宴到场嘉宾人数爆满且级别质量很高,IT趣学社目前拥有北京、上海、广州、深圳、成都、西安技术普通社群共
180+个社群,拥有精英联盟( CTO & 运维总监)群共 6 个,累积汇集了 500 个
CTO 和 1500 多个运维总监/经理会员,共计有 80000+
技术会员。​九、合作伙伴十、联系我们活动咨询请添加又小拍微信号:upyun1111
或扫描下方二维码,备注“音视频技术沙龙”,主办方将会邀请您到活动群,活动直播链接也将会在活动群内发布。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

相关文章

网站地图xml地图