第5章 运行架构设计

整体感觉这章没有讲太多东西

运行架构关注的是系统如何运行，是同步还是异步，是并发还是串行，关注运行中的各个对象如何交互，状态如何转换，关注那些安全必性、可靠性、可伸缩性等质量要求，以及响应时间、吞吐量等性能要求。

运行架构关注的不再是全局，而是局部，是系统中那些关键点与难点。

1、如何开展对非功能需求的分析与设计？

答：采用“属性à场景à决策”的过程，一步一步进行架构设计。

（1）属性：就是整个系统应当遵循的质量属性。譬如，整个系统应当达到的安全性、可靠性，应当达到多少秒内的响应时间，以及多大的高并发与吞吐量等。在制订非功能性需求时，每一项必须有明确的可验证的标准。

（2）场景：就是拿着非功能性需求中的每一个质量属性，到整个项目中去扫描，哪些功能达到要求，哪些功能不能达到。从而把整个项目对质量属性的要求变成某些关键场景对质量属性的设计。架构师会依据质量属性的要求，对这些场景进行技术选型，制订各种文豪发，然后依据方案设计编码，最后搭建实验环境进行测试验证，通过不断地优化最终达到质量属性的要求。

（3）决策：在这个阶段，架构师要决策的，就是他在该应用场景中进行的设计是不是适用于其他的各个场景。

架构设计是在对系统的功能性需求进行全面梳理，总结归纳的基础上制订的，是对各个功能共性的设计。

运行架构的设计，不是对开发架构的否定与替换，而是进一步的调整与优化。

2、非功能性需求有哪些内容？

答：简单可归纳为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其他（+）。

（1）可用性

是一个非常宽泛的概念，泛指那些能让用户顺利使用该系统的指标，包括易用性（易操作、易理解）、准确性、安全性（系统安全、数据安全、权限体系、访问限制等）、兼容性（服务器、客户端的兼容程度），等等。

（2）可靠性

就是系统可以可靠运行不宕机，包括系统成熟度（数据吞吐量、并发用户量、连续不停机性能等）、数据容错度、系统易恢复性等。

（3）性能

是非功能性需求分析中非常重要的内容。功能性需求与部署方式是对性能影响最大的两个方面，必须在该阶段就想清楚，解决掉。

功能与性能往往是矛盾的，保证了性能就必须要牺牲功能。

（4）可支持性

就是软件的可维护性、易变更性。可支持性能于客户是透明而不可见的，因此客户通常不关心这个。

3、什么是恰如其分的架构设计？

答：

（1）当前的架构设计必须满足当前的所有需求

  利用“5视图法”进行架构设计，先全面梳理当前的需求，即要覆盖功能性需求，也要覆盖非功能性需求，即包含软件设计，也包含硬件部署，把来自方方面面的问题都囊括，不遗漏任何一个设计风险。在这样的基础上设计出来的架构就是高质量的。

（2）没有过度设计

      所谓的“过度设计”，就是脱离了当前的需求，试图去满足未来的需求。

不过度设计，并不意味着架构师完全不考虑未来。那些近期可以预见的变化还是可以预先做一些设计的，但那些自己都不确定未来会不会发生的变化，不做也罢。

4、什么是好的架构？

答：

（1）恰如其分的架构

  满足当前的所有需求；没有过度设计

（2）不停衍变的架构

好的架构其实只能适应一段时间的变更，只有不断迭代、重构、衍变，适应业务的变化的架构才能称之为好的架构

5、什么是意图架构？

答：不去规划一成不变的未来，而是规划可以预测的当前，并随时做好应对未来变化的准备。在这种思路指导下的架构就是“意图架构（Intentional Architecture）”

意图架构，就是根据近期需求变更的意图，去规划近期的技术架构，使其刚刚满足近期的需求。未来当需求变化时，再根据未来需求变更的意图，去规划未来一段时间的技术架构，使期刚刚满足未来这段时间的需求。也就是说，意图架构永远规划的是近期的架构，能够刚刚满足近期的需求，并随时做好应对未来变化的准备。这也就是恰如其分的架构设计。

6、什么是浮现式设计？

答：团队全部围绕着用户需求，用很短的时间去做增量

7、什么是使能故事？

答：“使能故事（Enabler Story）”是架构师实践“意图架构”的落地实践。

“使能故事”是相对于“用户故事（User Story）”提出的；所谓“使能”就是使自身的能力得到提高，包括：

（1）更深层次地理解用户业务，探索用户需求，给用户更好体验；

（2）优化即有的代码，提高代码质量，以降低日后变更的成本；

（3）调整即有的技术架构，以支持未来更多的功能，更快更好地完成开发；

（4）将现有功能算法下沉，构建更加强大的技术中台，以支持未来的发展。

虽然使能故事不能直接产生用户价值，却可以有效地提升无未来完成用户故事的速度与能力，从而间接地提高生产力，产生更多用户价值。

注意：长周期的大重构，不如短周期的小重构。

8、什么是架构跑道？

答：即要满足未来一段时间的需求，又不能规划得太远，从而产生浪费，这就是“架构跑道”的设计思路。（意图架构、架构跑道感觉都是一回事）

9、针对老旧系统架构师是如何架构的？

答：

（1）缝缝补补又三年

（2）走一步推两步，浅尝辄止

（3）洗心革面，重头再来

10、什么是演化式技术改造？

答：演化式技术改造就是利用重构在原有的系统上逐步改造。每一步重构都保持功能不变，只调整程序的内部结构。通过内部程序结构的优化，业务代码逐渐与各个层次、各种技术解耦。

演化式技术改造的目标是实现业务代码与技术框架的解耦，使系统适于进行技术改造，而采用的方法就是重构。

11、软件重构

答：软件重构，就是在不改变原有系统外部行为的基础上，调整它的内部结构，使其更加易于阅读、维护和变更。

从软件重构的定义中，我们可以总出以下几个特点：

（1）不改变系统原有的功能

（2）调整程序内部结构

（3）易于阅读、维护和变更

注：几个简易的重构方法

1）抽取方法  2）抽取类  3）抽取接口

12、演化式技术改造的执行过程是什么？

答：

（1）通过抽取方法，将各业务模块中对底层框架进行调用的代码从其他业务代码中剥离出来，放到单独的方法中，但代码还是在各业务模块中

（2）通过抽取类，将以上这些方法从各业务类中抽取出来，形成接口层单独的类，与业务代码分离

（3）通过抽取接口，将各业务类对接口层类的调用，变成对接口层接口的调用，从而实现业务代码与接口层的解耦

（4）通过对所有接口层的接口进行总结归纳，逐步合并，抽取共性，保留个性，逐步形成各业务模块对一些公用接口的调用