前言
通过 webrtc 的 turn 服务器 coturn 的搭建 我们知道自己搭的turn server 可以用于 webrtc 的 turn server转发了,所以接下来就要开始弄 coturn 的校验机制了。
具体的配置项:传送门
校验方式主要是有两种:
- 配置固定的用户名和密码
- 静态key校验
我们采用的是通过开启静态key的方式,和配合 ttl 有效期的方式来做连接校验。
Quick notes
通过 webrtc 的 turn 服务器 coturn 的搭建 我们知道自己搭的turn server 可以用于 webrtc 的 turn server转发了,所以接下来就要开始弄 coturn 的校验机制了。
具体的配置项:传送门
校验方式主要是有两种:
我们采用的是通过开启静态key的方式,和配合 ttl 有效期的方式来做连接校验。
这样主要是整理一下,之前做过的兼容一些浏览器的事情,而且因为IE比较特殊,而且各个版本差异化非常大,所以这边有针对IE进行归纳:IE 浏览器兼容问题整理
而这边更多的是在html 和 JavaScript 的使用上来进行整理, css 会比较少。
说明:
IE下,可以使用获取常规属性的方法来获取自定义属性,也可以使用getAttribute()获取自定义属性;Firefox下,只能使用getAttribute()获取自定义属性.
解决方法:
统一通过getAttribute()获取自定义属性。
最近vernemq集群中,香港和硅谷那两台有时候会重启,原因就是监控程序 cron 一直没办法 pub 和 sub, 然后调用 监控程序的 web 来重启的。
后面查看了一下香港那一台的log,发现有这么一个错误:1
2018-10-11 06:45:08.947 [error] <0.3648.0>@vmq_diversity_script:call_function:64 can't call into Lua sandbox for function auth_on_register due to {timeout,{gen_server,call,[<0.613.0>,{call_function,auth_on_register,[{addr,<<"220.130.153.xx">>},{port,1145},{mountpoint,<<>>},{client_id,<<"39f82305f5230abcc433ef5be342a">>},{username,<<"c177fc757d6be8534a57fa68fb910">>},{password,<<"xxx">>},{clean_session,false}]}]}}
看意思好像就是在执行lua脚本的 auth_on_register 这个方法的时候,连接redis超时了??同时官网也有一个对应的issue: Timeout error for call into Lua sandbox。
可能是 redis 的 ping 超时了导致,后面试了一下,每一个集群的 mqtt 服务 分别 ping redis 服务的时间:
除了广州那一台的ping是 18ms, 香港和硅谷那两台分别是 137 ms, 所以差距还是很明显的。所以才会有 调用 lua redis 脚本 timeout 的错误,因为校验的时候,要去连接 redis, 一旦网络差一点,就马上会超时了。
而现在之所以香港 和 硅谷 连接 redis 会超时是因为我们的测试服的 redis 是在泉州的实体机上。而 cn, hk,us 都是在腾讯云上, 其中 cn 在广州, hk 在香港, us 在硅谷。 所以在没有对等网络的连接下, cn 因为线路近,所以时间还行。但是 hk 和 us 那就坑爹了,分分钟就ping 超时。
所以后面的解决措施就是: 在 cn 那一台的腾讯云机器上, 部署一台新的 redis , 用来做 vernemq 的 校验 redis。 这样,由于在对等网络下,全部走内网的情况, 这三台服务器应该都挺快的。
后面部署完之后,广州那一台直接是同一台机子,所以速度就不用说了,0.01ms, 香港那一台走内网也很快,只要 9ms。不过美区那个有点坑,走内网还要 163 ms, 这个后面得再观察一下。
可以这样先试试看,后面如果美区会比较延迟的话,再对 redis 做主从,把一个从库架在美区, 因为本身 vernemq 对 redis 也只会读,不会写。
之前有个支付的修改,会涉及到建立非常多的plan 循环订阅plan。
所以就想知道 paypal stripe 和 google 这三个第三方支付对 plan 的创建有没有最大允许值。
相关资料:is-there-a-limit-to-how-many-billing-plans-can-i-create
看了一下应该是没有限制的:1
I was told by Paypal support that there is no limit on how many billing plans you have created.
相关资料:
看了一下,应该也是没有限制的1
2There is no limit in Google Play, or if there is it is not publicly documented.
On another note, why would you possible need 10000 in app products?
看了一下文档,也没有找到,应该也是没有限制的。
虽然现在做的一些项目,越来越不需要兼容IE的问题,但是早期几年在做的时候,还是需要兼容一些IE的问题的,所以这边就把之前遇到的一些IE的兼容问题列一下,算加入到自己的问题手册中。
这个可以看我的早期文章:ie8,ie9 使用 XDomainRequest 进行跨域
还是讲的比较详细的。
之前做官网项目的时候,有报了一个错误, 就是 IE8 以下不能用 self.server.payFromType.new 这种写法,因为 new 是关键字,会导致代码报错。
要改成这种写法 self.server.payFromType[“new”]
众所周知,每一个HTTP响应都会带有一个HTTP状态码(HTTP Status Code),是用来表示HTTP服务器响应状态的代码。它由RFC 2616规范定义的,并得到RFC 2518、RFC 2817、RFC 2295、RFC 2774、RFC 4918等规范扩展。作为web开发者,平时经常看到200、301、302、404、500、503等。但是如果想知道这些状态码,表示的是什么,使用场景在哪里? 我觉得还是挺有意思的。所以专门花了一些时间,结合自己的知识面,专门整理了一下。
HTTP定义遵循一条规则:所有状态码的第一个数字代表了响应的状态。
之前做的 Node命令行工具实践(3) - 一个用于批量导入key的命令行 其实就在项目中就很有用了。这次做的另一个命令行工具,叫做语言助手下载替换工具 lang-helper, 这个也非常有用。
我们的团队做的项目是基于全球范围用户的,因此我们的所有产品其实都是有多语言的,有些项目少一点的也有七八种语种,多一点可能达到二三十种。而且我们的很多语种都会送到线上的翻译平台上去翻译。当然还有一些语种是我们自己内部运营自己维护的。
为了便于管理,我就开发了一个内部的语言助手平台,用来对各个项目的多语言进行翻译和校验,拉取和下载功能,甚至是跟翻译平台的同步和拉取功能。
之前做了一个练习之作 Node命令行工具实践(2) - 自制项目脚手架命令行,实用价值不高,这次要做的命令行就是用在项目中的。
为了收集用户在web上的点击行为,我们有自己的talking data 系统,并提供给web端,让web端的程序抛送。 但是为了便于存储,所以基本上存在数据库里面就是以 01020304 这种方式存放的。
其中前面两位就是项目的代号,每一个项目都有一个唯一的代号,后面的6位,两位为一个单位,所以会有树级的结构,所以会有三层来描述一个具体的用户行为,举个例子, 比如 01020101 可能就是表示 官网(01)下的个人中心(02)的购买模块(01),然后用户点击购买按钮行为(01)。
通过了学习了 Node命令行工具实践(1) - 几种使用的组件库。开始试着尝试自己做一个命令行工具,就是项目初始化的脚手架 p-helper
原理很简单,执行 p-helper i –name myProject 命令,就会在当前目录中,建立一个 myProject 的项目目录。里面就是一些常用的一些目录结构:
在使用NodeJs过程中,有很多包都支持全局安装,然后提供一个命令,然后在命令行我们就可以完成一些任务,像 express, grunt, bower, yeoman, reap, karma, requirejs 等。有时候,我们也需要自己开发这样的命令行工具。
使用自定义的Node命令行,在我们的很多项目里面都有使用过,而且真的很好用,尤其是我们内部还有一些项目是辅助项目,比如多语言翻译平台,这些项目都是内部项目,但是线上的项目有涉及一些资源和文件,都跟这些内部项目息息相关。这时候我们就会开发一些Node命令行提供给开发人员,用于开发人员的更便捷操作。接下来的几篇都会讲到使用自定义的Node命令行在开发的过程中,所能提供的便捷有多好用。本篇主要是讲一下在开发Node命令行的时候,经常使用的几个npm 库。
通过 官网构建优化流程(12) - 优化加载速度,资源分开存放 可以知道我们已经将官网的资源文件挪到云存储服务上了,并配上CDN了, 果然国内访问的话,速度快了很多。但是还是有发现了一个问题:
之前有测试的同学反馈说,每次官网更新,速度都会变得很慢。这个其实是因为我们官网的服务器是在国外,所以国内访问的话,就会比较慢。
这个项目其实之前也有做了一些的优化,比如