软件设计要素初探：应用模型

请求-响应模型###
流处理模型###
人机交互模型###
分布式模型###

在 “软件设计要素初探” 一文，尝试从软件设计的整体角度，综合讨论了软件设计的各种要素。本文讨论构建软件可采用的应用模型。

应用模型涉及到数据处理与响应的全局流程和交互方式。 我所接触过的，主要有“请求-响应模型”、“流处理模型”、“分布式模型”、“人机交互模型”。

请求-响应模型###

Web应用通常采用“客户端请求-服务端响应”模型。主要有“同步”和“异步”两种方式。

同步是服务端将请求处理完成后直接将结果返回给客户端，通常适用于非常快速完成的任务；异步是服务端先返回给客户端一个响应，然后在后台启动任务来处理请求。处理完请求后将结果存储到指定位置，或者通知客户端。异步适用于耗时长的批处理任务。

无论是同步还是异步，处理请求时都可以采用并发的方式来提升性能和可扩展性。并发会带来不确定性、死锁、理解、调试以及测试的复杂性等，需要仔细权衡。通常耗时长的批量任务需要采用并发异步的模式，大多数服务请求可采用“顺序-同步”模式。

“同步-异步”是请求的接收与返回形式，“顺序-并发”是请求的处理形式。两两组合，可衍生出请求的四种“接收-处理-响应”方式。择善而行之。

流处理模型###

海量数据的(准)实时计算应用可采用流处理模型。比如Storm应用预先构建一个用于数据流处理的拓扑结构，运行时将进入拓扑的数据流“发射”到拓扑中的并行工作的工作节点，而每个工作节点亦能发射处理过的数据流到相邻的工作节点，依次处理直到在拓扑的终节点得到最终结果。订单同步采用了Storm技术，从消息中间件中获取消息数据，并同步到Hbase中。

使用storm框架开发分布式实时应用时，主要包括三部分：

• 任务拆分和拓扑构建
• 消息设计/分组/并发处理/ACK
• 同步延迟监控与告警。

对于涉及金额的敏感的消息处理，(准)实时同步应用尤其要注意添加延迟监控报警。

人机交互模型###

人机交互模型，通过人与计算设备的持续而紧密的交互活动来完成应用服务与功能。

流处理模型和分布式模型，通常是客户端感知不到的后台基础服务；请求-响应模型，通常是人与互联网的间歇性交互；而人机交互模型，通常着重于视觉和交互设计的友好性、易用性和吸引力，是软件之形之观。设计优秀的人机交互在某种程度上会弥补内在功能的不完善，让已有功能服务发挥的更加出色。

分布式模型###

分布式模型更多是一种部署的结构，将部署在不同机器上的大量普通服务器应用通过联网的分布式的结构组织起来，共同协作来完成高性能计算和高可用服务目标。熟知的互联网即是一种超大规模的分布式系统。阿里云ECS控制系统架构，也采用分布式模型。如下图所示：

分布式体现在如下两点：

(1) 控制系统与部署在Linux集群上的上千个NC(每个NC上运行着若干VM)之间的交互。控制系统访问RegionDB，根据一定的算法，识别VM所在NC，然后向指定物理机发送虚拟化、存储、网络命令，NC接收到命令后，控制指定VM作出正确变更，并向可靠消息组件RMS推送消息，控制系统接收到消息后更新RegionDB信息。集群上的NC/VM还必须通过可靠心跳服务组件RHS上报心跳，及时识别和修复故障VM。 NC 是物理机上实现的逻辑控制器(NodeController)，每个NC都是集群的一个节点。分布式系统通常是以集群为单位部署。

(2) 从整体看来，多台部署的ECSOpenAPI、部署于所有Region的ECS业务系统，部署于所有Region的控制系统，部署于所有Region的Linux集群、分布式缓存组件 Tair、消息组件 RMS、消息心跳 RHS ，构成了一个大型分布式服务系统， 即：ECS弹性计算服务。

部署结构在一定程度上会影响设计决策。为了能通过添加更多机器来水平扩展集群的服务能力，设计上要求请求无状态。分布式模型适用于搭建大型计算基础能力与服务。

作者：@琴水玉

转载请注明出处：https://www.cnblogs.com/lovesqcc/p/9502356.html

微信扫一扫下面的二维码，关注我的公众号 编程大观园 :)