系统建模：了解逻辑和物理架构
逻辑和物理体系结构规范的目的是分别定义和记录系统的逻辑和物理组件，以使这些组件元素之间如何相互关联变得更加清晰。由于付出的努力而产生的工件可能是文本文档或图表，两者都有其自身的优点和缺点。
文本文档通常可以更快地生成，但是除非可以应用某种体系结构文档标准，否则一个系统团队之间的格式可能（并且可能会）变化最少。这种差异可能导致所产生的工件难以在其起源的团队之外理解。如果开发人员在团队之间没有太多变动，或者新开发人员大量涌入团队，则可能不会引起太大的关注。确保所有移动部件或它们之间的连接都被完全考虑也可能是困难的。
图表的主要优点是相对容易理解。如果该图具有明显的指示符或明确表示例如一个组件是数据库服务而另一个组件是应用程序的符号，则它们之间的区别一目了然。图还具有非技术人员更容易理解的优点。
在这两种情况下，基于文本或基于图表的文档显然都非常有用，如果它们结构良好，并提供了系统的准确视图或模型。
逻辑架构
与物理相比，开发通常更关注系统的逻辑体系结构。假设为将系统中的实际代码部署，生存，连接和使用与逻辑组件相关的各种物理组件所需的任何机制都已到位，并且几乎不考虑任何物理体系结构约束通常需要更多信息，因此从该角度看，给定组件存在的位置并不重要。这通常意味着物理体系结构故障充其量是一个不错的选择，或者最多应该是一个应有的选择。这也假定所讨论的结构不是很普遍的东西，以至于需要对其进行记录。例如，有
用户通过演示层进行请求
该请求已移交给应用层
应用程序从数据层检索所需的任何数据，也许在流程中进行了一些操作或汇总
应用层生成响应并将其递回给演示层
展示层将该响应返回给用户
看起来有点像这样：
这种三层体系结构在Web应用程序中尤为常见，其中：
Presentation Tier 是Web服务器（Web浏览器只不过是远程输出呈现组件）
应用层 是用任何语言和/或框架编写的由Web服务器调用并生成响应的代码
数据层 是可以在请求之间保留应用程序数据的多个后端数据存储变体中的任何一个
例如，考虑以下用于加油跟踪系统概念的逻辑体系结构。它适用于具有特定标识的组件的Web应用程序，它是此三层体系结构的一个很好的示例：
物理架构
逻辑和物理体系结构文档之间的主要区别在于，尽管逻辑体系结构的关注点以标识系统的功能元素而告终，但是物理体系结构又采取了另一步骤，即指定这些功能元素在其上执行的实际设备。逻辑体系结构中标识的各个项目可以物理上驻留在公共设备上。
实际上，唯一的限制是物理设备的性能和功能。这意味着这些不同的物理体系结构在逻辑上都是相同的。它们都是实现相同的三层Web应用程序的逻辑体系结构的有效方法：
虚拟化和云的影响
目前随着热情的虚拟化，无服务器，并在基于云的技术 行业 的公共云和私有云技术，如Amazon Web服务和VMware提供的，无论是在物理架构规范确实是一个物理架构往往成为狡辩一个语义的东西。尽管在某些情况下，可能没有单一的，可识别的物理计算机，就好像只有专用的服务器硬件那样，但在许多情况下，区分是无关紧要的。如果它充当不同的物理服务器，则可以将其视为定义物理体系结构的服务器。从文档的角度来看，在这种情况下，将虚拟服务器视为真实服务器不会损失任何知识价值。
在考虑系统中的许多无服务器元素时，仍然可以将几个表示为物理体系结构元素-只要从与其他元素交互的角度来看，它像一个真实的设备一样工作，则表示就足够了。 ，假设该Web应用程序完全存在于某些公共云中，其中：
该云允许定义无服务器功能，将定义
功能以处理以下内容，其中每个实体的后端数据库也都位于云中：
顾客
产品展示
订单
相应的物理体系结构可能如下所示：
这种无服务器架构的示例现实实现可以在所有三个大型公共云中实现：Amazon Web Services（AWS），Azure和Google Cloud Platform（GCP）。
这些公共云平台中的每一个都提供可以为网站甚至数据库提供服务的虚拟服务器实例。当网站将事件发送到处理器元素中的功能时，此结构中的处理器服务器可以使用无服务器功能（AWS Lambda或Azure和GCP中的Cloud Functions）来驱动网站与数据库之间的交互。
1