什么是架构设计 如何进行架构设计

这可能是一个有争议的话题，到底需不需要，还是要结合实际情况。

什么是架构设计

1.架构设计概念的认识 相信看这篇文章的同学，大部分都是从事嵌入式开发的，大家也肯定有这么一个印象：在招聘网站上的一些架构设计的岗位，都是针对 Web 方向的，却很少看到招聘嵌入式岗位的系统架构师的岗位。

我的理解是大概有下面2个原因：

（1） Web开发：百家争鸣，没有统一的标准和老大 这些年得益于移动互联网的发展，前、后端开发岗位的需求量大增，而且各种框架层出不穷。 如何利用这些框架来为用户提供高性能的服务并没有一个统一的标准，于是百家争鸣，相应的设计师岗位也就层出不穷。

（2） 嵌入式开发：Linux 舍我其谁 在嵌入式系统的开发中，在操作系统的选择上几乎没有太大的余地，大部分是 ARM+Linux 组合。

在 Linux 操作系统层面：那些大神们已经把内核和驱动层设计的很完美了，很少需要开发人员做大量的修改。

在应用程序层面：开发人员如果没有什么追求，只为了实现规格书中定义的功能即可。 而老板呢，也只是重视产品功能是否能正常实现，至于什么可移植、可扩展、执行效率等等，不会想到这个层面。

即使产品需要更新换代，让开发人员重新实现即可，反正只需要功能OK就行。

2.嵌入式系统的架构设计重要性 说一个小故事。 有一位同事为客户写一个单片机产品的程序，后来同事离职后把代码移交给我。 这个产品有一个小功能需要修改一下，恰巧那会我正在处理另外一个项目，于是在征得老板许可的情况下把源代码发给客户，请他们自己修改。

因为拿到了源代码，客户肯定很开心啊，因为只要吃透了代码，其他类似的设备都可以自己开发了。

过了一段时间，我问客户：上次那个产品的功能修改怎么样了？ 他说：还没搞定呢，上次你给的代码我丢了，会把人看死的，现在正从头重新写代码呢。

故事是真实的。 代码都是字符组成的，有些代码看起来赏心悦目，有些代码看起来怀疑人生。 没有架构设计进行指导的代码，有这些缺点： （1） 代码不能复用，移植很麻烦。 （2） 当需求发生改动时，不能快速调整代码。 （3） 对于已有的代码：不敢改、不想改，牵一发而动全身。

（4） 调试bug很头疼。

相反的，如果架构设计的好，对各方面都有好处：

对于项目来说：

(1)项目周期可控

(2)代码可读性好

(3)功能可扩展

(4)修改单一模块不会影响其他功能

(5)并行开发

(6)单元测试方便

对于开发人员来说： (1)节省开发时间 (2) 全局视角，提高开发大型项目的能力 (3)debug轻松、快速

如何进行架构设计

1.设计文档 只要进入编程领域，大家都知道要高内聚、低耦合，分模块、分层设计。 但是具体需要怎么做？ 如何在规定好的项目周期内把事情做好，而且让自己没那么累？ 如何为自己后期的维护做好铺垫？ 。。。 这些问题可能在项目初期的时候，都规划的比较好。 但是在执行过程中，就会越来越偷懒，越来越偏离预定义的方向。

我的建议是： 无论项目的大小，无论项目周期的长短，一定要有设计文档，设计文档的详细程度就需要根据项目的实际情况进行灵活把握了。 在设计文档中，就要把架构方面的设计体现出来。在实现的过程中，严格按照文档中的要求来做。 取乎其上，得乎其中；取乎其中，得乎其下。

2. 程序文件的物理模型

（1） 分层设计 业务层 功能模块层 驱动层

（2） 分模块设计、 根据功能来划分模块 模块之间通过API接口函数进行数据交互 设计灵活的API接口函数

3. 进程与线程的选择 在嵌入式系统中，实现产品的功能，可以通过多个进程相互配合来完成，也可以用多线程来实现，这个选择没有固定的标准，视项目的具体情况而定。

我一般的做法是： 如果产品功能不复杂，尽量用多线程来实现； 如果产品设计到的功能比较多，那么就把强相关的模块放到独立的进程中。

（1） 使用进程 各模块独立编译，不会相互影响。 出现类似 SegmentFault 问题，很容易定位到肇事者。 方便分布式部署。 代码安全：除了整合人员，其他人只需要 clone 自己负责的模块代码，没有权限、也不需要访问别人的代码。 但是：需要考虑到进程之间的通信问题，比如：IPC调用、socket通信、总线。（我一般都会采用在本地系统内使用一条MQTT总线来挂接所有的通讯模块）

（2） 使用线程 创建线程成本低。 线程之间共享全局变量（换个角度，这也是一种缺点）。 模块之间调用方便，因为函数地址直接可见。

4. API设计 可以把一个模块看成是黑盒，给定一个输入，就会返回确定的结果，或者执行确定的功能， 模块之间只需要定义好这个API接口函数就行。 至于模块内部是如何实现的，大家各显其能。 另外，如果你是API设计人员，一定要注意要让调用者用起来很舒服。就像你递一把剪刀给别人，一定是把手给对方。 另外一个经验，在项目设计初期，尽量不要把API的函数设计的太死板，容易给自己下套。 例如： （1） 可以设计带有 char *的变量，使用json格式的字符串，来传递任意长度和类型的数据。

（2） 可以设计带有 void *的变量，用来传递任意数据类型的地址，这个功能在很多项目中被使用的出神入化，比如：很早之前高通手机的BREW平台，智能家居中的 ZWave平台。

5. 文件目录的设计 这部分容易理解，职责不同的文件要存放到相应的目录中：头文件、库文件、可执行文件、相关文档。如果这部分组织的不够好，当你把项目移交给其他同事时，肯定会被其他人在心中默念一千遍：F-U-C-K Y-O-U！

6.编译脚本的设计（构建工具） 当我们接到一个嵌入式项目时，在确定方案之后，程序运行的平台都是确定的，大部分情况就是嵌入式Linux，或者是一些变体。 在开发阶段，我见过有些开发人员每调试一个功能点，就把代码交叉编译后放，然后通过NFS远程挂载，或者scp远程拷贝，在真实设备上执行。我看着都比较累。

其实完全可以在编译脚本中为不同的平台编译一个版本。 比如：使用Ubuntu系统来开发产品时，只要x86平台可以模拟产品功能，就直接编译x86版本。 当所有的功能点在x86平台上测试OK了， 再统一放到真实的嵌入式系统中进行联调，这样做能节省很多时间。

Demo说明

1.简介 这个Demo是从一个智能家居项目中抽取出来的，只是体现了各功能模块的设计，函数内部没有实现任何功能，仅仅是用来展示设计的过程。 2.代码获取 https://pan.baidu.com/s/1B3F9byydXeNWdtgYEEQNLg 密码：3a9p 在 Ubuntu16.04 系统下，可以直接编译执行。 3.系统架构图

4.目录结构 Makefile: 编译脚本 application: 业务层 module: 功能模块层 driver: 硬件驱动层 5.执行序列演示 图中橙色的箭头，表示从云端发来一个控制指令。 业务层接收到指令后，解析指令，发送给 Control 模块。 Control 模块再次解析具体的指令，发送给 ZigBee 设备，同时记录到日志中。

编辑：hfy