架构思维第一篇

Posted hanruikai

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了架构思维第一篇相关的知识,希望对你有一定的参考价值。

定义与实现解耦,运行时加载实现

 

代表性实现方式就是java里面的SPI机制。比如mysql的驱动mysql-connector-java里面有个MATA-INF/services目录,里面定义具体驱动类,这些驱动类都实现Driver类接口。

如下图所示:

驱动加载类如下:

 

  • 系统的可扩展性可以遵循标准、识别、注册、运行总的法则去演化不同的具体的实现,可以根据实际的场景选择合适的方法,不再是 SPI,思维就会打开很多。如 Spring 通过 PostProcessor 开放了用户自定义的业务逻辑,它的流程也是遵循上面的八个字"标准、识别、注册、运行"
  • 什么是框架?:固定的流程,并且对用户开放业务逻辑半成品

 

固定流程+开放扩展点

 

  • 架构思维固定不变的流程,开放变化点阿里 TMF 框架中的关键思想也有类似的表述。笔者所提的可扩展性架构设计方案就是从 SPI、插件模式中获取相应的思想,然后选择合适的方法去实现。

 

系统架构定义及分类

定义及分类

  • 系统就是若干相互联系、相互作用、相互依赖的要素结合而成的,具有一定结构和功能,并处在一定环境下的有机整体
  • 系统架构 = 要素 + 连接 + 解决特定问题
  • 谈系统架构一定要指定类型,否则两个认识就不一致
  • 架构分类

业务架构 : 定义业务战略、治理、组织和关键业务流程。

数据架构 : 描述组织的逻辑与物理数据资产及数据管理资源的结构。

应用架构 : 应用之间结构和交互的描述。

技术架构 : 描述支持业务、数据和应用服务部署所需的逻辑的软件与硬件能力,包括 IT 基础设施、中间件、网络、通信、处理和标准等。

所以,聊系统架构要指定架构类型,因为不同的架构类型侧重点不一样,明显的业务架构和技术架构就不一样,业务架构偏重的是业务愿景、业务价值、业务流程;而技术架构偏重的是运用哪些技术组件来解决实际问题。

架构特性

  • 目标性:目标是我们的灯塔,指引我们向什么方向走。

  • 可分解性:这与分而治之是一样的意思,不管是系统架构在设计还是实施都具有可解性,一方面不同的人可以专注于某一方面深入研究;另一方面是可以并行工作,提升效率。

  • 层次特性:层次特性是系统架构的基本特性,像网络协议、计算机系统结构,都是有一定的层次的,所以系统架构也有这样的层次。比如在业务架构中,笔者习惯按场景层、业务能力层、业务模型层、依赖层来划分。

参考文章https://www.infoq.cn/article/fwhQ-dIN2xTUH6zNLYZp

 

架构目的

我们已经知道系统架构是什么,有必要讲一下系统架构的目的,即为什么要进行系统架构。对于简单的系统而言,可能没有什么所谓的系统架构,这里的"没有"可能对我们来讲是常识,如简单的系统分层。系统架构的本质目的从公式定义中就可以看出:解决特定的问题,这个特定的问题有技术上的问题、业务上的问题、项目管理上的问题。

架构难点

技术难点

在有些场景下,技术会成为架构的难点之一,如笔者之前在阿里店铺团队,双 11 高达十几万的 QPS,如果处理不当,可能就会导致访问的店铺页面打不开。所以,对于高并发场景,我们面临很多挑战,

业务难点

在业务架构的基础上,笔者提出业务能力地图的观点,如何让一个新人以最少的成本熟悉业务系统,除了业务系统设计得非常好,有详细的文档可参考外,还要有可视化的能力地图,从一个业务场景出发,中间涉及到的调用逻辑全部通过可视化界面展示出来,一个新人就可以很清晰地知道整个业务流程如何运转,先从宏观上理解产品、业务运转,再去看代码要轻松得多

项目难点

一个大型系统设计的业务方比较多,如果系统架构方案已经产出,剩下的就是落地执行,项目管理也有可能是我们的一个难点,如何协调资源、处理冲突、关键项目里程碑、问题跟踪和解决、上线灰度策略、业务监控…这些在系统架构设计时都要考虑到,并且在执行的过程中要有反馈。

一个项目如果没有人管理延期的风险会很大,其实大部分开发不善长做管理、沟通等事情,在一个组织里,不同的人、不同的事形成一个较复杂的环境,所以也有人说管理是一门艺术。

应对架构方法

 

  • 系统性思考

我们考虑的目标是系统,不是单一的点,所以要系统性思考。这个听起来比较虚,还是拿一个技术架构中的秒杀场景来说明。秒杀的本质是有限的资源应对大量的请求,解决这个问题资源肯定不能加大,就 100 个商品,不可能加到 10000 个商品。所以怎么应对大量的请求就是解决问题的关键点,我们可以直接从两个方面来考虑:用户和系统两个角度。用户大量的请求直接涌入,系统可能承担不住,能不能打散用户请求?系统方面能不能更快的处理用户请求,之前要 100ms 处理完的,能不能用 10ms 处理完?所以这样分析下来,从接入层、处理层、存储层考虑,而不是单一考量。

  • 分解

一个复杂的问题分而治之是一个宝贵的经验,同样在系统架构中也经常使用到,还是拿上面的例子继续说,上面从用户和系统两个角度考虑,那么从用户角度如何去做?从系统角度又该怎么去做,两个独立的可以单独拿出来设计。技术架构可以按照这种方法来做,业务架构也会使用分解的方法,业务流程的分解,分解出更小的流程,从流程中找出产物是什么。

  • 抽象

抽象这个词本身就很抽象,经常说就不知道它是什么,笔者对抽象的理解就是抽出来要像,如人在医院中重要的是身份信息+健康信息,在学校中重要的是身份信息+成绩信息,在工作中重要的是身份信息+工作经验+KPI,所以不同的场景要抽象出本质的东西来描述事物。那么复杂的一个系统,要抓住核心的点,可能核心点不超过 10 个,这样就大大降低理解的复杂度了。

  • 模式

好比写作一样,有不同的模式,架构设计也有不同的模式,这种模式是约定俗成的,一看就能理解,常见的是分层架构模式,一些比较少用的模式了解即可,把重要的精力花在常见的模式上,遵循二八原则。

用一句话概括系统架构的方法:明确我们要解决的问题,通过系统化的思考方式找到关键的点,对不同的关键点进行分而治之,再通过抽象找出要素,最后通过一定的模式表现出来

 

 

以上是关于架构思维第一篇的主要内容,如果未能解决你的问题,请参考以下文章

架构思维第一篇

架构思维第一篇

关爱青少年作品,灯塔

前端学习 linux —— 第一篇

架构设计的四大思维支柱

架构师必看:架构设计的四大思维支柱