荔枝架构实践与演进历程

　　好的系统不是设计出来的，而是演进出来的。荔枝APP，致力于打造声音处理平台，帮助人们展现自己的声音才华。荔枝集录制、编辑、存储、收听、分享于一体，依托声音底层技术积淀，具有声音节目录制功能，可在手机内完成录音、剪辑、音频上传和语音直播。简单理解，荔枝APP上有很多主播，主播和用户之间可以通过声音互动。目前，荔枝APP月均活跃用户达到好几千万，月均活跃主播达到好几百万，全球注册用户和音频节目数量都已过亿。那么，对于有着大用户量的社交APP来说，荔枝APP的背后架构该如何设计?它的成功经历了什么演进历程？

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

　　垂直架构，虽然，这个时候已经能做到相对快速交互，但是依然存在很多问题。一个是，后端服务水平扩展时，不能动态化;另外，系统间采用 http 交互时，通讯效率较低，并且数据包较大;还有一个问题是，json 解析速度较慢、体积较大。所以使用 LVS 集群解决了分发请求，但是随着业务的快速发展，人力资源都投入在业务开发上，对第三方产品了解也不够深入，导致运维成了最大挑战。所以，后期考虑采用自己开发代理服务来取代 LVS。另外，还有一个挑战是，随着用户量、访问量的持续上涨，系统访问压力依然很大。接下来的目标是，app server 与后端服务需要按业务垂直拆分。演化到V5.0版架构的时候，所有服务已经能够按业务拆分，可支持水平扩展，整体架构能抗得住一定的访问压力。2014年10月，用户量曾突破 1千万。

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

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

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

文章来源：

https://mp.weixin.qq.com/s?__biz=MzA5MDc1ODQxMw==&mid=2653325500&idx=1&sn=efa02d6e6010f6e1a942e949d13cd075&chksm=8bd4e4debca36dc82e8bf757f829747a128c428f4c62c87388d8f17887519075dd957d727045&scene=21#wechat_redirect