关于蚊香狗

真的是long time no see了,一直没有更新博客最近。难道我挂了?然而并没有!

今天要安利的是一个基于nodejs的api网关中间件:蚊香狗(下文称:MCDog)

没错,是我最近做的一个模块。虽然还处于初期,但还是忍不住给大家分享一下。

其实关于网关模块,很久前就已经开始关注了,由于种种原因(拖延症)一直没有下手。不过,现在公司开始需要这样一个中间件,刚好我又有时间有兴趣,就着手随便搞了搞。

之所以叫蚊香狗,并没有什么特殊含义,就是觉得足够猎奇,创意来自于下面的这张图:

说回正题,其实目前MCDog提供的功能简陋的不要不要的,我也强烈推荐不要真的部署在生产环境上。不过,这并不表示它完全没有价值。你完全可以把项目在本地跑起来,然后将计划合并的api创建出来,然后把MCDog生成的文件放到线上来提供服务。

而一个称职的网关系统,对可用性和安全性要求都是很高的,同时还要保证灵活可扩展,对于我这样能力的人来说确实有些难以实现。两周前无意间看到了一篇文章,感觉其思路很好,就立马着手开发了这个扩展版。

在开发MCDog过程中,除了已知的难题外,还遇到了一些计划外的问题,小有收获。例如,在校验和解析使用者提交的DSL时,要求要尽可能覆盖到所有异常情况,生成的代码一定要捕获所有可能的异常。

尽管MCDog目前的DSL校验和解析的完善度还不够,采用的解决方案和实现的代码可能也很土鳖,未来也许会选择完全不同的路线。不过在编码的过程中我还是充满了乐趣的。

这篇文章并不打算详细介绍MCDog的使用方式和开发思路,因为我已经在github上提交了较为完整的文档,有兴趣的童鞋可以看一眼去,也欢迎大家把想法和问题在github上反馈给我。

好了,不说了,回家《地平线:黎明》去~~~

如何避免遭受Wordpress的xmlrpc攻击

早上收到领导简讯,说公司官网无法访问了。omg,这怎么可能?第一反应是为啥360监控没有第一时间给我邮件提醒类?

然后立刻登录到服务器上,发现所有的配置都没有变更过,运行了几个月就突然挂了吗?而且从表象上来看,nginx依然坚挺,只是返回403错误而已。
这里需要注意的是,打开配置文件之前一定要先查看一下核心配置文件的最后修改日期,这样可以知道是否有其他人登录服务器修改过。

我毫无头绪的尝试了一些配置的修改后放弃了,因为一切都是那么的自然,毫无理由的就403了,nginx在,php-fpm也在。不过,nginx只能提供静态资源的请求,
所有对php的请求都直接403了。

最终我只能去翻看一下nginx的日志文件,发现了线索:

… connect() to unix:/var/run/php5-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client…

日志中还显示出了一个ip地址,查了一下是一个芬兰的地址,不停的请求xmlrpc.php,引起了我的关注。

将该地址加入黑名单后,瞬间网站就恢复了。

由于服务器配置不高,所有我之前给php-fpm分配的配额很低,所以大量的请求一下子就让php-fpm饱和了。所以就有了前面的403返回。

有趣的是,对方使用了一个固定的ip不停的发来请求,如果是大量不同的ip,我可能到现在都无法定位问题。这里还是要提醒大家:线上系统突然出现问题,一定要第一时间去翻看日志。这样可以省去大量的时间来猜疑,像我,一开始就认为是https配置的问题。

接下来我查了一下wordpress的xmlrpc攻击相关的文章,发现这个问题对于使用wp的网站来说似乎普遍存在。
这篇文章 有非常细致的剖析问题和提供了多种的解决方案,非常推荐看一下。

安利Ios的web远程调试神器

今天是农历春节前的最后一班岗,站好!

前几天我们组的项目上线了一个手机端页面,一切都是那么自然,只是到发现问题后调试的时候很慌张。

andriod还好,很容易就找到了远程调试的方法,一条数据线即可,直接开启强大的chrome开发者工具,十八般兵器任君挑选。

可ios下就有点辣鸡了,基本上只能使用fiddle来抓包。我们不是专门的移动端开发团队,所以公司并没有给配mac机。黑苹果也不赶趟啊~

今天突然发现一个方案,实测有效,高兴坏我了。

它的名字叫: weinre

现在,我想说的就只有这些,祝大家新年快乐,随便扫得敬业福!

2016不完全感悟

这是一个对我来说变革的一年,上一次类似的变革发生在大概3年多前,那一次侧重于技术认知上的变革,这一次偏向于为人处事上的!

程序生涯已有9年,写代码对我来说已经成了一种生存本能,和呼吸一样。虽然岗位变迁了几次,title也不停的变更,但对我来说初心未变,我依然清晰的记得第一次自己写的程序成功运行时的那刻喜悦,每每脑中浮现那一幕,嘴角依然会不由自主的上扬!

我是个没有长性的类型,所以做一件事儿做了九年,这对我来说真的是一个奇迹。我此时此刻依然在庆幸选择了程序人生。记得刚毕业时,一个小小的伪愤青,骂公司,骂领导,骂同事,基本上恨不得拿着一把标尺去评价每一个人。那个阶段,活的虽然很有干劲儿,但却不顺利,自己内心清楚,那种格格不入的感觉无时无刻不让自己感到很无助。

曾经觉得,自己是千里马,自己是主人公,自己有主角光环,虽然这和祖国的教育脱不了干系,但总不能全都责怪整个世界,愚钝的自己不懂得自我反思,活的累也是活该。思维一旦跳出来,一切也就跟着不同了。

跳出固有的思维模式,虽然很多心灵鸡汤都有强调,但真的让我有所顿悟的还是我的老朋友:代码。曾经以为程序世界,非黑即白,对就是对错就是错,不存在丝毫妥协。在开头提到的我的第一次技术变革后,我明白了,即便是一个完美的技术方案,其中也无处不在权衡利弊。一个绝对正确的方案只可能存在于空气中,世界上任何一个个人或团队都不可能将其落地。那是我的感悟是,毕竟架构包含方方面面,涉及到企业文化,组织结构,甚至参与者的个人修养。简单的一个函数应该就很纯粹了吧,总不至于还要有什么妥协了吧?

我不清楚如何详细的描述我想要表达的场景,但我深刻的认识到,即便是一个功能简单的函数,也有可能存在权衡,一味的追求极致有时候真的是自取灭亡。“调的一手好参数”就能得到最佳结果真的不是什么玄学。虽然这里面包含枯燥的数学原理,但大道至简,平衡各方才能达到最大效能。

15年中的时候,我离开了上一家公司,16年初到现在的公司,这就是我开头提到的我个人的第二次变革。虽然我担心你误解我的本意,但我依然想用“垃圾”来形容上一家公司。它让我看到了人性的阴暗面,虽然里面也有我尊重的人,但带给我更多的是一种精神污染。现在回想起,依然有反胃感。人与人之间,信任可以不谈,尊重可以没有,但虚伪真的让我受不了,上至领导,下至员工,随处可见的虚伪和欺骗,让我如履薄冰。离开它曾经让我误以为是错过了一个人生高峰,但事实却证明对我来讲,它只是一个深渊,爬的出来就是一种成长。敬还在公司的我尊敬的那几个人,祝福你们衷心的。

整整一个16年,我在新的公司,新的岗位继续成长着。虽然有些新的同事我不欣赏,但总体是幸福美好的,上级给予我足够的信任和尊重,同事相处也很和谐。自己也不再过于固执,很多存在妥协空间的事儿也都懂得妥协,求同存异嘛。虽然仍然会因为一些讨论控制不住自己的情绪,但总体还是处于稳态。

17年,依然很多事儿等着我来面对,不过相比年初时的我,少了彷徨和失落。我仅有的阅历,让我明白如何努力,才能完成目标,足够我识人辨事,与人相处。路还很远,路在脚下,路没错,走起~~~

Request使用proxy导致的socket连接数泄漏问题

这是一篇快餐文章,源于前天接到了服务器预警邮件,提示:连接数超过阀值。

快速定位问题,发现是因为之前跑的一个nodejs开发的小程序,该程序用于定时去指定网站采集相关数据的。

由于要采集的网站需要设置翻墙代理,很麻烦的。之前直接使用Request来发http请求也没碰到这个问题。所以归结为是由于使用proxy不稳定,导致大量的socket异常。

在进入主题之前,先吐槽一下Request这个库,它的文档看似详实,但如果你仔细阅读就会发现很简陋。很多地方感觉欲言又止,很是让人烦躁。

尝试去看它的源码,发现它返回异常的方式采用了2种不同的方法(一般异步方法都如此处理):

  • 沿用nodejs的回调返回异常风格
  • 发布异常事件

这也是一开始总是被无法捕获的异常导致程序crash的原因。

去github上的issues翻到别人的异常捕获异常方法,也是醉了:

1
2
3
4
5
6
7
Request
.get({/*some config*/}, function(err, response){/*回调逻辑,第一个参数为error*/})
.on('error', function(error){
// 再次绑定error事件
console.error('Request on error');
console.error(error.stack);
});

按道理说,这两种方式同时只需要用一种,同时使用两种则会发生重复调用问题。但如果我们没有绑定error事件(只采用回调风格),socket级别的异常是无法捕获得到的,这也就导致了上面的方案。不过经过绑定了这个error事件后,发现几乎Request触发的所有异常都被其捕获到了,不会再因为无法捕获的异常而导致程序crash了(还存在一些异常,我建议process.on('uncaughtException')还是不能省)。

接下来主题,先看一下一个issue,题主已经详细描述了问题也给了解决方案。
实测了一天,感觉确实解决了,至少从图标中观测正常许多了:

如果去看源码,会发现很绕,毕竟到处可见的回调和事件流。不过从解决方案上来看,很直观。思路就是在: 确保在链接出现异常后也触发回调,在回调中来处理善后工作,最终会回收相关资源,而不是直接清除掉必要的事件监听器

去看源码吧,你将会收获更多。

去年的今天就是你的Deadline

我最近有个感悟:时间,最复杂的存在。

像我这样一个从没有跨过时区的孩子,是感受不到时间算法的复杂度的。直到有一天,我们的系统需要面对多时区的场景,我才恍然大悟。简简单单的一个时区问题都已经让系统很多基于时间的逻辑变得复杂,更不要提分布式时序问题了(我们今天并不讨论这个问题,我也讲不好)。

阅读全文

Javascript项目单元测试小结

这几天在写一个采集程序,用nodejs。老实讲这是第二次(相对正式)写和采集有关的模块,第一次是因为要定时访问自身项目来触发缓存的,细节可以看这里。后来从上一家公司离职,也没有继续维护这个程序了。
这次算是正宗的采集模块(确实是从目标网站中获取有价值的内容,我就不方便透露具体细节了~),而且这个项目是正式产品,不像之前公司那样扯~~这篇文章本身不是讲采集程序细节的,其实个人感觉开源的采集系统已经很成熟了,如果不是有特别特殊的需求,还是不要重复造轮子的好。

阅读全文

译-Sinon入门:利用Mocks,Spies和Stubs完成javascript测试

最近写完一个基于nodejs的组件后的我打算为其写一下单元测试,本以为之前了解过相当多的关于测试的知识,应该可以很顺利的搞定,可真的去写测试项的时候才发现依然存在一些需要克服的困难。不过,接下来翻译的这篇文章就是专门针对测试神器的,应该可以帮到和我一样的新手。

原文地址:https://www.sitepoint.com/sinon-tutorial-javascript-testing-mocks-spies-stubs/

阅读全文

一次被咨询后的感触

上周末陪着朋友去谈项目,刚好派单方是我以前的同事(好吧,其实我就是传说中的介绍人~)。一进办公室,对方的程序员就开始直奔主题,让我感到些许的不舒服。别误会,我十分喜欢开门见山直奔主题,但项目背景肯定是不能省的,直接进入具体功能细节真的让我感觉不适应。不过考虑到我只是个旁听,所以也就耐着性子听了一会~不一会老板来了,我就被拉出来私聊了。

阅读全文

十月份杂谈

Long time no write.

整整一个多月没有更新blog,原因有很多,但主要还是忙~

现在工作岗位偏重需求分析,我需要花大量的精力在与需求方一起讨论工作流程和系统的落地方案上。纯粹的技术性质的问题一般都会交给
其余同事负责跟进。所以一时不知道应该写什么在博客,毕竟之前博客都是偏向具体技术问题的主题。

阅读全文

如何基于接口文档生成模拟数据

前后端分离是目前主流的团队开发方式,有效的隔离不同技术领域开发人员的依赖,包括开发进度上的依赖和代码文件上的依赖。而做到这一点,全靠一个规则:依赖接口而不依赖实现。

那么,web领域前后端分离,通常都会选择基于http+json的方式,也就是大家说的restful类型的接口。在进入代码编写之前,团队会定义好所有依赖的rest接口,前后端开发人员遵照接口文档各自完成自己的工作,完美!

阅读全文

译-在多个标签页之间共享sessionStorage

原文:Sharing sessionStorage between tabs for secure multi-tab authentication

译者得er瑟


昨天,就在昨天,前端一同事提了一个问题:我们的系统,用户重新开一个标签页,就要重新登录。我当时觉得这怎么可能?结果现场一测,还真是,好尴尬!

今天抽了点时间网上查了查,才发现原来一直以为很简单的sessionStorage,还真埋了这么一颗雷。不过国外前辈也提出了一个解决方案,不仅如此,文章还把浏览器端保存数据的场景分析的很透彻,所以斗胆翻译了一下。

阅读全文

小团队玩不转的测试

早在上一家公司,就为测试问题头疼过,那时候测试全靠人肉,还整出了黑盒白盒测试文档,还要对代码进行打点,还要人工去匹配打点数据是否执行…都是泪,都是泪,都是泪啊!

那个时候团队人数最多时有十二个,项目现在想想也不算大,按道理是可以分出来一部分人来专做测试工作的,只是当时无法说服领导成立测试小组,毕竟自己也没有自动化测试的经验。最后强迫别的部门的同事来帮我们测,除了心不甘请不愿外,测试的结果也不是特别的理想。

换了一家公司,依然是四人小团队,现在我开始琢磨如何自动化测试了。毕竟之前的不愉快精力,再加上我现在的岗位更多是解决团队的开发效率问题,所以必须得正视这个头疼的问题。

阅读全文

Git Hook帮你维护前端代码规范

只要不是一个人在战斗,你都一定会碰到很多工程问题。我们今天来说的,就是代码格式问题。这不是个什么有意思的话题,这个话题讲的就是条条框框,就是枯燥,就是没意思。但是,如果你的团队缺少代码格式规范的话,当你review组员的代码时,你就会感觉在吃屎,没错,不夸张!

我不怀疑团队组员的积极性,因为条条框框本来就不是程序员的调调,而且人类和机器的最大差别就是遵守规范的程度。所以,你不能要求你口头上说代码格式要怎样怎么,所有同事就会立刻写出符合要求的完美代码。

阅读全文

Open-Falcon初探

随着项目的开发一点一点的完成,离初版上线日期已经越来越近了,这样就涉及到各种运维问题,监控的意义就体现出来了。虽然项目最终会部署在云平台,而云平台自身会带监控套件,不过不够灵活,一些想要的指标和报警方式还是需要自己来实现。大概看了几款监控解决方案,对Open-Falcon特别有好感,虽然我不懂GO语言~

阅读全文