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

这可能是一个有争议的话题，是否有必要，还是要结合实际情况。

什么是建筑设计？

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

我的理解是，大概有以下两个原因：

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

(2)嵌入式开发：Linux独大。在嵌入式系统的开发中，操作系统的选择余地几乎没有，大部分都是ARM Linux组合。

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

在应用层面：如果开发者没有什么追求，只能实现规范中定义的功能。而老板只关注产品功能能否正常实现。至于可移植性、可扩展性、执行效率等。他不会想到这种程度。

即使产品需要更新，也要让开发者重新实现。反正功能还可以。

2.嵌入式系统架构设计的重要性。讲个小故事。一个同事给一个客户写了一个单片机产品的程序，后来离职后把代码交给了我。这个产品有一个小功能需要修改。正好我当时在做另一个项目，所以我在老板允许的情况下把源代码发给客户，让他们自己修改。

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

过了一会儿，我问客户：上次那个产品的功能修改怎么了？他说，这it’还没有完成。上次你给我的密码丢了，会死人的。现在我我将从头开始重写代码。

这个故事是真的。所有的代码都是由字符组成的，有的代码看起来顺眼，有的代码看起来可疑。没有架构设计的代码有这些缺点：(1)代码可以被重用，所以它移植起来很麻烦。(2)当需求发生变化时，代码不能快速调整。(3)对于现有代码：don don’我不敢改变它。I don’我不想改变它，我想领先。

(4)调试bug是一件很头疼的事情。

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

对于项目：

(1)项目周期可控

(2)代码可读。

(3)功能可扩展。

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

(5)平行发展。

(6)单元测试方便。

对于开发者来说：(1)节省开发时间；(2)提高从全球视角开发大型项目的能力；(3)调试简单快捷。

架构怎么设计？

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后，再放到真正的嵌入式系统中进行联调，可以节省很多时间。

演示描述

1.简介本演示摘自一个智能家居项目，它只反映了各个功能模块的设计。函数内部没有函数，只是用来展示设计过程。2.获取https://pan.baidu.com/s/1B3F9byydXeNWdtgYEEQNLg密码的代码：3a9p可以在Ubuntu16.04系统下直接编译执行。3.系统架构图

4.目录结构Makefile:编译脚本应用：业务层模块：功能模块层驱动：硬件驱动第5层。执行序列演示图中的橙色箭头表示控制指令是从云发出的。服务层收到指令后，解析指令并发送给控制模块。控制模块再次解析特定指令，将其发送到ZigBee设备，并将其记录在日志中。

hfy