论文:论微服务架构及其应用
摘要
2021年2月,我公司承接某视频会议云直播项目。该项目主要为了解决视频会议系统对用户终端硬件要求过高、入会用户数量受限的问题,通过增加云直播的方式,将云直播与视频会议对接,以支持更多用户在电脑网页和手机端观看会议实况。
我在项目中担任技术负责人,负责项目服务划分、架构设计和技术指导工作。本文结合我的亲身实践,论述了微服务架构在项目中的应用。在服务分层设计阶段,以客户需求为依据,对系统功能进行总体分层架构设计,各层各施其职。在服务开发阶段,对较粗粒度的服务进一步细化成粒度更小微服务,并采用开源组件框架进行有效组装,完成项目微服务化开发。在部署阶段,采用容器化技术,完成微服务的容器化部署和集群管理。通过上述过程的实施,项目最终顺利交付。
正文
互联网直播业务在2012年至2022年呈现快速增长,这种业务形态对传统的视频会议行业带来了新的机会。传统视频会议常常需要用户购买价格不菲的设备,且支持的同时在线的用户量级别只能在百级~千级,而直播方式支持同时观看用户量都在十万级以上。
我所在公司的产品线深耕视频会议行业多年,并于2021年2月,中标某视频会议云直播项目。需求的出发点是对接视频会议系统,构建一个云直播平台,提供会议直播、直播监控、录制存储、点播等能力,对用户提供在网页、手机上观看会议直播或回放等功能。视频会议是我司已有的产品形态,此时我们需要基于现有的技术积累,开发出支持直播的流媒体服务、录制存储服务,还需要全新开发上层业务、Web端和手机客户端。不同的服务相互独立,且采用的开发语言或数据库有所不同,这意味着既需要进行服务化划分,还需要通过某种机制实现服务间通讯,打通全业务流程。同时,该项目还需要以云服务SaaS的方式运营,服务需要容易部署和扩展。项目启动后,我在项目中担任技术负责人的角色,负责服务划分、架构设计、技术指导等工作。
在项目架构选型上,我根据自己多年的工作经验,选用了微服务架构。相对传统的单体架构,微服务架构在支持技术异构、各服务组件独立开发、动态扩容、独立部署等方面都有很多优点。2013年,我们曾实施过一个项目,当时采用的是单体架构,所有的服务都集中在一个工程进行开发,虽然功能上都能正常开放实现,但后来发现存在较多问题,一是服务之间耦合度非常大,项目臃肿难以维护。二是技术异构难,整个项目只能采用单一的开发语言、单一数据库。三是服务横向扩容难,当用户访问量增加时,单体架构无法很好扩容。四是项目不能实现轻量化部署,即使更新一张图片,也要整体发布。根据这些经验考虑,当前视频会议云直播项目,我采用微服务化架构。一是此项目设计功能组件较多,如有视频会议服务、直播流媒体服务、录制服务、文件存储服务、直播监控服务、在线点播服务以及其他上层服务等,不同组件技术异构大,采用微服务架构可以解决技术异构问题。二是各业务团队专注于某业务领域的开发,通过约定轻量级通讯接口,实现服务通讯。三是各微服务可以单独部署、互不影响。四是支持动态扩容。下面从服务分层设计、微服务开发、微服务部署三个阶段分别论述系统的微服务架构落地过程:
一、在服务分层设计阶段,以客户需求为依据,对系统功能进行总体服务分层架构设计,各层各施其职。
为了避免后期不同服务间重复处理某些业务逻辑,我们进行了业务流分析和分层设计。从用户基本需求分析业务流程,视频会议开始前,系统会提前下发通知给用户。视频会议系统调用直播媒体服务器接口,开启直播并推流。直播服务器开启直播,再调用录制服务接口开启录制,并把码流保存到分布式存储系统。用户在预定的时间点击链接或打开客户端登陆后观看直播,鉴权成功后进入某个直播间。在直播过程中,客户端收集直播性能指标并上报服务。直播结束后支持点播。为了有效贯穿所有业务流,我把整个系统自上而下划分为五层:前端层、对外网关层、业务层、核心计算层、存储层。前端层设计WEB前端、手机客户端,提供人机交互。对外网关层实现负载均衡、路由、鉴权、日志记录。业务层涉及用户管理、会议管理、直播间管理、监控管理等基础服务。核心计算层包括直播、录制存储,媒体点播等服务。存储层包括数据库、分布式缓存以及分布式文件系统。服务分层设计,可以减少重复开发,降低服务开发复杂度。以鉴权功能为例,如果后端各服务每次都要调用鉴权,效率就低了,我把它提到对外网关层。
二、在服务开发阶段,对较粗粒度的服务进一步细化成粒度更小微服务,并采用开源组件框架进行有效组装,完成项目微服务化开发。
在上述分层服务化架构确定后,我对某些粗粒度的服务进一步划分。比如业务层细分成用户管理、会议管理、直播间管理、监控管理,提问管理等,不同的微服务由不同的开发小组独立完成。
有些微服务适合采用NoSQL分布式数据库,有些微服务采用MySQL关系型数据库,互不影响。微服务化之后,还需要把各个微服务有效组装起来,使得它们可以相互协作,彼此通过轻量通讯框架调用,这时就需要引入微服务治理的框架,当时选用的是Spring Cloud,此时增加服务的注册中心、配置中心、微服务网关。在使用Spring Cloud过程中发现了一些性能问题,因为Spring Cloud实现微服务间通讯是采用RESTful,走的是HTTP协议,某些接口调用频繁、性能较差。后来引入了Dubbo开源框架配合使用解决这个问题。Dubbo采用RPC通讯,比RESTful性能更高,用在为服务内部。Spring Cloud可以提供RESTful服务,则用到与其他异构服务通讯和对前端提供服务。
三、在部署阶段,采用容器化技术,完成微服务的容器化部署和集群管理。
微服务化后的系统明显解决了单体架构的重度耦合,难以扩展的问题。但拆分出来的微服务过多,且每个都是独立部署,这就增加系统维护复杂性。如果手工部署明显工作量较大。为了解决这个问题,我采用了Docker容器化技术。公司内部提供了容器化的测试环境、各开发团队检入的代码会触发自动化构件脚本,自动构建生成Docker镜像,并更新到仓库和部署到测试环境中运行。这样,测试人员就可以针对该改动进行测试。版本经测试人员严格测试通过后,再一键部署到生产环境。
在服务容器化实施过程中,我们遇到的主要问题是IP映射和服务间通讯地址的问题。比如,直播媒体服务的端口需要直接暴露给客户端访问,如果某个媒体服务发生宕机,需要及时启动其他容器,同时还需要通过某些机制,保证客户端能发现故障并平滑切换到新的IP和端口上。而服务间的通讯也需要解决跨宿主机通讯的问题。后来,我们采用K8s实现把容器组成集群的环境进行管理,动态地启动服务和绑定对外端口。也解决了跨宿主机微服务间通讯的问题。
总结
整个项目划分成多个团队协助,顺利交付。运行在阿里云上生产环境的虚拟主机达10台,微服务的个数达到50个。支持根据业务变化动态启动微服务实例。整个系统稳定,项目获得客户的认可和领导的赞赏。
但在系统实施过程中,也遇到一些问题。例如直播监控功能是通过分析日志及时发现客户端播放存在的异常,包括延迟过大、播放卡顿等。在客户端我们埋点记录异常信息,并上报后台服务保存。在服务端所有服务的运行期间的异常日志都会保存到文件。当时我们采用定时任务分析日志,但后来发现当访问量陡增时,定时任务出现严重滞后的现象,即使微服务扩容,获得的效果也不明显。最终我们在大数据部门的支持下,引入数据采集引擎flume和Spark Streaming实时计算引擎进行了完美解决,实现直播高效的故障告警和定位,效果很好。
更多内容请见: 备考系统架构设计师-核心总结索引