本论文结合作者的实践，讨论了软件架构风格的选择与应用。首先概述了项目，并介绍常用的软件架构风格及其含义，然后结合活动需求分析架构的选择与应用。本系统采用层次结构结合SOA的架构风格，将系统分为应用层、服务层、数据层，将应用业务逻辑抽象服务化。在应用层的业务逻辑层设计中，将平台业务划分成多个应用子系统；服务层基于REST为应用层提供统一的业务逻辑服务；数据层提供数据持久化、缓存、搜索访问，采用Eloquent ORM、缓存驱动等。通过合理的的软件架构设计，提高了系统的可复用性、可扩展性、可靠性，于次年5月发布，并持续迭代运营，累计C端用户两千多万，得到用户的好评与团队的认可。

正文

项目背景

移动互联网时代，用户对活动需求持续增长，但活动供需不透明、信息不对称，公司决定研发综合性活动平台（以下简称为：“平台”），为中小微企业提供活动组织发布服务，同时为用户提供更丰富的活动搜索服务，在活动和用户之间搭建一座好的桥梁。

项目概述

平台主要应用有：官网站点群、活动管理系统、运营管理系统、App、公众号、微信小程序。平台支持多种活动类型，比如报名、预约、投票、抽奖、小游戏类营销等活动。

平台围绕活动提供以下服务：纵向上为B端用户主办方提供活动发布与管理服务，同时为C端用户提供全端活动搜索服务；横向上为B端用户提供不同类型的活动服务，如报名、预约、营销活动等，同时为C端用户呈现不同模板的活动；运营管理系统提供运营管理中台服务，负责业务中台与数据中台数据配置管理，比如审核、统一配置、消息、客服、智能推荐、财务、日志分析、风控配置等。由于篇幅原因，不再细化功能介绍。

使用技术栈

考虑到平台更倾向于移动端用户，且主要围绕微信生态，出于快速迭代快速验证的目的，采用成熟的lanmp体系，基于阿里云ecs集群及阿里云SLB负载均衡服务，在框架上选择了ThinkPHP框架、使用redis cluster分布式缓存、数据库采用阿里云DRDS云数据库、前端资源打包到云端CDN、使用阿里云消息队列MQ实现消息异步通信等

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

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

软件工程常用的软件架构风格有5种：数据流风格、调用/返回风格、独立构件风格、虚拟机风格、仓库风格。

数据流风格包含批处理序列和管道-过滤器，其每一步处理都是独立的顺序执行的，适用于简单的线性流程；

调用/返回风格包括主程序/子程序风格、面向对象风格、层次结构风格，其进一步降低系统耦合度，明确系统层次；

独立构件风格包括进程通信、事件驱动系统（隐式调用），其构件特点为软件复用提供了支持；

虚拟机风格包括解释器、基于规则的系统风格，其具有良好灵活性，可自定义规则；

仓库风格包括数据库系统风格、超文本系统风格、黑板系统风格，其以数据为中心。

除了这些架构风格，近几年面向服务架构、微服务架构在各大中型项目中得到广泛应用，面向服务架构中每一个功能都能通过服务来提供，服务定义了明确的可调用接口，服务之间的编排调用完成一个完整的业务，具有松耦合粗粒度的好处；微服务是对面向服务的升华，强调按照领域进行拆分应用，拆分后的应用可以敏捷开发和部署。

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

以下结合平台实际情况分析我们选择层次架构结合SOA思想的模式的原因及其使用情况：

我们分析了平台将支持的各种活动类型，发现在发布、管理、授权、分享、支付、推送、统计、广告、渲染粒度上的具有同一性，但活动逻辑、属性、数据结构、模板具有各自的特殊性；且活动数据将应用于活动管理系统、活动搜索服务、运营管理系统，而运营管理系统又要完成对所有应用的业务控制与数据配置，考虑数据一致性、运营统一性、可复用、易扩展维护及后续敏捷迭代的顺利进行，我们将公共模块及业务模块进行服务化，提出三层架构，将平台分为应用层、服务层、数据层。

应用层负责具体业务和视图呈现，整合编排不同服务完成具体业务的实现，在应用层，我们划分出10+个应用系统，比如活动管理系统、活动搜索服务应用（涉及pc、公众号、app、小程序）、运营管理系统等。以活动搜索服务为例，报名活动内容呈现、微信授权、报名、支付、核验等功能，这些功能会调用用户管理服务、订单支付服务、消息推送服务等服务做为支撑，通过这些服务实现业务数据的统一管理。应用层采用MVC设计模式，表现层采用vue实现，与后端完全分离，并结合CDN技术完成资源分布式部署。

服务层负责提供公共服务与业务服务。比如用户管理服务、消息推送服务、统一配置服务、风控服务等，前面提到活动的同一性和特殊性，我们也将每一种活动类型比如报名活动、抽奖、投票等作为单一的活动服务，由专门的虚拟团队负责，而不影响其他活动或模块的实现进度，同时方便后续扩展其他类型的活动。

服务层采用REST提供服务，内部实现了服务注册、服务查询等服务网关，用于服务层服务发现与服务使用。一开始我们考虑每个应用抽象出自己对应的服务层，好处是团队前期编码快速实现容易，不需要与其他团队协作，但考虑到需求的多样性与关联性、服务规模变大、开发人员不断增多，应用之间难以通信，耦合性强、存在大量冗余代码，数据松散一致性难以保证，后期扩展和维护将面临大量的人力，所以我们进一步考虑将原有的面向应用的服务重新整合编排成单一业务服务，比如现在的消息推送服务包含了微信公众号、小程序、App及第三方消息推送服务，与应用无关，不同应用可以调用其授权可使用的消息推送服务。而统一配置服务可以为不同应用提供不同的配置，比如轮播配置、广告位配置等，这些配置数据通过运营管理系统的统一配置中心配置并持久化到数据层，再提供给服务层为各应用服务。服务化使得层次结构更加清晰，让团队分工明确，通过服务化实现更高阶的模块化，完成小而美的服务。

数据层提供数据存储与访问服务。涉及数据缓存、持久化、搜索。由于较多高并发场景，用户在短时间内集中访问，我们基于redis实现了缓存机制，并结合消息队列实现部分异步调用，由于C端用户数据量级大，且读操作远大于写操作，我们采用了读写分离，在一些只读的场景访问只读数据库。在数据库访问上，我们采用Eloquent ORM进行读写。在数据分析与全文搜索方面使用Elasticsearch，完成活动全平台搜索与活动智能推荐服务。

层次结构的好处与不足

由于层次的分离及服务化的设计，我们能快速响应用户需求，快速支持新活动类型及新模块功能，快速调整满足运营数据验证。在结构清晰功能分明的架构下，牺牲了部分性能，所以我们也针对部分性能不佳，甚至实现多层缓存。除了服务松耦合外，后期我们发现活动模板需求多且重要，逐步影响常规化运营，考虑将前端活动组件模块化建设一个“乐高”式的活动页面运营系统。

总结

通过这个项目，我们实在的感受到软件系统架构设计的重要性，也感受到随着业务需求的增多和变化，给架构带来了各种各样的挑战，而通过合理的的软件架构，提高了系统的可靠性、可用性、可维护性、可扩展性、可复用性，间接提高了开发维护效率、运营效率，同时降低各方面成本，加速了团队成长及产品验证速度。

论系统架构风格选择与应用

目录

摘要

正文