微信客户端各项功能开发、技术优化等工作工作地点,gRPC 调用是通过 HTTP POST

摘要据统一推送联盟官方公众号消息:统一推送联盟全体成员大会将于2018年4月26日在中国信息通信研究院召开。以下内容来自统一推送联盟官方资讯:内容概述2018,移动互联网安卓生态依旧混乱。2018,我们尝试给出答案。纵观安卓生态,产业链各方依旧受到困扰:对于用户,依旧被索要各种涉及隐私、安全等不必要的权限;流氓App依旧会疯狂利用非必要进程占据后台,有的“全家桶”甚至会利用交叉唤醒等方式长期打扰用户;对于开发者,依旧被各家的推送接口和通道文档所困扰,不知所措;对于推送通道方,终端厂商及第三方推送服务方依旧会对一些消息是否能够推送到达而犹豫徘徊;对于运营商,依旧会面临短信业务快速萎缩及通道能力资源浪费的矛盾。2018,我们尝试破解难题。统一推送联盟全体成员大会将于2018年4月26日在中国信息通信研究院召开。本次会议将尝试全面破解移动互联网安卓生态混乱的难题,推动安卓绿色生态的建设。经过前期密集筹备,本次会议尝试针对上述问题给出“药方“,主要聚焦四个方面:统一推送接口标准和测试方法,内容审核系统框架设计,短信推送技术要求和测试方法,中国绿色App召集令。统一标准真的来了统一推送联盟成立受到了业界及用户的广泛关注。经过半年的准备和近期紧锣密鼓的讨论,《统一推送接口标准(V1.0)》及《统一推送平台测试方法(V1.0)》已接近完成。本次大会将重点针对上述两份标准做进一步的讨论和修改,最大限度地满足开发者,终端厂商,第三方服务商等各方诉求。本次标准的制定得到了华为,小米、OPPO,VIVO,百度、阿里巴巴、腾讯、爱奇艺、个推,极光,谷歌等公司的大力支持。标准的制定本着开放,共赢的原则,既放眼全球,又聚焦中国。我们相信,统一推送系列标准(V1.0)的发布,将一定程度上解决目前推送接口混乱、开发者重复开发、应用常驻后台、终端耗电等问题。最大程度上助力安卓绿色生态的建设,助力国产智能终端的发展,使用户真正使用到后台“纯净”的安卓手机。“推送”还是不“推送”?这是一个问题统一推送联盟汇聚移动互联网产业各方,始终将积极支持和响应各项国家政策及法规视为己任。我们深刻地意识到,技术必须要用社会主义核心价值观来引导,要符合时代要求,尊重公序良俗。任何业务不能只片面地注重增长和规模,更要不断强化自身的社会责任。长期以来,推送业务的快速增长也带来了一定隐患。推送业务由于其具有发送不可撤回,快速传播,广泛覆盖等特性,如果被不当行为所利用,将带来不可估量的后果。为了解决上述问题,统一推送联盟在此倡议:通过行业自律的方式阐释并切实践行社会责任;我们呼吁联盟成员利用科技创新创造价值的同时,一起探讨有效方式实施自我监管,合作共赢;在行业监管部门和主管部门的指导下,统一推送联盟将在本次会议推出《内容审核系统框架设计》标准,最大限度的进行行业自律,敬请关注。
推必达——推送的新面孔!作为用户,你有没有过以下困扰?填写手机验证码时必须在应用之间的来回切换及复制粘贴?收到银行提醒时想要查询和操作时需要另外打开App?收到机票订单的同时想赶紧选座?短信箱中大量的过期提醒导致有用信息被淹没?统一推送联盟本次将联合中国联通,中国移动,中国电信三大运营商及相关各方,在本次大会上共同探讨新业务模式,利用信令级通道的高可靠及广播能力,帮助开发者推送提供基于场景及业务的短信/推送的增值服务,以期解决上述问题,共同提升安卓终端上的短信及推送用户体验,最大限度地助力安卓生态的建设。本次大会将提出并讨论《短信推送技术要求和测试方法》,打通短信和APP之间的连接,利用运营商宝贵的无线和网络资源,创造更多的商业价值,同时帮助用户提升终端侧的用户体验。更纯粹的体验——绿色App一直以来,安卓系统的后台问题常常为用户所诟病,应用常驻后台、周期性启动给手机的能耗和流量都带来了巨大的负担。目前,随着国内消费市场升级,消费者对于手机体验的关注度甚至于超过了对品牌及价格等敏感因素的关注度。安卓生态的种种缺陷已经造成一定的负面影响,在一定程度上制约了我国自主品牌手机的发展,对国内手机产业链和移动互联网产业造成了不利影响。统一推送联盟深刻地意识到这个问题的严重性并积极尝试产业力量给出解决方案。就如“Andorid绿色应用公约”创始人Oasis
Feng所述,这是一次理想主义的尝试。我们一直相信,理想主义虽然偶尔会迟到,但从不缺失。因此,在本次大会上我们将联合“Andorid绿色应用公约”,共同发布《中国绿色App应用公约》,我们相信统一推送相关标准的发布及公有云平台的建设能够更好地推动此项工作。我们希望,让一部分有良知有担当的应用团队,在保全流量利益的前提下,卸去对设备体验的伤害,再推动手机厂商卸去它们对这部分应用的敌意和束缚,从而让双方都有机会携手创造一个更加良性的国内
Android
生态。这一次,我们诚挚邀请你加入我们,共同为理想而奋斗。如需提交App,请发邮件至upa@taf.org.cn。后记一直以来,统一推送联盟将实现更好的用户体验视为己任,将落实行业监管部门的要视为责任,将产业生态链各方的诉求和关切视为目标,积极发挥生态引领者的角色,努力打造积极向上,技术驱动,责任共担,合作共赢的行业组织,为中国安卓绿色生态做出自己的努力和贡献。最后,我们再一次诚挚地邀请您参加2018年4月26日在中国信息通信研究院召开的“统一推送联盟全体成员大会”。这一次,我们将尝试全面提出破解新时代移动互联网安卓生态混乱这一难题的答案。这一次,我们是认真的。撸起袖子加油干,一张蓝图绘到底!

摘要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 指定的错误消息。

摘要微信终端开发团队 2018
暑期实习招募。1、微信终端开发团队介绍(公众号:WeMobileDev),主要负责
iOS / Android / Windows / Mac
等平台上微信客户端的研发工作,工作范畴涉及聊天、朋友圈、小程序、小游戏、看一看、支付等业务,以及微信客户端的架构设计、性能优化、体验优化等技术性工作。在这儿你会有机会实现被
10
亿用户使用的产品特性,面对不曾想象的技术难题,并完成各种富有挑战性的任务。非常期待热爱研究终端技术、敢于挑战、乐于学习、有实力的你加入我们。这个暑假,和微信一起成长,一起做点正经事。2、面向群体2019
届毕业生3、岗位介绍岗位名称:微信终端开发实习岗位工作职责:微信客户端各项功能开发、技术优化等工作工作地点:广州
/ 深圳岗位要求:1. 计算机软件相关专业本科及以上学历2.
扎实的计算机理论基础、算法和数据结构知识,热爱编程3.
熟练掌握至少一门语言,良好的编程动手能力。4.
有很好的学习能力和自驱动力,对于创新及解决具有挑战性的问题充满激情5. 有
iOS / Android /Windows /
Mac开发经验优先4、简历投递简历投递邮箱:wemobiledev@qq.com

相关文章

发表评论

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

*
*
Website