重零开始学架构读后感小结
2022/6/8
软件架构指软件系统的顶层结构。每个程序员心中 都有一个成为架构师的梦想 , 梦想是美好的,但道路是曲折的 。
架构设计的关键思维是 判断和取舍, 程序设计的关键思维是 逻辑和实现 。
架构设计三原则
- 合适原则一一合适优于业界领先;
- 简单原 则一一简单优于复杂;
- 演化原则一一演化优于一步到位;
架构从来不是一成不变的,架构也没有一劳永逸 。 Facebook 每隔 3~ 5 年就会重新设计 一 次架构,就像凤凰重生 。 诚如 《三体 》 所传达的思想,与其维护 一个旧世界,不如开创一个 新世界。
技术的本质定义:
新技术都是在现奇技术的基础上发展起来的,现有技术又来源于先前的技术。将技术进行功能性分组 ,可以大大简化设计过程,这是技术“模块化”的首要原因。技术的“组合”和“递归”特征,将彻底改变我们对技术本质的认识。
模块?组件?
从逻辑的角度来拆分后得到的单元就是“模块”,从物理的角度来拆分系统得到的单元就是“组件”; 划分模块的主要目的是职责分离,划分组件 的主要目的是单元复用 。
结构化程序设计的主要特点是抛弃 goto 语句,采取“自顶向下、逐步细化、模块化”的指
导思想。(结构化程序设计本质上还是 一种面向过程的设计思想,但通过“自顶向下、逐步细化、模块化”的方法,将软件的复杂度控制在 一 定范围内,从而从整体上降低了软件开发的复杂度。)
20 世纪 60 年代第一次软件危机引出了“结构化编程”, 创造了“模块”概念; 20世纪 80年代第二次软件危机引出了“面向对象编程”,创造了“对象” 概念 ; 到了 20 世纪 90 年代“软件架构”开始流行,创造了“组件”概念。
我们可以看到,“模 块”、“对象”、“组件”本质上都是对达到一定规模的软件进行拆分, 差别只是 在于随着软件的复杂度不断增加,拆分的粒度越来越粗,拆分的角度越来越高 。
软件框架
软件框架( Software Framework )通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范, 也指为了实现某个软件组件规范肘, 提供规范所要求之基础功能的软件产晶。
- 框架提供基础功能的产品 。 例如, SpringMVC 是 MVC 的开发框架,除了满足 MVC 的规范, Spring 提供了很多基础功能来帮助我们实现功能,包括注解(@ Controller 等)、 Spring Security、 Spring JPA 等很多基础功能 。
- 框架是组件规范。例如,MVC就是一种最常见的开发规范,类似的还有 MVP、MVVM、J2EE 等框架 。
抉择
在做架构设计的时候,需要花费很大的精力来结合业务进行分析、判断、选择、组合,这个过程同样很复杂。这些技术并不是最新的就是最好的,也不是非此即彼的选择。
一个最简单的例子:
Nginx 可以用多进程,也可以用多线程, JBoss 采用的是多线程, Redis 采用的是单进程, Memcache 采用的是多线程,这些系统都实现了高性能,但内部实现差异却很大。
系统的高可用方案五花八门,但万变不离其宗 , 本质上都是 通过 “冗余” 来实现高可用。高性能增加机器的目的在于“扩展” 处理性 能 ; 高可用增加机器的目的在于“冗余”处理单元。
无论引入新技术,还是自己创造新技术,都是一件复杂的事情。引入新技术的主要复杂度
在于需要去熟悉新技术,并且将新技术与己有技术结合起来;创造新技术的主要复杂度在于需
要自己去创造全新的理念和技术,并且新技术跟旧技术相比,需要有质的飞跃。
阿里中间件团队 2008 年成立,发展到现在己经有十年了 。我们 只知道他们抗住了 多少次“双 11”,做了多少优秀的系统,但经历了什么 样的挑战、踩了什么样的坑,只有他们自己知道 ! 这些 挑战和踩坑,都是架构设计非常 关键 的促进因素,单纯靠拍脑袋或头脑风暴,是不可能和真正实战遇到挑战和问题同日而语的 。
业界领先的方案其实都是“逼”出来的!简单来说,"业务”发展到 一定 阶段, 量变导致了质变,出现了新的问题,己有的方式已经不能应对这些问题,需要用 一种新的方案来解决,通过创新和尝试,才有了业界领先的方案。
无论结构的复杂性,还是逻辑的复杂性,都会存在各种 问题,所以架构设计时 如果简单的方案和复杂 的方案都可以满足需求,一定要选择简单的方案,《UNIX 编程艺术》总结的 KISS (Keep It Simple,Stupid!)原则一样适应于架构设计。
对于建筑来说,永恒是主题,而对于软件来说,变化才是主题。
评论区