第六章 云计算与服务

什么都不做是最难熬的...你永远不知道何时才是尽头。---莱斯利·尼尔森

-------------------------------------------------------------------------------

服务代表行为或它完成的工作，如：更新客户信息、删除客户、计算保险风险和检查信用等。可以把服务理解成功能行为的集合，这些行为可以单独访问也可以成组访问。本章阐述的是如何有效地使用服务通往云计算。从宏观上看，将服务移入云计算平台的整个流程如下：

1.理解现有结构

2.标识架构内的现有服务

3.在目录中记录并列出服务

4.定义目标架构、包括云计算方法的使用。

 

将架构分解成一些逻辑的、功能性的元件，再将这些元件组装成一组服务，所以将架构看做服务的集合，即SOA。

 

服务处理的往往是信息，服务往往要绑定数据。

 

候选服务是在问题域中找到的所有可能转变成实际服务的服务。列出它们是为了通过标识并排序所有这些服务，确保找到正确服务。交付的是一组服务以及每个服务功能的描述。

服务和信息为候选服务及其绑定的数据建立关联。

服务模型是从候选服务列表中选出的一组服务，它们与架构密切相关。

 

                          创建服务模型

                                 |

                                 |       ________

                                 |------|              |

        数据目录 -------->        | 理解服务 |--------->候选服务

                           |              |_______|

        信息模型------                      |

                                                  |

                                                 ˇ

                                          ___________

                                          |                    |

                                          | 从信息到服务 |----->关联信息的服务

                                          |__________ |

                                                   |

                                                   |

                                          ___  ˇ______

                                         |                      |

                                         | 构建服务模型   |------>服务模型

                                         |___________|

 

服务是什么：使用服务通常是远程方法或行为。SOA与融合云计算的SOA的基本理念是在某种受控的基础设施里使用这些远程服务，让应用程序像调用本地服务一样访问远程应用服务。它的目标是由多个本地或远程应用服务组装的复合应用。

注意，此架构中的服务具有以下能力：不论服务位于何处，本地或云平台中，通过本地网络或是因特网，它们可以像本地服务一样被调用；由于服务接口通常是标准的（如WSDL或SOAP），可以在复合应用或流程中进行服务混搭；可以集中管理和治理服务。

理解云的耦合性：耦合可以理解成一个组件对另一个组件的依赖程度，紧耦合的系统或架构是相互依赖的；松耦合的系统或架构使用的是独立组件，能独立运行。

 松耦合的价值：1.松耦合的架构使得可以在不影响架构/系统中其他组件的前提下修改甚至替换组件；2.开发者不需要担心与其他技术的依赖关系，选择正确的技术完成工作即可；3.有了这层独立性，组件之间可以相互收到保护的，并且能够很好的从组件失败中恢复过来。

但并非所有的紧耦合都不好。某些情况下，紧耦合组件也是可取的。

松耦合的特点：1.位置独立性。不论服务处于何处，需要使用该服务的组件都可以从服务目录中找到它并通过延迟绑定访问它。

                    2.交互独立性。不论组件使用何种接口和协议，他们之间可以相互通信。

                    3.安全独立性。协调组内以及组件之间不同的安全模型。

                    4.实例独立性。指的是架构既支持组件间的同步交互，也支持异步交互。

定义元服务：在理解并收集服务信息时候，需要一些信息，称为元服务或描述服务的数据。此后再创建服务目录，并使用它记录服务的详细信息。这些基本信息包括服务的目的、接口、参数、规则、逻辑、所有者、语义、包含的服务及其他。

创建服务目录：利用元服务创建服务目录。服务目录是有关服务信息的数据库，包含以下几个方面信息：语义、目标、认证、依赖关系和服务级别等，此外还有所有者、使用技术、编程模型、结构图、流程图和接口定义==。创服务目录的最终目的是驱动流程的建设，包括创建流程、信息模型以及最终服务模型。

----------------------------------------------

服务治理：

①设计时治理。提供一个从服务设计到服务部署的各个环节对服务进行管理的整合注册库或存储库。关键组件：跟踪服务设计、管理、策略、安全；设计工具；部署工具。

②运行时治理。服务运行时的管理，应该与设计服务治理关联。一般包括：服务发现、服务交付、安全、服务校验和审计与日志==。