前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >大型复杂系统的架构设计思考

大型复杂系统的架构设计思考

作者头像
架构之家
发布2022-07-12 15:39:26
6620
发布2022-07-12 15:39:26
举报
文章被收录于专栏:架构之家

一、背景

架构设计存在两类系统的设计:大型系统和简单系统的架构设计。如何进行简单系统(单系统)设计我们看到的文章很多,大型系统设计相对较少。如何进行大型系统设计?是我们今天讨论的话题。

首先,我们需要思考几个问题。

1、 大型系统和简单系统设计有什么区别?

2、 大型系统设计不就是分布式设计吗?

3、 如何进行大型系统设计?

二、大型系统与简单系统设计的区别

从系统的简易程度可以将系统分为复杂系统或简单系统。我们这里成复杂系统为大型系统,大型系统是复杂系统,一般是指规模大、复杂度高的系统。而简单系统是指规模小,复杂度也不高的系统,一般是单体,也可能是分布式架构的简单系统。简单的对比如下:

对比项/对比类型

大型系统

简单系统

系统类型

分布式系统

一般是单体系统

业务复杂度

复杂

简单

规模复杂度

复杂

简单

技术复杂度

复杂

简单

资源投入

跨部门系统

三、大型系统设计不就是分布式设计吗

通俗讲,大型系统是有多个单体系统或简单系统组成的。一般都是分布式系统。为什么不用分布式系统呢?因为分布式已经到了技术层面,而系统的设计,应该从非技术到技术。而不是本末倒置。有没有遇到这样的情况,分布式技术学了一大堆,结果没搞清楚,如何进行架构设计,难道架构就是技术的堆砌吗?

四、如何进行大型系统设计

面对复杂问题,一般采用“分而治之”的思想,将大问题分解为小问题,解决掉小问题,大问题自然迎刃而解。对于系统设计来说,就是将系统拆分到适当的粒度,再组合的过程。分布式系统,微服务架构都是“分而治之”思想的体现。事物是变化的,深一点讲,如果掌握了事物的本质,自然不必为问题而烦恼了。

一般系统的设计,需要考虑几个层面,1是业务层面,2是系统层面,3是技术层面。业务层面是把要解决的问题搞清楚,系统层面进行系统的设计,技术层面确定使用什么使用实现。

写到这里,突然发现没什么可写的了,采用分而治之思想,针对业务,系统,技术三个层面进行设计就可以了。(微笑)简单系统也是这么设计呀?(微笑)简单思考是这么回事,遇到的问题类型类似,但是设计的深度不一样,规模不一样呀。比如:管理一个公司和一个国家,都是管理,两者的管理一样吗?

以上是知道了该做什么?那怎么做呢?

4.1 大型系统的设计步骤

大型复杂系统的设计不是一开始就进行架构设计,核心也不完全是分布式技术架构。而是要从业务开始,进行逐步设计的过程。其实简单系统也是类似的逻辑,这也就是麻雀虽小,五脏俱全的道理吧。

本文的核心是想通过引入企业架构的概念,打通很多技术人员不知道如何进行设计的问题(这也是笔者进行长时间架构学习和探索的感悟)。基本的架构设计步骤,如下:

业务架构设计,系统架构设计,技术架构设计,输出解决方案,其中系统架构又包括应用架构和数据架构,以上统称为企业架构。在进行了以上设计的基础上,才会进入单系统的设计(以RUP 4+1视图为参考)。

五、业务架构

系统建设是为业务服务的,所有的系统建设都是为了解决业务问题。因此,首先做的是进行战略分析和业务架构设计。

业务架构是企业治理结构、商业能力与价值流的正式蓝图。明确定义了企业的治理结构,业务能力,业务流程、业务数据。业务能力定义企业做什么,业务流程定义企业怎么做。

(1)企业治理结构一般是指组织架构,包括组织结构,业务渠道和合作伙伴。

(2)业务能力包括价值链,功能域和功能子域。

(3)业务流程可以细分为主干流程,分支流程和业务规则。

(4)业务数据是支撑业务的简单数梳理,包括数据域,数据模型和数据规则。

六、应用架构

应用架构是一组应用系统及其交互关系的描述,每个应用系统都是一个“逻辑功能组”,用于支撑业务功能、管理数据资产。

(1)应用架构不关注应用内部的结构,主要是识别业务和数据需要哪些系统支撑。

(2)应用架构很好的体现了“分而治之”的思想,在将功能识别后,分配到不同的应用。

(3)分析业务需要支撑的功能和服务,将功能和服务分配到组件和应用,设计应用之间的交互和协作。

从服务层面对业务进行支撑,主要是识别功能和服务,划分应用系统,并完成应用系统的交互设计以及应用相关的管理工作。

七、数据架构

数据架构是设计数据资产管理蓝图,用于指导如何分析数据需求,如何进行数据架构设计。包括数据的分类和来源,逻辑数据资产,物理数据资产,数据管理,以及数据的结构和交互。

这块可能有点绕口,看着熟悉却不知道做什么。简单讲就是建立数据模型,数据存储和分布设计,进行数据的管理。

八、 技术架构

确定系统建设的技术体系,包括技术需求,技术选型,技术架构设计和技术管理等。

技术选型:平台选型(运行平台,开发平台),技术产品(框架,中间件,产品),物理选型(硬件,网络)等;

架构设计:组件架构,网络架构,部署架构等;

技术管理:技术大图,选型标准,技术案例等;

九、 解决方案

综合业务架构,应用架构,数据架构,技术架构完整整体方案的设计,可分为《业务架构》和《技术架构》两个文档,《技术架构》包含应用架构,数据架构和技术架构。

十、参考资料

本文是阅读《业务架构·应用架构·数据架构实战》以及结合过往经验和理解的总结,未深入谈具体的架构设计方案。不足之处在所难免,欢迎留言讨论。

花名:明心

多年研发和管理经验,熟悉架构设计,设计模式,分布式(微服务)系统,中间件领域,最近在学习企业架构和DDD领域驱动设计。

2021-07-10

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-07-11,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 架构之家 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
消息队列 TDMQ
消息队列 TDMQ (Tencent Distributed Message Queue)是腾讯基于 Apache Pulsar 自研的一个云原生消息中间件系列,其中包含兼容Pulsar、RabbitMQ、RocketMQ 等协议的消息队列子产品,得益于其底层计算与存储分离的架构,TDMQ 具备良好的弹性伸缩以及故障恢复能力。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档