背景介绍
这是我的《架构整洁之道》系列的第十六篇，也是软件架构的第一篇。
《架构整洁之道》系列：
软件架构
什么是软件架构
架构这个词听上去就极其的神秘，当我们谈到这个词的时候总有一种逼格上升的感觉，会给人一种我站在会议室的 c 位指点江山进行重大决策与技术分析的感觉。
这是当然的，毕竟进阶到架构层次是大部分技术人追求的目标，比如说我这个狂妄至极的小垃圾～
这个时候就会出现灵魂三问：
- 什么是软件架构？
- 软件架构师工作的内容什么？
总不会是喝喝茶看看报吧
- 软件架构的工作是在何时进行的呢？
首先软件架构师自身一定是坚持编码的能力最强的一群程序员，他们不仅可以承接自身的开发任务，还可以逐渐引导整个团队向一个能够最大化生产力的系统设计方向前进。
他们一定要不停的承接编程任务，如果不亲身承受因系统设计导致的麻烦，就无法体会到设计不佳带来的痛苦，接着进入迷失。
软件系统的架构质量是由他的构建者决定的，而软件架构这项工作的实质就是：
- 如何将系统分成组件
- 安排组件间的排列关系
- 排列组件间的通信方式
而软件架构的目的就是更好的对这些组件进行：
- 开发
- 部署
- 运行
- 维护
如果想设计一个便于推进各项工作的系统 其策略就是要在设计中尽可能长时间地保留尽可能多的可选项。
这里有一个误区就是软件架构的目标是让系统正常的工作，然而并不是！
首先，软件架构设计最高优先级一定是正常工作，这个毋庸置疑，大家想，一个系统没法工作，多么精美的严丝合缝的设计都是没有意义的。但是软件系统架构的质量和系统能不能正常工作其实关系不大，毕竟世界上能运行的软件不胜枚举，而设计优秀的系统却只是冰山一角。
所以软件架构最麻烦的其实是如何让系统更好的进行开发，部署，以及后续的补充扩展。
开发
寒草说：一个开发困难的软件系统一般不会很长久，就像难以维系的感情一样脆弱。
所以系统架构的作用之一就是要方便其开发团队对它的开发。
这里我们思考两种情况：
- 系统A
只有五个人的小团队开发，他们其实非常快速的在一个没有明确定义接口和组件的系统里开发，这个时候会认为系统架构会是早期快速开发的障碍。
- 系统B
一个软件系统是由五个不同的团队合作开发的，而每个团队各自都有七个开发人员的话，不将系统划分成定义清晰的组件和可靠稳定的接口，开发工作就没法继续推进。
所以，不同团队应该采用不同的架构设计，根据实际情况出发。
部署
寒草说：一个系统的部署成本越高，可用性就越低。就像需要上上下下左右左右AABA的作弊码没有一键启动来的实在。
所以一键式的部署应该是我们设计软件架构的一个目标。然鹅 🦢，系统的早起很少考虑部署策略，这经常导致一些易于开发但是难于部署的系统架构。
具一个了例子，在系统的早期开发中，开发人员可能会决定采用某种“微服务“架构，优点有很多：
- 组件边界清晰
- 接口稳定
- ...
很利于开发，但是在部署的时候会出现微服务数量庞大，这些微服务之间的连 接以及启动时间都会成为系统出错的来源。
如果软件架构师早先就考虑到这些部署问题，可能就会有意地减少微服务的数量，采用进程内部组件与外部服务混合的架构，以及更加集成式的连接管理方式。「此处是书上说的，寒草对微服务了解不是很多」
运行
寒草说：软件架构对运行的影响远不及它对开发部署和维护的影响，毕竟运行问题我们可以增加硬件。就像衣服的大小不影响我穿它，大不了变成紧身衣。
对于一个因架构设计糟糕而效率低下的系统，我们通常只需要增加更多的存储器与服务器，就能够让它圆满地完成任务。毕竟资本家们也知道：
硬件比人力便宜
软件架构在整个系统运行的过程中还有另一个重要作用：
设计良好的软件架构应该能明确地反映该系统在运行时的需求
换个说法：
就是该架构应该将系统中的用例、功能以及该系统的必备行为设置为对开发者可见的一级实体，简化它们对于系统的理解，这将为整个系统的开发与维护提供很 大的帮助。
维护
寒草说：在软件系统的所有方面中，维护所需的成本是最高的。满足永不停歇的新功能需求，以及修改层出不穷的系统缺陷这些工作将会占去绝大部分的人力资源。就像开始一段感情容易，维护一段感情难，道理都是一样的。
系统维护的主要成本集中在“探秘”和“风险”这两件事上
- 探秘
成本主要来自我们对于现有软件系统的挖掘，目的是确定新增功 能或被修复问题的最佳位置和最佳方式。
- 风险
当我们进行上述修改时，总是有可能衍生出新的问题，这种可能性就是风险成本。
我们可以通过精雕细琢的架构设计极大地降低这两项成本。通过将系统切分为组件，并使用稳定的接口将组件隔离，我们可以将未来新功能的添加方式明确出来，并大幅度地降低在修改过程中对系统其他部分造成伤害的可能性。
保持可选项
软件有行为价值与架构价值两种价值『这个我之前的文章有提到』。软件被发明出来就是因为我们需要一种灵活和便捷的方式来改变机器的行为。而软件的灵活性则取决于系统的整体状况、组件的布置以及组件之间的连接方式。而我们如何让软件维持这种灵活性呢？
- 那就是尽可能多的可选项
那么到底哪些选项是我们应该保留的?
- 那些无关紧要的细节设计
基本上，所有的软件系统都可以降解为策略与细节这两种主要元素。
- 策略体现的是软件中所有的业务规则与操作过程，因此它是系统真正的价值所在
- 而细节则是指那些让操作该系统的人、其他系统以及程序员们与策略进行交互，但是又不会影响到策略本身的行为
包括 1/0 设备、数据库、 Web 系统、服务 器、框架、交互协议等...
软件架构师的目标是创建一种系统形态，该形态会以策略为最基本的元素，并让细节与策略各脱离关系，以允许在具体决策过程中推迟或延迟与细节相关的内容。例如：
- 在开发的早期阶段应该无须选择数据库系统，因为软件的高层策略不应该关心其底层到底使用哪一种数据库
如果在开发高层策略时有意地让自己摆脱具体细节的纠缠，我们就可以将与具体实现相关的细节决策推迟或延后，因为越到项目的后期，我们就拥有越多的信息来做出合理的决策。
一个优秀的软件架构师应该致力于最大化可选项数量
结束语
软件架构设计的主要目标是支撑软件系统的全生命周期，设计良好的架构可以让系统便于理解、易于修改、方便维护，并且能轻松部署。软件架构的终极目标就是最大化程序员的生产力，同时最小化系统的总运营成本。
记住，一切都是为了利益，软件架构也是！
以及，优秀的架构师会小心地将软件的高层策略与其底层实现隔离开，让高层策略与实现细节脱钩，使其策略部分完全不需要关心底层细节，当然也不会对这些细节有任何形式的依赖。另外，优秀的架构师所设计的策略应该允许系统尽可能地推迟与实现细节相关的决策，越晚做决策越好。
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
少年向来不识天高地厚
放眼处皆自负才高八斗
虽是自命风流
倒也坦诚无忧
我爱这样的少年
谦和而狂妄
骄傲又坦然☀️
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
