小欧有话说:
2016年10月28日,EGO杭州分会带领会员走进咪咕数媒,特别邀请到咪咕技术支撑部的多位技术专家,分享快速扩张背后,咪咕的技术探索与演进。其中,咪咕数媒技术部副总监张仲广向大家分享了咪咕架构演进之路。
本文根据其分享整理而成,分享给未能到现场的你,有删减。
【文章结构】
1.咪咕业务场景介绍
2.第一期:架构面临的问题以及解决办法
3.第二期:单体量庞大 新业务产品上线慢
4.第三期:在云化方面面临的问题
5.问答
各位专家下午好,我叫张仲广,先做一下自我介绍,我是2004年浙大毕业,最开始做增值业务,后来投入互联网和移动互联网,2009年手机阅读基地成立的时候,开始做一些技术方面的工作,一直做到现在。手机阅读这块是依托于国企,不敢说做得特别好,但是经历的痛苦和收获很多,今天针对架构演进做一个分享,我们的题目是“五全数字出版系统的架构演进”,“五全”是指全用户、全渠道、全终端、全产品、全版权的战略,这个影响我们整个架构支持的范围。
简单介绍一下我们的业务场景,让大家在进入架构之前有一个印象,我们的业务种类很多(参考图1)。支付方式上,除了我们自己的虚拟货币书券以外,最大的特色是话费支付,当然还有多种其他支付方式。
图1:业务产品介绍
2009年手机阅读成立开始,从公测到年底做到了3000万一天的PV,从图2中可以看到,我们第一个阶段(2009年—2013年)每年增长非常迅速,2013年已经达到了6.9亿,2014年以后的趋势稍微放缓一点,2015年主要是下降的。
图2:业务量发展过程
从2009年到现在我们经历了三期比较大的建设(如图3),最高支撑PV达到8.5亿,一个月有1.7亿的用户,订购关系400亿条。
图3:咪咕阅读经历的三期大建设
主要考虑我们架构面临什么问题,我们架构是怎么发展的,进一步来解决这个问题。
三大突出问题
第一,手机终端非常复杂,刚开始几年以功能机为主,有Kjava、Symbian、WinCE等等,2012-2013年智能机份额开始提升,而且终端差异很大,包括屏幕分辨率、内存容量等等,终端内存浏览器的兼容能力也千差万别,那个时候应该是做手机端应用最痛苦的几年时期。
第二,灵活运营。追溯到最早的出版,国内是方正一统天下,然后在互联网上慢慢出现了各类数字图书馆,但是那时候手机屏幕很小,在互联网以及电脑上以版式为主,版式指的是大小定好之后就不会变,如果屏幕小但是内容很大,需要拖拉才能看,所以在手机上不合适,手机上刚开始都是以流式为主,屏幕随着内容自适应,只有往下调整,当时数字阅读刚刚起步,我们做得几乎是最早的一家,运营思路不稳定。
第三,因为我们借助中国移动的一些优势,包括用户渠道的优势,整个市场发展的非常快,从2009年3000万做到1.9亿,对整个架构的挑战非常大。
读写分离应对规模压力
首先从业务规模快速发展开始说,我们的架构是怎样应对这样的问题变化的。2009年开始,预估一个月有200万用户就不错了,当时建设的都是单站点,而2010年规模已经到几千万甚至亿级了,我们就考虑要做负载的分散,我们做了两个站点,门户根据用户去分,到2011年考虑做灾备,把整个数据库也做了主备,这样不仅实现了双站点、双门户,也能够实现灾备这种方式。
图4:负载分散
2012年业务量已经上升到4、5亿的规模,不得不考虑做读写分离。我对其中一两个简单的展开一下,第一个是容灾跟双活,双活当时是通过GTM对用户做重新下载分流到两个站点,一个站点在三墩,还有一个在滨江,数据库做了一个主备。
图5:双站点、双门户
读写分离也遇到了一个非常大的难题——订购关系海量,已经有百亿级,而且还要确保用户不重复订购。
我们的商品跟电商的商品有差别:电商的商品用户买了以后,如果再次看到这个商品还要去购买,电商根本不会提示你不能订购,但对于在线阅读的书来说,发生重复订购用户肯定会投诉,因为不应该重复购买;电商的订单可以根据周期去拆分,按照时间去分库、分表,这个方式就可以把订单量给降下来,但是我们订购关系降不下来,是持续一直向上累加,累计到百亿级,我们需要更大的库,读和写的压力都非常大。
后来做了读写分离,用两套数据库,一套写的集群,一套是读的集群,读这一块还有一些数据路由去做,这里面还要解决写库和读库之间数据同步的问题,另外涉及到双向点、两个站点都有读库,所以这个稍微复杂一点。
图6:数据库读写分离
一体化编辑发布系统应对终端复杂
第二个问题,终端复杂,我们还支持灵活运营,这个问题我们怎么解决?最开始我们页面编辑发布系统是标签式的,在一个页面里运营了这个需求、设计好了之后,运营拿着这个需求可以直接把标签组装在一个页面,随便安装,随便换位置,标签里的内容可以再去选,页面编辑非常灵活。
一个标签代表一个功能或者数据,那时候终端比较简单,只能支持简单的图文,不支持样式,也不支持二次开发,运营只能在现有的标签上去调上下位置,放几个都可以,但是没法二次开发一个新标签,如果有这种功能或者数据要求,就需要开发重新去做新的,这是当时的那一套编辑方式。
到了2011年、2012年智能手机开始逐步提升上来,但还不是特别多,不占主流。但出现一个新情况,手机屏幕大了,分辨率也大了,我们原来简单的图文不支持样式改变的方式不能满足需求,因为屏幕可以展现的更多。所以在2012年我们上了一体化编辑发布系统,这个系统有两个特点,一个是我们在开发阶段开发出数据源,前端工程师可以二次开发,我们叫做碎片,可以外加样式模板。那时智能手机还没占大头,我们出了三个版式,一个简版,是Wap1.x的那个时代,还有彩版,彩版是面向Wap2.0的,还有触屏版,是在2.0基础上叠加一些样式,能让整个触屏的效果更加炫一些。
因为支持二次开发,只要现有功能是数据源具备的,都可以随时应用,随时提供给编辑去运营,这样的好处就在于能快速响应,只要现有功能已经有了,前端开发一般可能几个小时,或者是一、两天就能把新的页面发布出来。
另一个特点,去年到今年H5非常流行,H5新出的一些标签我们在外部很容易嵌进去,整个编辑发布系统都不需要改就能够快速的开发支持,这个系统对我们这几年帮助非常大。
到了二期的时候,面临以下3个问题:
图7:二期面临的问题
在解决思路上,我们架构总体是做能力服务化,这是在2014、2015年实现的,业务总体的思路是按照业务应用垂直拆分,能力拆分和服务化两个思路去做,构建了一批公共的业务能力中心。
图8:业务应用垂直拆分、能力拆分及服务化
再提一下订购关系压缩,五百亿级别,当时是到了什么量呢?整个订阅关系是分表的,订购表按照用户被分成了100张,100张订购表数据和索引共6.6TB,总空间每天增长 5GB,表空间继续扩大容易导致一些性能问题。
当时的存储结构是一个用户对应一本书,再对应它的章节,是一章一条,这个量非常庞大。解决思路比较简单,我们引入了分段,一本书章节少的有一、二十章,但是有很多书超过三千章,所以章节的量就要分段,比如五百章做一段,在这一段里面有所有订购的章节用章节串标志,章节串用位的方式表示,比如这一个位它订了就用1来表示,最后整个这一串用十六进制的字符串去转换一下。这个方式效果非常好,让我们整个数据量降低了,空间也降低了,数据量是原来的3.5%左右,空间是原来的7.3%左右,整体上大大的给我们减少了空间和压力。
三个层次一起推进解决云化问题
在云化上面,我们是三个层次一起推进:第一个是在上层,在SAAS层新建一些公共的服务云、比如图片、搜索;第二个是在PAAS层,尝试应用Docker容器,做了小规模应用接入和改造,明年会大规模接入, 容器资源使用物理机和云服务器都会尝试;第三个是在IAAS层,引入了阿里云来建设我们的私有云。
对市场变化演进方向,是客户端这块,之前我没有重点提,这里顺带着讲,2009年到2011年我们基本上纯C/S接口,接口当时是HTTP协议,但是它毕竟不是走浏览器的方式,它是C/S系统,基本功能全部靠客户端开发搭建,这是那时候的产品形态。
2012年开始,由于编辑发布系统推出,灵活运用能力比较强大,我们客户端也配套了做成部分的B/S接口,到现在B/S的量比较大,C/S的量比较少,在2016年我们会保留少量的Native加C/S的接口后端内容,利用本地的一些特性计算能力,其它尽量以页面的方式来做。
放弃部分H5兼容以及灵活运营能力
一体化编辑方式在我们这有几年的光辉历史了,但是新的市场发展也需要做一些演进,比如说对于H5之前的兼容可以逐步的放弃,这时候我们就可以全力面向H5的方向来支持。还有灵活运营能力,数字阅读领域我们做了这么多年,而且不少竞品现在做的不错,整个市场的产品功能以及运营思路也慢慢稳定下来了,这时候适当的可以放弃一些灵活运营能力,减少二次开发。
从数据源到前端开发,二次开发的时候,相当于两个层次,两个层次对我们整个质量以及开发效率影响很大,如果合并到一个层次,一次性就把功能页面效果全部做完,这时候质量效率都可以提高一些,我们是往这个方式去演进。
以小程序和微信分享导流发展自主APP
在微信小程序方面毋庸置疑,微信在国内市场独霸天下。我们阅读市场面向人群,应用频次属于高频,但非刚需应用,我们整体的策略是以小程序和微信分享导流为主,以发展我们自己品牌的原生APP为重点。关于小程序,发现腾讯玩儿的这招其实挺坏的,小程序虽然看起来很强大,但它的很多标签,以及文件格式与H5都不兼容,导致了我们这块又得新开发一条线去应付。
我今天分享到这,谢谢大家!
Q:咪咕是有好几个基地吗?基地之间还有跟移动之间又什么样的数据交互和业务交流?
张仲广:我们咪咕这一块原来是5个基地,包括游戏、动漫、视频、音乐还有阅读,现在变成咪咕的5个子公司,最早基地分别是每个省公司的一个部门,人权、财权上都归省公司管,在业务上是以前的移动集团数据部来管理。现在变成公司化以后,我们跟它们之间的交互是什么?第一个,我们依赖于各省公司,各省移动帮我们提供网络接入服务,简单说用户如果通过移动的网络进来,我需要知道它是谁,这个是我们最大的优势。第二个,我们知道手机号码,用户在使用了,我们需要去付钱、扣话费,这是最基本的来往。还有各省移动帮我们做一些业务的推广,因为10086以及各地的营业厅有渠道的优势。
Q:现在除了自有的安排以外,应该还有其他的第三方的APP接入到咪咕阅读?
张仲广:我们有些合作渠道,比如网易,他们作为我们的合作伙伴,我们向他提供内容,向他提供支付能力,他们做自己的APP。
Q:微信小程序有预期的那种效果吗?
张仲广:我们倒不着急,因为这块主要以分享导流为主,分享导流实际上你不通过小程序现在也能做,主要通过微信好友分享。但是小程序因为腾讯在大力推动,也许能有一些新的一些价值,所以我们也不能放过。
Q:更多只是为了导流量?
张仲广:更多为了导流量。
张仲广,咪咕数媒技术部副总监。
毕业于浙江大学,毕业后一直从事移动增值业务、互联网和移动互联网相关工作,先后在卓望公司、咪咕数媒从事研发、架构师和技术管理工作,热心于高并发高可用的架构设计和优化。
联系客服