本论文结合作者及团队实践，讨论了软件架构风格在2b2c混合活动平台中的具体运用，整个系统主要结合整体SOA与单体分层架构混合设计思想，整个系统分别是应用层、服务层、数据层。在应用层的业务逻辑层设计中，将整个平台业务划分成多个子系统，服务层基于REST+json为核心，数据层采用larvel的数据库模型。通过合理的的软件架构，项目取得成功，不但提高了开发维护效率、运营效率，降低成本，并提高了系统的可维护性、可扩展性、可复用性、可移植性，加速了团队成长及产品验证速度。

本文先介绍了常见的架构风格，然后结合该活动平台情况，论述了工作中使用的架构风格原因、运用情况及取得的效果，最后讨论可以改进地方。

正文

项目背景

2000年来，中国各行各业高速发展，人民群众生活水平从物质需求逐步跨入精神需求，创业、科技、游戏、文娱、教育、营销、电商、互联网、服务业等行业都为城市人民提供职场技能、开拓视野、拓展人脉、聚会交友及丰富业余生活的各种类型的活动，活动的需求一直旺盛，特别是近10年在移动互联网推动下，活动不再受时间和空间的太多限制，活动需求逐年上涨，特别是2、3线及城镇对活动的需求无限待开发释放，于是公司决定从投入搭建综合性活动平台（以下简称为：“平台”），为线下中小企业提供线上的轻量的活动组织入口，并陆续提供各种相关活动服务，帮助活动组织者更方便地发布、管理、分析、推荐活动，也让人民群众可以更方便快速地了解并参与区域性或线上的有意义的活动，平台规范活动内容、规范活动规则、规范活动流程、提供活动推广服务工具，让组织者更省心，只需关注于活动的组织进行，让参与者无感知的参与活动，不用关心活动其他环节，一键参与、实时通知、一键评价。平台还提供全终端应用，智能为用户提供高质量的各种类型的活动。

项目概述

平台应用业务逻辑层主要由平台多个内容营销站点、主办方活动管理系统、内部运营管理系统、移动端App、移动端H5、多个微信小程序构成。

平台支持多种活动类型，比如报名活动、预约活动、常规营销活动、小游戏类营销等活动。

平台服务围绕活动展开，纵向上为主办方（以下统称：“B端用户”）提供活动发布与管理服务，为参与者（以下统称：“C端用户”）提供全终端活动查询与参与服务；横向上为B端用户提供各种不同类型的活动服务，如报名、邀请函、预约、投票、抽奖等，也为C端用户提供各种不同类型不同模板的活动呈现与参与服务；同时为内部运营提供运营管理服务。

主办方活动发布与管理服务主要模块有活动发布、活动管理、活动数据分析统计、会员管理、财务中心、营销中心等，重点在各种类型营销活动的友好创建发布及活动良好的参与体验。

内部运营管理服务主要模块有商务管理、活动审核管理、素材模板管理、主办方管理、场地管理、统一配置管理、统一消息管理、统一客服管理、门户内容管理、智能控制管理、财务管理、系统权限管理、日志分析管理等，重点为提高平台复用性、扩展性、一致性，从而提高运营效率，降低公司重复成本

使用技术栈

平台设计初期，在spring框架与lanmp体系做了比对，最后考虑到平台更倾向于移动端用户，且主要借助微信生态，出于快速迭代快速验证的目的，在已有另一个lanmp团队中抽掉并重新组成新团队，基于阿里云ecs结合基于nginx的负载均衡SLB，在框架上选择了ThinkPHP框架、使用redis cluster分布式缓存、数据库采用阿里云DRDS云数据库、前端资源打包到七牛云CDN、使用阿里云消息队列MQ实现部分异步操作

常用的架构风格及具体含义

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。组织方式描述了系统有哪些构件及构件的组织方式。惯用模式描述了众多系统共有的结构和语义。

软件工程常用的软件架构风格有5种：数据流风格、调用/返回风格、独立构件风格、虚拟机风格、仓库风格。数据流风格包含批处理序列和管道-过滤器，其每一步处理都是独立的顺序执行的，适用于简单的线性流程；调用/返回风格包括主程序/子程序风格、面向对象风格、层次结构风格，其进一步降低系统耦合度，明确系统层次；独立构件风格包括进程通信、事件驱动系统（隐式调用），其构件特点为软件复用提供了支持；虚拟机风格包括解释器、基于规则的系统风格，其具有良好灵活性，可自定义规则；仓库风格包括数据库系统风格、超文本系统风格、黑板系统风格，其以数据为中心。除了这些架构风格，近几年面向服务架构、微服务架构在各大中型项目中得到广泛应用，面向服务架构中每一个功能都是通过一个服务来提供，服务定义了明确的可调用接口，服务之间的编排调用完成一个完整的业务，其具有松耦合粗粒度的好处；微服务是对面向服务的升华，微服务强调按照领域进行拆分应用，拆分后应用的可以敏捷开发和部署。

系统采用什么架构风格及其原因

评估了哪些，选择了什么，出于什么原因，怎么实现的架构

结合产品需求和系统环境实际情况，我们最终选择层次架构逐步升级为面向服务架构的模式。

在平台设计初期，确认了基本需求后，优先完成报名活动的产品设计，接下来我们开始进行架构的选择，分析平台未来的各种活动类型在发布、管理、用户授权、分享、支付、推送、统计、广告、呈现渲染粗粒度上的极度上一致，但活动逻辑、活动属性、数据结构、模板差异较大；活动数据将应用于B端管理系统、C端活动服务、内部运营管理系统，而内部运营管理系统又要完成对所有应用的各种控制与配置，考虑代码质量、高效复用及方便后续敏捷迭代开发顺利进行，我们将平台进行服务化，中间层不同的服务中心提供不同的业务服务。

最终我们将平台分为应用层、服务层、数据层。

应用层负责具体业务和视图呈现，整合编排不同服务完成具体业务的实现，比如营销站点页面、主办方活动管理后台、App应用、某个单独活动类型小程序等，每个应用使用MVC设计模式完成设计实现；

服务层负责提供不同的业务服务，比如独立的用户管理服务、订单支付管理服务，消息推送服务、统一配置服务、CMS服务、风控服务等，前面提到活动的同一性和特殊性，我们也将每一种活动类型比如报名活动服务、抽奖活动服务、投票活动服务等作为单一的服务，由专门的虚拟团队负责，而不影响其他活动或服务的实现进度，还方便后续扩展其他类型的活动，如开奖、祝福、签到等更多营销类活动，内部细分为业务逻辑处理层和数据结构层；

最后数据层负责提供数据存储及访问服务，包括数据库、缓存服务、文件服务。

接下来我们再详细介绍设计过程：

应用层

在应用层，我们根据应用进行水平划分，方便应用、代码管理与维护。我们划分出PC活动cms站点群、PC主办方管理系统、公众号活动服务系统、活动App、活动小程序、运营管理系统等10+应用系统。

以公众号活动服务应用为例，报名活动属性内容渲染、微信授权、报名、支付、留言等功能，这些功能会调用相应的服务做为支撑，比如微信授权调用用户管理服务，支付调用订单支付服务，报名成功调用消息推送服务，通过这些服务实现用户的统一管理避免权限混乱，订单统一管理，支付数据统一处理，消息推送统一管理。对于应用层采用MVC设计模式，前端表现层采用vue实现，与后端完全分离，独立打包部署，并结合CDN技术完成资源分布式部署，当然像需要seo的官网站点群，采用smarty模板框架完成表现成的实现会更友好。
服务层

其次在服务层，使用RESTful风格提供服务，REST灵活、接口规范、且可以由任何语言调用，相对于SOAP开销更小，由于不需要复杂的服务注册和查询，我们内部自己实现了服务注册与查询服务，用于服务层服务注册与查询。一开始我们考虑不同应用抽象出自己对应的服务层，好处是团队前期编码快速实现容易，不需要与其他团队协作，但考虑随着需求的多样性与关联性、服务规模增大、开发人员不断增多，应用之间越来越难以通信，存在大量冗余方案代码，数据一致性难以保证，后期扩展和维护将面临大量的人力，所以我们进一步考虑将原有的服务编排到各自垂直服务中比如现在的消息推送服务包含了微信公众号、小程序、App及第三方消息推送服务，不同应用可以任意调用其授权可使用的消息推送服务，统一配置服务可以为不同应用提供不同的配置，比如轮播配置、广告位配置等，这些配置数据通过内部运营管理系统这个应用的统一配置中心配置并持久化到数据层，再提供给服务层为各自应用服务。独立服务化使得层次结构更加清晰，让团队分工明确，通过服务化实现更高阶的抽象、模块化、高内聚、低耦合、信息隐藏。
数据层

最后数据层，涉及数据缓存、持久化、搜索。由于活动具有短时间高并发性质，类似电商秒杀，比如抽奖、某一时间开奖、投票刷票，这些场景都是用户在短时间内集中访问，基于阿里云redis实现了缓存机制，由于活动平台C端用户数据量级大，且读操作远大于写操作，所以使用读写分离，在一些只读的场景访问只读数据库。在数据库访问上，我们采用larvel的数据库模型进行读写，由于阿里云rds是基于mysql，所有使用该数据库模型一方面可以降低开发对sql的了解，另一方面也允许自定义sql语句满足特殊的sql优化，最后还支持pdo模式，不影响后期数据库移植。在数据分析与全文搜索方面使用Elasticsearch，完成活动全平台搜索与活动自动推荐服务。

总结

项目经过内部多次版本迭代，最终在次年5月完成RC版本，并对外发布，经过2年多的发展，累计B端用户几十万，C端用户三千多万，得到用户和团队的认可。由于服务化的设计，我们都能快速的完成新的活动类型，并完美对接到各个应用中，能短时间内赶超竞品，由于应用层与服务层的分离，我们可以快速精准的修改，满足用户需求，也能快速调整满足运营数据验证。虽然各方面做的很到位，但在结构清晰功能分明的架构下，是牺牲了部分性能，所以我们也针对部分性能不佳，甚至实现多层缓存，表现层缓存，应用层缓存，服务层缓存，数据层缓存；另外由于面向服务架构在应用层存在不少服务调用，在碰上大量僵尸用户刷票场景时，容易导致服务器连接超出，引起cpu上涨，高负载导致宕机，引入人机验证服务及队列服务，缓解服务器tcp连接请求，保证服务器可用性。

通过这个产品项目，我们实在的感受到软件系统架构设计的重要性，也感受到随着业务需求的增多和变化，给架构带来了各种各样的挑战

不足

前端模块耦合

除了服务松耦合、服务治理外，后期我们发现活动模板越来越多，且常规运营活动和定制运营活动开发逐渐增多，常规化运营活动因为组件具有复用性，并且需求非常多，因此也在考虑建设一个类似携程内部的“乐高”运营系统，支持将活动页面拆分为各种组件模块，运营人员通过自主的配置就能快速上线各种运营页面，并而推广给中小企业用户，达到前端模块松耦合、高效设计实现营销活动页面。

终端多且复杂

虽然目前支持了手机、邮箱、微信、qq、微博用户授权，但由于小程序终端越来越多，考虑到未来将兼容各种小程序用户授权体系，需要进一步调整优化平台用户体系，支持不同终端用户打通，方便用户一键注册/登录，多端数据互通，也方便内部运营统计与着重推广。

论系统架构风格之层次架构

目录

摘要

正文