从服务到云端：全面解析云服务架构

### 从服务到云端：全面解析云服务架构 #### 1. 服务的层次分解 服务存在着从高到低的层次结构。例如，“租车”服务由“预订车辆”“取车”“还车”等子服务构成，而“预订车辆”服务又包含“识别客户”“选择车辆”和“录入预订信息”等操作。以总账的候选服务为例，“Update_Product”可分解为： 1. Update_Product 1.1 Add_Product 1.2 Edit_Product 1.3 Del_Product 1.4 Check_Product 这种服务分解虽属于架构层面的操作，但任何考虑将云计算作为架构选项的人，包括开发者和项目负责人都可以进行。这只是一种快速分析，用于确定理解云计算选项的基础，并非像某些SOA和企业架构方法所定义的那样完整和严格的架构过程。 #### 2. 什么是服务 使用服务时，我们利用的是远程方法或行为，而非简单地向远程系统提取或发布信息。通常会将远程服务抽象到另一个应用程序中，即复合应用程序，它一般由多个服务组成。 例如，企业内部运行的风险分析流程，用于计算金融交易的风险。这个远程应用服务单独使用价值不大，但当它被抽象到一个更大的应用程序（如交易系统）中时，就具有了额外的价值。 从程序员的角度看，应用服务可视为子程序或方法，用于触发某些操作。SOA和基于云计算的SOA的基本理念是，利用受控的基础设施，让应用程序能够像调用本地服务一样调用远程应用服务，最终形成由多个本地和远程应用服务组成的复合应用程序。这些服务具有位置和平台独立性，可以部署在本地或众多云计算提供商处。 服务在这种架构中具备以下能力： - 无论服务位于本地还是云端，通过本地网络或互联网，都能像调用本地服务一样调用它们。 - 由于接口通常是标准的（如Web服务描述语言和简单对象访问协议），可以在复合应用程序或流程中灵活组合服务。 - 能够集中管理和治理服务。 #### 3. 理解云计算中的耦合概念 在讨论服务和云计算时，耦合是一个关键概念。因为服务不仅托管在不同的数据中心，还可能由多个云计算提供商托管，所以耦合在很多情况下并非理想的架构选择。 自计算机诞生以来，我们一直在处理应用和架构领域中的耦合问题，即一个组件对另一个组件的依赖程度。近年来，趋向于松散耦合有很多合理的原因。紧密耦合的系统或架构相互依赖，一个组件的更改可能会引发多个其他组件的更改；而松散耦合的系统或架构则利用独立组件，能够独立运行。因此，在创建SOA并利用云计算资源时，一般来说，松散耦合的架构是最佳选择。 不过，架构的耦合程度应根据需求来确定，而不仅仅取决于流行趋势。架构师必须理解云计算和松散耦合的价值，做出正确的决策，确保架构与业务目标相匹配。 松散耦合的系统具有诸多优势： - 支持在运行时进行后期或动态绑定到其他组件，并能协调组件在结构、安全模型、协议和语义方面的差异，从而抽象出变化性。 - 与编译时或后期绑定不同，松散耦合不需要在编译时或运行时（同步调用）绑定组件，也不需要同时对所有组件进行更改设计。在利用跨越本地到云提供商的云计算平台进行流程处理时，系统需要独立运行，这种类型的耦合几乎是不可行的。 松散耦合架构的优势不仅体现在技术层面，还具有商业价值： - 允许在不影响架构或系统中其他组件的情况下替换或更改组件，使企业能够更灵活地根据需要更改业务系统。 - 开发者可以选择合适的技术来完成工作，而无需担心技术依赖，如安全模型。可以将基于云的平台与本地的其他组件混合使用，以满足特定需求。 - 组件之间相互独立，能够更好地从组件故障中恢复。如果基于云计算的SOA架构设计正确，单个组件的故障不应导致系统中其他组件的崩溃，从而使架构更具弹性。此外，松散耦合也更有利于创建故障转移子系统。 需要注意的是，并非所有的紧密耦合都是不好的。在某些情况下，当组件之间的依赖关系对设计至关重要时，紧密耦合是合理的选择。例如，一个事务性服务需要远程数据库正常运行才能正常工作，那么这些服务应该紧密耦合。 #### 4. 松散耦合的基本模式 松散耦合可以分解为以下几种基本模式： - **位置独立性**：无论服务位于何处，需要使用该服务的其他组件都可以在目录中发现它，并通过后期绑定过程使用它。这在使用物理和逻辑位置不断变化的服务时非常有用，尤其是那些不属于自己组织的服务，如云提供的资源。例如，风险计算服务周一可能在本地运行，周二可能迁移到云端，但这对你来说应该没有影响。动态发现是这个概念的关键，即调用组件可以根据需要定位服务信息，而无需与服务紧密绑定。这些服务通常是目录中的私有、共享或公共服务。 - **通信独立性**：所有组件都可以相互通信，无论它们在接口或协议层面如何通信。我们可以利用Web服务等标准来协调协议和接口的差异。 - **安全独立性**：这是协调组件内部和组件之间安全模型差异的概念。虽然实现起来有一定难度，但