论应用系统的分层架构设计
目录
摘要
该平台系统是一站式全网整合活动平台系统,帮助中小微企业智能发展,提供全方位的营销活动服务。
本论文结合作者的实践,讨论了层次架构风格的实际应用。首先概述了项目,并介绍层次架构及层次功能,然后介绍了层次架构在活动平台中的应用、遇到的问题及解决方案。我们采用层次架构,并结合SOA思想,将系统分为应用层、服务层、数据层,将应用业务逻辑抽象服务化。在应用层的业务逻辑层设计中,将平台业务划分成多个应用系统,服务层基于REST为应用层提供统一的业务逻辑服务,数据层提供数据存储与访问,采用Eloquent ORM、缓存驱动等。通过合理的的软件架构设计,提高了系统的可复用性、可扩展性、可靠性,平台于次年5月发布,并持续迭代,累计C端用户两千多万,得到用户的好评与团队的认可。
正文
项目背景
移动互联网时代,用户对活动需求持续增长,但活动供需不透明、信息不对称,公司决定研发综合性活动平台(以下简称为:“平台”),为中小微企业提供活动组织发布服务,同时为用户提供更丰富的活动搜索服务。
项目概述
平台主要应用有:官网站点群、活动管理系统、运营管理系统、App、公众号、微信小程序。平台支持多种活动类型,比如报名、预约、投票、抽奖、小游戏类营销等活动。
平台围绕活动提供以下服务:纵向上为B端用户主办方提供活动发布与管理服务,同时为C端用户提供全端活动搜索服务;横向上为B端用户提供不同类型的活动服务,如报名、预约、营销活动等,同时为C端用户提供不同模板的活动呈现服务;最后运营提供运营管理中台服务,负责中台业务与数据管理配置,比如审核、统一配置、消息、客服、智能推荐、财务、日志分析、风控配置等。由于篇幅原因,不再细化功能介绍。
使用技术栈
考虑到平台更倾向于移动端用户,且主要围绕微信生态,出于快速迭代快速验证的目的,采用成熟的lanmp体系,基于阿里云ecs集群及SLB负载均和服务,在框架上选择了laravel框架、使用redis cluster分布式缓存、数据库采用阿里云DRDS云数据库、前端资源打包到云端CDN、使用阿里云消息队列MQ实现消息异步通信等
层次分层及层次功能
以下结合平台实际情况说明我们选择层次架构结合SOA思想的模式的原因及使用情况:
我们分析了平台将支持的各种活动类型,发现在发布、管理、授权、分享、支付、推送、统计、广告、渲染粒度上的具有同一性,但活动逻辑、属性、数据结构、模板具有各自的特殊性;且活动数据将应用于活动管理系统、活动搜索服务、运营管理系统,而运营管理系统又要完成对所有应用的业务控制与数据配置,考虑数据一致性、运营统一性、开发效率、代码质量、高效复用及后续敏捷迭代的顺利进行,我们将公共模块及业务模块进行服务化,提出三层架构,我们将平台分为应用层、服务层、数据层。
应用层负责具体业务和视图呈现,整合编排不同服务完成具体业务的实现。
服务层负责提供公共服务与业务逻辑服务。
数据层负责数据的存储与访问服务。涉及数据缓存、持久化、搜索。
注意问题与解决方案
在应用层,我们划分出10+个应用系统,比如活动管理系统、活动搜索服务应用(涉及pc、公众号、app、小程序)、运营管理系统等。以活动搜索服务应用为例,报名活动内容呈现、微授权、报名、支付、核验等功能,这些功能会调用用户管理服务、订单支付服务、消息推送服务等服务做为支撑,通过这些服务实现订单统一管理,支付数据统一处理,消息推送统一管理等。应用层采用MVC设计模式,表现层采用vue实现,与后端完全分离,并结合CDN技术完成资源分布式部署。
服务层负责提供公共服务与业务服务。比如用户管理服务、消息推送服务、统一配置服务、风控服务等,前面提到活动的同一性和特殊性,我们也将每一种活动类型比如报名活动、抽奖、投票等作为单一的服务,由专门的虚拟团队负责,而不影响其他活动或模块的实现进度,同时方便后续扩展其他类型的活动,如祝福、签到等更多营销类活动。
服务层采用REST提供服务,内部实现了服务注册、服务查询等服务网关,用于服务层服务发现与使用服务。一开始我们考虑每个应用抽象出自己对应的服务层,好处是团队前期编码快速实现容易,不需要与其他团队协作,但考虑需求的多样性与关联性、服务规模变大、开发人员不断增多,应用之间难以通信,耦合性强、存在大量冗余代码,数据松散一致性难以保证,后期扩展和维护将面临大量的人力,所以我们进一步考虑将原有的面向应用的服务编排到各自单一业务服务中,比如现在的消息推送服务包含了微信公众号、小程序、App及第三方消息推送服务,与应用无关,不同应用可以调用其授权可使用的消息推送服务。而统一配置服务可以为不同应用提供不同的配置,比如轮播配置、广告位配置等,这些配置数据通过运营管理系统的统一配置中心配置并持久化到数据层,再提供给服务层为各应用服务。服务化使得层次结构更加清晰,让团队分工明确,通过服务化实现更高阶的模块化,完成小而美的服务。
在数据层提供数据存储与访问服务,涉及数据缓存、持久化、搜索。由于较多高并发场景,用户在短时间内集中访问,我们基于redis实现了缓存机制并结合消息队列实现部分异步调用,由于C端用户数据量级大,且读操作远大于写操作,我们采用读写分离,在一些只读的场景访问只读数据库。在数据库访问上,我们采用Eloquent ORM进行读写。在数据分析与全文搜索方面使用Elasticsearch,完成活动全平台搜索与活动智能推荐服务。
总结
由于层次的分离及服务化的设计,我们能快速响应用户需求,快速支持新活动类型及新模块功能,快速调整满足运营数据验证。在结构清晰功能分明的架构下,牺牲了部分性能,所以我们也针对部分性能不佳,甚至实现多层缓存。除了服务松耦合外,后期我们发现活动模板需求多且重要,逐步影响常规化运营,考虑将前端活动组件模块化建设一个“乐高”式的活动页面运营系统。
通过这个项目,我们实在的感受到软件系统架构设计的重要性,也感受到随着业务需求的增多和变化,给架构带来了各种各样的挑战,而通过合理的的软件架构,提高了系统的可用性、可靠性、可维护性、可扩展性、可复用性,间接提高了开发维护效率、运营效率,同时降低各方面成本,加速了团队成长及产品验证速度。