zoukankan      html  css  js  c++  java
  • 《荔枝架构实践与演进历程》读后感

      荔枝,是一个致力于打造声音处理平台,帮助人们展现自己的声音才华。荔枝集录制、编辑、存储、收听、分享于一体,依托声音底层技术积淀,具有声音节目录制功能,可在手机内完成录音、剪辑、音频上传和语音直播。简单点说,就是荔枝APP上有很多主播,主播和用户之间可以通过声音互动。目前,荔枝APP月均活跃用户达到好几千万,月均活跃主播达到好几百万,全球注册用户和音频节目数量都已过亿。

      这边演讲体系是根据时间轴进行的:

      在2013年时候:单体架构

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

      在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年时候,就做到了分布式架构

      到这时候,就演变到了6.0版本,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、大主播开直播,访问量爆涨,影响了其他直播间的直播效果,比如出现卡顿、进入不了直播间、接口超时。

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

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

    2、在高并发环境下,Mysql 查询性能成为瓶颈。当数据量呈现爆发式增长,Mysql 查询速度变慢。我们对分布式数据库中间件作了扩展,在操作mysql时,在数据库上层加入缓存memcached后,大大提高了查询性能,并且自动维护缓存和数据库数据的一致性。

    3、访问量上涨,受日志文件的IO影响,服务出现长GC(stop the world,阻塞业务线程)。类似服务出现长GC的问题,很多互联网公司都会遇到。在GC的整个回收过程中,会有两个步骤涉及到IO操作。第一个操作就是写 perf 文件;第二个是写 gc log的时候。一台服务器一般会部署多个服务,这些服务在运行的过程中,会不断输出日志,这时容易出现与其他服务的GC线程发生抢占IO资源的冲突,而导致GC线程阻塞等待,最终导致整个GC过程耗时较长,影响了服务的响应和稳定。为了解决这些问题.

      采取了两个方案来解决:

      第一,不生成 perf 文件,在服务启动脚本里,加上参数 -XX:+PerfDisableSharedMem就可以了;

      第二,将 GC日志保存到内存盘中( tmpfs 或 ramfs ),在服务启动脚本里加上 -Xloggc:/dev/shm/lz-app-gc.log参数就可以解决了。

    4、随着业务的发展,系统的整体访问量越来越大,后端服务接口调用耗时越来越长,导致经常超时。经过分析和统计发现,整个平台实际上以“读多写少”的场景居多。有没有一个兼顾全局的解决方案呢?在分布式服务框架中开发“缓存接口”功能,解决了这个问题。其实有很多场景,我们是不需要实时看到最新数据的,即使新数据晚了30秒或者1分钟用户才看到,也是可以接受的。

    5、系统间异步消息通知功能不完善。之前,是通过redis来做异步消息通知,好处是比较轻量化,但是随着数据量增加,大数据传输增多,出现多个消费方需要消费相同消息的时候,redis 就不是很适用了。这时,使用 kafka可以满足系统间消息通知、大数据量传输、多个消费者消费相同消息的场景。

    6、当服务框架中的各种功能都比较完善后,却发现缺少一个报警功能。比如在请求失败/超时/异常等,如果有监控机制,就可以找到具体的问题点。借助监控系统,我们可以看到服务器负载、物理内存、swap、磁盘等信息,也能监控到GC信息的回收时间、次数以及JVM堆信息等,还可以对异常请求进行统计。

    7、随着服务的增多,每个服务都有很多实例,导致整个架构的调用链路不清晰,也不能预知整体架构存在的瓶颈。引入skywalking 实现调用链跟踪功能后,能快速定位到线上故障和整个架构的性能瓶颈。

    8、主要是更新服务的问题,上线/重启服务操作很原始,之前都是人工在本地打包,再上传到服务器。服务不多的时候还能支撑,但是服务实例数量开始增多的情况下,这种方式就需要改进。荔枝的做法是开发一个自动发布平台,一键式操作。另外,就是通过jenkins + gitlab,接入自动发布平台,实现自动打包、一键发布。

    9、服务发布流程不够规范。过去的部署流程很简单,先是在本地测试,测试通过后,打包部署到线上,再观察服务的运行日志。但是随着团队人员和系统越来越多后,这种做法是不合适的。要想保证整个业务顺利上线,必须把服务发布流程规范化。从预发布测试到影响评估,到回滚步骤,再到灰度发布、线上验证,每一个环节都要标准化。预发布测试包含业务流程测试、新功能测试、SQL 验证、代码审查;影响评估包含对业务系统的影响和对交互系统的影响;回滚方案包含回滚步骤和回滚版本号,灰度发布则要按照按流量百分比、按设备类型和按 app 版本号等来操作;线上验证要做功能回归测试,以及观察异常日志、报警信息等。

    10、研发规范不够标准。一个技术团队从10几个人发展到几百人甚至上千人的时候,规范很重要。为了提高效率,公司制定了各种标准的开发/操作规范,包括客户端开发规范、服务端开发规范、测试规范、运维规范、mysql、redis、kafka、mongoDB 等的使用规范。

    文中部分图片,内容摘自原文专业术语,如有不适,请联系15227013954,微信同号

  • 相关阅读:
    Android 废弃方法属性解决
    Android RecycleView分组
    Android 第三方库FlycoTabLayout
    Android 自定义dialog出现的位置
    Android 底部弹窗实现
    Android 自定义设置布局
    Android 微信、qq分享文本 (Intent)
    SpringBoot关于跨域的三种解决方案
    记录一次通用Mapper+自定义mapper出现的问题分析以及排查
    IDEA配置Maven+新建Maven项目
  • 原文地址:https://www.cnblogs.com/zhaochunhui/p/10997995.html
Copyright © 2011-2022 走看看