物理架构创建全解析

### 物理架构创建全解析 #### 1. 多对一关系与物理节点 在系统架构中，存在多对一的关系。逻辑节点最终可能成为物理节点上的分区，而非独立的处理单元，一个物理节点可以满足多个逻辑节点的需求。例如，当选择一个打包应用部署到单个物理节点时（以实现更紧密的耦合、提高性能和管理效率），原本架构在不同节点上的功能可能会整合到这个物理节点上。 #### 2. 识别物理部署元素 考虑到前面提到的一般指导原则，可以按以下步骤开发物理部署元素： 1. 对于每个逻辑位置，确定该位置将有多少个物理实例，以及这些位置在地理上的放置地点。 2. 对于分配到所考虑逻辑位置的每个节点，创建相应的物理节点（要牢记前面提到的拆分或聚合节点的需求）。 3. 将节点与特定的硬件产品进行关联（假设节点是采购而非自行构建的）。如果没有明显的关联，只需列出候选产品，并根据需求（特别是非功能需求）确定首选选项。这可能导致多个节点位于同一位置，每个节点代表一个候选硬件产品。 4. 通过审查非功能需求，根据所需的吞吐量、可用性、可扩展性等，确定物理节点的合适规模（即具有合适数量的实例、磁盘空间、处理器速度等的平台）。在大型分布式系统中，这项任务本身就非常重要，可能需要进行详细的性能建模，可能还需要构建进一步的架构概念验证来支持规模估算。 以下是一个示例，展示了YourTour系统中央办公室位置的物理部署模型： | 设备名称 | CPU | 型号 | 内存 | 制造商 | 磁盘 | | --- | --- | --- | --- | --- | --- | | 旅游预订服务器 | 2x1.2GHz | p320 | 4Gb | IBM | - | | 数据库服务器 | 2x1.2GHz | p320 | 2Gb | IBM | - | | 安全服务器 | 1x1.2GHz | p310 | 1Gb | IBM | - | | 管理客户端 | 1x1.2GHz | Dimension | 2Gb | Dell | 160Mb | | Web服务器 | 1x1.2GHz | p310 | 1Gb | IBM | - | | 集成服务器 | 2x1.2GHz | p320 | 2Gb | IBM | - | | 内容管理服务器 | 1x1.2GHz | p310 | 1Gb | IBM | - | | 磁盘阵列 | - | Fire X4140 | - | Sun | 1Tb | mermaid代码如下： ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A(逻辑位置):::process --> B(确定物理实例数量和位置):::process B --> C(创建物理节点):::process C --> D(关联硬件产品):::process D --> E(确定物理节点规模):::process ``` #### 3. 采购硬件 逻辑部署模型是实现正在开发的系统所需的部署元素的规范。与功能元素不同，实现系统部署方面所需的项目更有可能是购买而非自行构建。除非正在开发的系统非常特殊，否则极有可能使用现成的硬件来实现物理架构中指定的物理节点描述。 在决定需要购买哪些硬件元素后，可能需要遵循某种采购流程，以确保正确选择硬件。当有多种硬件选项支持相同的硬件规格时，这种指导尤为重要。 #### 4. 验证架构 功能模型和部署模型通常由不同的角色开发，这两个模型不可避免地会在一定程度上出现不一致。此任务的目的是确保架构在这些工作产品中定义一致，并且它们共同满足所有需求。验证有助于回答“我是否正确构建了产品？”这个问题，即是否遵循了方法并符合任何开发标准。其次要目的是确保架构决策工作产品中记录的所有决策（可能通过架构概念验证获得的数据进行量化）都反映在架构模型中。 #### 5. 构建架构概念验证 在对架构中使用的特定技术做出关键决策后，通过创建架构概念验证来证明架构的可行性通常是有意义的。然后可以利用构建和执行此概念验证所获得的信息来完善架构。以下情况应考虑创建架构概念验证： - 某些功能需求仅部分得到解决，需要进一步验证。 - 性能或其他所需的系统质量可能成为问题，需要建立详细的指标来证明系统可能满足这些质量要求。 - 某些组件被认为具有高风险或处于技术前沿，需要进行验证。 - 所使用的产品需要与其他产品或现有系统进行接口，这些接口需要验证。 - 所使用的产品有现有的用户界面，需要向最终用户展示以验证他们的需求是否得到满足。 - 所使用的产品或软件包需要复杂的定制或配置（某些产品可以有多种配置方式，这可能会影响产品的性能或可用性）。 架构概念验证的上下文和范围通常通过审查各种架构模型来确定，这些模型将突出上述列表中的一个或多个关注点。还应检查项目风险、假设、问题和依赖项（RAID）日志，以帮助确定已识别的技术风险领域，并确保概念验证在必要和适用的情况下专注于解决这些领域的问题。 #### 6. 细化功能元素 与概述功能元素任务一样，每种技术都有其独特之处，会影响以接口和操作签名定义的功能元素的细化。例如，通过业务接口而非直接访问EJB实现（Java EE环境会将正确的代码注入应用程序以实现此访问）。 在这项任务中，考虑这些特性，同时提供足够的信息，使设计师和开发人员能够构建系统。这样，物理架构就成为设计师和开发人员遵循的蓝图。此任务的执行与逻辑架构中细化功能元素的描述完全相同。 在实践中，特别是对于Java EE和.NET等标准技术，通常只需将特定于技术的模式与相关元素关联起来，就可以提供足够详细的规范来支持详细设计或编码。例如，BookTourController是一个无状态会话EJB，可以规定所有EJB都由一个JavaBean类前置，以提供对EJB的简化