关于架构设计的一点思考

Posted 2021-04-10 大数据学堂

概述

从产品经理撰写出产品需求文档（包括产品原型、功能描述等），到研发编程实现，中间有巨大的鸿沟。越复杂的业务需求，这条鸿沟就越大。一般而言，我们至少还要有两个步骤：业务分析与架构设计。

业务分析是针对业务领域的建模，解决的问题是业务上如何实现，产出是分析模型。架构设计是针对技术领域的设计，解决的问题是技术上如何实现。这两个方面是会互相影响的，设计的时候往往需要来来回回的考虑这两个方面。甚至系统开发时也时常会需要调整模型或者架构，当然相应的也需要更新文档。

设计方法

架构设计不一定要深入到具体的实现细节，但是应该尽量全面的考虑系统的各个方面。关键是要对项目风险有比较大的把握，这样才能避免开发过程出现不可控的问题。具体设计需要多详细，是需要设计者自己去把握度的。

对于暂时无法确定的内容，应该在文档中注明，在开发过程早期进行试验和验证。如果对项目比较关键，可以考虑先行开发原型来进行验证。

架构设计常见的是4+1视图，即逻辑视图、开发视图、过程视图、物理视图，再加上场景。另外一种我更喜欢的是6步法设计方法。

1、确定整体架构

首先需要在整体上考虑系统的位置和职责：

• 确定系统在整个上下文中的位置，与其他系统的关联。
• 确定系统自身以及各个外部系统的职责。

整体架构对应的就是情景视图。这一步将系统看作一个黑盒，确认系统自己的范围和职责，相关的外部系统的职责，以及他们之间的关联。

例如，抢票酱小程序的整体架构大概是这样的。

2、设计功能模块

其次需要确定系统内部的功能模块及其职责：

• 确定系统的模块划分。

• 确定每个模块的职责以及模块间的关联。

功能模块对应的就是功能视图。这一步需要明确系统的内部结构。内部模块划分主要有基于业务功能的划分，以及基于实现层次的划分，稍复杂的系统可能会两者都有。基于业务功能的划分方式主要是功能树。

功能模块内部职责及模块之间的关系（接口定义）可以使用UML的组件图表示。

3、考虑设计模块

由于在抢票过程中，有很多状态，比如抢票中、提交中、已取消、待支付、已完成、已过期、休息中等等。因此，可以考虑使用状态机模式。

另外，一个余票查询线程（根据出发车站、到达车站、出发日期查询）查到的结果可以供多个用户订单使用，所以，可以使用观察者模式设计余票查询。

4、设计外部接口

一般外部接口是通过HTTP 请求和 JSON 格式进行传输的，但也有可能会有其他的接口形式，例如消息队列、TCP、UDP、WebSocket等。设计阶段，API 文档可以通过 Markdown 文档记录，开发完成后可以独立维护，或者使用 Swagger 和代码一起维护。

接口设计需要注意几点：

• 接口的设计应该以系统提供的领域资源或服务为基础，同时考虑调用方的需求。

• 接口的粒度很重要，太细则调用方很不方便需要多次调用，太粗则无法灵活的满足各种需求，需要仔细权衡。

• 接口的设计也需要从调用方的角度考虑如何进行调用。必要的话可以画流程图、时序图、状态图详细说明调用顺序即状态转换等。

• 接口的文档一定要清楚的说明调用接口的方法、前置条件，参数作用、不同条件的处理、返回接口等。

下面是设计阶段用Markdown编写的判断用户是否登录的接口文档，可以作为参考。

简要描述：

• 检查用户是否登陆，在提交订单/候补订单前总是要先这样判断一下

请求URL：

• https://kyfw.12306.cn/otn/login/checkUser

  请求方式：

  参数：

  参数名	必选	类型	说明	示例
  _json_att	是	string	是一个空字符串	""

  返回示例

  {
  "validateMessagesShowId": "_validatorMessage",
  "status": true,
  "httpstatus": 200,
  "data": {
  "flag": true
  },
  "messages": [],
  "validateMessages": {}
  }

  备注

  参数名	类型	说明
  flag	bool	用户组id，1：超级管理员；2：普通用户

  返回参数说明

• 无

• GET

5、设计数据库模型

如果分析时有了完善了数据模型，设计数据库模型就不是什么难事了。开发完成后，数据库模型应该以数据库为准，架构文档就不需要保留这一部分了。

需要注意的是，数据库模型是数据模型在关系数据库的实现，但不一定是严格的映射。数据库可能会有范式、冗余、一致性、同步、分表分库方面的考虑，必要时可能会使用非关系型数据库如ElasticSearch、Cassandra等。

数据库设计的更多规范可以参考《数据库设计开发规范-阿里》

链接:https://pan.baidu.com/s/1yz6ayssw6RMJIR0tb1Thmg  密码:ca9a

6、考虑非功能性需求

对于我们的后台系统来说，功能性需求都已满足，但在设计时，也还是需要考虑以下非功能性需求：

• 技术选型：采用什么开发语言、框架、依赖库、中间件，当涉及到新技术的引入时，则需要仔细分析备用技术的优缺点，选择最合适的方案。

• 可用性：负载均衡、存储引擎、索引优化、分库分表等，主要是为了提高系统的性能和响应速度。

• 可靠性：数据迁移、同步和回滚方案，对于老系统的重构，需要仔细考虑并且提前演练。分布式架构或者使用了缓存时还需要考虑数据的一致性。

• 安全性：数据加密、传输加密、token策略等，主要是考虑数据安全、访问安全等。

• 可扩展性：数据存储容量、代码可扩展性等。
  

• 系统监控和告警：除了常规的监控和告警，是否有特殊的指标需要监控