作者： zhongdaiqi

中国联通、中国电信、中国移动都推出过不限流量套餐，在2G\3G时代，我们熟悉的15元包月无限流量套餐，比如北神卡、深神卡、南神卡，随着4G时代、5G时代的成熟，曾经的15元无限流量卡、10元不限流量卡已经不再是历史舞台的焦点​。在当下的3G\4G\5G时代，炙手可热的神卡套餐，有我们熟悉的钉钉、畅玩、磅礴 、沃派 、老白等，中国电信、中国联通、中国移动均推出了不限流量套餐，中国电信、中国联通更有双不限套餐。虽然这些神卡套餐大多数不能新办理，但是还是可以通过过户的方式从卡友手上买到。​今天小编带大家看看现在还有哪些绝版套餐。

中国移动绝版套餐

中国移动推出的无限流量套餐，相对中国联通、电信而言，达量限速比较厉害，对于流量需求比较大的卡友而言，1Mbps的上网体验会​不太好。

中国联通神级套餐

中国联通推出的无限流量套餐相对来讲，比较丰富，有双不限，达量限速，二限​之分。最好的当讲双不限，不限流量不限速度，也是绝版套餐中最吸引人的，可遇可不可求​。

中国电信绝版套餐

​

官方总是喜欢留一个小坑，提供了python示例代码，也提供了java示例，就是没有提供php代码，折腾了许久，真的要抓狂了！

$headers = getallheaders(); $gitee_token = $headers["X-Gitee-Token"]; $gitee_timestamp =$headers["X-Gitee-Timestamp"]; echo "gitee_token: $gitee_token \n"; echo "gitee_timestamp: $gitee_timestamp \n"; $sign_key = "yuema"; $sec_str = "$gitee_timestamp\n$sign_key"; $compute_token = base64_encode(hash_hmac('sha256', $sec_str,$sign_key,true)); ​ echo "computetoken: $compute_token \n"; ​ if($compute_token==$gitee_token){ echo "授权验证通过\n"; } ​ echo "welcome to yue.ma! "; //git cmd here

亲测，有效！

这种验签的方式，是否有些熟悉?好多平台之间的签名都有种说不出来的默契，是的！找Gitee相关的签名，找到的都是token，感觉没有验签安全，于是，执着的找为什么？ 官方文档坑人之处

如果 WebHook 使用了签名方式，在请求目标时会在当次请求头中加入名为 X-Gitee-Token，值为生成的签名内容。其签名实现算法如下： ​ 签名参数说明 参数 说明 timestamp 当前时间戳，单位是毫秒，与请求调用时间误差不能超过1小时，请求时需和密钥一并发送 secret 签名密钥，机器人安全设置页面，加签一栏下面显示的SEC开头的字符串 Step1：把timestamp+”\n”+密钥当做签名字符串，使用HmacSHA256算法计算签名。 Setp2：对上述得到的结果进行 Base64 encode。 Setp3：对上述得到的结果进行 urlEncode，得到最终的签名（需要使用UTF-8字符集）。 第二步，把 timestamp和第一步得到的签名值拼接到URL中。 写的是生成算法，urlEncode在验签的过程中是不需要的。话说，小白们都等着验签，官方却丢一个，你看，我们是这么生成的，验签你们自己看着办。有点拽。

现状是我们需要将Gitee的代码拉到服务器上进行自动部署。Gitee的webhook也能通知到我们的服务器url，但是webshell执行权限卡住了。

于时采用了一种曲线救国的方式，实现自动部署。这么晚了，直接帖代码好了。

#!/bin/bash

for i in {1..12} do echo $i echo "检测git更新"

if [ -f "/www/wwwroot/www.yue.ma/yuemagit.lock" ];then echo "发现git更新" if [ -f "/www/wwwroot/www.yue.ma/yuemagit.runing" ];then echo "已有作业在执行，跳过本次执行" else echo "抢锁执行" touch /www/wwwroot/www.yue.ma/yuemagit.runing cd /www/yuemagit/yuema/server git fetch –all git reset –hard origin/master git pull echo "git拉取完成" \cp -r /www/yuemagit/yuema/server/* /www/wwwroot/www.yue.ma/ echo "部署完成" rm -rf /www/wwwroot/www.yue.ma/yuemagit.lock echo "释放部署锁完成" rm -rf /www/wwwroot/www.yue.ma/yuemagit.runing echo "释放部署执行锁完成" fi else echo "未检测到git更新" fi

sleep 5

done

echo "本周期操作检测完，等下一个周期" if [ ! -f "/www/wwwroot/www.yue.ma/yuemagit.runing" ];then rm -rf /www/wwwroot/www.yue.ma/yuemagit.runing fi

经过今天的折腾，发现linux的sh脚本在进行文件操作的时候，话法还是很精炼的，正是如此，使用起来就得重新学习一下这种语法。尤其是检查文件是否存在的写法，真的是无法再精简了，如果使用某此语言，还得写关键词什么的，这里直接使用了一个-f，我的天啦，简直没谁了。

技术岛是首发地址，每天折腾一点点！

http://www.jishudao.com/2020/06/29/gitee_auto_deploy/

压测全链路日志的时候，不知道怎么监测ES的实时入库速度，于是在Chrome的浏览器里写了点js脚本，实现了对ES实时入库速度的监控，不能说是百分之百实时，不过满足压测的数据观察。

二话不说上JS

var startTime = new Date(); var baseCount=0;

var showStat = function(){ $.getJSON("http://es.yue.ma:9200/_stats”,null,function(d){ console.log(d._all.primaries.docs.count); //有数据的时候才开始统计 if(baseCount==0){ baseCount = d._all.primaries.docs.count; startTime = new Date(); } if(baseCount>0){ var currentTime = new Date(); console.log("开始时间："+startTime); console.log("统计时间："+currentTime); var diffTime = currentTime.getTime() -startTime.getTime(); console.log("时间差："+diffTime); var diffSec = diffTime / 1000; console.log("时间差（秒）："+diffSec); var speadSec = d._all.primaries.docs.count / diffSec; console.log("平均每秒新增doc数量："+speadSec); console.log("预估每分钟新增doc数量："+speadSec*60); }else{ console.log("还未探测到数据流"); }

}); setTimeout(‘showStat()’,3000); };

showStat();

能实时速率显示效果，及时发现压测指标是否达成！

感觉功能小巧好用！

自从团队自研全链路日志系统上线后，一直想分享一下本人对日志系统的一些感受与记得，今天正好是周未，仔细回想了一下有关日志的点滴，因为涉及到全链路日志的概念，由于我打算从非全链路日志（普通）到全链路的演化路线做一次分析，就打日志关系的一次业务问题做一些简单的案例剖析。请搬个小凳子，开场了。

非链路日志（普通日志）

如果没有链路的概念，那恭喜，您正在使用普通的日志。普通的日志没有链路标识，不同请求的日志可能穿插在一起，查看的时候不太好串起来，分析日志有点点眼花缭乱。尤其是出现线上问题的时候，面对一团无序的日志，心急如焚。如果站点业务机有10台，定位日志的范围，也成为一个不太愉快的时候。若是多线程的服务日志，日志穿插得眼花缭乱。非链路日志（普通日志）在实时排查问题的过程中，存在的最大问题就是定位分析问题，简单的示例如下图，日志穿插在一起，不易分析同一个请求的情况。

我收到一个请求，参数是
我收到一个请求，参数是
我收到一个请求，参数是
我收到一个请求，参数是
我收到一个请求，参数是
用户账号BBB未认证

单链路日志

当我看到有同事使用GUID将日志请求串在一起的时候，我就这应该算是单链路日志了。站点的单次请求或服务的业务操作日志能够很好的被标识出来，在分析日志的时候，需要搜索同GUID的日志，请能定位到一个请求或作业的日志，不用提心其他日志的干扰。单链路日志对于分析单个站点或单个服务的日志情况，还是很有帮忙。我们已经能从日志中挑出日志，专注于重点日志。

请求3fba452e-d9c9-45ee-96cb-19280fa59673 我收到一个请求，参数是
请求b3a45dec-7667-4822-b7b9-7db1eec11a8b 我收到一个请求，参数是
请求3e2f3851-9491-4f97-a47c-53d1001278ba 我收到一个请求，参数是
请求6180a2f7-d9bf-4612-9d23-c5e6d46a079d 我收到一个请求，参数是
请求26a9d771-f2f3-47fa-b810-d3071a1d98ca 我收到一个请求，参数是
请求3fba452e-d9c9-45ee-96cb-19280fa59673 用户账号BBB未认证

全链路日志

全链路日志在单链路日志的基础上进行跨站点，跨服务逻辑的日志追踪。分我们排查问题的时候，往往是一个完整业务排查，不单是涉及一个站点的，可能需要顺藤摸瓜，一点一点回溯。单链路日志 对此就无能为力了。所以引身出了全链路日志，我们需要为每个完整的请求分配一个追踪id，称之为TraceId，这个追踪id将在业务站点间流转，将业务日志串起来。当我们查看日志的时候，可以完整得看到业务日志的流转明细。同样的道理，服务日志在入口处，也将分配一个完整的TraceId，标识出完整的日志。

站点A
TaceId 2ad28f58-858c-47c0-8875-e2e9db4ff24b 请求3fba452e-d9c9-45ee-96cb-19280fa59673 我收到一个请求，参数是
TaceId 2ad28f58-858c-47c0-8875-e2e9db4ff24b 请求3fba452e-d9c9-45ee-96cb-19280fa59673 用户账号BBB未认证

站点B
TaceId 2ad28f58-858c-47c0-8875-e2e9db4ff24b 请求3fba452e-d9c9-45ee-96cb-19280fa59673 用户账号检查

针对于全链路日志，我们应该采用TraceId将跨站点的日志打上标记，对服务内部的日志转流也同样的道理。通过GUID标记好的日志，可以通过日志收集系统，FileBeat抓取到Kafka，LogStash从Kafka消费送到ES，我们DIY一个全链路日志查询系统，在出一线上问题的时候，快速的定位出完整的业务日志，高效的排查问题。今天本想分享如果打业务日志，写着写着就变主题了，下次再找机会分析打业务日志的经验。关于日志收集系统的搭建，也是另外分享。