架构设计开学第一天

2020-09-01

开篇词 | 照着做，你也能成为架构师！



每个程序员都有一个成为架构师的梦。我在大学本科的时候，以为系统架构师或者系统分析师是程序员的巅峰，也设想过去参加软考认证，不过后来……变成了咸鱼。



现在来重读这个《从零开始学架构》专栏，一方面是为参加架构师训练营热身；另一方面也知道自己距离架构师还挺远，但是并不妨碍先学一些架构设计。



架构设计的关键思维是判断和取舍，程序设计的关键思维是逻辑和实现……架构师是产品经理和程序员之间的桥梁



01 | 架构到底是指什么？



系统的定义主要在于关联、规则和能力。



系统和子系统的定义并无本质差别，源于观察角度不同，一个系统可能是另外一个更大系统的子系统。



A system is a group of interacting or interrelated entities that form a unified whole. A system is delineated by its spatial and temporal boundaries, surrounded and influenced by its environment, described by its structure and purpose and expressed in its functioning.



A subsystem is a set of elements, which is a system itself, and a component of a larger system. … A subsystem description is a system object that contains information defining the characteristics of an operating environment controlled by the system.



从逻辑角度拆分系统，得到“模块”Module，主要是为了职责分离；从物理角度拆分，得到“组件” component，目的是单元复用。



子系统和模块的区别在于，子系统能够独立运行，模块是子系统的逻辑组成部分。根据系统规模，模块也可以升级为子系统。



软件框架是提供基础功能的组件规范或产品，例如 MVP、MVVM、J2EE、Spring MVC；软件架构是软件系统的“基础结构”。



架构的四要素是：问题、模块、规则、系统。



In computer programing, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. A software framework is a universal, reusable software environment that provide particular functionality as part of a large software platform to facilitate development of software applications, products and solutions.



Software architecture refers to the high level structures of a software system and the discipline of creating such structures and system. Each structure comprises software elements, relations among them, and properties of both elements and relations. … Software architecture is about making fundamental structural choices which are costly to change once implemented.



IBM RUP 软件架构 4+1 视图：



• 逻辑视图 Logic View，面向对象模型，功能需求

• 处理视图 Process View，运行时的并发和同步，运行时质量（性能、可伸缩、安全……）

• 开发视图 Development View，开发环境下静态组织，开发期质量（可扩展、可移植、易理解……）

• 物理视图 Physical view，硬件分布，安装和部署需求

• 用户场景 Scenarios



能画好这个 4+1 视图，那么对于需求的理解也就比较到位了，其中逻辑视图和物理视图用的比较多一些。



参考资料：运用RUP 4+1视图方法进行软件架构设计



软件架构指软件系统的顶层结构



我之前对于软件架构的理解比较模糊，一方面更接近于手脚架之类的辅助框架，另一方面类似与系统的抽象结构。我觉的将框架和架构分开是比较合乎逻辑的，架构似乎更抽象一些，而框架偏向于实现。



02 | 架构设计的历史背景



按照文章的内容，简单梳理一下编程语言的发展



1. 机器语言，1940 年以前，难写、难读、难改

2. 汇编语言，20 世纪 40 年代，编写复杂，不同 CPU 指令不同

3. 高级语言，20 世纪 50 年代，Fortran、LISP、Cobol，一次编译、多处运行

4. 结构化程序设计，20世纪 60~70 年代，《GOTO 有害论》，Pascal，“自顶向下、逐步细化、模块化”

5. 面向对象，20世纪 80 年代，Simula、C++、Java、C#



第一次软件危机是因为软件的逻辑变得复杂，第二次软件危机是为了软件的扩展，那么现在还继会有软件危机么？（也许为了隐私保护，上区块链，脑洞）



只有规模庞大、逻辑复杂的系统，才需要更多的考虑软件架构的问题。我以前写过一些小的应用，简单的应用一些框架，使用默认的架构，就够用了。我觉的其实好的架构是慢慢“长”出来的，根据用户需求和系统规模的变化，不断的解决所面临的各种问题，最终形成各种“高大上”的架构。



在什么情况下会出现那种一开始就要求高可用、高性能、可扩展的软件架构？



我能想到的类似于 IBM 360 那样的大型系统有，航天工程、政府项目（例如 12306网站，或者医保系统之类）、金融管理……



其实很多现在的互联网大厂，当初起家的时候也没有想太多。



看到留言里面很多人在讨论《人月神话》，有空的时候可以重读一下。



03 | 架构设计的目的



架构设计的误区：



• 不是因为架构重要，所以要做，创业公司初始产品可能没有架构设计，没有架构的简洁开发效率可能更高，有架构不一定有业务（流量）。

• 不是每个系统都要做架构设计

• 为了满足公司流程或者是给架构师找事情做

• 为了高性能、高可用、可扩展



不过说来说去，如果是甲方爸爸要求，那么必须得认真做一份高大上的架构设计，各种新技术、新名词一个也不能少。



架构设计的主要目的是为了解决软件系统复杂度带来的问题



熟悉业务理解需求，识别系统复杂性，有针对性的解决问题，参考复杂点相似的架构设计方案。



在体制内接触过的一些项目，感觉是连需求都没有搞清楚，就盲目的迎合不懂技术的领导和喜好“高大上”的专家。



之前做过一个用户权限管理，只有不到一千个用户，每天的访问量并不大，性能要求不高，后台使用共用的 Oracle 数据库，Web 服务器使用 Windows 的 IIS。



用户数量不会激增，每日访问也相对稳定，可扩展性不重要。



权限管理系统可以宕机，但是后台的用户数据需要存储高可用，因为整个系统有 Oracle 集群，所以这一点也不需要我来考虑。



因为网络是隔离的，所以安全性方面只需要考虑用户账号密码管理和数据库访问权限即可。



成本几乎为零，只用了一台服务器，而且是与其他 Web 服务共用。



@代码荣耀 在留言里面说，需求驱动架构，这个说的真好。



另外看到老师在回复中说，一个架构师可以支撑一个 20 人以上的开发团队，那么反过来，如果开发团队人很少，那么架构师的存在感应该就不那么强，一般由技术 leader 或者项目经理兼任。



有一点好奇，架构师完成了架构设计之后，开发团队按图索骥，这个时候架构师做什么呢？这个时候可能应用还没有发布，也谈不上需求变更和流量增大。



在敏捷团队中，是否架构师的存在感更少？



题图来自：Choerodon（猪齿鱼）v0.17 中文文档