架构设计（Qt项目）

【文火冰糖】架构之路专栏

一、分类

1、可复用模块用pri分门别类不同文件夹存放代码文件。
2、同类型的代码放在一个文件夹中，如界面类、通信类、管理类、配置类等。
3、项目大时用插件组织，两种：一种是普通动态库形式的插件，必须和主程序放在一起；一种是Qt机制的插件，放在指定的目录。

二、架构

技术架构
技术架构3
架构可细分为业务架构、应用架构、技术架构。业务架构是战略，应用架构是战术，技术架构是装备。
架构设计是从业务需求到系统实现的一个转换，是对需求进一步深入分析的过程，用于确定系统中实体与实体的关系，以及实体的形式与功能。架构可根据从业务需求到系统实现的不同需要分为：业务架构、应用架构、数据架构、技术架构。
1、业务架构
（1）业务架构的设计原则
①将业务平台化。◎ 业务平台化，相互独立，例如交易平台、物流平台、支付平台、广告平台等。◎ 基础业务下沉，可复用，例如用户、商品、类目、促销、时效等。
②将核心业务和非核心业务分离。将电商系统的核心业务和非核心业务如主交易服务和通用交易服务分离，将核心业务精简（利于稳定），并将非核心业务多样化。
③隔离不同类型的业务。◎ 交易平台的作用是让买家和卖家签订交易合同，所以需要优先保证高可用，让用户能快速下单。◎ 履约业务对可用性没有太高要求，但要优先保证一致性。◎ 秒杀业务对高并发要求很高，应该和常规业务分离。
④区分主流程和辅助流程。要清楚哪些是电商系统的主流程，在运行时优先保证主流程的顺利完成；对辅助流程可以采用后台异步的方式，避免辅助流程的失败影响主流程的失败回流。

2、应用架构
（1）应用架构的设计原则：
①稳定。◎ 一切以稳定为中心。◎ 架构尽可能简单、清晰，追求小而美，不要大而全。◎ 不过度设计。
②解耦。◎ 将稳定部分与易变部分分离。◎ 将核心业务与非核心业务分离。◎ 将电商主流程和辅助流程分离。◎ 将应用与数据分离。◎ 将服务和实现细节分离。
③抽象。◎ 应用抽象化：应用只依赖服务抽象，不依赖服务实现的细节和位置。◎ 数据库抽象化：应用只依赖逻辑数据库，不需要关心物理库的位置和分片。◎ 服务抽象化：应用虚拟化部署，不需要关心实体机的配置，动态调配资源。
④松耦合。◎ 跨域调用异步化：在不同的业务域之间尽量异步解耦。◎ 非核心业务尽量异步化：在核心业务和非核心业务之间尽量异步化。◎ 在必须同步调用时，需要设置超时时间和任务队列的长度。
⑤容错设计。◎ 服务自治：服务能彼此独立修改、部署、发布和管理，避免引发连锁反应。◎ 集群容错：应用系统集群部署，避免单点服务。◎ 多机房容灾：多机房部署、多活。

（2）类型：单体式、分布式、SOA架构
①单体式应用
系统只有一个应用、打包成一个应用；部署在一台机器；在一个DB里存储数据。
单体式应用采用分层架构，一般为表示层、业务层、数据访问层、DB层，表示层负责用户体验，业务层负责业务逻辑，数据访问层负责DB层的数据存取。
优点：开发、编译、调试一站式、一个应用程序包含所有功能点，容易测试和部署
缺点：系统逐渐庞大时，代码复杂度高，难以维护，应用扩展水平低，业务和模块职责区分不清晰。
②分布式架构
分布式应用架构中，相互独立，代码独立开发，独立部署，通过API接口互相通信。通讯协议一般使用HTTP，数据格式是JSON，应用集成方式比较简化。
优点: 应用内部高内聚，独立开发、测试和部署，应用之间松耦合，业务边界清晰，业务依赖明确，支持大项目并行开发。
缺点: API接口需求变化，应用就需要重新部署，通信可靠性和数据的封装性相对于进程内调用比较差。
③SOA架构
SOA也是分布式应用架构一种， SOA架构提供配套的服务治理，包括服务注册、服务路由、服务授权、服务降级、服务监控等等，
SOA架构既体现业务的分，又体现业务的合，更多地从业务整体上考虑系统拆分
优点：以服务层为主，聚焦核心业务，同时以提供整个系统共享，服务作为独立的应用，独立部署，接口清晰，很容易做自动化测试和部署， 服务是无状态的，很容易做水平扩展；通过容器虚拟化技术，实现故障隔离和资源高效利用。
缺点：系统依赖复杂，给开发/测试/部署带来不便，分布式数据一致性和分布式事务支持困难，一般通过最终一致性简化解决

3、技术架构
技术架构就是对在业务架构中提出的功能（或服务）进行技术方案的实现，包括软件系统实现、操作系统选择和运行时设计。
（1）设计原则：
① 无状态。即尽量不要把状态数据保存在本机上。
② 可复用。复用粒度是有业务逻辑的抽象服务，不是服务的实现细节。 服务引用只依赖服务抽象。
③ 松耦合。跨业务域调用，尽可能异步解耦。在同步调用时设置超时时间和队列大小。 将相对稳定的基础服务与易变流程服务分离。
④ 可治理。服务可降级、可限流、可开关、可监控、白名单机制、制定服务契约。
⑤ 基础服务。◎基础服务下沉、可复用，例如时效、库存和价格计算。◎ 基础服务自治、相对独立。◎ 对基础服务的实现要精简，并可水平扩展。◎ 对基础服务的实现要进行物理隔离，包括基础服务相关的数据。

4、数据架构
数据架构是对存储数据（资源）的架构，其设计原则和应用架构
设计大同小异，在设计时需要考虑系统的业务场景，需要根据不同的业务场景对数据进行异构设计、数据库读写分离、分布式数据存储策略等。

数据架构包括两部分内容：静态部分的内容和动态部分的内容。静态部分的内容的重点是数据元模型、数据模型，包括主数据、共享动态数据和所有业务相关的业务对象数据的分析和建模；动态部分的内容的重点则是对数据全生命周期的管控和治理。因此，不能单纯地将数据架构理解为纯静态的数据模型。业务架构中数据模型的分析重点是主数据和核心业务对象，应用架构中数据模型的分析重点则进一步转换为逻辑模型和物理模型，直到最终的数据存储和分布。

数据分两个层面的生命周期：单业务和跨业务。单业务对象数据的全生命周期，它往往和流程建模中的单个工作流或审批流相关；跨多个业务域对象数据的全生命周期，它体现的是多个业务对象数据之间的转换和映射，往往和端到端的业务流程 BPM 相关。这里要注意，数据虽然是静态层面的内容，但是数据的生命周期或端到端的数据映射往往间接反映了流程，这是很重要的内容。

将数据集成分析分解为两个层面的内容：业务层面的分析，以及应用和 IT 实现层面的分析。前者的重点是理清业务流程或业务域之间的业务对象集成和交互，而后者的重点是如何更好地共享数据或如何通过类似的 BI 工具或大数据平台实现数据的集成和交互。

数据架构的设计原则：
① 统一数据视图。即保证数据的及时性、一致性、准确性和完整性。
② 数据和应用分离。◎ 应用系统只依赖逻辑数据库。◎ 应用系统不直接访问其他应用的数据库，只能通过接口访问。
③ 数据异构。即在源数据和目标数据内容相同时做索引异构，在商品库不同维度的内容不同时（如订单数据中的买家库和卖家库）做数据库异构。
④ 数据库读写分离。◎ 将访问量大的数据库做读写分离，例如订单库。◎ 将数据量大的数据库做分库分表。◎ 将不同业务域的数据库做分区隔离。◎ 对重要的数据配置备库。

三、MVC和三层结构

MVC设计模式(C++版)
三层架构和MVC目的一样的：分层，解耦！

四、总结

1、程序架构：
（1）UI模块：负责处理来自业务逻辑层或者其它模块的数据展示，把用户操作的发送给业务逻辑模块。
（2）通信模块：TCP、UDP、mqtt、串口等，采用单例模式负责外部通信。
（3）数据库模块：读取和保存数据。
（4）业务逻辑模块：处理通信模块的返回数据，并把结果通知UI模块。
（5）中间层：关联通信模块和业务逻辑模块。
（6） 独立模块（初始化配置模块、守护进程、更新模块、日志收集模块…）