架构设计初识

由于各种原因,好久没有写文章了。最近学习了一下架构设计方面的知识,拿来和大家分享一下。

1. 架构是什么

架构是什么,大家能都说出一二,每个人对架构的理解又不尽相同。但对于架构,我们有几个模糊相似的概念需要知道,分别是:系统与子系统,模块与组件,框架与架构。来说说这几种概念的区别。

1. 系统与子系统

1. 系统

维基百科的解释是:

系统泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能单独完成的工作的群体。

抽象成三部分,分别为:关联(有关联的个体),规则(根据某种规则运作),能力(完成个别原件不不能单独完成的工作,新能力)。

2. 子系统

根据字面意思,和系统定义相同,只是范围更小。举个例子,如淘宝系统,里面有资金,购物,会员系统等,都是一个个子系统

2. 模块与组件

模块和组件都是系统的组成部分,但是从不同的角度拆分,有了不同的名称

1. 模块

从逻辑单元拆分,得到的就是模块。主要用与职责分离

2. 组件

从物理单元拆分,得到的是组件。主要用于单元复用

3. 框架与架构

1. 框架

框架更多用于规范,如MVVC,MVP,如实现MVC的Spring框架

2. 架构

架构更多的关注的是系统的结构

2. 系统复杂度

现在,我们在设计架构或系统时,关注的点有很多,安全,可用,性能等,主要总结下来,有6点,分别是:高可用、高性能、可扩展、安全、低成本,规模。接下来对这几点进行总结。

1. 高可用

对于用户量大、访问量高、重要的系统来说,高可用总是必不可少的。高可用分为二部分,分别是计算高可用存储高可用

计算高可用主要是通过增加计算单元,如:多机部署。存储高可用主要通过备份数据,保证数据一致性,但数据间同步,又是新的问题。不管是增加计算单元,还是数据备份,都未系统带来了新的复杂性。但这些手段都是用来减少和避免不可用问题,而不是用来解决问题

2. 高性能

高性能复杂度主要体现在2个方面,分别是:单机高性能复杂度,集群高性能度。

1. 单机高性能复杂度

单机提高性能主要体现在:多线程,多进程。多线程在数据同步问题,多进程在通信方面都会带来复杂度

2. 集群高性能复杂度

集群复杂度主要体现在:任务分配,任务拆解。任务分配是在集群中,对任务如何分配是一个问题。任务拆解是因为在集群中单节点性能达到最大的时候,只有通过将任务通过过系统处理,来提高性能。

3. 可扩展

可扩展的复杂度主要体现在:预测变化,抽象在一直改变。

只有预测未来业务的变化,才能设计出可扩展的系统。如:系统是否需要分库分表,现在不需要,随着业务增长需要吗?..等等。

对系统抽象出来的代码也会随着业务的改变不停的改变,只有进行深层次抽象才能兼容多种业务逻辑。推荐多使用设计模式。设计模式主要用来将变化和稳定分离

4. 低成本

低成本复杂度主要体现在与高可用相互违背,如:高性能可能需要引入新技术,自研新框架,或增加机器,这些都会带来成本的增加。但低成本是架构设计考虑点,但不是首要点。

5. 安全

系统安全也是需要考虑。主要分为从架构层面和代码层面。

架构层面需要考虑架构是否安全,如Ddos攻击。 代码层面要考虑功能是否安全。如:Sql注入,RSS

6. 规模

规模的复杂度主要体现在:规模增大,会量变引起质变。如用户从1W变成10W,100W,就要考虑:高性能,高可用等。

3. 架构设计三原则

架构设计的主要原则体现在三方面,分别是:合适大于业界领先,简单优于复杂,演化优于一步到位。

1. 合适大于业界领先

在做架构设计的时候,要选择业务合适的,而并非业界领先的。如:设计一个学生管理系统,看到大公司都是用微服务,那我们就用是用微服务。这样并不合适,因为学生管理系统在用户量,功能上等都打不到这样的量,单机就可以,可能需要考虑数据问题,但这在数据层面解决即可

2. 简单优于复杂

在进行架构设计的时候,复杂的设计,带来的逻辑关系,或业务处理关系就会变得更复杂。如:把一个系统拆分成10个系统交互,这样带来的问题远远大于一个系统。并且复杂的系统排查问题,就需要更多的时间,花费更多的精力

3. 演化优于一步到位

任何事物是符合生物进化论的,架构设计也是如此。一开始我们设计架构,并不能就"一步登天"。主要体现在:

  • 人力,资源方便过多的投入会浪费资源
  • 业务在不断变化,并不能完全预测业务

在业务发展的的时候,会有更多的收入,这时候,再花费更多的资源,取其精华,去其糟粕,进行重构,这样也是合适的,收入和投入是成正比的。避免在一开始,进行假大空设计,到头来,业务并达不到量,浪费设计。或系统过与庞大,导致系统无法上线等问题。

4. 设计流程

设计流程主要也分了三部分,分别是:识别复杂度,设计备选方案,设计系统详细方案。

1. 识别复杂度

根据业务的需求,将目前主要的复杂问题罗列出来,根据团队,业务,技术等综合情况排序,选出最先需要解决的复杂问题。

2. 设计备选方案

在识别出系统复杂度问题后,我们就需要出设计方案,但是设计方案不能只有一套,需要设计出3-5套。设计方案太少,可能会由于自己的疏忽,见识等问题,未能覆盖复杂问题。设计的太多会影响精力,耗费大量的时间。

设计出的备选方案,需要有较大的区别,而不是一些无关紧要的区别,如:消息中间件是采用Kafka还是RocketMQ,而不是消息延迟15s还是30s。

3. 设计出系统的详细方案

在经过沟通后,选择出来一套整体看起来可行的方案,这个时候我们就需要给出更多的细节,分步骤,分方式,分系统降低系统的复杂度。在设计详细方案时,可以找出系统整体能否实施部署等问题。在根据出现问题,做出一些细节问题的修改。

4. 架构设计的目的

以上就是学习架构设计方面的知识啦,经过上面这些观察,了解,总出来一个架构设计的目的。架构设计的目的主要有两点:

  • 解决系统软件带来的复杂度问题
  • 应对业务或其他变化带来的麻烦

在做架构设计的时候,要紧紧贴合架构设计的目的,我们才能设计出够好的架构。

posted @ 2021-06-14 11:44  编号94530  阅读(35)  评论(0编辑  收藏  举报