系统架构分析与设计方法论

 

 

 

1      什么是架构

三要素：

一、  构件

二、  构件之间的关系

三、  构件与环境之间的关系

 

 

 

2      软件架构原则

2.1      全面解耦原则

对业务进行抽象建模，业务数据与业务逻辑解耦，软件和硬件解耦，平台和产品解耦，系统各部件间解耦

• 什么是系统的耦合性耦合性(Coupling)，也叫耦合度，是对系统模块间依赖或关联程度的度量。耦合的强弱取决与模块间接口的复杂性、调用模块的方式以及经过界面传送数据的多少。模块间依赖或联系越多，其耦合性越强，同时代表其独立性越差。
• 系统耦合性的评估标准（耦合性依次从强到弱）
• （1）内容耦合: 当一个模块直接修改或操做另外一个模块的数据,或者直接转入另外一个模块时，就发生了内容耦合。此时，被修改的模块彻底依赖于修改它的模块。
• （2）公共耦合: 若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境能够是全局数据结构、共享的通讯区、内存的公共覆盖区等。
• （3）外部耦合: 一组模块都访问同一全局简单变量而不是同一全局数据结构，并且不是经过参数表传递该全局变量的信息，则称之为外部耦合。
• （4）控制耦合: 一个模块在界面上传递一个信号（如开关值、标志量等）控制另外一个模块，接收信号的模块的动做根据信号值进行调整，称为控制耦合。
• （5）标记耦合: 模块间经过参数传递复杂的内部数据结构，称为标记耦合。此数据结构的变化将使相关的模块发生变化。
• （6）数据耦合: 模块间经过参数传递基本类型的数据，称为数据耦合。
• （7）非直接耦合: 模块间没有信息传递时，属于非直接耦合。
• 若是模块间必须存在耦合，就尽可能使用数据耦合，少用控制耦合，限制公共耦合的范围，坚定避免使用内容耦合。

 

2.2      服务化/组件化原则

以服务、数据为中心，构建服务化、组件化架构，具有灵活、按需组合的能力

 

• 乐高式微服务组合，更适合快速变化业务
• 更小粒度扩缩，提高资源效率
• 良好的解耦显著提高敏捷性
• 各微服务之间独立开发、独立发布、独立部署

 

2.3      接口隔离及服务自治原则

经过接口隐藏服务/组件的实现细节，服务/组件间只能经过接口进行交互，接口契约化、标准化，跨版本兼容；服务、组件可独立发展、独立发布、独立升级；服务自治，可视、可管、可控、可测、可维、故障自愈。

 

服务注册

微服务A（Pod1,2,…） 经过K8s Service访问到Service Center并进行注册

微服务A订阅微服务B~n，Service Center将现有微服务B~n的访问列表返回给微服务A

服务动态调整自适应某个微服务有新的POD注册上去以后，Service Center会主动推送给关联微服务

服务访问

A须要访问B时，能够直接根据 IP+Port访问

服务注销

微服务的Pod到Service Center注销，并通知到关联的微服务

 

2.4      弹性伸缩原则

构建全分布式云化架构，或借鉴云化架构思想，每一个服务具有横向扩展能力，支持按需使用、自动弹性伸缩，可动态替换、灵活部署，支撑高性能、高吞吐量、高并发、高可用业务场景

 

2.5      用户体验和自动化运维原则

 

面向业务获取和使用场景，构建实时、按需、在线、自助、社区化、方便易用的用户体验；支持远程、自动、智能、安全、高效地完成网规/网设、安装、部署、调测、验收、扩缩容、软件升级、打补丁、平常维护、问题处理

 

2.6      开放生态原则

面向生态场景，按需开放平台设施、中间件、数据、业务逻辑、UI等能力，构建开放生态，支持分层、远程、自动、自助、简单高效地完成定制、集成、第三方应用开发

 

2.7      高效开发原则

建立支持迭代、增量、持续交付的架构，支持部件独立开发、自动化编译构建、测试、集成验证，并易于高效修改和持续优化；支持开发组织小型化、扁平化，支持小团队独立高效并行开发

 

2.8      安全可靠环保原则

• 构建最小权限、纵深防护、最小公共化、权限分离、不轻信、开放设计、彻底仲裁、失效安全、保护薄弱环节、安全机制经济性、用户接受度以及增强隐私保护的安全体系，确保系统、网络和数据的机密性、完整性、可用性、可追溯；以业务系统零故障为导向，按需构筑分层分级的可靠性，经过故障的预测、预防、快速恢复，避免故障的发生；系统资源使用效率最大化，实现节能、节地、节材、环保

 

2.9      柔性供应制造原则

• 模块化设计，模块/物料归一化、标准化，支持自动化、数字化、智能化、随需应变的柔性制造

 

2.10   持续演进原则

• 架构并不是一蹴而就，须要有效地管理架构需求，持续构建和发展架构，适应业务需求变化，适时引入业界最佳实践，及时重构，确保架构生命力和竞争力
• 因为影响架构设计的各个质量属性之间存在必定的联系和冲突，好比：高的性能需求会致使成本的上升，高的可靠性要求也会致使成本的上升，扩展性的提升可能会牺牲必定的性能，而可移植性好则会提高架构的可重用性等等。所以架构设计时必须对各个质量属性的进行权衡，而权衡的依据就是架构设计的商业目标，包括：目标市场、架构的应用范围、上市时间、成本和收益、生命周期、与老系统的集成、关键需求（质量属性需求）、开发过程和约束等，只有肯定了商业目标才能肯定架构设计的方向并对各个相互冲突的质量属性进行仲裁和权衡。
• 重用分为几个层次：架构重用、组件重用、设计重用、代码重用。领域架构设计强调的是领域内架构的重用和基于架构的组件重用。架构重用包括：逻辑架构重用和物理架构重用，在可能的状况下要尽可能扩大重用的范围，特别是物理架构的重用，将带来巨大的价值。
• 产品进行系统设计和实现时必须遵循重用原则，产品应用开发时，若是已有领域架构和平台，则其系统设计必须符合领域架构，并应用平台组件开发；若是无领域架构和平台，则须要考虑如何构建领域架构和平台为后续相似产品的重用和共享作好准备。
• 目前大型通讯系统，其需求和规模是很是大的，它的实现通常都要分期分步进行，架构设计要可以支持平台和产品分阶段/增量式实现和交付的要求，具备较强的可修改性和可扩展性。分阶段交付的版本之间要保持兼容性。

2.11   商业目标原则

2.12   重用原则

2.13   支持分阶段交付原则

 

3      架构分析方法

3.1      领域需求

要点：

一、  收集需求

• 保证全面——尽可能收集；
• 识别重点；
• 深刻理解，了解客户背后的声音。

二、  定义环境与系统边界

• 划分系统边界；
• 明确与已有系统的关系；
• 划分大的解决方案下的多个系统之间的边界。

 

三、  描述需求

四、   

3.2      领域分析的关键要点

建立领域分析模型

肯定分析模型的职责和接口

 

3.3      逻辑架构设计

3.3.1        逻辑架构的要点：

一、  需求包含：功能性需求+非功能性需求

二、  分层定义子系统

三、  定义可重用架构（公共机制、设计框架）

四、  关键流程演绎（模块交互顺序和操做、识别关键技术）

 

3.3.2        逻辑架构构件块：DM（Deployable Module）

• DM -  Deployable Module
  • DM内部紧耦合，DM之间松耦合
  • DM具备明肯定义的接口和规格
  • DM是与实现无关的
  • DM是与物理位置无关的，能够灵活部署的
• DM是构成设计阶段设计模型的重要模型元素，因此DM也能够称为设计模块（Design Module）。做为领域架构的基本组成单元，DM不只要可以知足部署的需求，还要
  • 实现架构层次的质量属性
  • 达到架构重用的目的
  • 符合架构管理的要求
  • 能顺利进入下一道工序: IM设计

 

TIPS：DM本质就是一个功能模块，上述特征决定它又不一样于通常意义上的功能模块。DM的规模也不是固定的，规模取决于须要，这包括架构描述的须要，质量属性设计的须要，下一步设计和开发工做的须要，部署的须要，甚至架构管理的须要。

 

3.3.3        逻辑架构设计的通常方法

• 自顶向下，分而治之
  • 分平面：按制平面、管理平面、用户平面/转发平面/数据平面
  • 分层：层次模型、洋葱模型
  • 分子系统
• 自底向上，抽象封装
  • 从分析模型出发，或从现有产品模块划分的状况出发，将小的功能块（或对象）分组打包
• 通常状况下是二者相结合
  • 经过自底向上的方法获得DM
  • 将DM对应到合适的层或子系统

 

3.4      实现分析

3.5      物理架构实现