用户您好!请先登录!

软件设计的第一性原理:结构化抽象

软件设计的第一性原理:结构化抽象

软件设计的第一性原理,是结构化抽象。术生于道,技术生于原理。

引语

所谓的第一性原理,就是无论使用什么方法论,都无法绕过的那最最基础的部分。无论是 DDD 设计,还是面向模式的架构设计,或 微服务架构,均建基于结构化抽象。

何为结构化抽象 ?先回答 “何为抽象” 与 “何为结构化” 两个问题。

何为抽象 ? “编程漫谈(三):抽象” 一文阐述了什么是抽象及在编程与计算中的意义; “代码抽象与分层” 则列举了从代码中提炼出来的六类抽象,涵盖了编程开发中常见的实体及处理。

何为结构化 ?结构,是事物的组成元素及关联和作用。 “编程漫谈(十一):编程概要” 一文阐述了编程中的各种数据结构及控制结构,“软件的组合结构:从指令到软件” 则阐述了组合元素的方法与结构。结构化,分为数据结构化和控制结构化。数据结构化指海量数据的组织和存储及需要满足的约束(比如一致性、完整性等);控制结构化,是指,操作的组织和执行以及需要满足的约束。

软件,本质上是一种可动态而弹性变化的逻辑装置。结构化,即是将逻辑进行抽象、提炼、分离、聚合,构建成更加缜密、动态、弹性的结构流。

逻辑,是思维意识的一种形式。软件设计与开发,是与自己的思维意识进行抗争与和解。

理念

设计与开发

软件设计与开发工作渗透着结构化抽象的思想。譬如:

  • 软件建模。是对大量原始数据进行结构化组织,使之更加有序、有意义、可交互。
  • 数据存取。在建立对数据的组织抽象之后,就要进行数据的存取操作。数据是规则的还是不规则的 ?数据量有多少及增长速度如何 ?是否要进行缓存 ?选取合适的数据存储组件。数据存储组件是对海量数据存储和访问的结构化抽象。
  • 流程构造。在确定数据存取方案后,需要构建完整的流程。流程可以使用时序图来表示。流程包含前置、操作与契约。前置,是进行操作需要满足的条件;操作则是获取数据或请求某种执行;契约,是在完成操作之后,必须满足的一系列断言。完整流程通常是:“前置-操作-契约”的子流程的有序组合。
  • 编程实现。需要评估潜在变化的部分,将通用的部分与易变化的部分相分离。

设计模式

设计模式是对象职责及交互的结构化抽象,是体现结构化抽象思想的基本单元。可参阅:“软件设计要素初探:基础设计模式概览” 。

架构模式是基于设计模式的更高层次的结构化抽象。可参阅:“软件设计要素初探:架构模式” 。

设计模式和架构模式主要应对软件的业务可扩展性难题。

技术机制

在软件设计中,技术是绕不开的一道槛。技术的作用在于,在指定的场景下,所执行的操作效果必须满足某种约束。技术机制,是将多个相关联的结构化抽象进行聚合后的成品。

异步

比如先快速响应客户端,再进行请求处理。其结构化抽象是,操作相对于主进程的执行耗时与实际执行耗时无关。

幂等

比如处理资金问题,必须考虑幂等问题,即同一个请求,执行多次的效果必须与执行一次的效果等同。幂等的结构化抽象是,操作的主效果与操作次数无关。

事务

比如多个关联数据的插入、更新和删除,必须保证原子性。要么全部执行,要么一个都不执行。需要使用事务来保证。事务的特性是ACID,结构化抽象是关联数据集合在操作前后必须满足某种一致性约束。确定“关联数据集的一致性约束”是关键,其实现是还原点、快照与回滚日志。

并发

大量请求或数据集的处理,使用串行的方式效率难以满足性能或吞吐量要求,需使用并发的方式,充分利用多核CPU资源。结构化抽象是,多个相互独立的执行单元。这些执行单元拥有独立的CPU和缓存,所使用的内存可以为共享内存型和独立内存型。

同步

在并发场景下,要保证多个执行单元(比如线程、进程等)能够看到共享内存的最新更新值。同步的本质是确保指定顺序执行,避免不确定的执行顺序带来不确定性的结果。其结构化抽象是临界区。临界区是约束执行顺序的一种结构。

框架

应用的组件、配置与启动,可以做成通用的框架和脚手架反复使用,快速启动和部署一项工程,减少不必要的重复工作量。框架的结构化抽象是,将工程中的配置、部署与启动、运行结构、通用任务进行提炼并形成固定的模式,应用只需要关注可变的业务部分。

限流

突发的峰值流量,为了避免瞬间占满和击垮服务器的资源和服务能力,需要进行限流。其结构化抽象是,在指定时间间隔内的通过许可数必须满足指定规格。

缓存

对于热点数据,为了避免反复从源存储获取,增大对存储的访问压力,可以使用缓存来存储热点数据,增大命中率,提升性能,减少对存储的不必要的访问压力。缓存的结构化抽象是,使用少而精的空间优先于大而全的空间的搜索。“少而精”是指聚焦应用的经常被访问的热点数据。缓存的衡量指标是命中率和过期时间,操作是缓存与源存储的读写同步。

降级

当非核心的依赖不可用时,可以及时切断依赖,舍小取大,保证整体服务正常运行,不受局部影响。降级的结构化抽象是,是主备策略的设计与切换机制。

重试

当处理数据发生错误时,可以进行重试来进行补偿和恢复。重试的结构化抽象是,至少(且通常只需)保证一次操作成功。

切面

比如耗时统计。耗时统计与操作的执行内容无关,仅关注操作的耗时。切面的结构化抽象是,操作的非功能属性与功能本身的解耦。

代理

比如请求的负载均衡。不是直接执行目标操作,而是创建一个代理,由这个代理转发请求和执行目标操作。代理的结构化抽象是,隐藏目标操作。

版本号

版本号通常用于实现非阻塞式并发,即乐观锁。其结构化抽象是,一个严格保证特征数值单调递增的机制。

实践

示例分析

要对问题进行结构化抽象,需要先提取问题的结构特征。可以分别从数据结构化和操作结构化两个角度来思考。

分页

比如分页功能是大多数信息系统管理的必备功能之一。怎么实现一个通用的分页功能呢 ?

从数据结构化来思考,其结构要素为:偏移量、页大小、起始和结束位置。分页本身和获取何种对象无关。

从操作结构化来思考,其结构要素为:1. select columns from table where condition limit offset, size ; 2. count distinct(id) from table where condition limit offset, size .

columns , table, condition 都是可以根据具体业务来动态生成的,而整个 SQL 的骨架是固定的。table 不一定指 DB , select , count 也不一定是 DB 的 sql ,它只是表示在指定搜索条件下进行对象选择与统计的操作语义。columns , table, cond 的动态生成,可以使用泛型和回调函数来传入和处理。

限购

限购,是指定时间内,指定 key 的实体允许通过的许可数量。与限流是同一类结构化抽象。许可数量,是一个全局性约束。

假设去掉“指定时间”的约束,只限制许可数量, 其结构化抽象是,dec if total – count(key) > 0. 并发的场景下,total – count(key) > 0 的值需要进行全局同步。

如果加上“指定时间”的约束,还需要考虑高并发场景下 dec if total – count(key) > 0 的操作耗时。如果指定时间内不允许超过限购数量(强约束),则必须对 dec if total – count(key) > 0 进行加锁,吞吐量取决于操作耗时而不是指定的限购数;如果指定时间内可允许暂时地超过限购数量(弱约束),则可参考限流算法。

数据同步

数据同步的结构化抽象是,将源存储 S1, S2, …, Sn 的数据复制到目标存储 D 。

数据同步分为两种不同的场景,有实时同步和离线同步。实时同步对数据延迟性容忍非常低,离线同步则要求更快的吞吐量。

实时同步通常采用流式同步,通过接收消息流来处理。操作的结构化是,Receiver (msg) -> Format(msg) -> Save for each msg . msg 是源存储中的一条数据或一个单位数据集。

离线同步通常采用批量处理,实现方式是批量获取数据并批量格式化后存储。操作的结构化是,Divide(S) into N part(S) ; Select part(S) Then Format part(S) and Save for each part(S) 。可以根据业务唯一 ID 实现一个通用的 Divide 算法。

离线同步要注意 format 的超时和健壮性处理,记录下异常以便重试,同时不因单个数据处理失败而中断整体流程;流式同步则要注意控制好并发情形下的准确性。由于对吞吐量要求比较高,往往采用乐观锁的方式,找到某种能够控制全局版本号单调递增的机制,或者尽量避免“多表同步到单表”的场景【并发场景下会带来更多复杂性】。

积累抽象

在实际工作中,可以反思和提炼设计中所用到的结构化抽象。如果现有的结构化抽象及组合难以解决问题,是否需要新的结构化抽象 ?创建新的结构化抽象,并使之与已有的进行组合和集成。

规模化挑战

如果程序媛猿面对的是几万的数据量,那是可以夜夜笙歌的。然而,现实情况是,面对的是亿级以上规模的数据量,且数据量仍然在指数级增长。为了人类社会的无理性发展,程序媛猿们真是费尽了心思花白了头。

为了应对亿级规模的数据量,并发、分布式等方案层出不穷,结合变化的业务场景,又衍生出更多的挠人烧脑的复杂问题。如何应对呢?

规模化挑战的结构化抽象是,在指定时间内,每秒处理的请求/单位数据集的吞吐量,处理一个请求或单位数据集的平均响应时间,以及在流量剧烈变化时的弹性扩展能力。

并发

并发和并行机制取代了串行机制。单CPU和单机的性能基本抵达瓶颈,只能从多核CPU和多机上想办法。将要处理的数据量分解为多个相互独立的子数据集,并在不同的执行实体里相互独立地执行。比如线程池,Fork/Join , Map-Reduce 执行模型。并发和并行虽然解决了单机性能不足的问题,却引发了更多的问题。

同步

有了并发执行之后,由于有些资源是共享的,而一些热点数据往往被多个执行实体同时读取和修改,又产生了竞争问题。为了解决竞争,引入了同步机制。大量对同一资源、数据的操作进行同步,引起性能问题。

缓存

对于热点数据的读取和操作,通过“空间换时间”的策略,使用缓存来提升性能,降低对源存储的访问压力。

限流

由于允许并发请求进入,则必须应对瞬间的峰值流量(可见世态)。限流必须有度,不能因噎废食。需要对系统承载的负荷及极限负荷进行测量,根据测量值来确定一个可动态调整的限流值。极限负荷测量即是压测。

降级

由于业务特性的不同,环境的不稳定波动,以及采用方案的局限性,依赖服务有可能出现部分失败,对于调用极其频繁的服务来说,依赖服务的少许失败可能导致上层的雪崩效应。因此在依赖服务出现问题时,必须进行适当的降级熔断。

测量

为了避免大流量或大数据结构导致软件运行出现问题,降低维护成本,不能仅仅停留在定性分析上,还要进行量化。需要对系统进行仔细的测量。服务接口的 RT 和 吞吐量 如何 ?存取操作耗时如何 ?消息处理耗时和吞吐量如何 ?内存占用如何 ?大数据对象占用内存多大 ?能够承载的极限流量有多大 ?能够承载的极限对象大小是多大 ?指定时间段的失败数和失败率有多大 ?

集群

若以单机视角去考虑问题,就会殚精竭虑地在“并发、同步、缓存、限流、降级”等上做到极致,就像在单核时代将CPU主频做到极致一样。然而,即使做到极致,为了峰值流量所构建的机器资源,在平均流量场景下会造成很大的浪费;并且,很难预估峰值流量会在什么时候来到。如果有一个超级大的聚合的池化资源,总可以提供足够强大而弹性的CPU计算能力、内存能力、磁盘空间,那么以上规模化引起的问题也将迎刃而解。这个超级大的聚合的池化资源,就来自于构成集群的分布式系统的资源虚拟化后的能力,即云计算能力。

可视化

为了从数据集中发现整体性的规律和趋势,通过将大量数据集进行可视化,拥有一个简明的全局视角。

AI

以数据为基础,以规则集为准绳,训练机器通过基本的规则集与数据的计算而获得某种“学习”能力,从而能够分析更多的数据集,调整现实活动和方式,获得人力所无法得到的见解和经济效益。

经验与洞见

招聘或找工作的人,常常说要“工作经验多少年才行”,然而,在软件设计中,却容易“有经验而无洞见”。

经验是什么?经验是工作中遇到的问题及解决方案。有些问题,只有在规模达到足够大的时候才会出现;而大多数问题,只要根据原理就能推导出来。在软件世界里,并没有一成不变的最佳经验。

洞见是什么?洞见来自于究根追源,从最基本的公理进行推导得出定理和定律,从而能够预知问题。逻辑,本质上是一种数学结构,而数学正是能够进行推导的严密思维体系。

软件设计的洞见来自哪里 ?究根追源,软件逻辑建始于两条公理:

  • 1 + 1 = 2
  • 机器的字长有限,内存有限;执行指令需要 CPU 时钟周期

几乎所有软件问题都是这两个基本要素的组合和叠加而产生的。软件设计崇尚“自顶向下”的方式,然而,要获得洞见,却需要“自底向上”的思考和推导,通过多个层次的结构化抽象来建立。万变不离其宗。

注意到,第二条公理描述了现实系统的局限性。局限性,正是经验的用武之地。

在初期,可以 80% 依据经验,20% 依据原理;而在后期,则应该 80% 依靠原理,20% 依靠经验。那么,不依靠经验应该怎么做呢 ?举一个 API 调用的例子。可以测量这个 API 的平均耗时,耗时分布,大体了解这个 API 的对外输出指标。API 超时是因为什么呢 ?可能是网络环境波动导致。很难通过设计和开发优化环境的波动。如果不是,从 API 的实现层面来说,很可能是因为并发的大流量导致了竞争加剧,线程死锁或者大量线程阻塞。API 超时又会导致多个子系统间数据不一致。可见,并发与大流量,是系统必须要面对的“对手”。并发与大流量一定需要通过工作经验来获得吗?非也。并发与大流量的场景是可以模拟的。

可以通过原理推导,结合实验,来模拟各种现实场景,测量数据, 并制订应对方案。 这是细功夫,也是洞见的产生之源。

行走的code
行走的code

要发表评论,您必须先登录