黄全：荔枝架构实践与演进历程

　　黄全，荔枝APP架构师。拥有10年的互联网开发经验，对分布式系统、高并发解决方案有着丰富的实践经验，在国内知名互联网企业担任过资深工程师、系统架构师等职。曾就职于UC浏览器、春笋新科技。现任荔枝资深工程师，负责基础架构的设计与开发，目前专注于分布式系统、微服务、数据库中间件等技术的研究与探索。2018年10月18日,黄全 受邀参加了由IT168主办的《SACC 2018第十届系统架构师大会》,并发表了精彩演讲，以下内容根据 SACC大会实录整理。

　　如果你对声音互动平台有所了解，那对于荔枝APP一定不会感到陌生!

　　荔枝，致力于打造声音处理平台，帮助人们展现自己的声音才华。荔枝集录制、编辑、存储、收听、分享于一体，依托声音底层技术积淀，具有声音节目录制功能，可在手机内完成录音、剪辑、音频上传和语音直播。

　　简单理解，荔枝APP上有很多主播，主播和用户之间可以通过声音互动。目前，荔枝APP月均活跃用户达到好几千万，月均活跃主播达到好几百万，全球注册用户和音频节目数量都已过亿。

　　那么，对于有着大用户量的社交APP来说，荔枝APP的背后架构该如何设计?一个时间轴可以概括整个架构的演进过程。

　　架构演进时间轴

　　2013年：单体架构。

　　这个时候的架构是V1.0版,主要特点是APP 直连服务器，服务端是单体架构。也就是说，一个服务，一个存储解决所有问题。这种架构看上去简单、粗暴，好处是快速上线、快速响应市场需求;但劣势也非常明显，APP直连服务器模式在扩展的时候非常不灵活。项目上线后3个月，用户数突破 100万，访问量上涨，服务器压力增大。

　　2014年：垂直架构

　　到了2014年，荔枝APP的后台架构演进到V2.0版。这一版架构的特点是：支持水平扩展和功能拆分。首先，APP 与 app server 之间加入app代理层，用于分发请求给多台 app server，分摊压力。其次，对app server 按功能进行拆分，数据操作及业务逻辑部分由后端服务负责，并采用 netty(http) + json 方式进行交互。

　　虽然，这个时候已经能做到相对快速交互，但是依然存在很多问题。一个是，后端服务水平扩展时，不能动态化;另外，系统间采用 http 交互时，通讯效率较低，并且数据包较大;还有一个问题是，json 解析速度较慢、体积较大。所以，V3.0版采取了一系列措施，重点解决扩展、交互等问题。比如：引入Linux虚拟服务器集群系统 LVS，采用 TCP 取代 HTTP，通过定制私有协议取代json。

　　V3.0版使用 LVS 集群解决了分发请求，但是随着业务的快速发展，人力资源都投入在业务开发上，对第三方产品了解也不够深入，导致运维成了最大挑战。所以，后期考虑采用自己开发代理服务来取代 LVS。

　　V4.0版架构中，我们开发了代理服务，当时使用 VIP 与其他服务连接，取代LVS分发请求。这时候的整体架构依然比较简单，app server 与后端服务还是单体架构，没有做业务拆分，虽然能让后端服务支持水平扩展功能，但需要重启代理服务。另外，还有一个挑战是，随着用户量、访问量的持续上涨，系统访问压力依然很大。接下来的目标是，app server 与后端服务需要按业务垂直拆分。

　　演化到V5.0版架构的时候，所有服务已经能够按业务拆分，可支持水平扩展，整体架构能抗得住一定的访问压力。2014年10月，用户量曾突破 1千万。但新的问题又来了：一个是服务的配置不能做到热更;另外，不同业务的后端服务之间产生了交互需求。还有，微服务化已成为主流发展方向。所以，下一个阶段的解决方案是，开发配置中心 config server实现配置热更;采用开发分布式服务框架 lz-RPC，封装远程调用功能。

　　2015年：分布式架构

　　V6.0版架构开启了分布式架构新征程，这时候的特点是app server、后端服务、代理层等，都实现了配置热更，能灵活水平扩展。到2015年9月，用户量曾突破 5千万。但是面临的问题依然很多。比如：mysql、redis 操作的重复代码太多;mysql、redis 慢操作不能及时报警;各个服务的数据源配置分散，难以管理等。另外，还涉及跨机房数据操作和数据同步问题。而分布式数据库中间件可以很好地解决这些问题。

　　2016年：分布式数据库中间件

　　从2016年开始，荔枝APP的后台架构走入V7.0版时代。这时，开发团队自研了分布式数据库中间件data store服务。data store的特点是：简单易用，可减少重复代码。只需要在类上加上注解，就可以实现与数据库的交互、数据转换等功能，大大减少了开发的工作量。另外，data store具有自动维护缓存和数据库表的对应关系、自动维护缓存与数据库数据的一致性的功能。最重要的是，屏蔽了服务对数据源的管理，便于数据库的迁移和扩容等操作。

　　总体来看，V7.0版的最大特点是，已形成一个比较完整的分布式架构。data store 封装了常见的 mysql、redis 操作，能提供慢操作监控。后期根据业务发展，还引入了 kafka、mongoDB、zookeeper、hbase等多种第三方产品。

　　随着应用的增加，V7.0版架构也逐渐暴露出了一些缺陷。一是资源监控、业务监控、分布式跟踪链等功能不完善。另外，随着访问量上涨，分布式服务框架的功能也需要进行扩展。

　　2017-2018年：监控体系

　　进入2017年以后，整个架构已趋于完善，重点引入第三方产品，建立监控体系，完善对服务器资源、业务、跟踪链路等的监控，同时也扩展了分布式服务框架功能。也是从这个时候开始，整个架构迎来了V8.0版。经过完善后，业务监控及基础监控功能已比较完整，分布式服务框架扩展了接口缓存、熔断、降级、过载保护等功能。

　　近两年踩过的“坑”以及应对措施

　　1、大主播开直播，访问量爆涨，影响了其他直播间的直播效果，比如出现卡顿、进入不了直播间、接口超时。举个例子：李易峰晚上8点在荔枝APP上做直播，那么从8点前开始，整个系统的访问量就会比平时要高出很多。有用户就会出现进入直播间慢、评论出现慢以及其他体验不好的情况出现。像这样的问题，应该如何解决呢?

　　第一个方案，也是最简单的方法，是“隔离”。在 data store 中，针对 redis 存储开发，按前缀分片的功能，对大主播的直播数据进行隔离，避免影响其他主播的直播效果。

　　第二个方案是，在高访问量期间，结合分布式服务框架中开发的熔断、降级、过载保护等功能，采取对部分非关键服务做降级措施，避免服务器因访问量过高发生雪崩。

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!