论文题 示例
试题:
论软件架构风格软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。体系结构风格反应了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
请围绕“论软件架构风格”论题，依次从以下三个方面进行论述。
- 概要叙述你参与分析和设计的软件系统开发项目以及你所担任的主要工作。
- 软件系统开发中常用的软件架构风格有哪些?详细阐述每种风格的具体含义。
- 详细说明你所参与分析和设计的软件系统是采用什么软件架构风格的，并分析采用该架构风格设计的原因。
摘要
本文描述了一个新能源汽车媒体、社区、选车等一体化平台的架构分析与设计过程。该项目始于 2020 年，弥补了当时市面上没有新能源汽车平台的空缺，响应了国家对于新能源汽车的政策向导。本文介绍了 C/S架构风格，B/S架构风格，分层架构风格等常用软甲架构风格。详细说明了该系统软件组成部分的架构分析与设计，其中应用系统采用 B/S 架构，前后端分离的服务端渲染模式，满足了推广、跨平台等需求，降低了开发成本，明确了职责与分工。后端服务采用分层架构，通过划分不同的层，实现了一种明确自责，耦合性低，方便测试的应用程序。前后端通讯采用 REST 架构风格，一种约定大于配置的架构风格，降低了学习与开发成本，减轻了开发人员的心智负担。
背景
2020年，新能源汽车开始蓬勃发展，国务院发布了《新能源汽车产业规划通知（2021-2035）》。此时，市面上并没有专门针对新能源汽车的平台，于是，我司决定开发一个关于新能源汽车的一体化平台，其中包括媒体、社区、选车等功能。该项目于 2020 年 10 月开始规划，系统主要分为三个部分，其中前端应用采用 B/S 架构风格，后端服务采用分层架构风格，前端与后端通信采用 REST 架构风格。我在该项目中担任技术经理，负责架构设计与技术选型工作。
理论
在日常实践中，系统常用的软件风格有：C/S 架构风格，B/S 架构风格，分层架构风格等。C/S 架构风格，该架构分为客户端与服务端，使用约定的协议进行通信，具有分工明确、耦合度低、客户端性能好等优点，但同时因为需要开发两个端，会出现开发成本高，升级维护困难等缺点。B/S 架构风格，主要使用浏览器，传统 B/S 架构会在一个服务端进行渲染，现代开发流程中，考虑到分工问题，会分为浏览器客户端与服务端，是一种瘦客户端模式，具有开发成本低，跨平台等优点，但因为需要浏览器支持，所以可能出现兼容性问题。分层架构风格，该模式约定不同的层级，每个层级只做一类事情，一般只调用下一层，具有结构明确、耦合度低、维护方便等优点，同时分层过多也会带来性能降低等问题。
正文
该项目立项后进行需求分析，为了通用性，应用系统使用 B/S 架构，优先满足推广与跨平台等需求并保留未来的扩展性。服务端采用分层架构，明确责任并解耦。同时约定使用类 REST 架构风格进行通讯。
- 应用系统
该系统主要采用 B/S 架构风格，传统 B/S 架构中，客户端与服务端开发人员往往是不同的人，但是要在一个项目中进行开发，会出现分工不明确，责任不清晰等问题，所以使用前后端分离的方式进行架构设计，客户端开发人员可以专注于 UI 的交互，数据通过 http 协议与后端进行通讯，后端开发人员可以专注于业务流程的开发，明确责任，方便维护。一般前后端分离，前端只负责 UI 的交互，数据通过 AJAX 等技术去后端获取，展示效果通过 JavaScript 进行操作渲染，导致最终呈现在浏览器源码上的 HTML 是一个固定的结构，没有业务的相关数据，无法进行 SEO。因为该项目有推广需求，所以决定使用 SSR(服务端渲染)同构技术，客户端服务端都采用相同的 JavaScript 语言，客户端使用浏览器提供的 JS 引擎，服务端使用 NodeJS 运行时。用户或者爬虫初次访问页面的时候，NodeJS 会执行对应的 JavaScript 代码，生成对应的 HTML 与运行上下文返回给客户端，客户端拿到后，可以在客户端进行 UI 展示、路由控制等功能。按照该方案，可以做 SEO，满足推广需求，使用同构模式，同一套代码运行在两端，降低了开发成本。同时前后端分离，明确职责与分工。 - 后端服务
该部分主要采用分层架构，主要包括的层包括：中间件层，守卫层，拦截器层，管道层，控制器层，服务层，数据访问层，数据实体层。其中中间件层用来处理日志，包括用户请求信息，系统响应时间等。项目使用Json Web Token 进行登录验证，当中用户权限验证在守卫层。拦截器层用于数据的接口统一返回处理，其中包括 http 状态码的处理，返回体数据的格式标准化等功能。管道层用于数据转换与验证，比如一些数据类型的转换映射，还有用户输入参数验证、XSS 预防等功能。控制器层用于处理路由响应，委托给服务层处理业务。服务层为主要的业务逻辑处理空间，提供可复用的功能模块，做好封装，方便调用。数据访问层，主要是针对数据的操作，项目中用到的数据库、缓存的操作都在该层。数据库实体层是对数据库实体的映射，标识数据库实体字段与格式等。该架构风格可以提供一种职责清晰，低耦合，方便测试的应用程序。 - 前后端通讯
考虑到通用性，通讯协议使用 http，架构采用 REST 风格。REST 风格是一种以资源为中心的架构风格，所有的操作均是对资源的控制。REST 对应的 http 控制操作有 GET、POST、PATCH、PUT、DELETE 等方法，GET 表示对资源的获取，POST 表示对资源的新增，PATCH 表示对资源的部分更新，PUT 表示对资源的整体替换，DEL 表示删除资源。REST 标准中要求使用 HTTP 状态码来表示对操作资源的响应，同时在返回体中标记该资源的状态。但是实际开发中会发现 HTTP 状态码过少，且有些复杂状态需要通过响应体里面的内容去判断如何继续交互。所以我们对 REST 做了一些改动，请求分为是否到达业务层，如果没有达到业务层，按照标准 REST 风格进行响应。如果达到业务层那么统一状态码为 200，表示操作已经发生，在响应体里面以约定的标准格式表示本次处理的状态。项目中约定，业务状态码为 0，那么表示此次交互成功。如果业务状态码非 0，表示业务处理异常，客户端需要根据响应体里面的状态码、错误信息、参考文档链接等信息定位异常确定后续操作逻辑。这种以约定大于配置的方式降低学习和实现成本，极大简化了开发人员的心智负担。
结束
该项目于 2022 年 7 月上线，项目在运行过程中，遇到过数据库压力比较大的情况，我们在调用较为频繁的流程上增加了缓存，并在数据库上做了读写分离、分库分表等操作后趋于稳定。后续为了部署扩容方便，增加了 CI/CD 流程，因为服务端在设计之初是无状态的，方便横向扩展，我们将所有的应用都打包为 Docker 镜像，部署在云服务平台的 ServerLess 上，使用后才付费，极大降低了运行成本。但同时也遇到了 ServerLess 的冷启动慢的问题，目前方案是根据日常流量大小，预留启动实例并适当裁剪镜像。目前该项目已运行三年多，未出现严重生产事故，后续二期工程增加了移动平台适配，由于该项目架构扩展性良好，目前已成功上线运行。