一个媒体行业Coder的10周年回顾

不知不觉从业小10年了,想想上学那会,刚接触互联网的时候,玩的都是域名、虚拟主机、CMS、肉鸡这些,现在的大学生玩的都是大数据、机器学习这些了,真的有种旧貌换新颜的感觉。

10年前,一边学着编程,一边尝试自己做点东西放网上,那时候主要是接触到都是些很廉价的虚拟主机,而且针对学生也没啥优惠,再便宜一年也要小300块,所以服务器资源都是从饭钱里省出来的,现在学生9.9就能买服务器了,条件比我们那时候优渥很多了,社会在进步~

我毕业后,脑子一热,一脚跨进了媒体行业做研发,10年风雨,一路走来,无论是研发还是企业管理都感触颇多,感触最深的是开源、云化对行业的影响是最深的。

因为我们本身是做媒体行业软件的企业,10年,我们的客户需要花费好几十万去采购一套软件,然后再买上3-5台服务器去部署到本地,之后每次升级再花几万块请技术人员来上门服务。

彼时,传统媒体大兴,没有人觉得这中付费模式和交付方式是一个问题,因为当时的传媒集团都很有钱,然而随着互联网的发达、新媒体的崛起,传统媒体的日子越来越不好过,“一次性付费+本地部署”这种模式就变成了它们的负担,而且新媒体的崛起倒逼着传统媒体要“快一点”、“再快一点”,整个行业的系统服务、软件服务都到了迫切改革的时候,此时我们推出了基于云环境的SaaS化服务,在行业内获得了较好的口碑。这一切的背后既是时代的变迁,也是科技的进步,才让我们以传统厂商10%的成本去运营,1%的周期去交付我们的产品。也正是借着这个机会,我们彻底的拥抱了云生态。

那时候,我们的技术栈主要是SVN+PHP+MYSQL,因为创业初期我们需要更好的迭代效率和更低的招聘成本。

运作一年后,产品也卖的不错,口碑也不错,但是我们收到的运营故障直线上升,处理BUG的效率也大不如前,我们开始反思,是不是我们的技术栈出了问题?是不是我们的运维技术不到家?

后来经过一系列的调整,我们调整了我们的技术栈。

所有基于HTTP的服务,使用Git+PHP+MongoDB进行处理,大数据集的检索使用阿里云的OpenSearch进行管理和供能,日志全量打入SLS中。

所有持久化的服务,使用Git+JAVA+MongoDB进行处理,统一通过阿里云的MNS队列进行调度管理,日志同样打入到SLS中。

所有打入SLS的数据,最终可以通过ODPS(MaxCompute)进行离线计算并输出,为企业提供了一整套的大数据处理方案。

就这样运作了一段时间后,产品的运营、研发没问题了,但是迭代交付和运维开始出现问题,我们做了一个大胆的决定,很激进的把架构层进行了重构,全量依托Docker进行产品的交付、运行,也因此我们成了阿里云容器服务的第一个商业客户。

再后来,我们内部提效升级,把研发工作流改为了阿里云的“云效”产品,彼时它还叫“RDC”,还没有这么洋气的名字。

我们从2010年开始拥抱阿里云,虽然踩过很多坑,走过很多弯路,但是给我印象最深的是阿里云同学的坚韧光芒。

你凌晨3点业务出问题了,阿里云的同学会在5分钟内钉钉或者电话给你处理,问题比较大的情况下可能整个产品部门的同学都会参与,往往是凌晨3点出问题,拉了个钉钉群,处理到天亮发现群里有20个阿里的同学了。

阿里云的产品永远在走向完美的路上,但是这一路上少不了同学们的添砖加瓦、架桥铺路!

因为之前的经历,认识了上百位阿里云的工程师,也为很多产品提出了建议,所以有幸在2017年受邀成为“阿里云MVP”的一员。

加入MVP组织后,觉得最大的感觉是,压力变大了,因为大家的水平都很高,倒逼着你去学习,去成长,去做更优秀的人。

所以我在18年的深圳云栖大会上做分享的时候最后以一句“我见青山多妩媚,料青山见我应如是”收尾,也是希望在我眼中的优秀的MVP们,看我时也觉得我很优秀,算是一种鞭策激励吧~

加入MVP组织后,隐形福利挺多,首先你出的产品出问题后,响应时间更快了。而且提产品建议响应的更好、更被重视。再加上和各种行业大牛的交流机会,更是难得。

最让我高兴的是,可以提前体验各种阿里云的内测新产品,比如我最近就领了一套阿里云的物联网开发套件进行体验,虽然我不是IoT方向的开发人员,但是玩玩树莓派还是很有乐趣的。

10年来,作为一个技术人,云计算一定是对我影响最大的事件,阿里云作为中国云计算领域的佼佼者在我的技术生涯中是举足轻重的。

阿里把一整套阿里的能力对外输出,把曾经阿里踩过的坑和得到的经验都毫无保留的告诉了全世界,给了我们技术人员一盏指路明灯。

这种思想上的传递,是我觉得阿里云如此重要的原因!也正是因为众多的技术人、公司吸收了这些思维火花,才创造了如此多的奇迹。

巧用RDS全家桶搭建亿级新闻源仓库

我们的业务,有一个实时新闻源库,初始大概有3000万数据,现在大概有上亿条数据了,我们在起初的处理方式比较简单粗暴,直接购买了3台8核16G的SSD版本的ECS,组成了一主双从的机组,从库只读。

业务是单库,但是具体的内容是分表的,比如:

article_content_01一直到article_content_200或更多,业务系统会在满足要求后实时创建新的表,每张表的数据量大概在100万左右。

我们在2013/2014年开始遇到各种各样的问题,也算是一些经验教训吧:

1.使用ECS组建的数据库集群,可用性不是特别特别的高,主要受限于IO、网络同步速率。甚至遇到过从库意外关机,然后影响业务了。

2.我们把所有的读取SQL放到了从库进行,但是问题来了,我们的开发语言是php,所以它没有办法像JAVA那样做一个连接池来处理请求,一开始我们使用一个随机算法来分配每次读请求所使用的从库,导致当我们的并发很大的时候,从库的连接分配策略会出现不平均的问题,从而导致某个从库满载。虽然最后通Haproxy完成了从库的负载均衡,但是也带来了额外的运维负担。这个谈不上是坑,算是一个经验教训,想当然的以为随机算法可以替代负载均衡了。

3.风控的问题 ,有的时候一些不应该发生的低级错误就是这么堂而皇之的出现了,比如,测试库只有3000万数据,而正式库有3亿数据,有些逻辑代码在测试库的响应正常并不代表在正式库也是正常的。如果你不能敏感并及时的去处理慢查询,那业务基本也就凉了。

4.监控的问题不提了,直到最后都没找到一个称心如意的MYSQL监控解决方案。

5.审计的问题,我们永远处于有日志,而没办法审计的状态,有事没事假装看看罢了。

6.备份就讨厌了,需要手动这先不说。备份时机、锁表、备份后的归档处理、定时清理老备份、备份文件的校验,这些都是事儿啊,对运维人员来说,都是很低级但是不得不做的工作。

7.有的时候,你的Web服务器抗住了流量,但是不幸的是你的数据库没能坚持下去,这种突发的流量往往没办法预测,或者出现后需要最短时间内修复,我们出现过大概3次,每次大概2小时时间去扩容,会影响一部分我们用户的体验,表现为卡顿、页面报错等。

8.硬成本和运维成本问题,3台高配ECS+1个全职运维人员的成本,一年下来少说也要几十万。

问题应该有很多,但是只能想到这些,先记下来吧。其实有很多问题不是MYSQL的问题,属于架构层面或者开发层面的问题,但是我们谈一个具体技术细节的时候不能只谈它本身,没有场景和实践,那是耍流氓啊。


然后我们从15年开始,实在是不行了,这种方式已经让所有人都接近崩溃,所以我们考虑切换到RDS上去,当时只是先切换了几个不重要的业务库,试试看效果。然后一发不可收拾,总结一句话,这产品除了价格,简直完美。

首先RDS for Mysql解决了我之前提到的几个问题:

1.托管式的服务,动态弹性的升级,不需要关心运维的问题。

2.可以动态的添加只读库,方便。

3.控制台对慢查询很敏感(虽然这个是近2年才有的功能),而且可以做报警。

4.阿里云现在这一版的控制台看监控还算是比较舒服,也能看的全。

5.日志审计这一块,通过最新版本的阿里云DMS已经可以比较简单的完成了,它还有个收费版,没用过,没有发言权,但是现在这个免费的版本也挺不错的。

6.备份不提,阿里云RDS的备份已经做得很好了。

以上的问题,除了突发流量暴库的问题不能通过RDS直接解决,其他都能很好的解决了。而且相对于3个ECS的成本,单独购买RDS的费用也还在可以接受的范围内。

下面说一下,我们如何解决突发流量的问题,阿里云有个比较好的产品叫DRDS,但是这个产品属于好用,但知名度不高的一个状态,可能是小客户用到的概率不高吧。

DRDS扮演了一个类似负载均衡器的角色,当然了,比普通的负载均衡更高级一些。它不仅仅是Haproxy这种基于网络点的负载均衡,还可以针对SQL进行负载均衡,这一点在处理超大表检索的时候特别好用。而且它的后端是一个个的RDS,对于低成本突破连接数限制有非常大的帮助,同时弹性增减扩容,只需要购买按量RDS就可以了。

在高并发的场景下,数据库遇到的问题主要在于连接数限制、IO限制、锁、并发读写等问题,这些问题通过RDS/DRDS几乎都可以很好地去进行处理,有些高级应用需要做一点点开发上的让步。


阿里云的RDS实例其实也经过变迁的,起初是只限制内存和连接数,后来才出现“CPU核数”这个概念,所以也导致了我这种老用户一度很难适应,毕竟老版本2400M内存的RDS就默认8核了,而现在购买一个8核的RDS价格还是比较高的。我有个骨灰级的实例,可以截图给大家看下,现在买不到啦:

有一段时间,时不时也会收到短信提示,RDS发生主备切换云云,起初是比较紧张的,担心阿里云的技术不硬从而影响我的业务,后来切换过多次之后,发现真的没出过问题,从此也就安心了,小顾虑罢了。


最后一部分说一下,我们如何解决全文检索的问题,因为有分表的原因,所以很难通过程序去完成全文检索,而且因为量大Like语句基本不可能使用。在这种情况下,我们开始尝试使用第三方的工具去完成,比如Sphinx 。但是我们很快又遇到了问题:

1.成本问题,因为Sphinx 不写磁盘,一切读取到后都存在内存,所以几亿数据对内存的要求就高了,买ECS的时候就要买高内存的配置。

2.Sphinx一次性读取数据到内存这个过程,可能对业务产生一定性能影响,但是不严重。

3.Sphinx 的运维问题及配置问题。

然后我们偶然的发掘了阿里云的OpenSearch产品,支持RDS一键同步并且可视化的创建表、索引很舒心,还提供了SDK和各种好用的函数。唯一的问题在于,价格感人,特别是数据量大且每天并发检索高的用户来说,这个成本很可观。但是优点也很明显:

1.除了一开始的创建,几乎不需要你运维。

2.所有数据都打平到一层,检索速度极快。

3.支持分表结构,支持多个实体表,支持主外键关联,万物皆可查询。

4.对数据源几乎没有任何影响,即便你源库挂了,检索服务依旧可用。


就先写到这里了,都是些经验教训,谈不上太高深的技巧,主要还是要结合场景去做一个适合自己业务的架构。现在我们关系型数据库用RDS for Mysql,NoSQL数据库使用RDS for MongoDB,一路走来也都挺好的,虽然某个阶段它有这样那样的问题,但是一个持续迭代的产品必然会有更高的生命力和稳定性。

 

记一次DataX导致的数据同步断头路(二)

经过几天的尝试,发现在DataX层面、数加层面是真的无法解决这个问题了,我调整了策略,计划使用MongoDB的自定义方法来实现,我在MongoDB中创建了一个名为“TS10”的方法,用于将”2018-06-06 18:00:00″这种字符串转为10位时间戳。

一切准备就绪,自定义方法也创建完成了,一切都很顺利。

当我想要实践的时候,突然发现阿里云的MongoDB团队出于安全考虑,全局禁用了db.eval()方法,这样一来,我的自定义方法无法运行,也就无法提供给DataX调用了。

再次断头。

记一次DataX导致的数据同步断头路(一)

最近因为业务需要,想要把Mongodb中的某些数据打入到阿里云的OpenSearch中进行检索,在同步的过程中遇到一些问题,导致暂时没能进行下去,这里做一次笔记。

images

可以看到的是,阿里云的DataX中,Mongodb Reader使用的是Mongo SDK(JAVA),所以不能像直连MongoDB数据库那样执行mongo shell,也就不支持JS语法,也就无法实现字符转10位时间戳的效果。

而又因为数加平台本身不提供底层的字符串转时间戳的能力,所以也不能在数加平台进行处理。

此处断头,暂时无法解决,如果后续解决了,再更新一下。

记一次WIN10权限问题导致的程序开发故障

前两天用.NET写了个命令行工具,主要是读取本地磁盘上的文件,然后生成对应的XML文件。

原理上并不复杂,代码寥寥数百行,但是却遇到一个很致命的问题,程序运行的极慢极慢,处理一个文件并生成XML文件的过程需要30秒到几分钟。

一直以为是自己的代码有问题,反复检查了好久。

最后突然想到,是不是在WIN10下非管理员权限大量产生IO会被系统拒绝或审查?

紧接着尝试了一下,直接使用管理员权限运行程序,速度飞快,0.1秒不到就完成一个文件了。

这件事上,吸取经验教训,开发人员真的应该换换环境,老在WIN7、CentOS6这些系统上开发,会忽略最新版本的操作系统特性。