Qt 项目架构之二：架构设计

除了极小的微型 demo 级别项目外，其余项目建议用 pri 分门别类不同文件夹存放代码文件，方便统一管理和查找。同类型功能的类建议统一放在一起，如果该目录下代码文件数量过多，也建议拆分多个目录存放，比如系统配置的窗体放在一个目录下，日志管理的窗体放在一个目录下。

很多通用功能，多个项目都会用到，可以考虑封装成 pri 形式的模块，俗称轮子，不断完善这些轮子，多个项目共享该模块，一旦遇到 BUG 修复，只需要更改一个地方就行。

项目如果还更大或者项目组人员分配不同功能，可以考虑插件形式，插件一般会用到两种，一种是普通动态库形式的插件，必须和主程序放在一起；一种是 Qt 机制的插件，放在指定的目录。如果只是就 3-5 个界面的项目，统一搞个 form.pri 存放这些界面。

架构可根据从业务需求到系统实现的不同需要分为：业务架构、应用架构、数据架构、技术架构。

一、业务架构

业务架构的设计原则：

• 将业务平台化。业务平台化，相互独立，例如交易平台、物流平台、支付平台、广告平台等。基础业务下沉，可复用，例如用户、商品、类目、促销、时效等。
• 将核心业务和非核心业务分离。将电商系统的核心业务和非核心业务如主交易服务和通用交易服务分离，将核心业务精简（利于稳定），并将非核心业务多样化。
• 隔离不同类型的业务。交易平台的作用是让买家和卖家签订交易合同，所以需要优先保证高可用，让用户能快速下单。履约业务对可用性没有太高要求，但要优先保证一致性。秒杀业务对高并发要求很高，应该和常规业务分离。
• 区分主流程和辅助流程。

二、应用架构

应用架构的设计原则：

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

应用架构有这几种主要类型：单体式、分布式、SOA 架构。

2.1 单体式应用

系统只有一个应用、打包成一个应用；部署在一台机器；在一个 DB 里存储数据。单体式应用采用分层架构，一般为表示层、业务层、数据访问层、DB 层，表示层负责用户体验，业务层负责业务逻辑，数据访问层负责 DB 层的数据存取。

• 优点：开发、编译、调试一站式、一个应用程序包含所有功能点，容易测试和部署。
• 缺点：系统逐渐庞大时，代码复杂度高，难以维护，应用扩展水平低，业务和模块职责区分不清晰。

2.2 分布式架构

分布式应用架构中，相互独立，代码独立开发，独立部署，通过 API 接口互相通信。通讯协议一般使用 HTTP，数据格式是 JSON，应用集成方式比较简化。

• 优点: 应用内部高内聚，独立开发、测试和部署，应用之间松耦合，业务边界清晰，业务依赖明确，支持大项目并行开发。
• 缺点: API 接口需求变化，应用就需要重新部署，通信可靠性和数据的封装性相对于进程内调用比较差。

2.3 SOA架构

SOA 也是分布式应用架构一种， SOA 架构提供配套的服务治理，包括服务注册、服务路由、服务授权、服务降级、服务监控等等，SOA 架构既体现业务的分，又体现业务的合，更多地从业务整体上考虑系统拆分。

• 优点：以服务层为主，聚焦核心业务，同时以提供整个系统共享，服务作为独立的应用，独立部署，接口清晰，很容易做自动化测试和部署， 服务是无状态的，很容易做水平扩展；通过容器虚拟化技术，实现故障隔离和资源高效利用。
• 缺点：系统依赖复杂，给开发/测试/部署带来不便，分布式数据一致性和分布式事务支持困难，一般通过最终一致性简化解决

三、技术架构

技术架构就是对在业务架构中提出的功能（或服务）进行技术方案的实现，包括软件系统实现、操作系统选择和运行时设计。设计原则：

• 无状态。即尽量不要把状态数据保存在本机上。
• 可复用。复用粒度是有业务逻辑的抽象服务，不是服务的实现细节。 服务引用只依赖服务抽象。
• 松耦合。跨业务域调用，尽可能异步解耦。在同步调用时设置超时时间和队列大小。 将相对稳定的基础服务与易变流程服务分离。
• 可治理。服务可降级、可限流、可开关、可监控、白名单机制、制定服务契约。
• 基础服务。基础服务下沉、可复用，例如时效、库存和价格计算。基础服务自治、相对独立。对基础服务的实现要精简，并可水平扩展。对基础服务的实现要进行物理隔离，包括基础服务相关的数据。

四、程序架构总结

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