论云原生架构及其应用
摘要:
2023年4月,我作为技术负责人参与了某大型通信运营商旗下的智能家庭管理平台项目研发,该项目旨在整合家庭设备互联、远程控制及信息交互功能,服务于千万级家庭用户。项目核心是构建一个集设备管理、场景服务、运营商业务集成于一体的智能家庭综合平台,支持多终端适配和跨网络通信。本文将以智能家庭管理项目建设为例,阐述云原生在本项目当中的具体应用。基于云原生的弹性原则、服务化原则、自动化原则所解决的一些问题。通过云原生架构的成功使用,平台实现了资源层和应用层的弹性伸缩能力,提升了平台对外提供服务的能力以及整体自动化水平。现在平台已经顺利上线运营,并取得了良好的社会效益和经济效益。
正文:
随着智慧家庭产业的快速发展,智能家居用户对家庭设备集中管理、跨场景服务联动的需求日益迫切。传统家庭设备管理模式存在不少共性问题:1、不同品牌设备需要下载对应APP单独控制,操作步骤繁琐;2、设备间缺乏联动,难以满足个性化场景需求;3、基础服务与设备管理相互割裂,用户体验碎片化。基于这些行业痛点,在2023年4月,集团内负责家庭业务的另一业务子公司联合我司开展了智慧家庭管理平台项目,我被任命为技术负责人,负责系统架构设计、编码等工作。该项目总投入500万元人民币,历时一年,最终完成交付。为利用好以前各种硬件平台的投资,并应对高并发场景,选择将平台运行于linux平台上,采用Java开发技术,打包为Docker,并部署在K8S服务上。最终构建一个集设备管理、场景服务、运营商业务集成于一体的智慧家庭综合平台。项目核心功能涵盖三方面:一是设备统一接入与控制,支持主流智能家居协议(如WiFi、ZigBee、蓝牙等),实现灯光、空调、安防设备的远程操控与状态监控;二是场景化服务编排,用户可自定义“回家模式”“离家模式”等场景,触发多设备联动(如“离家”时自动关闭电器,启动安防);三是运营商业务融合,集成宽带故障诊断、套餐查询、增值业务办理等功能,打造“一站式”家庭服务入口。
我们在项目中采用云原生架构,充分体现云原生架构的自动化、服务化、弹性化和可观测性四大原则。1、自动化原则,体现应用的自动发布,自动化代码审查等流程;2、服务化原则,体现在云原生架构实现了“微服务,轻应用”,按需对外提供服务。3、弹性原则,主要来源于云计算特有的对云资源的弹性伸缩能力。4、可观测性,通过相关采集系统和监测工具的使用,系统的可观测性进一步加强。接下来,我将基于本项目的实践,着重论述云原生架构中的自动化原则、服务化原则及弹性原则。
一、自动化原则。以往系统建设过程中,如果要上线一个新应用,需要准备环境,搭建服务器以及配置文件等相关准备工作,很容易由于人工问题导致上线工作周期长,问题多。本项目中我们采用K8S来进行容器编排和镜像管理,基于容器的技术实现了应用的自动化部署以及按需灵活扩缩容,使用Docker打包项目,利用Docker的“集装箱”思想来规避可能出现的环境不一致问题。为了实现自动化上线和运维,我在项目中倡导了DevOps实践,从开发人员写下第一行代码开始,就要考虑相关后期上线及运维工作,运维人员也在一开始就介入其中,使得项目从编码到上线的过程更加高效。同时我也引入了相关自动代码检查,代码安全漏洞扫描工具,在编码工具中引入相关云服务商提供的代码检查插件进行代码检查,以及Jekins提供的漏洞扫描功能,代替以往的人工走查和桌面检查。我们的测试团队也开发了相关自动测试工具,引入相关云服务商提供的自动压测工具,极大提升了团队的工作效率和项目质量。
二、服务化原则。以往系统建设过程中,系统服务多是竖井式建设,烟囱式排列,小而全,大而全,但智能家庭综合平台将要开发大量的“定制化”应用,如果还是按照以往的惯用方式,一是工作量巨大,二是一定会有大量的重复建设,造成工期和成本的巨大浪费。项目中我们基于SOA的架构思想,采用“微服务,轻应用”的概念,采用Spring Cloud+docker的技术路线,将设备绑定、设备控制、消息同步等能力进行拆分解耦,封装为一个个微服务,实现平台整体的“高内聚、低耦合”,这些服务通过微服务网关支撑各类上层应用服务建设,以及对应APP开发。在实际应用当中,我们对“设备绑定”的能力拆分,使得绑定服务可以应对普通设备,“融合类”网关设备及音箱设备等不同类型的设备接入,通过对设备类型解析,来进行不同的绑定请求分发到对应服务进行处理。
三、弹性原则。以往系统建设过程中,如何按需对项目所需要的存储、计算、网络资源进行动态扩缩容,以及在面临海量高并发的情况下,如何能够实现应用服务的高可用性也是一直没有很好解决的难题。为了解决这个问题,我主要从:1、在IaaS层通过VMware对存储、计算资源进行虚拟化,构建统一的虚拟化云资源池。2、在PaaS层通过K8S,实现根据服务请求数量,实时调整相关微服务数量,使得系统就算在高并发条件下也具有非常高的可用性,比如在实际使用中,上下班高峰期时,我们平台的场景服务联动设备控制服务请求非常多,通过K8S及时上线相关备用服务,满足忙时业务需求,当非高峰时期,也可以非常方便的下线相关服务,释放系统资源,提升了平台服务层的弹性,在早晚高峰数据量激增5倍时,系统响应时间能够稳定在150ms,资源成本降低了30%。
项目上线后,经过为期半年的稳定运行,各项功能均达到设计目标:平台累计接入设备数量突破预期,用户活跃度稳步提升,场景化服务的使用率较传统模式提升显著,有效解决了设备操控繁琐、服务割裂等问题。从用户反馈来看,平台的统一管理入口和个性化场景功能获得广泛认可,用户满意度调查显示,超过八成受访者认为使用体验较之前有明显改善。
该项目性能要求高,技术实现难度高,项目建设周期长,通过该项目,团队在跨领域服务整合、复杂场景需求分析等方面积累了宝贵经验,尤其在平衡功能完整性与操作简洁性上形成了可复用的设计思路。同时项目也暴露出一些不足:在极端场景下,部分设备类型增多,系统配置的灵活性仍有提升空间。后续通过优化资源调度机制减少响应延迟,并引入更灵活的配置模板,进一步增强了平台的适配能力。在后续的学习和工作中,我将不断地学习,与同行保持交流,提升自己专业技术水平,更好地胜任系统架构设计的工作。
更多推荐


所有评论(0)