架构师应具备什么能力?

要回答这个问题,我们首先要搞清楚,为什么要做架构设计?不做行不行?

1、架构设计的目的

早在 1960 年代,诸如艾兹格·迪杰斯特拉就已经涉及软件架构这个概念了。自1990年代以来,软件架构这个概念开始越来越流行起来。

卡内基·梅隆大学的玛丽·肖(Mary Shaw)和戴维·加兰(David Garlan)对软件架构做了很多研究,他们在 1994 年的一篇文章《软件架构介绍》(An Introduction to Software Architecture)中写到:

“When systems are constructed from many components, the organization of the overall system-the software architecture-presents a new set of design problems.”

译:随着软件系统规模的增加,计算相关的算法和数据结构不再构成主要的设计问题;当系统由许多部分组成时,整个系统的组织,也就是所说的“软件架构”,导致了一系列新的设计问题。

这一系列新的问题诸如:

  • 系统规模庞大,内部耦合严重,开发效率低;
  • 系统耦合严重,牵一发动全身,后续修改和扩展困难;
  • 系统逻辑复杂,容易出问题,出问题后很难排查和修复。

可以看到,软件技术其实就是与“复杂度”作斗争的,架构的出现也不例外。简而言之,架构也是为了应对软件系统复杂度而提出的一个解决方案,通过回顾架构产生的历史背景和原因,我们可以基本推导出答案:架构设计的主要目的是为了解决软件系统复杂度带来的问题。

《第50次中国互联网络发展状况统计报告》显示,截至 2022 年 6 月,我国网民规模数达 10.51 亿。架构复杂度越来越高,已成必然。

架构复杂度主要体现在以下方面。

2、架构设计的复杂度来源

2.1 高性能

性能反应了系统的使用体验,想象一下,同样承担每秒一万次请求的两个系统,一个响应时间是毫秒级,一个响应时间在秒级别,它们带给用户的体验肯定是不同的。

高性能系统的复杂度可以概括为两个方面,一方面是单台计算机内部为了高性能带来的复杂度,涉及的技术点有:进程、进程间通信、线程等。

另一方面是多台计算机集群为了高性能带来的复杂度,涉及的技术复杂点有:任务分配、负载均衡。

2.2 高可用

高可用的关键在于“无中断”,“无中断”的难点在于:硬件故障,软件 bug,外部环境。所以,系统的高可用方案五花八门,但万变不离其宗,本质上都是通过“冗余”来实现高可用。

2.3 可扩展

设计具备良好可扩展性的系统,有两个基本条件:正确预测变化、完美封装变化。但要达成这两个条件,本身也是一件复杂的事情。

2.4 低成本

低成本本质上是与高性能和高可用冲突的,所以低成本很多时候不会是架构设计的首要目标,而是架构设计的附加约束。

2.5 安全性

安全本身是一个庞大而又复杂的技术领域,从技术的角度来讲,安全可以分为两类:一类是功能上的安全,例如,常见的 XSS 攻击、CSRF 攻击、SQL 注入、Windows 漏洞、密码破解等;

另一类是架构上的安全,传统的架构安全主要依靠防火墙,但在互联网领域,防火墙的应用场景并不多。互联网系统的架构安全目前并没有太好的设计手段来实现,更多地是依靠运营商或者云服务商强大的带宽和流量清洗的能力,较少自己来设计和实现。

2.6 规模

规模带来复杂度的主要原因就是“量变引起质变”,当数量超过一定的阈值后,复杂度会发生质的变化。常见的规模带来的复杂度有:

  • 功能越来越多,导致系统复杂度指数级上升。
  • 数据越来越多,系统复杂度发生质变。大数据就是在这种背景下诞生的。

3、架构师应具备什么能力?

围绕上述复杂度问题,程序员们来施展拳脚,能解决就是优秀的架构师。具体来说,可以往下面几个方面进行修炼。

3.1 透过问题看本质的能力

透过问题看本质是由事物的表象到实质,往深层次挖掘。比如,看到一段 Java 代码,知道它在 JVM 中如何执行;一个跨网络调用,知道数据是如何通过各种介质(比如网卡端口)到达目标位置。

3.2 多领域知识和技术前瞻性

架构师要有技术的广度(多领域知识)和深度(技术前瞻)。对主流公司的系统设计非常了解,知道优劣长短,碰到实际问题,很快就能提供多种方案供评估。

3.3 沟通交流

能落地的架构才是好架构,架构师还需要具备良好的沟通能力,能确保各方对架构达成共识,愿意采取一致的行动。

最后

引用《火影忍者》里面的一句话:并不是成为火影的人就会被大家所认可,而是被大家所认可的人才能成为火影。(被程序员们认可的人,才能成为架构师。)

与你共勉!

参考

架构师应具备什么能力?

https://studeyang.tech/2023/1.html

作者

Studeyang

发布于

2023-01-07

更新于

2023-06-17

许可协议

评论