软件架构是一个系统的基本组织，体现在它的组件，它们之间的关系和环境，以及指导它的设计和发展的原则。每个嵌入式系统都应该有一个软件架构来指导嵌入式开发人员构建什么。但是，在成功的软件架构的道路上遇到几个陷阱并不罕见。在本帖中，我们将探讨五个嵌入式软件架构陷阱以及如何避免它们。

　　陷阱1——相信进化架构

　　有些开发团队存在一种想法，即在开始编码之前没有必要考虑你的软件架构。相反，人们相信系统软件架构会奇迹般地从无到有，自行发展成可伸缩、可重用、高质量的架构。但是，这种信念似乎源于对敏捷运动思想的曲解。所以，让我们澄清事实。

　　软件架构是一张路线图，一张蓝图，它告诉编码人员他们的代码如何适应更大的难题。软件架构确定了主要的组件、它们的输入、输出以及彼此之间的交互。设计良好的软件架构的一个特点是它可以不断发展，以满足客户不断变化的需求。最成功的团队会花一些时间在软件架构的前期工作。

　　提前花一些时间找出软件架构的各个部分仍然适合在敏捷方法中工作的团队。该架构不需要以瀑布的方式开发，但可以随着细节和经验的积累，通过多次迭代来设计和完善。以这种方式开发的软件架构通常更灵活，并且比嵌入式开发团队希望架构只是出现要成功得多。

　　陷阱2——不遵循数据

　　设计软件架构的一个很好的原则是遵循数据。我的第一个现代嵌入式软件原则是数据决定设计。数据是每个嵌入式系统都要管理的真正资产。数据以各种形式进入系统，形成输入。这些数据输入然后被处理、存储和/或用于从系统产生输出。

　　当你设计嵌入式软件时，你不应该关心使用什么温度传感器，系统中设计了什么按钮，甚至不应该关心使用什么微控制器。相反，设计人员和开发人员应该识别并遵循他们系统中的数据资产。因此，例如，架构应该识别温度数据资产，而不是担心温度传感器供应商。同样，在软件架构中，我们不关心硬件，只关心有一个接口作为温度数据。

　　如果嵌入式开发人员遵循这些数据，在这些数据上执行期望的系统行为所必需的软件架构就会自然而然地到位。奇怪的是，它将创建一个独立于硬件且更容易测试的软件架构。通过软件系统识别和跟踪数据来避免这个陷阱。

　　缺陷3——没有考虑响应时间

　　嵌入式系统通常有与之相关的实时响应要求。例如，如果用户按下紧急停止按钮，系统将在十毫秒内停止。

　　虽然目标是创建可伸缩和灵活的架构，但是软件架构师还需要考虑他们的架构决策对实现的影响。在架构师阶段，它可能无法完全量化响应时间。但是，可以尽快识别和测试高风险区域。

　　开发人员在创建基于任务的架构时遇到困难。如果架构师在基于任务的设计模式方面经验不足，那么响应延迟远远超过预期的情况并不少见。许多定时问题源于中断和周期性任务之间的交互。这个问题有时可以通过将问题任务的架构从基于时间改为事件驱动来解决。

　　缺陷4——没有实施/架构反馈回路

　　当一个嵌入式开发团队把它的软件架构放在一起时，团队表现得好像架构是福音，不能被改变。对于编写代码的开发人员来说，进行架构上的更改，而从不将这些更改反馈给架构师，这种情况并不罕见。缺点是在实现和架构之间需要一个反馈回路。

　　架构师基于他们认为的应用程序的最佳解决方案来构建他们的体系结构。不幸的是，架构师通常没有完全构建架构所需的所有信息。因此，在实现过程中，由编码人员向架构师更新他们的发现、问题等等，以确定整个软件架构的最佳方向。如果编码人员在没有架构师反馈的情况下自己进行更改，他们可能会将系统推向对架构来说不是最佳的方向。结果是代码和架构慢慢积累了阻碍成功的技术债务。

　　陷阱5——选择错误的架构

　　几种不同类型的软件架构可以应用于嵌入式应用。例如，有非结构化整体、分层整体、事件驱动、状态驱动和微服务架构。如果架构师为他们的系统选择了错误的体系结构，他们可能会发现他们在应用程序的伸缩性方面有问题，在响应时间方面有问题，或者其他许多潜在的问题。

　　嵌入式开发人员可能为工作选择错误架构的几个原因。首先，他们可能只是对尝试一种他们从未使用过的新架构感兴趣。虽然扩大自己的视野可能是好的，但设计师必须小心确保他们决定使用的架构类型能够解决手头的问题，并且不会引入复杂性或其他潜在的问题。例如，微服务架构已经变得非常流行，但是如果不小心的话，它们可能会受到复杂性和响应时间问题的困扰。

　　设计嵌入式系统时，请仔细查看数据和数据运行的领域，以帮助确定最适合应用的架构模型。在某些应用程序中，你可能会发现需要混合架构类型来解决问题。

　　结论

　　软件架构是指导开发者成功构建嵌入式应用的关键设计元素。开发人员可以利用广泛的软件架构和设计模式来解决常见的设计问题。在探索这些体系结构和设计模式之前，嵌入式开发人员应该首先检查了五个软件体系结构陷阱，它们会妨碍好的体系结构。