0
点赞
收藏
分享

微信扫一扫

交易系统TMF2.0技术揭秘:跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路...

交易系统TMF2.0技术揭秘:跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路..._数据库


总体介绍

2017年双11,交易峰值达到了32.5万笔/秒,这给整个交易系统带来了非常大的挑战。一方面,系统需要支撑全集团几十个事业部的所有交易类需求:要考虑如何能更快响应需求、加快发布周期;如何能为新小业务提供快速支撑、降低准入门槛;是否足够开放使得业务方能做到自助式扩展;新需求是否已经在其他事业部有可复用资产等问题。

互联网的特点决定了业务系统是按领域服务建设的分布式架构。而电商业务的特点是业务生命周期长,从招商、选品、供应链、仓储、营销/导购、下单、履约、物流、售后等,其业务链路长、业务逻辑上游对下游又有影响。在这业务主线的链路上,又建设了众多系统进行支撑,比如商品平台、购物车系统、下单系统、履约系统、优惠系统、物流系统、供应链系统等,围绕这些核心系统,还有数不清的辅助系统/服务,比如服务平台、天猫SMC、淘宝CPC等等。

在每一次的业务需求分析过程中,又是需要能从业务生命周期的全链路视角进行需求分析、技术方案评估、编码、联调以及发布。这整个过程,也是一次复杂的跨团队协助过程,痛点主要体现在:

1)缺少全链路视角的需求管理机制,协同效率低 

2)平台准入门槛高,新小业务无法快速试错 

3)业务与平台没有很好分离,无法支撑业务自助式(Self-Service)发展 

4)缺少可复用业务资产。

痛点一: 缺少业务全链路视角的需求管理机制,协同效率低

对业务需求的跟踪与管理缺少全业务链路视角,主要体现在:

需求的描述往往就是一句话。详细的需求描述基本都是靠后期的一些文档、邮件以及组织需求澄清会的形式进行讲解。在讲解时,会尽可能拉上能想得到的可能会相关的平台开发同学,场面蔚为壮观。

需求传递低效,需要反复沟通。业务需求在建模与分解过程中,缺少有效传递载体和形式,不能准确无缝传递到开发,导致反复沟通澄清与需求返工以及重复工作量。

平台能力缺少透出,技术方案评估花费时间长。技术同学在评估需求实现对平台的改动点时,由于平台能力缺少透出,业务与平台代码没有分离,导致技术方案评估时,很难一下评估出针对新续期,现有平台有什么能力可以服用?改动对现有哪些业务会有影响?对相关的周边哪些系统有影响?工作量有多少? 这些基本都需要事后去反复翻代码分析评估。

类似需求重复建设。 需求发布上线后,随着时间的推移,人员的更换。就没有人知道这个需求当时是如何实现的?遇到类似需求的方案评估,又只能翻代码,或者重复实现一次。

痛点二:平台准入门槛高,新小业务无法快速试错

新小业务都有一个成长规律,在早期业务模式验证阶段,需要的玩法比较简单,希望能频繁的发布快速试错。但共享的交易平台、商品平台、营销平台等虽然能支持各种业务模式与营销玩法。但对于新小业务而言,这些在早期并不适用,他们希望平台能灵活裁剪,比如:

1)下单流程是否能裁剪成极简流程,而不是必须走完整流程 

2)与其他业务代码在运行期分离,不希望对其他业务或者被其他业务所影响 

3)业务发布节奏可以自行控制,不希望等待每周一次的全网回归

痛点三:业务与平台没有很好分离,无法支撑业务自助式(Self-Service)发展

阿里电商业务五花八门,各部门的定位也不一样,有的定位于是面向“垂直”行业的,比如天猫汽车业务、盒马生鲜业务、航旅业务等;而有的又是定位于面向对所有行业支撑的平台业务,如聚划算、导购宝等。 所以,业务本身会分成“垂直”和“水平”两个维度。在一次业务交互过程中,其业务复杂度就在于业务“垂直”维度与“水平”维度产生的叠加,并由叠加而产生的业务规则上的冲突。

针对业务叠加的处理,各系统基本上还是基于SPI扩展机制,这些SPI缺少按照业务维度进行组织与隔离。在业务种类少,不同业务在逻辑叠加度小的情况下还是可以在很大程度上解决业务可定制化、多样化的问题。但随着各类业务越来越多时,就会导致各类业务在同一个扩展点上的叠加效应越来越突出。其中最薄弱的点就是 SPI接口中是否需要执行的过滤方法(filter)的编写。一旦过滤方法写得不好,就可能会造成不该执行的逻辑被执行了,或者把后续本该执行的逻辑给跳过了。

在共享的各个平台中,提供给业务方可扩展的SPI多达几百个。一个业务的最终逻辑是否正确,就需要该业务确保这几百个SPI决策树中每个节点注册的位置正确,过滤方法中的过滤条件正确,同时执行逻辑也必须确。不仅如此,本业务注册的SPI都正确了,还需要其他的业务注册的SPI也都是正确的,这最终导致了业务与业务之间高度耦合。这种耦合,又进一步导致了各业务方之间、业务方与平台之间的大量联调、集成与回归等配合工作,无法做到自助式的业务设计、开发与交付。

痛点四:缺少可复用业务资产

一个企业的IT体系建设是否成熟,业界是有一些指导框架来进行评估的,比如TOGAF框架。在该信息系统建设框架中,有一个很重要的系统成熟度评估项目 —— Enterprise Continumm(企业统一体)。


交易系统TMF2.0技术揭秘:跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路..._编程语言_02


这里面的关键是企业需要建立:

架构统一体(Architecture Continuum): 该统一体能从特定架构中提取出可复用的组件到仓库中(Reposity),为后续的类似业务的重用(Gerneralization for future re-use)。在具体应用中,可以从组件仓库中选择可复用的组件并进行与实际应用场景适配(Adaptation for use)。

解决方案统一体(Solutions Continuum):与架构统一体类似,在面对不同的市场,需要能从可复用的解决方案库中选择并快速复制。对于新兴市场的交付,也能提取成可复用的解决方案到资产库中。

经过多年的发展,我们在淘宝、天猫国内市场中,我们 有各种各样的业务支撑工具与玩法,比如,电子凭证、预售、购物券、红包等等,在面对国际化市场交付时,是否能做到业务模式的快速复用?

解决这些问题的思路

整个电商体系涉及的应用高达7000+:要考虑需求的评估是否具有全链路视角;业务需求的技术评估是否分析全面、技术方案的影响范围是否评估到位;业务的全链路稳定性保障、调用链路监控、强弱依赖等问题。此外面对每天几百个业务需求,500+个独立的发布变更:要考虑各业务方的需求发布是否会相互产生影响;需求代码是否对平台有侵入、导致平台腐化;高频率的需求发布下如何管控质量;能否按业务维度进行业务监控、故障分析等等。

面对这些挑战,TMF2.0框架需要解决的六大关键问题:

业务全链路可视:业务分析人员和技术人员能基于同一套业务语言以全链路可视化方式进行需求讨论、影响分析以及技术方案评估,在业务视图上看到的规则就是实际在运行系统上运行的规则。在对大规模的业务交付支撑场景下,业务可视化对于效率提升是非常必要的。

需求结构化:基于透出的业务能力、已有的业务规则完成需求结构化分解降低沟通成本。

业务配置化:这是可视化的前提,要在需求明确的情况下在线配置业务、快速发布上线。

业务测试一体化:根据修改的代码进行自动化用例筛选、自动化测试。

业务监控:以精细化的业务维度进行监控,而不仅仅局限于交易大盘。

故障排查:当业务故障时快速拿到故障快照、还原故障现场以及迅速定位问题原因。

TMF2.0 关键设计思想

针对上面提到的问题,TMF2在架构设计上主要的思想是:

业务包与平台分离的插件化架构:平台提供插件包注册机制,实现业务方插件包在运行期的注册。业务代码只允许存在于插件包中,与平台代码严格分离。业务包的代码配置库也与平台的代码库分离,通过二方包的方式,提供给容器加载。

全链路统一的业务身份: 平台需要能有按“业务身份”进行业务与业务之间逻辑隔离的能力,而不是传统SPI架构不区分业务身份,简单过滤的方式。如何设计这个业务身份,也成为业务间隔离架构的关键。

管理域与运行域分离:业务逻辑不能依靠运行期动态计算,要能在静态期进行定义并可视化呈现。业务定义中出现的规则叠加冲突,也在静态器进行冲突决策。在运行期,严格按照静态器定义的业务规则、冲突决策策略执行。

业务包与平台分离的插件化架构


交易系统TMF2.0技术揭秘:跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路..._编程语言_03


如上所示的业务定制包与平台分离架构可以分为三个层次。最底层是业务规范层,包括一些交易模型、交易领域的划分、业务领域的划分、以及交易启动环境下的配置项。基于这个理论模型,就可以进行一些定义及规范工作,比如接口定义、流程规范、模型规范等,而且其中的很多内容都可以在不同的领域进行复用。

业务规范层之上是解决方案层。大家都知道阿里巴巴目前正在走国际化的战略,所以面对不同的市场会构建不同的解决方案,不同的解决方案中也就有自己不同的业务玩法、业务逻辑。所以要将不同的市场解决方案和他们自身的流程、规则结合起来。但是这一过程中会发现,不同的市场解决方案会有很多可以复用的地方,比如营销模式。所以形成的可复用基础实现就可以在不同的解决方案中得到复用,所那么在面对不同的市场时就不用考虑可复用基础实现的内容,只需要关注市场相关的业务就可以了。

再往上一层是业务定制层。即使是在一个市场内,也会有各种细分的定制玩法,这些不同的细分点就会有各自不同的业务逻辑,这就是制定业务定制层的原因。团队会根据底层的需求点来进行一些业务定制包的组装,就可以实现不同的业务逻辑和玩法了。

在这样一个复杂的分离架构中,最重要的是要将不同层次间的职责划分清晰,整个代码都严格地、有意识地进行分离。所以在最后的部署过程中,首先要完成底层业务的复用,然后形成不同市场的解决方案,再在解决方案下对不同的业务实现差异化的点。

全链路统一的业务身份

上面所讲的是业务和平台的分离,在业务和平台分离之后就要进行业务和业务之间的隔离,即统一的业务身份,类似于身份证号码,在整个交易链路上必须是唯一的。业务身份需要通过人、货、场三个维度进行抽象,比如市场类型、垂直市场、渠道来源等等,确定了这个唯一的业务身份后就可以将业务流程和业务规则进行关联。

基于业务识别,团队也提供了一个基于UIL的业务身份识别方案,总体设计基于标准模型来抽象,自定义语法,统一管理模型。事实上,通过样品模型、买家模型、卖家模型、类目模型这四个维度,99%的商品都可以有效地进行标识。业务身份确定后,就可以按照业务身份维度,对业务配置、部署进行统一管理,在这其中要注意配置隔离性、热部署、配置回滚、配置确定性等核心要素。

业务管理域与运行域分离


交易系统TMF2.0技术揭秘:跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路..._数据库_04


业务身份确定后就要进行业务定义,这其中就涉及管理域和运行域分离的问题。管理域就是指对业务生命周期、业务身份、业务对象进行定义,包括业务流程、业务管理等。这些操作完成之后就会将配置文件下发到,运行域上的各种平台就会自动解析配置域所下发的配置文件,然后将配置文件解析成业务命令来执行。

在上面所讲的业务域中,一个核心的问题就是如何定义业务:核心三要素是业务身份、业务叠加关系、冲突决策,即基于业务协议标准定义业务,执行单元按协议执行业务逻辑。


交易系统TMF2.0技术揭秘:跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路..._人工智能_05


在业务叠加关系中,业务的复杂度就在于业务规则在不同维度下产生的冲突。业务的复杂度可以分为两个维度,一个是横向维度,一个是垂直维度。

垂直维度,也可称之为“行业”。往往一个特定的“业务对象”(如商品),在静态期就能确认其具体归属于哪个行业。行业与行业之间的业务规则是不会有叠加的。比如,付款超时时间,各可以设置为1天超时。但“天猫汽车”把超时时间改了,一定不会联动改其他业务的超时设置。横向维度,也称为产品维度,特点有:产品是可以被多个垂直业务所使用的、一个垂直业务是可以使用多个产品的、产品是否生效是需要结合业务会话的。比如,“电子凭证”是否生效,要看用户是否选择了“电子凭证”的交付方式。

通过业务复杂度的分析,可以得出一个结论是:一次业务会话完整的规则=1个垂直业务规则集合+ N个水平业务规则集。所以在做业务定义和管理的时候,具体就是在管某一个垂直业务是和哪些横向业务在叠加。在叠加之后产生的业务冲突又是怎么解决的?要基于这一点进行业务管理。这是比较关键的一点。

TMF2.0 关键模型介绍

下面详细阐述一下TMF 2.0的关键模型,主要包括业务配置主线和业务运行主线。


交易系统TMF2.0技术揭秘:跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路..._java_06


在业务配置主线中,由项目的业务PD来看一下当前业务涉及到哪些业务域,以及这些业务域下面有哪些功能和产品可以去使用,哪些业务点是可以去扩展的。这其中就需要能力域模型的支撑,通过这个模型所透出的结构化数据,来研究平台中每个域具备的能力、每个能力具有的可变点,从而有针对性地进行设置。在配置模型里,通过关键的视图模板,进行模板透出,然后保存、下发配置数据到业务运行主线。业务配置主线和业务运行主线是相交互的。

基于TMF 2.0关键模型,整个交易平台实现了业务定义可视、可管、可配。业务定义可视化包括系统能力可视化、业务流程可视化、业务规则可视化、产品叠加可视化等;业务可配置,所见即所得的业务规则可配置能力,凡是基于TMF2标准构建的系统均立刻可获取业务可配置能力,不需做额外的开发;配置版本化,针对业务配置有完善的版本化管理机制,配置推送可实现按版本快速生效或者回退;业务多租户管理,不同的业务系统之间可以通过租户完全隔离的。不同的租户有自己的数据空间,以及配置推送策略。

面向业务维度的运维 & 稳定性保障

当业务与平台分离并且具有业务身份的识别后,我们就可以从业务维度进行可靠性保障,主要有:1)按业务维度进行故障监控 2)按业务维度分集群部署 3)按业务维度做稳定性保障 等。

1) 按业务维度进行故障监控

在过去没有做到业务身份识别时,每天的交易大盘监控还比较粗放,只能去从整体去监控交易量趋势。有些业务,特别是一些新小业务,其早期交易量非常小。即使因为故障交易跌零了,从交易大盘上也无法即使监控到,只有等到客户投诉了才发现有故障发生。

基于TMF2构建的业务系统,因为有“业务身份”的标示,我们就可以将业务身份标示贯穿整个接口调用链路以及写入日志中。并在各类监控大盘中,可以针对业务维度进行分组展现。

2) 按业务维度分集群部署

过去淘宝、天猫所有的交易,都是通过同一套BUY、TP进行下单并履约的。当某个业务有新需求或者故障解决等原因,要进行升级部署时,就不可避免的将所有机器都分批进行升级部署。每一次升级发布,都是一次变更行为,只要有变更就可能会产生新的故障。

基于TMF2构建的业务系统,因为有“业务身份”的识别。我们就可以根据业务身份做前置路由。给不同的业务身份分配不同的集群,并按集群去分别部署业务。从物理的隔离,在满足一些业务快速迭代发布的诉求下,还能保障业务的稳定性。

3) 按业务维度做稳定性保障

过去在没有业务身份的识别下,在做性能优化、大促保障时,是没法按业务维度用不同的QoS策略进行差异化的大促保障。比如,无法按照业务维度进行流量分配进行限流、无法按照业务维度建立性能基线并进行性能劣化监控等。业务平台目前正在做的天秤项目,与过去单纯监控物理指标不一样的地方,就是在于能按照业务进行场景化监控。例如:

可以按业务维度建立各业务在各个调用场景下的性能基线,如RT、QPS等,一旦某次发布和预设基线有重大差异,就能快速找到性能劣化的业务并进行改进

可以按业务维度建立外部服务调用的强弱依赖关系,结合强弱依赖关系可制定全局以及业务维度的各种预案开关。

可以按全局或者业务维度,构建全局调用链路监控大盘。

交易平台改造效果

业务需求平均开发周期缩短至12天: 比如汽车4S服务中,在老系统上做了一个月(未完成),新系统7天完成;五道口业务中,在老系统中评估工作量两个月,新系统12个工作日完成;饿了么业务中,老系统评估要两周,基于新系统2天完成。

平台与业务解耦: 目前已完成的业务,其业务定制均只存在于业务包;在平台未改动情况下,业务方的发布更加灵活(有多次单业务发布,不需要其他业务方进行回归的案例)。

业务资产库: 积累形成了50+业务资产库,新业务可快速进行快速复制、调整并发布。

原文:​​如何实现32.5万笔/秒的交易峰值?阿里交易系统TMF2.0技术揭秘​​

复杂业务系统的架构设计思路

做技术方案,核心是下面几个问题:

做什么?- 产品需求

业务上怎么做?- 业务文档

技术上怎么做?- 技术方案

代码怎么实现?- 落地实现

明确了这几个问题,可以处理大部分日常需求开发,如果是比较复杂的业务系统,就需要拆解的更精细。

比如电商的商品管理、订单交易等系统的开发和重构,业务相对复杂,开发人天在几个月以上,直接开发可能会老虎啃天,无从下手。

这时候可以通过一个流程化的模板来指导,如果抽象一个通用的流程,可以参考下面的套路:

业务拆解 > 复杂度来源 > 核心挑战点 

领域驱动设计 > 业务过程分析 > 领域模型抽象 > 模型分解

分层组织 > 工程架构 > 模块化 > 组件化

考虑功能复用 > 可选路径 —( 业务身份,能力,扩展点,工作流程,编排)

方案产出 >  整体-模块-流程-细节 > 方案评审 > 最终方案

其中的功能复用环节,是包括阿里在内的大部分业务中台的解决思路,仅供参考。

一、业务拆解

1.1 复杂度来源

为什么要关注复杂度?

架构设计的目的是为了解决软件系统的复杂度带来的问题。

所以在设计架构时,首先就要分析系统的复杂度。

只有正确分析出了系统的复杂性,后续的架构设计方案才不会偏离方向;否则,如果对系统的复杂性判断错误,即使后续的架构设计方案再完美再先进,都是南辕北辙,做的越好,错的越多、越离谱。

举个例子,医院管理应用的医疗管理系统(HIS),复杂度在于业务逻辑复杂,系统之间调用不清晰,如果你设计一个QPS几万的高性能架构,就是没有解决系统的核心问题。

正确的做法是将主要的复杂度问题列出来,然后根据业务、技术、团队等综合情况进行排序,优先解决当前面临的最主要的复杂度问题。

1.2 核心挑战点

射人先射马,擒贼先擒王。

确定了复杂度,也就确定了系统设计的难点,在进行系统设计时,可以把难点列出来,各个击破。 

以电商促销为例,促销活动最大的复杂度来自营销形态的变化,营销最大的不变就是变,乱花渐欲迷人眼,各类促销方式千变万化。

每次促销活动都有不同的玩法和定义,促销系统的设计必须对促销模式有所抽象,任何活动或优惠手段都是基于最基本的促销模式而建立的。

电商营销中心建设难点包括:

底层模型抽象:底层模型抽象可以通过DDD的方式,对领域模型和进行抽象。

促销引擎性能:性能问题如何解决?已经是老生常谈,工程领域有很多经典的解决方案,比如缓存,异步,最终一致性。

关联系统交互:理清和关联系统的交互

二、领域驱动设计

软件系统的目的反映在业务上,都是来解决一系列问题,例如考试系统完成考试,电商就是卖货,同一个领域的系统都具有相同的核心业务,因为他们要解决的问题的本质是类似的,一个领域本质上可以理解为一个问题域 。

只要确定了系统所属的领域,那么这个系统的核心业务,即要解决的关键问题就基本确定了。

任何一个系统都会属于某个特定的领域,例如论坛系统,核心功能是确定的,比如用户发帖,回帖等基本功能。广义的电商系统也是一个领域,做电商业务,必须要支持的商品,订单,交易,物流等功能。

DDD里有领域专家的概念,领域专家要在这个领域深入研究,只有这样才会遇到非常多的该领域的问题,积累比较更加丰富的经验。

通常来说,一个领域有且只有一个核心问题,也就是核心子域。在核心子域、通用子域、支撑子域梳理的同时,会定义出子域中的限界上下文及其关系,用它来阐述子域之间的关系 。

以电商营销为例,优惠券、抽奖、套餐等,都是围绕这个促销这个业务范围来进行的,在促销域之外,还有相关的用户、商品、订单、风控、商家等。

三、架构分层

3.1 架构分层

下图是领域驱动设计中经典的分层架构:

下图为 Eric Evans 在其经典著作《领域驱动设计》中的分层架构:


交易系统TMF2.0技术揭秘:跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路..._编程语言_07

交易系统TMF2.0技术揭秘:跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路..._大数据_08


三层架构:


交易系统TMF2.0技术揭秘:跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路..._大数据_09

交易系统TMF2.0技术揭秘:跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路..._java_10


整洁架构(Clean Architecture)


交易系统TMF2.0技术揭秘:跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路..._java_11


Robert Martin 的整洁架构将领域模型放在整个系统的核心,这一方面体现了领域模型的重要性,另外一方面也说明了领域模型应该与具体的技术实现无关。领域模型就是业务逻辑的模型,它应该是完全纯粹的,无论你选择什么框架,什么数据库,或者什么通信技术,按照整洁架构的思想都不应该去污染领域模型。如果以 Java 语言来实现,遵循整洁架构的设计思想,则所有领域模型对象都应该是 POJO(Plain Ordinary Java Object)(具有领域逻辑的 POJO 对象)。


交易系统TMF2.0技术揭秘:跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路..._人工智能_12

交易系统TMF2.0技术揭秘:跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路..._编程语言_13


3.2 工程架构

DDD的核心诉求就是将业务架构映射到系统架构上,在响应业务变化调整业务架构时,也随之变化系统架构。 微服务追求业务层面的复用,设计出来的系统架构和业务一致,不过领域模型并不直接反映数据结构,需要明确这一点。领域驱动设计最后落地到数据存储上,不需要直接参考领域模型,在最后的技术架构上可以自由选择合适的技术架构。

3.3 模块组织

Java项目一般是典型的Maven多模块项目,可以使用不同的Module,区分各个层次,进一步,通过Package来控制DDD中的限界上下文。

四、功能复用

4.1 编程DRY原则

大家都知道,编写整洁代码,有一个非常重要的原则就是DRY,Don't Repeat Yourself,避免产生重复代码,有经验的程序员都能够意识到这一条约束。

如果你使用Idea开发,Idea也会识别并且提示你重复的代码,建议你进行抽象。

DRY的好处更少的代码是好的,它节省了时间和精力,易于维护,并且减少了bug的几率。

除了在软件开发领域,在业务系统层面,也存在如何避免重复能力建设,考虑业务复用的问题。

4.2 业务层面的DRY

业务系统层面的DRY原则,其实可以总结为一个问题,就是复杂业务系统,如何实现具有共性的业务能力的复用,这个也是很多业务中台关注的问题。

一般的,大部分业务中台(特指业务中台,不包括数据中台等其他形态)对业务复用的方式,

都可以通过定义业务身份 ——>  梳理扩展点 ——> 枚举业务能力 ——> 根据不同业务身份编排工作流 ——> 实现业务能力复用,这样的流程来实现。

可以对比编程中的Pipeline模式,或者责任链模式,只不过每个链条上负责处理输入和输出的,是不同的业务功能。

业务中台是另一个话题,这部分是发散思考,具体可以参考阿里巴巴 TMF (Trade Mudule Framework)框架的介绍:

如何实现32.5万笔/秒的交易峰值?阿里交易系统TMF2.0技术揭秘

五、可扩展性和过度设计如何平衡

好的架构设计一定是扩展简单的。在设计时,要尽量封装可能的变化,在业务流程发生一些调整时,能够比较方便地修改系统程序模块或组件间的调用关系而实现新的需求,也就是我们常说的可扩展性。

但是可扩展性本身也是系统设计的复杂度来源之一,这就涉及到一个问题,如何平衡可扩展和过度设计。

5.1 区分确定性和变化

好的架构一定是扩展简单,运行平稳的。

系统架构最开始可以从一个通用的流程开始,case-by-case,然后将「变化少」的部分沉淀下来为架构,将「变化多」的沉淀为扩展或者配置,梳理清楚,将这两者结合起来,最后完成系统架构设计。

5.2 用容量规划的方式来处理扩展程度

可以使用容量规划的思想,来处理可扩展性设计。

在做技术方案时,容量规划是一个特别重要的环节,要预估未来几年的增长量,进行数据库和缓存的容量规划。

我觉得这个方式也可以应用在扩展性设计上,对业务变化进行预期,考虑技术方案能够支持的业务发展时间。

六、方案评审

好的技术方案很难一蹴而就,大部分时候要经过反复的调整,就是需要关联的各方参与方案的评审和修改,最终确定最终技术方案。

七、总结

复杂业务系统开发的一些体会:

熟悉业务,抽象产品需求,分析相关测试用例,了解各种用户角色和其使用的场景

自顶向下进行方案设计,对于比较复杂的业务系统,比较好的方式是先关注顶层模型,避免在一开始就陷入技术和业务细节中去

从整体设计,到模块局部规划,设计好部署架构、分层和分模块、API设计、数据库设计等

可以参考成熟的解决方案,比如将开源软件,改造,变成适合自己业务需求的架构

验证和优化架构设计方案,完整的架构设计方案,需要有多次的评审,充分收集各方面的反馈,反复修改后确定

合理进行扩展,考虑架构预期能满足多长时间的业务增长,比如未来一年的业务变化。

参考资料:

​​https://baijiahao.baidu.com/s?id=1658157066668484115&wfr=spider&for=pc​​


举报

相关推荐

0 条评论