海量订购关系+8亿高并发访问，咪咕阅读的架构演进之路
「 技术领导者 」的订阅首选
小欧有话说：
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：更多只是为了导流量？
张仲广：更多为了导流量。
张仲广，咪咕数媒技术部副总监。
毕业于浙江大学，毕业后一直从事移动增值业务、互联网和移动互联网相关工作，先后在卓望公司、咪咕数媒从事研发、架构师和技术管理工作，热心于高并发高可用的架构设计和优化。