<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[skybin090804的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/skybin090804</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; skybin090804]]></copyright><item><title><![CDATA[效率篇-定时任务管理系统,替代crontab]]></title><link>https://blog.youkuaiyun.com/skybin090804/article/details/72511168</link><guid>https://blog.youkuaiyun.com/skybin090804/article/details/72511168</guid><author>skybin090804</author><pubDate>Thu, 18 May 2017 22:27:54 +0800</pubDate><description><![CDATA[linux的运维者，逃脱不了定时任务的命题，最常用和快捷简单的是crontab，在少量机器的情况下，crontab效率还是比较高和比较便捷。但当机器越多、应用越多的情况下，继续使用crontab进行定时任务的管理配置，那严重影响工作效率。


机器多、服务多的情况下，就会遇到以下问题：
1.不知道哪个定时任务没配置好，瞎跑；
2.运维人员需要登录服务进行配置和管理；
3.运维人员需要全]]></description><category></category></item><item><title><![CDATA[杂谈篇-nginx(tengine)+lua动态后端实现,无间断扩容缩容]]></title><link>https://blog.youkuaiyun.com/skybin090804/article/details/70987208</link><guid>https://blog.youkuaiyun.com/skybin090804/article/details/70987208</guid><author>skybin090804</author><pubDate>Sat, 29 Apr 2017 19:39:02 +0800</pubDate><description><![CDATA[现在很多地方都使用nginx或者tengine进行前端的负载均衡，但单纯使用nginx（tengine）不能完全满足日常需求，所以，需要进行适当的功能扩展，在以往只能是nginx c模块开发，这样费时费力还难维护，对于中小型公司简直是一万点伤害呢。幸运的是有大神做了nginx的lua模块，使得nginx（tengine）功能扩展变得简单和易维护。


结合我们现在正在使用的例子，分几篇文章和]]></description><category></category></item><item><title><![CDATA[杂谈篇-用lua在nginx中实现一个WAF]]></title><link>https://blog.youkuaiyun.com/skybin090804/article/details/70045887</link><guid>https://blog.youkuaiyun.com/skybin090804/article/details/70045887</guid><author>skybin090804</author><pubDate>Tue, 11 Apr 2017 09:41:02 +0800</pubDate><description><![CDATA[几年前，开始在公众视野中不断爆发出应用的安全问题。当时想着应用运维能否也能在nginx中为应用做一层防护，基于该前提下，在Nginx中用Lua做WAF的架构就开始启动。在这里和大家分享一下这套小东西。


整个 WAF 系统的结构
拦截处理模块（ nginx 、Lua）
日志收集模块（ lua、kafka ）
日志分析模块（spark + mysql ）
数据展示模块（ web ）]]></description><category></category></item><item><title><![CDATA[优化篇-图片浏览]]></title><link>https://blog.youkuaiyun.com/skybin090804/article/details/68946539</link><guid>https://blog.youkuaiyun.com/skybin090804/article/details/68946539</guid><author>skybin090804</author><pubDate>Sat, 01 Apr 2017 17:28:19 +0800</pubDate><description><![CDATA[本编文章是介绍图片优化系列的最后一章，主要是介绍在用户端出图性能方面的优化工作。


图片体积
在保障图片质量的前提，缩减图片等体积无疑是为用户浏览图片提速。


图片EXIF信息
图片EXIF信息可以附加于JPEG、TIFF、RIFF等文件之中，为其增加有关数码相机拍摄信息的内容和索引图或图像处理软件的版本信息。大家可以“度娘“一下，exif信息还是记录不少东西。但对于非摄影类图]]></description><category></category></item><item><title><![CDATA[优化篇-图片动态转图]]></title><link>https://blog.youkuaiyun.com/skybin090804/article/details/68205290</link><guid>https://blog.youkuaiyun.com/skybin090804/article/details/68205290</guid><author>skybin090804</author><pubDate>Wed, 29 Mar 2017 22:34:54 +0800</pubDate><description><![CDATA[在前面分别介绍了“移动端”图片上传架构的变迁、后端图片服务的升级，剩下还有图片浏览优化、动态转图要和大家分享，本篇文章先介绍动态转图。


项目背景：2012年年底的时候，移动端的兴起，但图片需求和pc端要求（尺寸、大小、体积）不一样，需要对图片进行重新裁剪，但现有图片量大概是20T，转换实在是一个漫长的流程；当时不断地去参考别人家（云图片存储和处理当时市面上还没有），终于在淘宝（taoba]]></description><category></category></item><item><title><![CDATA[优化篇-后端图片服务的“打怪升级”]]></title><link>https://blog.youkuaiyun.com/skybin090804/article/details/63693676</link><guid>https://blog.youkuaiyun.com/skybin090804/article/details/63693676</guid><author>skybin090804</author><pubDate>Sun, 19 Mar 2017 20:57:42 +0800</pubDate><description><![CDATA[原文再续，书接上一回，上一篇主要分享了移动端上传优化，同时也指出图片在互联网应用中的重要性；本章节主要分享后端图片服务架构不断变迁过程。


图片架构整体的演进过程大致分两个阶段：集中式、分布式。


集中式-单机模式-本地存储
在图片较少的情况下，可以直接将上传+图片浏览放在同一个机器中，用web server（apache httpd或nginx）提供浏览服务。
优点：实现简单]]></description><category></category></item><item><title><![CDATA[优化篇-“移动端”图片上传架构的变迁]]></title><link>https://blog.youkuaiyun.com/skybin090804/article/details/62220155</link><guid>https://blog.youkuaiyun.com/skybin090804/article/details/62220155</guid><author>skybin090804</author><pubDate>Wed, 15 Mar 2017 12:53:54 +0800</pubDate><description><![CDATA[做互联网应用少不了图片的支撑，图片的上传、浏览速度很大程度上决定着用户的体验，甚至用户去留，就因为其重要，所以，在任何时候，图片的架构和优化都在进行，不敢丝毫放松。




在以后几个章节，会从后端图片存储、前端浏览、动态浏览这些方面和大家分享一下我们一路过来的经验。




经过数据的观察，APP、WAP的用户量基本与PC端持平甚至超越，因此，应移动端用户体验和访问速度都被运]]></description><category></category></item><item><title><![CDATA[效率篇-“私人订制”Openstack管理后台]]></title><link>https://blog.youkuaiyun.com/skybin090804/article/details/61615596</link><guid>https://blog.youkuaiyun.com/skybin090804/article/details/61615596</guid><author>skybin090804</author><pubDate>Sun, 12 Mar 2017 11:35:31 +0800</pubDate><description><![CDATA[当在排除万难上线openstack后，发现官方管理后台（dashboard）那么的简洁、那么的歪果仁化，有没有一种做一次“私人订制”的冲动。在线上跑了一段时间后这种冲动转化了动力，用了半个月时间推出融合部门内各个同事需求的openstack 管理后台。




不能容忍的点

1.各个机房都会存在1+套openstack，管理员需要登录多套dashboard。

2.虚机等信息与]]></description><category></category></item><item><title><![CDATA[效率篇-告警消息接收，借用微信企业号，想收就收So easy！！！]]></title><link>https://blog.youkuaiyun.com/skybin090804/article/details/60978131</link><guid>https://blog.youkuaiyun.com/skybin090804/article/details/60978131</guid><author>skybin090804</author><pubDate>Thu, 09 Mar 2017 22:29:00 +0800</pubDate><description><![CDATA[身为苦逼的运维，就算是非工作时间也需要实时了解所负责应用是否处于不健康、危机状态，争取第一时间恢复，这是做运维这份工必须担当的责任。既然逃不过，就要考虑通过什么渠道能低成本、方便、快速、稳定接收告警信息。






处于2014之前，接收信息是比较头痛问题，因为就只有那么一两种方式。

1.短信猫，按信息量计费，并有时候不稳定。

2.移动用户139邮箱，开通邮件通知，就能]]></description><category></category></item><item><title><![CDATA[效率篇-SQL自助查询平台]]></title><link>https://blog.youkuaiyun.com/skybin090804/article/details/60959060</link><guid>https://blog.youkuaiyun.com/skybin090804/article/details/60959060</guid><author>skybin090804</author><pubDate>Thu, 09 Mar 2017 14:02:39 +0800</pubDate><description><![CDATA[使用时间：2014-05 - 至今。


升级&变动：投入运作后没做任何修改变动，放养状态。


运行情况：内部环境下使用，日均分担DBA工作量500次+查询。


诞生背景：DBA人数-3，DBA除了做常规维护和数据库优化外，还需要花大量时间帮开发查询非敏感数据。


需求：1.查询不能影响线上数据库服务；2.与现有运维系统做Restful API对接；
3.不能接收数]]></description><category></category></item></channel></rss>