点击上方蓝字谈思实验室
获取更多汽车网络安全资讯
在我们做系统架构设计时,如何快速的向外界传达我们的设计思路。4+1试图适合我们厘清思路、表达自己的想法。在我们汇报,争取领导层的认同支持更适合用架构图来表述我们的观点。架构图包括总体架构、逻辑架构、应用架构、技术架构、数据架构、功能架构、网络架构、运行架构等等。
总体架构基本上把下面所有的架构都体现了。下面所有的架构也都是要与总体架构保持一致。
总体架构需要说明几件事情:
整个系统的硬件设置是怎么回事?
数据大概是从哪里来,怎么采集、存储、处理、交换的?
做了哪些功能抽象,以便于支撑上层的应用?
提供哪些业务应用?管理、控制等功能有哪些?
终端用户怎么访问和使用这些应用?
该系统与外部系统是怎么进行对接的?
如何保障整个系统的安全、可靠、高质量的建设?
逻辑架构就是整体架构去掉各种保障、底层的硬件基础等非软件开发逻辑核心的内容。所以有很多简单的项目压根就不写逻辑架构,直接用总体架构就行了。复杂的,就要把上面总体架构中间分层的逻辑给写清楚一些。
关注的是功能,包含用户直接可见的功能,还有系统中隐含的功能。或者更加通俗来描述,逻辑架构更偏向我们日常所理解的“分层”,把一个项目分为“表示层、业务逻辑层、数据访问层”这样经典的“三层架构”。
逻辑架构设计的目的就是为了告诉读者,整个系统是怎么产生左右的。所谓的系统架构,主要说的就是这部分。早期的单体架构、后面的各种分层架构、微服务、服务网格等,说的都是在这里进行设计。
在设计的时候,会用到很多种设计模式,比如你看到有一个应用支撑层/服务层之类的,这就是做了一个MVC,把业务逻辑和用户前端分离。而所有的逻辑架构都有数据层,这是最早的MVP,即数据、用户视图和处理逻辑分离。当然,系统越复杂,架构图就越复杂。
企业架构框架白皮书中把架构分为了四个层次,分别是业务、应用、数据、技术。只有梳理清楚了业务,才能指导应用、数据和技术架构。业务架构的分析过程是复杂的,最终的产出可能也不仅仅只是一张架构图。还有更细节的流程、建模等产出物。一张好的架构图大概是:分层次、分模块讲清楚了各个产品模块之间的关系。
就是应用太丰富了,需要整理整理。内部有哪些应用,怎么对外部提供服务。很多项目都没有这个,因为应用比较少,不值得多废点人工单独写。用以阐述细化逻辑架构。
技术架构要干啥也就很清楚了,就是每一层,我们都用什么组件、什么技术解决什么问题。要求是:精准、明确、简练。但大体上的结构是类似的,从最底层的存储,到最上层的接口。右边是一些通用的运维体系或者支撑服务。体现出来依赖的SDK、第三方类库、中间件。
现在更多的情况,是多个系统模块,组成一个大的分布式系统,或者现存多个系统的情况下,需要进行集成开发一个产品。
这样的话,技术架构,就是高层级的技术架构了,不仅仅体现的是技术组件了,而是更高层级的一些模块,甚至规范。
数据架构其实就是从数据侧描述数据怎么来、怎么存、怎么加工、怎么使用。从数据源开始,数据通过哪些方式集成过来;集成到数仓之后,都存在哪里,数仓怎么分层,每一层都干啥;在数据集市中又怎么存、怎么管;到数据应用层又提供哪些应用。上面所有的一切,都用什么技术,什么组件,解决什么问题。系统需要什么样的数据、如何存储、如何进行数据架构设计。
部署架构也叫网络架构,就是底层服务器、网路的设计,提供网络安全、服务可靠性的设计。再简单一些理解,就是你这些应用、数据库都放在那台服务器上,这些服务器都在哪个ip端,怎么进行访问。要具体体现:机房;服务器个数、配置;网络分区关系;体现数据库、高可用;体现负载均衡;
就是前台页面的功能菜单的目录结构。你怎么组织系统的所有功能,给用户提供相应的服务。
运行架构其实就是软件内部,这些系统内部是怎么运转的,一般会画很多时序图、状态图、活动图。一般不单独画一个运行架构,而是在概要和详细设计里画。