一线架构师实践指南（二）

Conceptual Architecture阶段

       有经验的架构师不会一上来就关注如何定义“接口”，他们在大型系统架构设计的早期比较注重识别重大需求、特点需求、高风险需求，据此来设计概念架构。概念架构是对系统设计最初构想，就是把最关键的设计要素和交互机制肯定下来，而后考虑具体技术的运用，设计出实际架构。概念架构应该抓大局、不拘小节。虽然概念架构都跳不出“架构=组件+交互”的基本定义，但它们描述架构的具体方式仍是有比较大的差别：有点重视逻辑层、有点重视物理层、有的经过隐喻代表机制、有的看上去彷佛就是一些设计元素的组合。不一样的概念架构视图中，“连接”表明的含义千差万别：有的是依赖方向，有的是控制方向，有的是控制方向，有的是控制数据流向，所以，必须根据具体状况而定。在概念架构设计中，不关注明确的接口定义；以后才是“模块+接口”一级的设计。对大型系统而言，这一点偏偏是必需的。

       概念架构界定西塘的高层组件，以及它们之间的关系。概念性架构意在对西塘进行适当分解，而不陷入细节。概念架构规定了每一个组件的非正式规约及架构图，但不涉及接口细节。

       概念架构知足“架构=组件+交互”的基本定义，只不过概念架构仅关注高层组件。概念架构对高层组件的“职责”进行了笼统的界定，并给出了高层组件之间的相互关系。概念架构不该涉及接口细节。需求不一样，因此架构不一样；固然，“需求”不是指“功能需求”，而是包含了功能、质量、约束等方面。进行概念呢架构设计时应确立架构大方向。架构设计贵在有针对性，概念架构设计针对重大问题、特点需求、高风险需求的要求，给出高层次的解决方案，这是概念架构的重要意义。所谓“被选架构方案”常常是概念架构一级的，有助于架构的对比分析、评审优化。

       架构设计的驱动力 = 功能 + 质量 + 约束。用例技术是功能需求实际上的标准，用例技术涉及，但没法全面涵盖非功能需求。

       初步设计的目标简单而明确：那就是发现职责。初步设计无需展开架构设计细节，不然就背上了“包袱”，这是复杂系统架构设计起步时的大忌。初步设计识别出了职责，后续的高层分割方案才有依据，由于每一个“高层分割单元”都是职责的承载体，而分割的目的也偏偏在于规划高层职责模型。

       实际的工程化实践中，需求捕获、需求分析、系统分析不是彻底孤立进行的。相反，它们每每是相互伴随、交叉进行的。

       有的书上明确地说“实体对象就是持久化对象”，这是错误的。由于实体对象涵盖更普遍，它能够是持久化对象，也能够是内存中的任何对象。实体对象不等于持久化对象，这个正确认识将有助于你的实践。

       分析与综合是思惟方向相反的过程。通常是先分析后综合，没有分析就不能有综合；没有综合的分析，也只是片面的分析。

       “架构=模块+接口”的作法，其不足可归纳为两点：

第一，忽视了多视图。“模块+接口”仅是逻辑架构设计视图的核心内容，而软件系统的架构设计还可能涉及开发视图、运行视图、物理视图、数据视图等多方面的考虑。

第二，忽略了概念架构设计。对规模稍大的系统而言，都必须先根据重大风险（包括功能方面、质量方面、约束方面），有针对性地定制包括“高层分割”在内的设计决策，而后才是“模块+接口”一级的设计。

架构设计中“高层分割”的两种实践套路：

l   切系统为系统；

l   切系统为子系统。

高层分割很重要，但不是概念架构的所有。除了切分决策以外，概念架构还包括技术选择、权衡策略等种类的决策。

 

 

Refined Architecture阶段

       概念架构难以支持并行开发。要支持开发组相对独立地进行工做，需要提供指导和限制做用更明确的“规约”一级的设计。细化架构和概念架构之间存在以下典型差别：

l   接口。在细化架构中，接口占据很是核心的地位，而概念架构并不关心明确的接口定义（只有抽象的组件和抽象的交互机制）。

l   子系统。细化架构重视经过子系统和模块来分割整个系统，而且子系统每每有明确的接口；而概念架构中只有抽象的组件，这些组件没有接口，只有职责，通常是处理组件、数据组件或连接组件中的一种。

l   交互机制。细化架构中的交互机制应是“实在”的，如基于接口编程、消息机制或远程方法调用等；而概念架构的交互机制是“概念化”的。

固然，概念架构和细化架构都知足软件架构的定义——不管是“架构=组件+交互”，仍是“架构=重要决策集”。

方案=“项目+需求+架构” 的总揽，方案！=架构的所有。

       架构设计是一门解决复杂问题的实践艺术，因而，以分而治之为核心思想的多视图方法必不可少。Refined Architecture（细化架构）属于架构设计，不能与Detailed Design（详细设计）相混淆。

       不一样涉众看待软件架构的视角是不一样的。多视图方法有两方面的实际意义：

l   利于思考（由于分而治之的思惟方式）；

l   便于交流（由于在必定程度上分离了涉众关注点）  。

5视图方法包括：逻辑视图、开发视图、运行视图、物理视图、数据视图。5视图各有其“思惟立足点”，分别是：

l   职责划分（逻辑视图）

l   程序单元组织（开发视图）

l   控制流组织（运行视图）

l   物理节点安排（物理视图）

l   持久化设计（数据视图）

看似复杂的5视图方法其实很简单，由于其每一个视图都是从特定角度规划系统的分割与交互，都是（架构的定义）“组件+交互”的一种体现。

一线架构师最缺的不是理论，也不是技术，而是位于理论和技术之间的“实践策略”和“实践套路”。

分层是最经常使用的架构模式。在架构设计初期，100%的系统均可以用分层架构，就算随之设计的深刻而采用了其余架构模式也未必和分层架构矛盾。

为了获得客户常常性的反馈，快速迭代有个基本前提：开发应该“深度优先”，而不是“广度优先”。为了支持迭代开发，逻辑架构设计中必须引入分区。分区是一种单元，它位于某个层的内部，其粒度比层要小。一旦架构师针对每一个层进行了分区设计，“深度优先”式的迭代开发就很是天然。

机制才是设计的灵魂所在，不然咱们就将不得不面对一群没法相互协做的对象，它们相互推搡着作本身的事情而绝不关心其余对象。软件系统中的机制，是指预先定义好的、可以完成预期目标的、基于抽象角色的协做方式。机制不只包含了协做关系，同时也包含了协做流程。对于编程实现而言，在没有提取机制的状况下，机制是一种隐式的重复代码。对于逻辑架构设计而言，机制是一种特殊的子系统，做为子系统的机制并不能“直接实现”软件的“最终功能”。在实现不一样的最终功能时，能够重用同一个机制，避免重复进行繁琐的“组装”工做。

 

子系统划分的4个重要原则

l   职责不一样的单元划归不一样子系统（职责分离原则）

l   通用性不一样的单元划归不一样子系统（通用专用分离原则）

l   须要不一样开发技能的单元划归不一样子系统（技能分离原则）

l   兼顾工做量的相对平衡，进一步切分太大的子系统（工做量均衡原则）

 

对问题进行分解，分别解决小问题，其实这只是手段。合才是目的，不能“合”在一块儿支持更高层次功能模块，又有何用？

 

硬件强大了，但数据量在增长，计算复杂性也在提升，因此增长硬件未必能解决问题。增长硬件= 增长计算能力！= 软件的实际服务能力加强

物理架构视图着重考虑运行软件的计算机、网络、硬件设施等状况，还包括如何将软件包部署到这些硬件资源上，以及它们运行时的配置状况。因为一部分运行时质量属性须要硬件或网络的支持，因此物理架构必须关注如何配置硬件和网络来知足软件系统的可靠性、可伸缩性、持续可用性、性能、安全性等方面的要求。

物理架构设计有3项任务：

l   硬件的选择与物理拓扑

l   软件到硬件的映射关系

l   方案的优化

 

若是系统中，并不许备引入任何并行或并发处理，而且系统也没有基于SDK、API等基础软件进行定制开发，那就不需要设计运行架构的设计。

最经常使用于实际控制流的手段有3种：

l   进程

l   线程

l   中断服务程序

 

开发架构的设计应完成下列工做：

l   将“逻辑职责”映射为“程序单元”

Ø  要自主编写的源程序

Ø  可重用的库、框架

Ø  其余方式（如shell脚步、平台支持下的配置文件）

l   开发技术选型

Ø  开发语言

Ø  开发工具

l   “程序单元”间关系

Ø  Project划分

Ø  Project目录结构

Ø  编译依赖关系

 

非功能需求的考虑是“贯穿环节”，在概念架构设计阶段，以及细化架构设计阶段都应重视。对大型系统而言，开发架构设计中的“Project划分”是不可或缺的。

 

肯定数据分布方案是数据架构设计的难点。越是大系统，数据分布越关键。所谓分布式系统，不仅仅是程序的分布，还涉及数据的分布。常采用不一样的数据分布存储与处理手段有：

Ø  独立Schema（Separate-schema）

Ø  集中（Centralized）

Ø  分区（Partitioned）

Ø  复制（Replicated）

Ø  子集（subset）

Ø  重组（Reorganized）

分区方式包括水平分区和垂直分区两种类型。水平分区的特色能够归纳为“两个相同，两个不一样”——相同的应用程序、不一样的应用程序部署实例（instance）相同的数据模型，不一样的数据值。在实践中，水平分区的应用很是普遍，而垂直分区的的做用相比之下要小得多。

在整个分布式系统中，数据保存多个副本，而且以某种机制（实时或快照）保持多个数据副本之间的数据一致性，这就是复制方式的数据分布策略。

“子集”是“复制”的特殊方式，就是某节点因功能或非功能考虑而保存全体数据的一个相对固定的子集。

重组这种数据分布策略，就是不一样数据节点因要支持的功能不一样，而以不一样的Schema保存数据——但本质上这些数据是同源的。因而，重组策略要进行数据传递，而不是数据的“原样”复杂，而是以“从新组织”的格式进行传递或保存。根据典型的应用背景，重组分为两种类型：统计性重组和结构性重组。

 

非功能目标的方法论

       软件架构设计为何这么难？由于架构设计不是简单地处理“纯粹的技术问题”，而是要面对“技术与业务的关系问题”。最终，要求架构师不只懂技术、懂业务，并且可以理顺复杂的技术和业务之间的关系。

       从面向业务的需求，到最终的面向技术的软件系统，要跨越很大的鸿沟。软件架构设计就是要完成从面向业务到面向技术的转换，在鸿沟上架起一座桥梁。软件架构师根据各类需求进行架构设计，最终的软件架构包含告终构、协做、技术等方面的重要决策，为系统化的开发活动创建了基础。精通需求，是对架构师最基本要求之一，不了解需求是如今许多架构师职业发展道理上的瓶颈。值得强调的是，需求分析师和架构师这两个角色要掌握的需求知识并不彻底同样。经典的观点师认为架构师应该掌握的需求知识师需求分析师的一个子集，其实否则。架构师必须懂需求。虽然无需研究诸如需求捕获等技术，但需求类型、需求影响架构的原理、质量属性间的相互影响关系都是必须精通的。

       架构设计实践中，面对非功能需求目标时是容易犯“拍脑壳”这个经典错误的。非功能目标的设计是以场景技术为核心手段、以目标-场景-决策表为思惟工具，致力于支撑非功能目标的理性设计过程。非功能需求不愿能是“速决战”，它必然是“持久战”，连编码都会影响到性能等非功能属性，更况且概念架构设计和细化架构设计呢？因此架构师必须注意，非功能目标的考虑是纵穿架构始终的环节。

       软件的质量是设计出来的，这是公认的一个基本观点。实践中，架构师必须对场景进行评估，以决定是否支持这个场景。架构师常常要考虑的场景评估因素包括：

l   价值大小

l   代价大小

l   开发难度高低

l   技术趋势

最后，必须提醒的是“不支持某场景”偏偏是架构师的一种重要决策——若是每一个场景都给予支持，理性设计就无从谈起，过分设计就在所不免了。