文章目录

前言
软件架构是什么？
- 软件架构定义
- - 元素、关系、属性
为什么合适的架构很重要？
- 架构是系统的骨架，而又不仅仅是骨架
- 架构影响质量
- 架构与系统功能互相独立(基本上)
- 架构约束程序
- 架构设计的目标
- - 问题在哪里？
分治、知识、抽象
- 分治
- 知识
- 抽象
- - 一个真实的示例
- 视角转换
- 过度设计与风险驱动

前言

解决软件复杂度与规模增长有效的利器总结下来，就是分治、知识、抽象。开发者把问题分割为规模更下且易于处理的更多子问题，这样他们就可以利用相似的知识集中的解决这些子问题，并且使用抽象帮助推理与判断。
从看见树木，到看到森林，再到看见树木。

软件架构是什么？

参考相关文档：
Software architecture refers to the high level structures of a
software system and the discipline of creating such structures and
systems. Each structure comprises software elements, relations among
them, and properties of both elements and relations.[1]

The architecture of a software system is a metaphor, analogous to the
architecture of a building.[2] It functions as a blueprint for the
system and the developing project, laying out the tasks necessary to
be executed by the design teams.[3]
————卡内基梅隆软件工程研究所

简单来说，软件架构设计=底层实现细节+高层架构信息。所谓底层和高层本身就是一系列组成的连续体，并没有清晰的分界线。

如果架构师只画几张笼统抽象的图，而对底层实现细节没有控制力，这样的架构就是万能的架构，没有任何意义！

我观察到有些架构师只是画几张抽象的图，以为这就是架构设计的全部，当时我感到十分怀疑。更多阅读了《clean architecture》、《恰如其分的软件架构》书籍，更加坚定了我的想法。软件宏观架构信息只是一部分，缺失了重要的底层细节，就是毫无意义的万能架构！

研发工程师、架构师并不是作坊里的熟练工，我们不能总是通过自己的感觉去工作（往往我们的视野是有限的,空间、时间限制了，一叶障目），有很多设计原则经过许多业内优秀的先贤验证总结。这些都是我们做好工作必须去要学习的！

软件架构定义

一个软件系统抽象概况层面的结构体集合（骨架），并且是创建这些结构和系统的约束规则。

每个架构都由软件元素集合（模块
组件、连接器等）、这些元素之间的关系，以及这二者各自的属性组成。

元素、关系、属性

一般人会认为，架构关注宏观方面，比如模块（元素）、模块与模块之间的连接方式（关系）。但实际上，并不仅仅如此。

JavaBean的规范说明书就明确规范了命名，隐藏在其后的想法是利用反射实例化JavaBean对象，并且通过反射那些遵守命名规范的方法，从而获知JavaBean的属性，进而调用其属性保存数据。

软件设计不过半个世纪，而建筑设计已悠悠千载。建筑设计中，只要直接影响建筑的整体质量都属于架构范畴，例如，建筑的水密性，美观，可施工性。

正如建筑设计，只要细节关乎到系统的整体质量，它就应该属于架构层面的内容。（属性）

为什么合适的架构很重要？

无论设计与否，软件系统总会有一个架构。最差也是大泥球（a big ball of mud）。

架构是系统的骨架，而又不仅仅是骨架

鹰之所以善飞，豹之所以善短跑，袋鼠之所以善跳，都得益于各自的骨架。而各种骨架之中并不存在最好的，只有满足特点下的最合适的。

软件架构也是如此。

然而软件架构又不仅仅是系统的骨架，除了显而易见的特点之外，上文也说了架构不好必要的细节，比如某些看不见的规约也很重要。例如，锁策略，内存管理，或者集成扩展方式。

架构影响质量

软件系统能做什么，这是软件系统的功能。但是同样托货物，狗和马都能做到，但是从效率等方面来看，马肯定更胜一筹，也更持久可靠。

软件系统也是如此，满足功能性的同时，需要满足一些性能属性，如，安全性，可用性，伸缩性等等。

这就需要软件架构的设计，比如一个面向100人的b2c网站，如果要面向1亿人，那么不变更软件架构是无法满足的！所以选择一个合适的架构可以让软件系统事倍功半，否则就会事半功倍。

架构与系统功能互相独立(基本上)

通常情况下，架构与系统功能是相互独立的，相似的架构可以用在截然不同的功能上，功能相似的系统也可能采用截然不同的架构。

但重要的是，合适的架构可以与系统功能取长补短，互相混合。就比如我们理论上可以把船坞建在沙漠里，但是很明显加载水域附近更方便轮船下水。

架构约束程序

任何系统都有约束，比如目前做的订单升级不得不考虑MQ不稳定的情况；再比如与不稳定的第三方进行同步交互，必须考虑第三方长时间异常，需要熔断的约束。

约束的目的是保证系统具备特定的质量属性！
系统不做什么与系统做什么同样重要，比如安全相关的系统不会与不可信的第三方进行数据通信等。为了保证特定的质量属性（如安全性，可用性）就必须施加约束。就比如高铁总是要跑在轨道上的，显然不灵活，但是更重要的是保证了其应有的高速运行与安全性。
提升整体度，统一一致的设计比散落在各处的奇思妙想更合适。

架构设计的目标

软件架构的终极目标是，对这个系统的维护与构建做到最大化的高效率！
以下数据摘自《clean architecture》数据来源一个某公司的核心系统。

以下图表示了该系统发布0~8个版本过程中，研发人员的增长。

以下图表示了该系统发布0~8个版本过程中，代码数量的增长(KLOC表示千行代码)。

以下图表示了该系统发布0~8个版本过程中，每行代码变更的成本（fuction(人力\时间)）

以下图表示了该系统发布0~8个版本过程中，人均生产效率的变化

以下图表示了该系统发布0~8个版本过程中，资金成本的消耗

问题在哪里？

龟兔赛跑的故事很好的说明了这个问题，先跑的快并不能赢得胜利。
想要跑的快，先要跑的稳。

核心问题在于，兔子偷懒了：持续低估了那些好的、优良设计、整洁高质量代码的重要性。

兔子总是会用一句话欺骗自己：“我们可以未来重构代码，先上线最重要！”但问题在于，每次都是一样的情况，每次过后都没有人再会提及质量问题的隐患，大泥球就是这样一步步堆积起来的！

分治、知识、抽象

分治

（如何分？）分割后的各个部分需要足够小，以便一个人单枪匹马的就可以解决。
（如何合？）必须考虑如何将分割后的各个部分组合、装配为整体

知识

开发者利用之前自己或别人积累的知识，解决各个部分内的问题，解决各个部门组合的问题。这些知识的积淀，考验的也是最基础的技能深度（个人认为能够做到源码级、原理级就够了）。

抽象

精简问题本身，简化问题复杂度。因为抽象能力能够解决软件的复杂度以及规模的增长。抽象概念化，意味着更多遵循约束，而非随意实现代码就行（如下文的“job”,幂等算是基础约束）。开发者主动对系统增加约束，可以增强他们的推导能力。

一个真实的示例

来看一个真实的示例，简单来说这个系统的功能就是需要做数据ETL（Extract Transform and Load）的功能。

阶段一
集中汇总收集所有数据，并使用grep等脚本命令进行查询。
随着规模增大（熵增），查询的开销越来越大，而且技术支持人员无法正确使用相关命令脚本。
阶段二
所有数据会直接录入关系型数据库中，中央数据库管理并CRUD，技术支持等非技术人员通过web界面进行查询。
随着规模增大（1TB/month），查询开销越来越大，对硬件的使用达到瓶颈，需要更多的数据库以及带来的各种问题。
阶段三
使用HDFS存在，并且对每种查询进行分布式MapReduce计算，然后保存索引结果。如果需要扩展，一般通过先再编写一个job，来完成对结果的索引存储。
每个job每个10分钟执行一次，大约5分钟执行完成。因此最新结果会滞后15分钟。技术支持人员依旧在web页面查询结果。

以上示例可以看到：

1.
阶段1中，阶段2中，可以随用户查询条件的变化，实时查询。而阶段3中需要编写新的程序满足新的查询，并且延迟15分钟。阶段1中，阶段2中，可以随用户查询条件的变化，实时查询。而阶段3中需要编写新的程序满足新的查询，并且延迟15分钟。

功能虽然相同，但是质量属性（扩展性、延迟性、伸缩性）却不同。
伸缩性（弹性）：阶段3>阶段2>阶段1
实时性（延迟性）：阶段1>阶段2>阶段3
扩展性 : 阶段1>阶段2>阶段3

质量属性是随着复杂度相互抵消的，如果要一种属性发挥到极致，其他属性必然会收到消减！

2.
架构与功能完全独立。不同的底层架构，实现了相同的功能。

视角转换

在Edsger Dijkstra 1968年写了那篇著名的文章<GOTO是有害的>，大量的驳斥者汹涌而出，但今天来看结论似乎无需争议。

【<GOTO是有害的>：主要观点就是论证goto这种模式的命令会导致大型问题无法拆分、无法独立、不可测试等缺陷。
而作者认为并推荐采用do-while，if then else ，until等语句可以构造出任何程序】

在每一轮新的抽象观念的诞生，总会有迷恋的守旧者，只知道抱残守缺，却不懂兼容并包、与时俱进。他们的目光只顶着新抽象带来的缺陷，却忽略其中陌生的优势。
同样适用于今日,如果不主动的思考架构，就会依旧停留在一堆面条代码的大泥球之中（a big ball of mud）。

过度设计与风险驱动

首先无论是敏捷设计或是传统的瀑布流，设计与计划肯定是需要的。但是对于没有任何风险的、不会越来越复杂的、并不需要长期迭代的软件，任何形式的过度设计都是没有必要的！杀鸡焉用牛刀。

但是对于长期迭代并且复杂化不断增长的项目，前期合理的设计是保证系统远离大泥球的保证。

因为对于每个复杂系统，重构都是破费周章且有风险的。

架构设计的深入思考与总结——概述相关推荐

我对支付平台架构设计的一些思考
我在前一家公司的第一个任务是开发统一支付平台,由于公司的业务需求,需要接入多个第三方支付,之前公司的支付都是散落在各个项目中,及其不利于支付的管理,于是聚合三方支付,统一支付平台的任务就落在我手上,可 ...
十问 TiDB ：关于架构设计的一些思考
"我希望能够把 TiDB 的设计的一些理念能够更好的传达给大家,相信大家理解了背后原因后,就能够把 TiDB 用的更好." 做 TiDB 的缘起是从思考一个问题开始的:为什么在数据 ...
系统架构设计的一点思考
原文链接:https://mp.weixin.qq.com/s/2vATENTGyqtyWx1Xjqj-_g 系统化思维在以前的文章中,有提到过很多.总结为三个方面. 1.系统三要素:元素.元素之间的 ...
异地多活高可用架构设计实践与思考
一.引随着业务的快速发展,对于很多公司来说,构建于单地域的技术体系架构,会面临诸如下面的多种问题:础设施的有限性限制了业务的可扩展性:机房.城市级别的故障灾害,影响服务的可持续性. 为解决遇到的这些 ...
林仕鼎：架构设计的一些思考
林仕鼎在演讲中就系统架构中基本的存储.分布式技术.服务架构以及计算模型进行了分析,并分享了当架构师的经验.林仕鼎谈到的内容点包括: 高并发网站存储.分布式.服务架构.模型实例存储架构设计的四大注意事 ...
林仕鼎[百度云首席架构师]：架构设计的一些思考
林仕鼎在演讲中就系统架构中基本的存储.分布式技术.服务架构以及计算模型进行了分析,并分享了当架构师的经验.林仕鼎谈到的内容点包括: 高并发网站存储.分布式.服务架构.模型实例存储架构设计的四大注意事 ...
高老师架构设计思考短句集(2)
高老师<架构&设计思考>短句集(2) << FEB 2014 >> 为什么要思考呢? 因为许多古典的架构思维视角,都已经不符合智能化&大数据时代的 ...
高老师架构设计思考短句集(3)
高老师<架构&设计思考>短句集(3) << FEB 2014 >> 一般架构师用心于改善客户的系统架构和设计,而杰出架构师努力改变自己的思考视角和视野. 杰 ...
Android项目架构设计深入浅出
简介:本文结合个人在架构设计上的思考和理解,介绍如何从0到1设计一个大型Android项目架构. 作者 | 璞珂来源 | 阿里技术公众号前言:本文结合个人在架构设计上的思考和理解,介绍如何从0到1 ...
游戏服务器架构设计的一些整理
一.前言没有最好的架构,只有最适合自身业务的架构. 首先我们应该确定的是大的架构方向:分布式 / 单应用+负载均衡,这两种架构设计直接影响后续的网络层.缓存层.数据层.业务层的设计.笔者这两种架构的 ...

架构设计的深入思考与总结——概述