在上个星期之前一直不知道redis居然还有事件机制，一个研发同事问了下我，居然一直都不知道，但是BLPOP和RPUSH也算是事件啊。一直只是把它当做一个高速缓存和队列来使用。
具体的这个介绍可以参考： https://redis.io/topics/notifications
在每个redis里可以设置3种事件，测试过把所有加上并不起作用，具体列表如下：
1 | K Keyspace events, published with __keyspace@<db>__ prefix. |
设置的方式如下：
1 | $ redis-cli config set notify-keyspace-events KEA |
在一台nginx服务器上，本地弄了个redis，使用https://github.com/openresty/lua-resty-redis 做一些简单的逻辑判断使用，可奇怪的时候一直产生大量的time_wait，机器连接数总共才2000多，可time_wait居然要2万多。 按理说lua-resty-redis是有连接池的，看了下写法也没有问题啊，网上那个坑1坑2坑3也都没有问题啊，可就是继续大量time_wait。 https://moonbingbing.gitbooks.io/openresty-best-practices/web/conn_pool.html 这段反反复复看了好多遍，也没想出是什么原因。 从time_wait的产生分析也是nginx产生的，不是本地redis配置的问题，而且redis也本来就配置的keepalive。 于是就继续使用tcpdump大法了，看看为什么nginx发了FIN没有得到ack。dump出来结果也是这样。 
redis-server这里没有对FIN 进行ack， 导致nginx一直保持time_wait状态，而且这个状态必须要等1分钟后2MSL(最大报文段生存时间)才会到close状态。这个是无法通过sysctl.conf来进行修改的。 这个时候就完全到到lua-resty-redis这个模块的问题，去github上更新了最新的，然后看到文档里又有依赖对应的nginx-lua版本，也都检查了没有问题。 这个时候那就只能是代码本身的问题，看lua-resty-redis的邮件列表也没有什么人说有不能keepalive的问题。 然后把代码恢复成官网事例一样，结果发现好使。 过了一遍代码果然找到了问题所在
1 | if not ngx.var.cookie_userid |
原先代码里是判断如果cookie里没有userid就直接return，但是一旦return出来之后就用不到后面的keepalive了，所以将这里直接赋值一个0无效的userid，然后再继续后面的判断。 从这个问题来看主要还是对lua的循环跳出机制还是不够了解，忙活了4个小时答案就是这个。
上周就开始阅读了，作为一个伴随着腾讯长大的80后，同时也身处互联网中的网中人还是挺有感触的。
其实在追新这方面我还是挺后知后觉的，除了饭否和豆瓣是第一时间开始用的，其他基本都很落后，98年开始上网，一直到01年才开始申请QQ号，微信号更是在微信红包大战的时候才申请了。而书中说的msn在06年已死，可我居然一直用到07年底，而360的东西更是从来没接触过。
对于腾讯这个公司，其实在11年以前是没有什么好感的，抄袭的王者，但是读罢以后发现还是小看了他们，其实也是自己没有很深的思考和阅历导致的。08年做视频，总觉得很简单，不就是视频文件分割走CDN，而自己负责的恰恰就是CDN，我所看到的也就是CDN，而对于调度，p2p，合并，加速视频流这些居然都视而不见。其实这些才是这家公司的核心啊，至于CDN这些都是很外围的，用自己和别家区别不大（akamai除外）。
刚上大学的时候，正是生物特别热门，那时候最好的学生都被忽悠进生物系了，这个可是改变人类未来命运的，生物医药，基因工程，可15年过去了，生物系出来的大多是当生物老师，或者转行了，水木上有生物大神最后也去了MBB中的一家做咨询了。虽然未来还是可期的。 而现在机器学习的崛起，是不是意味着我们很多工作都基本也会被替代了，首当其冲我觉得运维是最容易被替代的，一个云计算基本把所有系统运维的活给替代了，而后面的PAAS的全面普及和优化，那基本没啥应用运维的事情了，这些岗位可能在云计算公司里还会存在，但是其他公司内基本就可以取消了。 按这个逻辑下去真是越想越可怕，除了完全需要创造类的工作，其他机器都可以做啊，矮大紧在一集好莱坞的介绍里讲了好莱坞挑选剧本就完全属于一个机器行为，多少时间铺垫，什么时候高潮，有多少个高潮，结局如何收尾都是有固定模式的，但为什么好莱坞也会出好片呢？ 最近在看《腾讯传》里说的一点就是微创新可以很好的解答上面那个问题，很多东西是有一定规律，机器完全胜任，但是这个规律我们是不是再修正下，就比如PAAS平台，就拿最简单的redis来说，针对每个服务需要优化的地方也是非常多的，那我们就一点点修正，直到出来一个公式可以适配这些不同的应用，不过这个没啥难得，连AlphaGo这样超复杂的围棋机器人都可以做，这点条件根本不算啥，但是这当中就是一个训练机器人的过程。 这些所有的微创新机器人至少不能提前做，但是能很快学会。 看到国外有一个新职业叫训机师，就是给机器人喂数据，但是可悲的是这个职业的目标居然是让机器人来取代自己。 但这个世界就是这样啊，汽车出现会导致了马车的沉寂，当然现在很多旅游景点还是有的，接下来该失业的估计就是汽车司机了吧。很多职业都会随着技术的进步而消亡，只是在IT行业这个消亡的速度会非常之快。 近期看运维是最危险的了，然后写代码也挺危险了，你只要描述伪代码就直接产生对应的程序，这种工具现在有，只是还不成熟罢了，最终会不会演变成只要产品文档符合某种规范就直接生成了呢？ 虽然说是近期，那估计还能活5年吧，但是5年后的事情真是难说了。看来要不被社会所淘汰，得加快步伐了。
2016年如果从工作上来看，几乎是一事无成啊，也没研究点啥，也没提高啥，就跟黄舒骏的《马不停蹄的忧伤》里唱的一样。 从博客的荒废程度就知道今年啥都没干了。 但是自己干的很苦逼，底下兄弟们也很苦逼，整个技术部也很苦逼，原因呢？ 其实最苦逼的倒不是工作忙，忙的有意义经常还让人精神振奋，无意义的才会感觉苦逼。 看来现在是已经过了自由自在搞技术的年代了，邹哥说之前会上有人问运维能否做到40岁，中国运维的起步是1999年，到现在已经17年了，当年23岁的小伙现在也已经40岁了，不过当年那批运维现在都是各厂的管理层了，所以应该现在是没有的，未来说不好，也许运维这个岗位随着云计算的快速发展就会继续萎缩下去，最终只有一些大厂里才会存在的了。 有些趋势你是阻止不了的，你可以往基础上更专，那样确实很有前途，也可以在需求上更广。 怎么说呢，互联网发展那么多年了，但是总离不开tcp/ip的，搞这些基础的要有深度才行。常说移动电信最终给他人做嫁衣，但是那些应用厂商真的离得了这些基础运营商？ Fenng说过一句话现在看来是挺对的，“技术总是在短期内被高估，但是在长期又被低估。” 放在国内任何中小厂里都是适用的，毕竟生存是第一位的。在生存都有问题的情况下谈什么自行车呢？对于商业来说短期利益永远都是第一位的，至于长期的东西谁又能说的清楚呢？ 虽然工作上和技术上没有任何长进，但是从生活上来说是进步很多，小小球一天天的长大，球子也恢复的还不错，只是北京这雾霾天让我对家人的健康很是担心了，而且现在一点没有趋好好迹象，某些发誓2017年前要治理好雾霾的领导也滚蛋了，最终也没有提头来见。 在年末的时候老妈脚骨折了，本来还说过来给小小球过生日的计划也泡汤了，定的机票也给退了。还好恢复的挺快，居然已经拆线了，不过里面的钢钉要不要拿出来还是未知数。老妈住院几乎所有亲戚都来看了，老妈应该还挺欣慰，最好的还是姐妹俩的感情深啊。 2016年的美元价格直线上升啊，但是算了下其实1年差不多是10%的样子，但是买美元可不是为了这个，只是资产的多样配置。2016年我们见识了太多的黑天鹅事件了，所谓的民调现在看来是并不可靠，看来大多数人不会在公共场合中表达自己的真实想法，所以产生了英国脱欧，特朗普当选这样的事件。
直接使用的 https://github.com/airbnb/kafka-statsd-metrics2.git 这个将metric汇报到statsd中。 statsd是使用了collectd自带的plugin来实现的。这样等于每台服务器上都有statsd了。 最后collectd将收集到数据存储到influxdb集群中。 这个jar包在kafka 0.8.2和0.10.0上使用都没有问题。 不过在官网的readme中有些问题，故还是走了点弯路。 必须要自己编译一下。 c git clone https://github.com/airbnb/kafka-statsd-metrics2.git ./gradlew shadowJar 这样我们就可以获得 kafka-statsd-metrics2-0.4.1-all.jar 这个jar包，放入到kafka的libs下。 由于这个是依赖了datadog的statsd client，因此还要下载一个jar包。 https://repo1.maven.org/maven2/com/indeed/java-dogstatsd-client/2.0.16/java-dogstatsd-client-2.0.16.jar 配置文件官网写的没有问题，直接使用就可以了 ```c
#for metric # declare the reporter kafka.metrics.reporters=com.airbnb.kafka.KafkaStatsdMetricsReporter # enable the reporter, (false) external.kafka.statsd.reporter.enabled=true # the host of the StatsD server (localhost) external.kafka.statsd.host=localhost # the port of the StatsD server (8125) external.kafka.statsd.port=8125 # enable the support of statsd tag extension, e.g. datadog statsd (true) external.kafka.statsd.tag.enabled=true # a prefix for all metrics names (empty) external.kafka.statsd.metrics.prefix= # note that the StatsD reporter follows the global polling interval (10) kafka.metrics.polling.interval.secs=60
微服务是去年开始很热门的词汇，有幸碰到老板也想实践微服务的。但是这这中间确实碰到了很多的问题。 首先是api的规范问题，这也是从运维角度来说最重要的部分。 由于之前是单jar包的方式，原先的开发者也不关注api的规范，导致api的URL完全是凭感觉编的，这个在拆分服务的时候就特别头疼。 /api/stat/1 是指向A服务 /api/stat 又是指向B服务 另外一个是输入和输出的问题，api最关键的是保证输入输出能够长期保持一致，就跟你用第三方的api，你总不能让你新增加的response啥的吧，或者json里再增加点新的内容，当然在公司内部，我们还是可以商量的，但是不能今天这个API是做这个功能，明天就变成B功能了。 这个就很头疼了。 配置文件的统一管理，这个因为拆分成很多服务了，所以再也不能一个配置文件解决所有的问题了，那统一起来管理还是很有必要的了。 基础服务saas化（比如redis，cassandra, kafka, MySQL），这些基础通过程序包装起来供程序来申请资源，调用，容灾，升级等。这个也是对于原先的运维团队工作量最大的地方。但是也是必须的。 因为拆分成微服务后，各个服务都可能需要用到redis，是分个大redis池，还是每个服务单独一个池子呢？ 在微服务领域一般都是一个服务给一个池子，但是不应该一概而论的。我们还是要综合评估的。不能为了微服务而微服务的。 日志的汇总收集，展示。这个标准做法就是通过ELK来完成了，当然我们还用到了kafka来做这个。不过前期是做好日志格式的定义。还有别忘记分了新服务出来后要reload下日志插件，不然都还是找的老的服务。这个就扔部署脚本里一起做了。 在实际使用中发现 consul缺乏服务使用率情况，这个现在是通过监控去收集各个服务的信息再汇总到grafana中，后期是想通过kong来做api调度，然后通过这样的https://getkong.org/plugins/runscope/ 插件来实时查看。 而且consul要跟upsync模块结合的话还要自己写程序去迁移consul中service的内容到kv中，这个实时性就不高了。后面准备自己写入和删除kv。 最后：微服务的优势就是为了更好更快的扩展，降低服务之间的耦合性，但是对于开发的要求更高了，对于运维的要求也同样更高了。
jar包都通过maven+nexus来进行管理了。不想部署多套版本管理，所以有些其他程序的也想用nexus来进行版本管理，最简单的方式就是通过curl的了。当然nexus原生还提供使用npm的方式。 主要通过下面2个页面学习了下。 https://support.sonatype.com/hc/en-us/articles/213465818-How-can-I-programatically-upload-an-artifact-into-Nexus- http://stackoverflow.com/questions/4029532/upload-artifacts-to-nexus-without-maven
1 | curl -v -F r=releases -F hasPom=false -F e=zip -F g=com.timoq.blog -F a=Wordpress-frontend -F v=v1.5.2 -F p=zip -F [email protected] -u timo-deploy:PASSWORD http://blog.timoq.com/nexus/service/local/artifact/maven/content |
不过要稍微注意下，上传的Repository的policy必须是release的，不能是snapshot的，至于snapshot和release这2个policy有啥区别，可以参考 http://stackoverflow.com/questions/275555/maven-snapshot-repository-vs-release-repository 其实就是snapshot可以随时改，就是覆盖原先的版本，而release不能。
阿里云RDS有个功能叫临时升级，你可以随意升级多久，但是默认阿里云给你自动升级1年，每次都得往回退。 今天说的是一个奇葩的bug。 6月份为了大促升级了一个RDS，升级33天，就升级了cpu和memory， 可前2天发现磁盘快不够了，于是想升级磁盘到1TB，结果不允许，跳出下面的提示。 
以为还有什么东西还没续费，可看了订单里没有什么东西，都是已经支付的。找售后问就如下回复了。 
最后还是没有升级成，只能自己去清理DB了。 而阿里云的原因就是2个升级操作不能再同一时刻生效。在一个续费变配还没完成以前就不能执行其他的升级和降配的任何操作。 我觉得唯一的理由就是阿里云自己不会算这笔帐了。而这样其实是一个非常大的坑。 这种变配操作你不能设置的很长，但是设置短了可能又会导致自己的麻烦。
用了阿里云服务其实已经很多年了，但是一深入用，感觉各种问题。 这不这次又出问题了。 起因是增加了内存和CPU，阿里云只能在页面中关机，启动才能生效。 这也不说了，其它很多云也都是这样的。 这个机器原先单独加了一个磁盘，做了LVM卷，这下悲剧了，重启以后发现LVM卷丢失了。但是盘还在，没办法只能给阿里与发工单请求解决。 然后阿里云的售后要了root密码，找了半天就这样回复我 “服务器上没有看到任何有lvm创建过的痕迹，建议您其他机器先检查下创建过程是否正常。”。还特地给我截图了一下。 
要是pvs和lvs这些我能看到也就不找售后了。于是打回去让他们继续找。结果他们居然还是找到了，但是原因不知道。 
但有一点还是肯定，他们技术人员还是很敬业的，那么晚了还给我打电话呢，但是从这里可以看到，阿里云的技术是真不怎么样。 后来就懒得用那个数据恢复了。原因找不到没啥意义，我另外几台ES依然不能直接重启，不过后来试了几台，发现都没问题，应该是阿里云自己有什么bug在后台偷偷修复了给。 继续吐槽其他的吧。 原先没VPC，现在有了VPC，但是不支持迁移，也不能互访，就只能通过公网互访。 内部几乎没有标准，有的区使用xvda, xvdb这样的命名方式，但是有的区是vda, vdb也没有啥规律。 网段划分混乱，导致内部无法做nat服务都。 由于没有VPC原先，所以搞了安全组出来，结果一个机器只能有5个安全组，对于我们这种用户远远不够啊。 非高性能IO的机器可以挂载SSD云盘，但是IO还跟原先SATA磁盘一样，理由是底层不支持，但是不支持你倒是别让人挂载啊。 RDS sql审计的功能突然哪天就变成收费了的。 RDS机器居然都是100.xxx.xxx.xxx这样网段的，你们还真敢用。 SLB没有日志，导致没法查看详细的内容，经常出了问题只能摘除后端重建。 原先OSS只能有10个bucket， 不过现在已经增加到1000个，也不知道原先10个限制是怎么想出来的。 API不好用，经常碰到文档跟实际不符合，而且没有像AWS那样一个完整的SDK。 好了，吐槽就这样了。