《一线架构师实践指南》- 数据架构、非功能目标

数据架构

6种策略

独立

一个大系统由相关多个小系统组成，且不同的小系统具有互不相同的数据库Schema定义，这种情况就是独立；

集中

一个大系统支持来自不同地点的访问，或者该系统由相关的多个小系统组成，而持久集中化数据进行集中化、统一格式的存储。

分区

系统为“地域分布广泛的用户”提供“相同的服务”时，常常采用水平分区策略。分为水平分区和垂直分区；
水平分区应用比较广泛，概括为“两个相同，两个不同”，相同的应用程序，不同的应用程序部署实例；相同的数据模型、不同的数据值；
垂直分区的特点：不同数据节点Schema会有“部分字段差异”，但可以从同一套总的数据Schema中抽取得到。

复制

分布式系统中，数据保存多个副本，并且以某种机制保持多个数据副本之间的数据一致性；

子集

复制的特殊方式，某节点因功能或者非共嗯那个考虑而保存全体数据的一个相对固定的子集；
子集和复制方式有着非常类似的优点：

• 数据的本地化，提高数据访问的性能 数据的专门副本，
• 利于针对性的进行优化 数据的专门副本
• 便于提高可管理性，加强安全控制
• 减少了跨机器进行数据传递的开销
• 降低数据冗余，节省了存储的成本

重组

不同数据节点要支持不同的功能，而以不同的格式进行传递和保存，本质上数据是同源的。

6种策略的对比

二维对比

可靠性： 复制；
可扩展性： 分区，复制在只读的情况下扩展性也很强，否则为了保证数据一致性会消耗不少资源；
通信开销最低： 独立，强调将一组数据与它关系密切的功能放在一起的高聚合原则，覆盖不同功能的应用之间就是松耦合的 — 用于传递数据的开销自然很小；
可管理性： 独立，集中；
数据一致性： 集中；

3条应用原则

合适原则

把握系统特点，确定分布策略

综合原则

系统比较复杂时，数据产生、使用、管理等方面可能很难表现出压倒性的特点，此时要考虑综合运用不同的数据分布策略；

优化原则

架构设计是一个过程，合理的架构往往需要团队甚至外部的意见，因此注重优化原则很重要；一个经验是：当难以一步到位做出数据分布策略的正确选择，以及还存在质疑时，应从对吗、好吗 两方面进行评估和优化；

非功能目标方法论

非功能需求分为 质量属性和约束两大类；
《软件工程的事实与谬误》

架构师必须懂需求；
需求=功能需求+非功能需求；
交流非功能需求的时候，普遍存在说不清楚的情况，架构师要有意识的明确；

非功能目标设计

如何使很”虚“的非功能需求落地？

1. 需求决定架构，架构设计的成果已属于解决方案的范畴；
2. 架构设计的过程是从需求域向设计域过渡的过程；
3. 目标很飘，意味着根据诸如高性能等非功能需求直接做出设计决策跨度过大；
4. 需要过渡技术–场景技术，来呈上启下，使笼统的非功能目标明确化，帮助架构师做出更有针对性的设计决策；
   将一个目标明确为N个场景，可以使架构师设计更加针对性、更加有效；

方法：”目标-场景-决策“表

场景推演技术并不产生于计算机行业，商业领域对场景技术的重视大大超过了软件行业，所以可以从商业书店里找到场景规划方面的书籍进行参考；
场景不等同于用例：
场景是基础技术，用例是应用技术。
为了以结构化的方式描述”能够给外部角色带来可见价值的交互序列“，将成功场景和各种意外场景”打包“形成了用例。
于是不难理解，用于测试设计的”测试用例“、用于评审的”基于场景的架构评估方法“、用于支持非功能目标设计方法论的”目标-场景-决策表“都是场景技术的具体应用；

场景包含的五要素：

1. 影响来源。来自系统外部或者系统内部的触发因素；
2. 如何影响，影响来源施加了什么影响；
3. 受影响对象。默认为”本系统“
4. 问题或价值。受影响对象因此出现什么问题，或者需要体现什么价值；
5. 所处环境。此时，所处的环境或者上下文为何？

目标-场景-决策 表

最后，”不支持某场景“也是架构师重要的决策，如果每个场景都给与支持，理性设计就无从谈起，过度设计在所难免。

《软件架构设计》