《实用软件架构:从系统环境到软件部署 》——第1章 案例研究1.1 业务问题

简介:

本节书摘来自华章出版社《实用软件架构:从系统环境到软件部署》一书中的第1章,第1.1节,作者[印]蒂拉克·米特拉(Tilak Mitra)著,爱飞翔 译,更多章节内容可以访问云栖社区“华章计算机”公众号查看。


第1章 案 例 研 究

我这个人专门解决难题,有什么事尽管拿来问!

生活脱离了环境,就如同船没有了帆。环境使得我们可以专注于手头的工作,它能给人一种方向感,也能给人提供一个理由,使我们觉得完成某件事情是值得的。信息技术(IT)和计算机工程等领域中的架构也是如此,它同样需要有一个存在的理由。我们必须对架构进行实例化,必须按照需要将其实现出来,以解决实际的问题。

笔者将在本章中描述一个虚构的案例,以演示问题的陈述。尽管笔者不会明确宣称它与某个真实案例有所对应,但读者在工作中或许真的就会遇到这么一个类似的案例。这种描述实际问题的案例研究,能为我们提供一个环境,使得IT或软件架构中的元素可以在这个环境中呈现出来。该环境可以说是软件架构得以存在的客观理由。

1.1 业务问题

有一家名为BWM(Best West Manufacturers)的重型设备生产公司已经拥有稳定的客户群,主要开展机器和重型设备生产等传统业务。

行业展望分析和独立分析师的研究报告都指出:未来几年中,BWM公司通过与新客户签订设备购买合约来增加其市场份额的机会是相当有限的。

董事会为此举行了将近两周的闭门会议。在经过多番构思和头脑风暴之后,参加会议的人员对会议成果进行了总结,并将其作为业务指示,传达给了公司的高层领导。他们要求公司极力提升现有客户群对售后市场的关注程度,并想办法使客户在售后市场中进行大量消费。

公司的高层管理者分析了董事会所下达的指令,他们认为公司必须把注意力集中在怎样向客户提供更多服务上。这意味着BWM不仅要做好设备本身的销售工作,而且还要提供更多的增值服务。这些服务可以帮助客户提升机器的使用效率,从而最大限度地提高生产量,也可以帮助客户减少意外的停机检修时间,还可以帮助客户尽早预见有可能出现的故障。

1.1.1 技术挑战

为了在提供机器的同时,向客户提供一套高价值的服务,BWM需要打造一个高水准的IT系统作为公司的基本骨干。要构建这样一个健壮的企业级系统,就必须具有相关的IT知识,以便对其进行概念化、表述、架构、设计及构建,但公司内部现在明显缺乏这样的专业知识。

于是,很多问题接踵而至:

公司缺乏软件开发技能及专业知识。

公司对时下流行的先进技术接触得不够多。

公司对软件开发方法论接触得不够多,也没有足够的经验及专业知识。

公司没有一个能够安置企业级系统的IT基础设施。

技术团队在得到了公司的资助和支持之后,决定聘用一家顾问公司,来帮助本团队实现转型。于是这家顾问公司就过来了。

顾问公司把重点放在解决方案上,他们先挑出几个使用场景,然后将其表述成用例,以便使团队成员能够对即将要构建的这套解决方案所具备的复杂度、关键点和相关能力,有一个适当的了解及领悟。

本章将会描述其中某些关键的用例,这些关键用例具备如下特点:

它们主要是业务方面的用例。

实际的用例数量是比较多的,而本章所描述的用例只占其中的一小部分。

这些用例采用简单的语言和宏观的视角来描述,其中不包含技术表现形式或技术细节。

1.1.2 用例

在接下来的几个小节中,我们要描述几项系统特征,以刻画本系统所应提供的核心能力。这些能力用来表示一个可以完全发挥其能力的IT系统,该系统会参与到一个更大的生态环境中,该环境里整合了点对点的供应链,其中包括设备销售和售后市场的增值服务(这是本IT系统的重点所在),也包括优化之后的零部件供应库存。

下面将要演示四个用例,它们会构成本次案例研究的主题。

注意:     本书所提到的“IT系统”,都是指正在构建的这个系统或应用程序,而本书所提到的“系统”,也应视为“IT系统”的同义词。此外,在进行案例研究时,机器与设备指的是同一个概念,因此,这两种说法可以交替使用。

1.1.3 在机器运转过程中进行实时处理与监控

系统应该能够处理从机器的仪表中所传进来的数据流,并实时地计算出关键性能与监测指标,也就是说,当数据从机器中的数码传感器等仪器内产生出来时,系统就要对其进行实时的处理与监控。许多项指标可以合起来形成有足够分量的信息,无论是哪种类型的机器,我们都可以通过这些由实时处理与监控而得到的信息,来了解该机器的状况。

实时处理的过程,应该发生在数据写入持久化设备之前。对于任意一台机器来说,每隔几毫秒就会有一条数据从中产生出来,而且多台机器也有可能会同时产生数据。

计算出来的指标,会写入持久化存储设备中,同时也会展示在可视化的监控面板中。该面板会按照数据的计算速度和生成速度,来更新其中的信息。

在发挥并利用这项能力时,IT系统主要是与现场工作人员和监控主管进行交互的。

1.1.4 为新机器提供无缝的激活服务

这个系统应该是个随加随用的(on-board)系统,也就是说,用户要能够随时给其中添加新的机器。系统不仅要能够无缝且透明地支持新的机器,而且还必须迅速地完成这一过程。

客户购买了某台新机器之后,这台机器应该能够自动激活。也就是说,当客户初次使用机器,并且有数据从机器中的仪表里产生出来时,该机器就应该自动地向IT系统进行注册,以激活相关的服务。

此处所谓的无缝,意思是说:IT系统在几乎不需要由用户来干预的情况下,即可处理好与新机器的添加有关的各方面问题。这包括收集工作现场的机器数据,将监测到的仪表读数实时展现出来,进行前瞻式的诊断,以及自动生成后续的工作定单(以应对机器中有可能出现的异常状况)。

在发挥这项能力时,IT系统主要是和超级用户(Power User)进行交互的。

1.1.5 生成工作定单

系统应该能够提前判定并生成维护所需的工作定单(work order)。它应该要能察觉到机器在运作过程中所出现的错误,并且要能在机器本身或其中的某个部件即将发生故障或崩溃时,提前将这一情况预测出来。

系统要能够智能地评估出机器所遭遇的状况到底有多严重,并且要判断出有没有可能把维护过程放在下一个维护周期中执行。在进行判断时,它需要决定是应该生成并立刻执行相关的工作定单,还是应该等到下一个维护周期再去进行维护。如果决定采用后一种办法,那么系统还要给相关人员发出警示信息。

整个这套流程都应该是自动化的,然而到了最终的验证环节时,维护人员可以决定是否真的要把系统所生成的工作定单中的指令,运用到机器上。

在发挥这项能力时,IT系统主要是和维修主管进行交互的。

1.1.6 尽量减少在为全球客户提供服务时所产生的延迟

系统不应该给用户留下一种运作较为缓慢的印象。用户与系统之间的交互,以及系统所给出的响应,都应该比常见的企业级系统更加迅速,以防用户失去耐心。

系统要把分布在全球各地的用户全都覆盖到,但这并不应该增加系统的延迟时间,也不应该使系统的吞吐量变低。

系统要根据时间方面的敏感度和关键度,来对各项特性进行归类,并且优先保证那些较为敏感且较为关键的特性,可以具有最小的延迟时间和最大的吞吐量。比如,“在机器运转过程中进行实时处理与监控”,就是一项对时间要求比较严格的特性,因此,系统不应该给用户留下响应速度比较慢的印象,也就是说,系统要能够迅速展示机器的性能和监测到的指标等信息,以便给用户呈现出一种实时刷新的感觉。

无论什么人与系统相交互,这项特性都应该得到体现。

本章提到的这四个用例,应该视为IT系统所必须体现出的一些重要能力。这些能力,通常都是用上面所展示的业务用例来进行描述的。

此外大家还要注意,业务用例(business use case)与系统用例(system use case)是两个不同的概念。在进行用例分析时,我们固然不能陷入其中而无法自拔,但同时,却也必须意识到业务用例与系统用例之间的区别。前者说的是系统应该提供“什么样的”能力,而后者说的则是系统应该“怎样”来实现这些能力。用例的定义,本身就是一门学问,我们要把它放在整个软件开发生命期的第一个阶段,也就是需求收集(Requirements Gathering)阶段中来完成。

相关文章
|
3月前
|
存储 缓存 固态存储
【vsan数据恢复】vsan分布式存储架构数据恢复案例
VSAN数据恢复环境: 一套有三台服务器节点的VSAN超融合基础架构,每台服务器节点上配置2块SSD硬盘和4块机械硬盘。 每个服务器节点上配置有两个磁盘组,每个磁盘组使用1个SSD硬盘作为缓存盘,2个机械硬盘作为容量盘。三台服务器节点上共配置6个磁盘组,共同组成VSAN存储空间,存放虚拟机文件。 需要恢复服务器节点上的数据库数据。 VSAN故障: 非正常关机导致VSAN逻辑架构出现故障,部分虚拟机磁盘组件出现问题,磁盘文件丢失。
|
6月前
|
存储 监控 安全
大厂案例 - 腾讯万亿级 Elasticsearch 架构实践1
大厂案例 - 腾讯万亿级 Elasticsearch 架构实践
82 0
|
7月前
|
SQL 安全 网络安全
交易所开发测试版丨交易所系统开发规则玩法/架构设计/项目步骤/方案逻辑/案例解析/源码部署
The development process of the exchange system involves multiple steps and links. The following is the detailed process and steps for the development of the exchange system:
|
25天前
|
存储 Java 应用服务中间件
【分布式技术专题】「架构实践于案例分析」盘点互联网应用服务中常用分布式事务(刚性事务和柔性事务)的原理和方案
【分布式技术专题】「架构实践于案例分析」盘点互联网应用服务中常用分布式事务(刚性事务和柔性事务)的原理和方案
45 0
|
2月前
|
KVM 虚拟化 Android开发
DP读书:鲲鹏处理器 架构与编程(十二)鲲鹏软件实战案例Docker+KVM的部署
DP读书:鲲鹏处理器 架构与编程(十二)鲲鹏软件实战案例Docker+KVM的部署
54 1
|
4月前
|
存储 数据挖掘
Vsan数据恢复—vSAN逻辑架构出现故障的数据恢复案例
一台存储采用了VSAN分布式存储架构,存储内共有24块硬盘存储数据。 这台vSAN存储设备关机重启。经过数据恢复工程师的检测,发现vSAN逻辑架构出现故障,上层虚拟机瘫痪,存储内的数据丢失。
|
5月前
|
数据采集 SQL 数据可视化
79 网站点击流数据分析案例(整体技术流程及架构)
79 网站点击流数据分析案例(整体技术流程及架构)
54 0
|
6月前
|
关系型数据库 MySQL Linux
Linux环境下LNMP架构实战案例
Linux环境下LNMP架构实战案例
|
6月前
|
存储 Java 数据库
大厂案例 - 腾讯万亿级 Elasticsearch 架构实践2
大厂案例 - 腾讯万亿级 Elasticsearch 架构实践2
35 0
|
6月前
|
敏捷开发 测试技术
推三返一开发稳定版丨推三返一项目系统开发详细指南/方案需求/步骤逻辑/流程功能/案例设计/技术架构/源码程序
推三返一系统开发是一种软件开发模式,也被称为迭代增量开发模式。它是一种敏捷开发方法的一种,通过将整个开发过程分为多个迭代周期,每个周期都会增加新的功能和特性,并在每个迭代周期结束后进行测试、反馈和修改。推三返一系统开发的核心思想是“推进三步,反馈一步”。