为了让你在网易云听一首歌,后端工程师都做了什么?( 二 )


用户量增加后,大量日常的文件存储(如用户头像、朋友圈图片)需要一个统一的文件存储中心,这时我们用上了分布式对象存储平台 。
 
性能不行?缓存来凑开放数字专辑售卖功能之后,我们发现用户的购买热情非常高,为了应对高并发大流量,减轻数据库的压力,我们引入分布式缓存(Memcache,redis)来抗一部分流量,避免数据库宕机 。

为了让你在网易云听一首歌,后端工程师都做了什么?

文章插图
 
解耦神器,非你莫属
为了避免业务的上游和下游强耦合,实现调用异步化,或者应对突发流量,实现业务的削峰填谷,我们用到了消息队列(Kafka,RabitMQ,RocketMQ),将上游业务消息缓存到队列中,由下游业务异步消费 。
为了让你在网易云听一首歌,后端工程师都做了什么?

文章插图
 
分解巨无霸业务快速发展,团队也在扩张,原有的巨无霸单点应用部署已经越来越制约业务的快速迭代和多人协同开发 。为了避免单点,实现业务模块的去耦合和故障隔离,我们开始了服务化拆分进程 。
我们将原本部署在一个进程中的代码拆分到多个进程放到不同的集群中运行 。服务化拆分之后相互之间调用不再是一个进程内调用,而是需要跨进程网络调用,这时需要注册中心和RPC框架来实现服务的注册、发现及跨进程调用 。引入RPC框架之后,为了方便监控和在线调整线程池参数,又开发了RPC管控平台实现动态管控 。
 
排查问题随着服务拆分的深入,用户的一个请求可能会经过几个甚至几十个服务,如何定位问题出现在哪个服务,以及查看各个服务的链路耗时,这时需要一个链路跟踪系统 。服务拆分之后,根据重要程度对服务进行定级(P级),为了保障核心应用的稳定性和可用性,引入了限流熔断降级框架,可以实现应用网关层的全局限流和单机限流和降级 。
线上服务越来越多,机器越来越多,日志分散,可检索性差,为了统一的日志查询,方便及时定位问题,需要一套日志平台(ELK) 。
为了让你在网易云听一首歌,后端工程师都做了什么?

文章插图
 
团队开发业务越来越复杂,团队开始爆炸增长,需求迭代相互交织,开发、回归、预发、线上环境管理越来越复杂,此时迫切需要一个持续集成平台管理环境和机器的自动分配、任务排期和发布计划 。
为了实现前后端同步开发,接口的定义要优先于接口的开发,这时我们开发了一个接口管理平台来达到事前约束的目的 。前后端开发可以愉快地协同开发了 。测试同学也可以利用平台管理测试用例,接口覆盖率得到了极大的提升 。
 
看好你的报警线上接口越来越多,各种异常满天飞,有些需要关注,有些可以忽略,这时我们需要一个异常报警平台,根据服务将报警通过各种渠道通知到负责人 。
随着业务模型越来越复杂,老旧的架构开始腐化,链路也变得越来越脆弱,线上事故频发,9999的可用率无法得到保证,这时我们需要进行架构梳理和全链路压测,针对性地进行故障注入,全链路压测平台和故障注入平台应运而生 。
 
终极之路随着用户量的数量级升级,单个机房的集群部署稳定性风险越来越高,可能光纤被挖断或者机房断电之后,服务就全部挂了,带来的损失不可估量 。这时,同城双机房和异地多活单元化就提上了议事日程 。
为了让你在网易云听一首歌,后端工程师都做了什么?

文章插图
 
终于,服务的稳定性得到了极大提升,你可以放心地听歌了 。好了,不多说了,我又来了一沓新需求 。
下面是一张时间轴,展示了后端基础设施发展的整个历程,囊括了企业基础设施、基础运维设施、研发提效设施、中间件基础设施、测试基础设施、大数据基础设施等六大基础设施 。
为了让你在网易云听一首歌,后端工程师都做了什么?

文章插图
 
后记:本文中涉及到的绝大部分技术方案都已经在内部落地,有一些还在进展中,不过相信很快就可以应用到生产环境 。学无止境,勉励自己在后端技术之路能越走越远,成为一个懂业务的技术专家 。
 
【为了让你在网易云听一首歌,后端工程师都做了什么?】


推荐阅读