浅谈复杂业务系统的架构设计

浅谈,复杂,业务,系统,架构设计 · 浏览次数 : 101

小编点评

**复杂系统架构设计原则** **1. 重视功能拆解** * 将功能拆解成多个独立的模块。 *模块之间有依赖关系,但应该通过领域驱动进行管理。 **2. 采用领域驱动设计** * 将业务需求作为领域驱动的中心。 *领域驱动设计能自动推断依赖关系,并进行依赖管理。 **3. 微服务架构** * 将复杂系统拆分成多个独立的服务。 *服务之间可以独立进行管理,并进行纵向扩展。 **4. 云原生架构** * 将服务先天具有云上部署、提供服务的能力。 *这能确保服务的可持续性,并进行横向扩展。 **5. DevOps架构** * 将研发、运维、测试集成在自动化流程中。 *这能提升开发效率,并减少依赖的复杂性。 **6. 考虑大数据架构** * 对海量数据的处理、价值的挖掘进行设计。 *数据处理、存储、提取、计算、挖掘等能力需要通过大数据架构进行设计。 **7. 总结** * 复杂系统的架构设计需要考虑多个原则,包括功能拆解、领域驱动设计、微服务架构、云原生架构、DevOps架构、大数据架构等。 * 适当的原则能帮助您设计可持续、可扩展、易管理的复杂系统架构。

正文

作者:京东科技 皮亮

1. 什么是复杂系统

image.png
我们经常提到复杂系统,那么到底什么是复杂系统。我们看下维基的定义:复杂系统(英语:complex system),又称复合系统,是指由许多可能相互作用的组成成分所组成的系统。强调了两点:

  1. 由点组成
  2. 点之间有各种关联

image.png

两点的规模和复杂性直接决定了系统的复杂程度。比如就拿我们的电商系统举例,分成很多部分,商品、库存、采购、订单、物流、财务,这个只是大的分类,还有针对C端的营销、会员、购买、售后等体系,针对B端的商家入驻、管理等体系。各个部分、体系之间有着千丝万缕的联系,可谓之复杂系统了。当然了,远远不止这些,随着业务复杂性的不断提升,整个系统的复杂性也会愈来愈复杂。

2. 什么是架构

image.png

生活中我们经常谈及“架构”,那么到底什么是“架构”,Robert C.Martin《架构整洁之道》中的定义:软件架构是指设计软件的人为软件赋予的形状,这个形状是指系统如何被划分为组件(Components),各个组件如何排列(Arrangement),组件之间如何沟通(Communication,通讯),维基百科的定义:有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计,IEEE的定义:架构 = 组成单元的结构 + 组成单元的关系 + 原则和指南,总体来看会包括几个内容:

  1. 整体:强调部分的组成,强调合力
  2. 规则:强调部分之间有关联关系,有规则,有约束
  3. 通信:强调部分之间有往来,有交互

这样说来,我们人类社会本身就是一个社会架构,各种职责、分工、圈层,就我们的软件系统来说,DDD是架构,MVC也是架构,大数据设计也有大数据的架构。所以架构无处不在,好的架构能够对特定的问题,特定的领域起到规范和指导作用。

3. 架构的本质

image.png

我们知道,架构这个词是源于建筑行业的,英文原词是:Architecture,维基百科上的解释是规划、设计和建造建筑物的过程及产物。那我们就用建筑行业来理解一下。建房子对大家而言再熟悉不过了,那我们盖个小平层、盖个两层小高层、盖个5层小高层、搞个10层、盖个几百层的摩天大楼的过程、因素、风险是完全不同的。盖摩天大楼需要付出的成本更高,过程中的不确定性更多,挑战和风险也更大,例如如何选地、选择什么样的结构,如何承重,采光如何控制,优化、如何取暖,如何上水、排水,如何通风,如何避震等等。这些东西我们考虑的越多,房子未来的质量,可控性也会越好。

所以架构本质上就是一种指导型的约束,以约定整体和部分、部分和部分之间的关系,以使整体更加稳定,更加可靠。

image.png

4. 架构分类

image.png

我们上面举的例子我们可以叫做建筑架构,实际上架构有很多种类型,比如业务架构,应用架构,技术架构,数据架构等。单个架构分类,站在不同的维度也会有不同的看法,复杂性也会有相当大的区别。比如企业级架构能够凸显出公司的整体战略,业务涉及情况,分布情况,发力情况。而某一个单一的业务线也同样有自己的业务架构,凸显单独业务自己的业务目标、战略等。应用架构、技术架构也是同理,会有不同层面视野的架构。我们下面就以业务线内部视角对我们常见的架构分离进行下简单的说明。

4.1. 业务架构

说到业务架构,偏顶层设计了,业务的定义和划分甚至会影响到整个公司整体组织架构的设立和关系。业务架构偏向业务领域划分,模型设计,对整体业务进行语言转化,内化为领域通用语言。

4.2. 应用架构

体现应用内部的结构关系。应用如何进行设计,包括模块如何划分,功能如何实现,技术如何支撑,数据如何展示,流程如何定义,逻辑如何实现,数据如何存储等等,都是应用架构的范畴。我们经常说到的MVC、分层架构、CQRS、DDD传统洋葱圈架构、DDD六边形架构都可以归结为应用架构的范畴。

4.3. 技术架构

技术架构不一定局限于单个应用内部,尤其是当前微服务架构时代,服务之间如何交互,服务如何治理,数据如何存储,缓存如何构建等等,都是技术架构的范畴。技术架构给应用和业务架构提供了一个技术基础,以使业务更好的发展,更健壮的迭代,发展。

image.png

5. 架构需要考虑哪些因素

image.png

5.1. 功能性需求

无论是什么架构,我们第一时间考虑的一定是需要满足我们实际的业务述求的。没有需求的架构就是相当于空中楼阁,中看不中用,不切实际。这并不是真正的架构。一般来说,功能需求会直接决定业务架构,对应用和技术架构影响不大。我们的架构必须能够正确、完整地对功能性需求起到支撑作用。

5.2. 非功能性需求

架构满足功能性需求是第一要务,同时我们需要考虑能够稳定、可靠的支持功能,也就是我们同时需要满足一些非功能行需求,比如性能、可靠性、扩展性、兼容性等等。

5.3. 可靠性

为了更好的服务于功能,我们需要确保架构能够稳定、高效的运行。不会时不时的出现服务崩溃或者不可用的情况。

5.4. 可用性

同样的,服务对外要始终处于可用的状态,即使单个服务实例出现问题,我们依然可以正常的对外提供服务。

5.5. 扩展性

功能性需求不是一层不变的,尤其在当今盛行敏捷的时代,需求不是一次性提出的。我们需要对系统、服务的整体能力有全面的定位和把控。这就需要我们的架构在新的需求出现的时候,可以方便的进行扩展支持。

5.6. 治理能力

好的架构一定是方便运营、管理和监控的。甚至微观到工程管理,代码一定是易于维护、扩展、协同的。

5.7. 响应性能

一般的,功能性需求都会对性能有一定的预期。这个业务要我们在架构上做很多工作,比如读写分离、缓存、异步等等的介入,以满足整体架构的响应能力。

6. 复杂系统如何分析

有的同学会有误区,一想到类似这样的系统就觉得会有很大的复杂性,就会考虑知难而退。但是你所认为的难不一定是难。我们都知道一句熟语:“难者不会,会者不难”,往往会由于大家经验的不同,对待同一问题的想法和思路就都会不一样。这也就是为什么我们会在系统设计的时候,强调专家的重要性。尤其是目前又被逐渐提及并广泛应用的DDD领域驱动设计方法,更加提倡领域专家的重要性。这样才能够识别现实问题的复杂性和根本痛点所在,进而能够客观合理的推导出可靠、合适的解决方案。很明显,复杂系统设计中非常重要的两个环节:需求分析、架构设计。需求分析过程中,我们需要确认需求到底要解决什么问题,面向的角色有哪些。现在流行的分析方法要数DDD领域驱动的分析方法。使用DDD的模式分析业务需求大概会有几个步骤:

  1. 确认角色
  2. 确认角色功能
  3. 确认问题子域
  4. 确认模型、事件、归属
  5. 确认界限上下文

image.png

7. 复杂系统的设计原则

image.png

  1. 识别出核心问题:对于需求的承接,有些人会直接进行入开发设计阶段,尤其是对于出入职场的小伙伴。其实遇到需求我们更多的需要思考,为什么要做这个需求,这个想明白,非常有助于我们进行业务等相关的架构设计,进而掌舵整个需求。这样不会很容易的走入偏路。
  2. 复杂的问题简单化,需要把复杂的问题拆解成各个小的模块,进行逐个攻破,各个模块职责会相对单一,未来的扩展性和可维护性也相对独立、简单
  3. 确认使用通用的语言进行沟通,尤其是面向领域设计中,领域模型的认识大家一定要保持一致
  4. 理清系统、模型的定位、关系、交互等
  5. 具备未来的规划能力,包括系统、技术、方案、容量等等,以使系统能够长期更好、更稳定的提供价值服务
  6. 遵循各种设计模式,最佳实践,避免从0开始,包括:SOLID设计原则,CAP理论,BASE理论

8. 复杂系统的架构特点

image.png

8.1. 重视功能拆解,模块化设计,原子化设计

复杂系统一定要进行细致功能、模块、领域的划分。每个模块的都应该有明确,单一的职责。这样我们在分析问题的时候,可以把问题聚焦在某一个范围内,不会产生太大的影响,方便整体系统的维护和扩展。

8.2. 纵向 + 横向拓展能力至关重要

我们做小的功能的时候,可能不会考虑太多。但是复杂系统的时候,必须要考虑很多,包括未来的功能承载、流量承载、数据规模、响应要求等等,这些都需要我们在纵向或者横向留出足够的扩展能力。这些不能一蹴而就,但是需要根据规划留有必要的扩展,以使系统具有长期价值。

8.3. 架构先行

对于复杂系统,已经不是一个或几个流程图能解决的事情了。我们需要通过领域架构明确领域划分及领域边界,通过系统架构明确功能模块和功能边界,通过应用架构明确各个应用的职责、边界、结构划分、依赖关系等。通过技术架构明确我们使用的技术栈及在整体系统中的应用边界。通过数据架构明确我们的数据存储方式、结构、数据使用方式等。

这些架构一定要清晰,明确,着眼于系统长期价值。

8.4. 分而治之

对于复杂系统,拆分是必然的,大的问题化解成小的问题,根据领域、模块、功能的划分,我们把问题归属于不同的边界内,进行逐个攻破。小的问题得道解决,那么通过合理的依赖和组合,即可有效的解决大的问题,达到整个系统的建设目的。

9. 典型的复杂问题解决架构

image.png
随着社会的不断进步,信息化组件发达,我们更需要信息化的方式去解决系统化的问题。早前我们更多的通过数据驱动的模式,也就是我们会先去思考会用到什么样的结构去存储相关的数据,模型之间都有什么样依赖关系,怎么样组织数据,怎么样把数据和外围交互,这些思想也是典型的MVC架构。

MVC架构迫使我们是面向视图来开发的,我们知道视图的变化最是不可控的,越是偏向于用户的东西,越是容易受到用户主观的影响。我们知道复杂系统必然存在的纷繁复杂的依赖,依赖不可能存在于视图部分,肯定会表现为接口的依赖。对于复杂系统,我们要强迫我们转换思维,强迫我们面向接口进行设计。结合着业务系统的复杂性,如果想要系统未来具有长期价值,不得不把大的系统进行拆分,用统一的业务语言进行描述,把不可识别的问题,拆分成可识别的问题域进行解决,这也就是现在又逐渐盛行起来的领域驱动设计的方法。

9.1. 领域驱动设计

image.png
领域驱动设计,强迫我们不再用数据进行驱动,而是使用领域进行驱动。遇到问题,我们先进性领域上的划分和拆解。这个问题到底属于哪个问题域,或者需要拆解到哪些问题域,然后再通过领域的组合、依赖完成最终问题的解决。

领域驱动,早在2004年Eric Evans在《Domain-Driven Design : Tackling Complexity in the Heart of Software》(领域驱动设计:软件核心复杂性应对之道)这本书中就战略和战术两个方面进行了详细的阐述。

目前来看,对于复杂系统的设计,领域驱动的模式利于系统的可持续发展。

9.2. 微服务架构

image.png
其实微服务架构就是早些时候的SOA(面向服务架构)的一种变体。其实这个词是从2014年Martin Fowler发表的一篇文章《Are Microservices the Future》开始被业界广传而火起来的。微服务架构强调去中心化管理,尽可能的保持服务的自治性和独立性。强调能力通过不同的小的服务进行整合获取。这样我们可以对服务进行有选择的纵向和横向扩展,同时也避免了单个系统的臃肿和功能的堆叠、耦合。

9.3. 云原生架构

image.png
说到原生,大家再熟悉不过了。比如我们说IOS,Android原生界面,意味着界面是他们本来就支持的。而谈到云原生,对于服务而言,我们更多强调服务先天具有云上部署、提供服务的能力。这种能力使得服务具有先天的去中心化的能力,先天的横向扩展的能力。这也是微服务重点强调的能力。

9.4. DevOps架构

image.png
DevOps之前,我们也一直在谈敏捷,业界也有战术上的落地方案。比如极限编程、Scrum等等。如果说敏捷更多是为了解决需求、产品、研发、测试之间的协同、高效,那么DevOps更多的是在解决研发、运维间的协同问题。DevOps近年来发展的是如火如荼,这和领域驱动、微服务架构、云架构技术、虚拟化技术(尤其是Docker的发展)的发展息息相关。准确的说,是各种技术微妙组合的一种共力。DevOps的发展,是的运维不再关心应用的部署等问题,这些事情都可以交给研发来处理,运维更多的在给研发提供自动化的构建、集成、部署、监控等等相关的云基础能力。

9.5. 大数据架构

image.png

当今的是一个数字化的时代,各行各业都在忙于进行数字化的转型。对于复杂的业务系统,数据的价值尤显突出,那么自然对于海量数据的处理、价值的挖掘诉求是必然存在的。那么数据的海量存储、提取、传输、清洗、计算、挖掘等能力就需要通过大数据架构的模式进行设计。

10. 总结

image.png

现如今,系统设计的关键已经变成分布式、云化、微服务化、大数据化。架构的本质依然没有改变,只是由于社会的发展,我们的需求,需要处理的问题、依赖愈来愈复杂,我们需要用发展的眼光,时刻追随技术前沿,进而推进、优化、迭代系统的架构设计。

复杂系统的架构设计不是一蹴而就的,合适的才是正确的。希望本文能够对您在进行复杂系统设计时有一定的参考意义。

与浅谈复杂业务系统的架构设计相似的内容:

浅谈复杂业务系统的架构设计

复杂系统的架构设计不是一蹴而就的,合适的才是正确的。希望本文能够对您在进行复杂系统设计时有一定的参考意义。

浅谈常态化压测 | 京东物流技术团队

随着业务的不断增长,支撑业务系统的压力也逐渐增加,会面临如系统越来越厚重、逻辑越来复杂、迭代节奏越来越快等繁杂的情况。我们当前并没有做到在每次变化时快速识别出性能风险,检测产品或系统的稳定性、可靠性,而且我们还在不断的投入人力成本在压测这件事情上也是不合理的,所以我们要将性能验证融入到我们日常的工作中,把压测做到常态化,做成平常的一件事。

浅谈幂等设计

如今随着互联网技术快速发展,业务越来越复杂,系统的高并发和关键数据的场景越来越多。在分布式系统中,机器宕机和消息丢失也是需要重点关注的问题,其中的一个典型就是幂等性问题。

手把手带你搞定用户权限控制

在实际的软件项目开发过程中,用户权限控制可以说是所有运营系统中必不可少的一个重点功能,根据业务的复杂度,设计的时候可深可浅,但无论怎么变化,设计的思路基本都是围绕着用户、角色、菜单这三个部分展开。 如何设计一套可以精确到按钮级别的用户权限功能呢? 今天通过这篇文章一起来了解一下相关的实现逻辑,不多说

MySQL性能优化浅析及线上案例

关于数据库的性能优化其实是一个很复杂的大课题,很难通过一篇帖子讲的很全面和深刻,这也就是为什么我的标题是‘浅析’,程序员的成长一定是要付出代价和成本,因为只有真的在一线切身体会到当时的紧张和压力,对于一件事情才能印象深刻,但反之也不能太过于强调代价,如果可以通过一些别人的分享就可以规避一些自己业务的问题和错误的代价也是好的。

浅谈k8s中cni0和docker0的关系和区别

最近在复习k8s网络方面的知识,查看之前学习时整理的笔记和文档还有过往自己总结的博客之后发现一个问题,就是在有关flannel和calico这两个k8s网络插件的文章和博客中,会涉及到cni0和docker0这两个网桥设备,但是都没有明确说明他们俩之间的关系,有的甚至将两者混为一谈,这也是我之前的学

浅谈基于Web的跨平台桌面应用开发

近些年来,跨平台跨端一直是比较热门的话题,因为跨平台方案的优势十分明显。对于开发者而言,可以做到一次开发,多端复用,一套代码就能够运行在不同设备上,今天我们聊聊桌面应用开发。

什么是浅拷贝和深拷贝,如何用 js 代码实现?

〇、简介和对比 简介 浅拷贝:只复制原始对象的第一层属性值。 如果属性值是值类型,将直接复制值,本值和副本变更互不影响; 如果是引用数据类型,则复制内存地址,因此原始对象和新对象的属性指向相同的内存地址,改变任一值,另一变量值也会同步变更。 深拷贝:递归地复制原始对象的所有层级。 每一个属性值都会在

Java的深浅拷贝认识

目录浅拷贝深拷贝分辨代码里的深浅拷贝 在Java中,深拷贝和浅拷贝是对象复制的两种方式,主要区别在于对对象内部的引用类型的处理上。 浅拷贝 定义: 浅拷贝是指创建一个新的对象,但这个新对象的属性(包括引用类型的属性)仍然指向原来对象的属性。换言之,如果原对象中的属性是一个引用类型,那么浅拷贝只会复制

C#中的浅拷贝与深拷贝

## 前言 众所周知,C#中有两种类型变量:那就是**值类型**和**引用类型**。对于值类型而言,copy就相当于是全盘复制了,真正的实现了复制,属于**深拷贝**;而对于引用类型而言,一般的copy只是**浅拷贝**,只是copy到了引用对象的地址,相当于值传递了一个引用指针,==新的对象通过地