初识服务计算 2020-08-31 笔记 暂无评论 1164 次阅读 [TOC] # 开始之前 ## 下载文献 想了解一个知识，最好还是直接找论文。 这次是通过[小米文献](https://www.mixueshu.com/)，搜索“service computing”，看搜索结果中的第一篇文献，也是引用次数最多的一篇。 点进去复制其DOI号，通过[sci-hub.shop](https://sci-hub.shop/)免费下载。 [《serviceoriented-computing-concepts-characteristics-and-direction.pdf》](https://www.proup.club/usr/uploads/2020/08/550644654.pdf) ## 凭经验的理解 **什么是服务：** WebAPI提供的就是服务。 apache、MySQL等，提供的都是服务。 游戏服务器，提供的也是服务。 总的来说，C/S架构、B/S架构中的服务端，就是用来提供服务的。 **用服务（WebAPI）有什么好处：** 1. 是一种抽象 - 对底层来说，目标会非常明确，有助于代码的编写 - 对高层来说，隐藏了实现细节，能让复杂的系统变得更加逻辑清晰 2. 方便跨平台 - 可以让网页端、手机端、桌面端，访问同一个WebAPI来获取相同的服务。 3. 方便扩展功能 - 服务与服务之间，几乎是没有关联的。 - 想增加或者修改哪一个服务，对其他的服务几乎没有影响。 4. 可以将多个服务，分散部署在多个服务器上 - 如果恰好有多个服务器，这么做可以充分利用服务器资源。 - 和中心化稍有不同，因为这是有多个中心。 5. 可以去中心化 - 如果全国各地都有服务器的话，可以把同一个服务，部署在各地的服务器上。 - 用户可以就近获得服务 - 哪怕有一个服务器挂了，还有多个服务器可以提供相同服务 # 看论文 - 面向服务的架构（Service Oriented Architecture, SOA） - 将软件应用程序和基础设施重组为一组交互服务 - 不能解决： - 管理 - 服务编排 - 服务事务管理和协调 - 安全性 - 扩展的面向服务的架构 - 使用网格服务（grid services） - 类似于“开发市场” - 组合和协调服务 - 管理服务 ## 面向服务计算 - 面向服务计算（Service-Oriented Computing, SOC） - 是一个计算范式（computing paradigm） - 利用服务作为开发应用程序/解决方案的基本元素 - 依赖于：面向服务的架构（Service Oriented Architecture, SOA） ## 服务 - 服务 - 是自描述的、与平台无关的计算元素 - 支持快速、低成本地组合分布式应用程序 - 执行从简单请求到复杂业务流程的任何功能 - 允许公开其核心能力 - 使用标准语言（基于XML的）和协议 - 通过互联网（或内部网） - 基于开放标准的自述接口 ### 服务的特点 - 服务应该满足： - 技术中立 - 协议、自述、发现机制，应符合普遍标准 - 低耦合 - 不需要依赖客户端或服务端的知识?、内部结构、上下文 - 地址透明 - 客户端不用考虑服务端的(IP?)地址，就可以定位和调用服务 ### 服务的类型 - 服务的类型 - 简单服务（Simple services） - 复用的基本单元 - 合适的 - 现成的 - 可部署成服务的 - 能被管理，以达到服务质量要求 - 复合服务（composite services） - 组合现有的服务 - 服务可能来自多个服务提供商 - 可以用来创建分布式应用程序 ### web service - web service - 由URI(统一资源标识符,Uniform Resource Identifier）标识 - URI与URL的区别： - URI：是抽象概念。满足以下三点的，就是URI - 资源的命名机制 - 存放资源的主机名 - 资源自身的名称 - URL：是URI的一个子集，有固定的格式： - `protocol :// hostname[:port] / path / [;parameters][?query]#fragment` - URI的特点： - 使用标准的Internet语言和协议，通过编程方式在Internet上公开其功能 - 可以通过基于开放式Internet标准的自描述接口（例如，在基于网络的存储库中发布的XML接口）来实现 - SOAP(Simple Object Access Protocol) 简单对象访问协议 - 用来通信 - WSDL(Web Services Description Language) Web服务描述语言 - 用来描述服务 - UDDI (Universal Description Discovery and Integration) 统一描述、发现和整合规范 - 用来注册和查找服务 - [↓]使用的是公共的、不安全的、低保真度的交互机制 ## Web server和WebAPI web service和webAPI是两个东西。 - web service - 用HTTP的通道，SOAP通信协议 - XML格式 - 有状态 - 客户端可以让服务端上创建对象，返回Session - 只能部署在IIS上 - webAPI - 用HTTP通信协议 - JSON格式 - 无状态 - 可以部署在IIS和应用程序上 ## ASP软件模型 - ASP(Applications-service-provider) - 是第三方实体，用来部署、托管： - 对打包好的应用的访问控制 - 交付基于软件的服务/解决方案 - 从中央数据中心，横跨广域网，到消费者 - 通过订阅或租赁，从网络上交付服务 - 用于公司的外购信息技术 ASP负责维护软件的基础设施和用户数据。 - ASP的局限性 - 无法开发： - 无法开发高度交互式应用程序 - 无法开发完全定制化的应用程序 - 原因： - 单片(monolithic)架构 - 高度脆弱 - 特定于客户 - 紧耦合（无法复用） - 改进： - 松耦合异步交互 - 基于XML标准 - 用意图(intention)来与网络上的应用程序通信 ## SOC范式 - SOC（Service-Oriented Computing） - 不是交付应用程序 - 而是交付“业务过程”、“事务” - 应用程序可以动态构建 - 服务可以随意复用 ## 面向服务的架构SOA - SOA（service oriented architecture） - 是一种“重组以前孤立的软件”的一种方法 - 让基础设施变成一组相互连接的服务 - 通过标准接口和消息传递协议访问 - 一旦部署完毕所有服务元素： - 现有的应用程序和未来的应用程序，都可以按需访问这些服务 - 不需要基于复杂的点对点方案和专有协议。 ------  - 客户端（service requestor）(client) - 请求执行服务的软件代理 - 客户端必须能找到所需服务的描述，并且能绑定到提供者 - 服务提供者（service provider） - 提供服务的软件代理(agent) - 软件代理可以同时是**提供者**和**客户端** - 提供者负责发布**服务介绍** - 服务发现机构（service discovery agency） ---- - SOA中服务的基本视图 - **服务接口** 和 **实现** - 黑盒封装（模块化原则） - 服务接口 - 提供了“服务-应用程序”、“服务-其他服务”的通信机制 - 技术上讲，接口是一组“允许客户调用的操作”的签名 - **服务规范**必须明确描述所有“客户需要的接口” - 提供服务的环境必须提供这些“客户需要的接口” - 服务规范（service specification） - 与“组合(composition)元模型(meta-model)”有相同任务 - 提供了“Web接口如何相互交互”的描述 - 将**新的Web接口**定义为**现有接口的集合** - 服务使用接口（service usage interface） - 是服务暴露给客户的简单接口 - 是客户端程序查看的唯一接口  - 服务的界限 - 一边是“服务部署（service deployment）” - 另一边是“服务实现（service realization）” - 划分的界限： - 决定了Web服务接口组合的可替换性粒度 - 是可靠地设计服务的唯一方法 - 引用服务，而不知道实现细节 - 引用的服务包含： - 内部服务（自己的服务） - 采购/租赁/购买的服务 - 外包的服务 - 通过包装器/适配器，来使用老代码 - 服务描述 - 用于宣传服务的功能、接口、行为和质量 - 在服务登记处(service registry)发布 - 是“发现、选择、绑定、组合服务”的必要手段 - 服务质量（Quality of Service, QoS） - 服务计量和成本 - 性能指标（如：响应时间） - 安全属性 - （事务）完整性 - 可靠性 - 可伸缩性 - 可用性 - SOA中的服务设计 - 服务可被各种客户机调用 - 逻辑上与任何调用方分离（松耦合） - 服务可以复用，且不必查看服务内部来了解功能 - 服务对调用者一无所知 - 服务中没有任何关于“消费者正在使用什么服务、处于什么目的、在什么上下文中使用”的任何假设 ## 原版的SOA的问题 - 原版SOA不解决以下问题： - 管理 - 服务编排 - 服务事务管理和协调 - 安全性 - 其他应用于服务架构中的所有组件的关注点 ## 扩展的SOA（Extended Service Oriented Architecture, ESOA） - 服务组合层（service composition） - 包含了必要的角色和功能 - 作为**服务聚合器**的组件 - 服务聚合器（service aggregators） - 由 客户的应用程序/解决方案 调用。 - 是服务提供者 - 有以下功能： - 协调 - 控制**服务组件**的执行，管理数据流（包括服务组件的输出数据） - 监测 - 允许订阅**服务组件的事件/信息**，发布高层的组件事件 - 一致性 - 约束服务组件的参数类型 - QoS组合 - 组合**服务组件**的QoS，以导出复合QoS - 服务管理层（service management layer） - 在金字塔的顶层 - 负责管理、部署服务和应用程序 - 用于业务管理 - 用于垂直业务市场 - 服务管理功能依赖于网格计算  ## 服务网格总线  标签: none 本作品采用 知识共享署名-相同方式共享 4.0 国际许可协议 进行许可。
评论已关闭