1 什么是架构
三要素：
1、 构件
2、 构件之间的关系
3、 构件与环境之间的关系
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 领域需求
要点：
1、 收集需求
- 保证全面——尽量收集；
- 识别重点；
- 深入理解，了解客户背后的声音。
2、 定义环境与系统边界
- 划分系统边界；
- 明确与已有系统的关系；
- 划分大的解决方案下的多个系统之间的边界。
3、 描述需求
4、
3.2 领域分析的关键要点
创建领域分析模型
确定分析模型的职责和接口
3.3 逻辑架构设计
3.3.1 逻辑架构的要点：
1、 需求包含：功能性需求+非功能性需求
2、 分层定义子系统
3、 定义可重用架构（公共机制、设计框架）
4、 关键流程演绎（模块交互顺序和操作、识别关键技术）
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 物理架构实现