1.SOA架构：服务和微服务分析及设计--- 理解面向服务

3.1　面向服务简介 3.1.1　业务自动化中的服务 一般来说，服务是一款软件程序，其通过发布API(服务契约的一部分)实现其功能的可用性。web服务契约通常由WSDL定义和一个或多个XML Schema 定义组成。作为rest 服务实现的服务通过统一契约访问。服务契约可以进一步由人类可读文档组合而成，例如描述附加服务质量保证，行为和限制的服务水平协议(SLA)。3.1.2　服务是能力的集合 在讨论服务时，重要的是记住单个服务可以提供一个提供能力集合的API。因此，服务本质上是相关能力的容器。它由一组皆在执行这些功能的逻辑体和表明其功能可用于公共调用的服务契约组成。服务消费者是当软件程序访问和调用服务时的运行时的角色，或者更具体的说，当它向服务契约中表示的服务能力发送消息时软件程序采用的运行时角色。在接收到请求时，服务开始执行调用能力所包含的逻辑，执行后可能会向服务消费者返回相应的响应消息也可能不会返回。服务消费者可以是能通过其API调用服务的任何程序软件。一个服务本身也可能扮演另外一个服务消费者。3.1.3　面向服务是一种设计范式 设计范式是设计解决方案逻辑的一种方法。在构建分布式解决方案逻辑时，设计方案通过一种称为"关注点分离"的软件工程理论而实现。这个理论说明，将更大的问题分解成一组较小的问题或者关注点时，这个问题就能有效的解决。这让我们产生了将解决方案逻辑划分为多个功能的想法，每个功能都皆在解决单一的关注点，相关功能可以分组为解决方案逻辑单元。面向服务体现在：面向服务执行关注点分离的方式以及它如何塑造具有特定特性和支持特定目标状态解决方案逻辑的单个单元。从根本上说，面向服务将适合的解决方案逻辑单元整合为企业资源。服务，作为面向服务解决方案的一部分，以具有明显设计特征的独立物理软件程序而存在。每个服务均分配了代表自己典型功能的上下文，并且由该上下文相关的一组能力组成。服务组合是服务的协同聚合。服务目录是描述企业内或企业内有意义部分边界中，互相依赖的服务的独立标准化和管理化的集合。当组织有多个服务目录时，此术语进一步定位为域服务目录。在面向服务的应用中，服务目录对于建立本地服务间的高度互操作性是至关重要的。这支撑着有效服务组合的重复创建。服务被发布到服务目录中，而服务组合中的服务则来源于服务目录。1.面向服务的解决方案逻辑通过服务和工具面向服务设计的服务组合来实现2.服务组合由一系列组装起来以提高特定业务自动化任何或流程所需功能的服务组成3.因为面向服务将许多服务形成企业资源，所以一个服务也许会被多个消费者程序调用，每个消费者程序可以涉及不同服务组合中的相同服务。4.标准化服务集合能够形成在自己的物理部署环境内独立管理的服务目录的基础5.通过从服务目录中的现有不可知服务池中创建服务组合可以使多个业务流程实现自动化3.1.4　面向服务的设计原则 1.标准化服务契约：同一服务目录中的服务符合相同的契约设计标准服务通过服务契约表达其目的和能力。这可能是最基本的原则，因为它基本上规定了以标准化方式分隔和发布面向服务解决方案逻辑的需要。它还特别强调服务契约设计，以确保服务表现功能方式和定义数据类型方式保持相对一致。2.服务松耦合：服务契约降低消费者耦合需求，并且它们自身与它所在的周围环境解耦耦合是指两个事物之间的依赖性的程序。这个原则在服务边界内部和外部建立特定的关系类型，并且持续强调("松散化")服务契约，实现服务契约和服务消费者之间的依赖性。服务松耦合促进服务逻辑的独立设计和演进，同时保证基本的互操作性。3.服务抽象：服务契约只包含基本信息，以及那些仅限于服务契约中发布的信息抽象设计面向服务的许多方面。从根本上来说，这一原则强调需要尽可能多的因此服务的内部细节。这样做直接实现了前述的松耦合关系。服务抽象在服务组合的定位和设计中也起着重要作用。4.服务可重用性：服务保护并显示不可知的逻辑，可以定位为可重用的企业资源 每当构建一个服务时，我们会寻找方法使其潜在能力得到最佳发挥而非仅仅针对一个目的。面向服务极大的强调了重用，因此它成为设计过程的核心部分，并且也是关键服务模型的基础。5.服务自治：服务对其内部的运行时执行环节进行高度的把控为了使服务能够持续可靠的发挥其功能，其内部的解决方案逻辑需要对其环节和资源进行最大程度的把控。服务自治能够在上线生成环节中有效实现其他设计原则。6.服务无状态：服务通过必要时推迟状态信息的管理来最小化资源消耗过度的状态信息管理可能会损害服务的可用性以及其行为的可预测性。因此，服务被理想化的设计为仅在需要时维持状态。与服务自治一样，这是另外一个更少关注契约，更多关注内部逻辑的设计原则。7.服务可发现性：服务补充了交互元数据，通过它们可能有效的发现和诠释服务对于定位为具有可重复投资回报率(ROI)的IT资产的服务，当需要重用时，我们需要很容易的识别和理解这些服务。因此，服务设计需要考虑服务契约和能力的"通信质量"，而不管诸如服务注册表的发现机制是否是环境的直接部分。8.服务可组合性：服务是有效的组合参与者，无需考虑组合物的大小和复杂性随着面向服务解决方案复杂性的增加，潜在服务组合配置的复杂性也随着增长。有效组合服务的能力是实现面向服务计算的一些基本目标的关键要求。复杂的服务组合对服务设计提出了要求。服务有望作为有效的组合成员参与，无论它们是否需要立即加入组合。3.2　面向服务所解决的问题 3.2.1　竖井式应用架构 从这些应用程序进一步获取任何价值的能力往往会被抑制，因为它们的能力与特定的业务需求和流程相关。当新需求和流程符合业务方式的时候，我们就要对已有的应用程序做重大变化或者完全建立一个新的应用程序。3.2.2　大量的浪费 独立开发不同应用可能会产生大量的冗余功能。3.2.3　缺乏效率 由于战术重点是为特定流程需求交付解决方案，所以开发项目的范围具有高度针对性。3.2.4　企业膨胀 3.2.5　产生复杂的基础设施和错综复杂的企业架构 3.2.6　系统间集成成为永恒的挑战 3.2.7　面向服务的需求 1.提高了功能和数据表达的一致性2.降低了解决方案逻辑单元之间的依赖性3.降低了对底层解决方案逻辑设计和实现细节的关注4.增加了将解决方案逻辑单元组合成不同配置的机会5.提升了行为可预测性6.提高了可用性和可扩展性7.提高了对可用解决方案逻辑的认知3.2.8　增加大量可复用解决方案逻辑 在面向服务的解决方案中，逻辑(服务)单元封装了不属于任何应用或业务流程特有的功能。这些服务被归类为可重用(和不可知)IT资产。3.2.9　削减应用个性化业务逻辑 增加不针对任何一个应用程序或者业务流程的解决方案逻辑数量，减少所需的针对应用程序逻辑的数量。3.2.10　削减业务逻辑的总量 3.2.11　本征互操作性 3.3　面向服务对企业的影响 3.3.1　面向服务和“应用”的概念我们非常从容的远离了应用程序以前存在的竖井。因为我们希望尽可能共享可重用逻辑，所以我们通过服务组合自动化实现现有的，新的和增强的业务流程。当组合服务愈加普遍时，应用程序，系统或者解决方案的传统概念实际上会随着容纳它们的竖井逐渐消失。应用程序不再由负责自动化实现特定任务集的程序逻辑自包含体组成。应用程序现在只是另外一种服务组合，其中一些可能参与其他组合。因此，应用程序失去其独立性。可以认为面向服务的应用程序实际上不存在，因为它实际上只是许多服务组合中的一个。3.3.2　面向服务和“集成”的概念服务目录由面向服务原则的服务和已被塑造成标准化(大部分)可重用的解决方案的逻辑单元组成。我们可以看到，这将挑战传统的"集成"概念。在过去，集成意味着两个或者多个兼容或不兼容的应用程序连接起来。3.3.3　服务组合3.4　面向服务计算的目的和优势 3.4.1　增强本征互操作性 互操作性指的是数据的共享。软件程序的互操作性越高，它们之间的信息交换越容易。不具备互操作性的软件程序需要集成。因此，集成可以看做实现互操作性的过程。面向服务的目标是在服务中建立天然的互操作性，以减少集成需求。1.标准化服务契约：标准化服务契约，以保证相关操作性的基线测试与数据模型协调2.服务松耦合：降低服务耦合程度并通过降低各个服务于其他服务的依赖性而促进互操作性，因此对不同服务消费者的调用更加开放3.服务抽象：关于服务的抽象细节限制了对服务契约的所有互操作，底层服务逻辑的独立发展增加了互操作性的长期一致性4.服务可重用性：设计服务重用意味着服务和许多潜在的服务消费者之间需要高层次的互操作性5.服务自治：提高服务的个体自治性，其行为变得更加一致可预测，增加其重用潜力，从而实现可达到的互操作性水平6.服务无状态：通过强调无状态设计，服务的可用性和可扩展性增加，它们可以更频繁，可可靠的进行互操作7.服务可发现性：可发现性只是允许服务更容易的定位哪些服务于该服务存在潜在的互操作性8.服务可组合性：最后，为了服务的有效组合，它们必须是可操作的。可组合成功率直接与服务标准化和跨服务器数据交换优化的程度紧密相关3.4.2　增强联合 3.4.3　增加供应商多元化选择 3.4.4　同步提升业务与技术领域 面向服务在多个层次上促进了抽象化。应用功能抽象最有效的手段之一是建立准确封装和代表业务模型的服务层。3.4.5　提高投资回报率 3.4.6　提高组织的业务敏捷性 在组织层面，敏捷性指的是组成能够对变化做出反应的效率。IT部门有时候被认为是瓶颈，需要太多的时间或资源来满足新的不断变化的业务需求，这就阻碍了期望的响应值。这也是敏捷开发受欢迎的原因之一。3.4.7　减少IT成本 3.5　面向服务的4个支撑点 3.5.1　团队合作 ：跨项目团队和合作是需要的3.5.2　教育 ：团队成员必须基于常识和理解进行交流和合作3.5.3　纪律 ：团队成员必须一致的应用他们的常识3.5.4　平衡范围 ：需要实现所需的团队协作，教育和纪律水平程度由有意义但可管理的范围来表示

1.SOA架构：服务和微服务分析及设计--- 理解面向服务相关推荐

[.NET领域驱动设计实战系列]专题二：结合领域驱动设计的面向服务架构来搭建网上书店...
原文:[.NET领域驱动设计实战系列]专题二:结合领域驱动设计的面向服务架构来搭建网上书店一.前言在前面专题一中,我已经介绍了我写这系列文章的初衷了.由于dax.net中的DDD框架和Bytear ...
通俗地理解面向服务的架构（SOA）以及微服务之间的关系
SOA是一种软件的应用架构方法,它基于面向对象,但又不是面向对象,整体上是面向服务的架构.SOA由精确的服务定义.松散的构件服务组成,以及业务流程调用等多个方面形成的一整套架构方法. 这话是不是听起来 ...
【数据分发服务DDS】软件定义汽车【二】- 面向服务的架构设计
引言上一篇文章主要介绍了电子电气架构.车载操作系统.基础软件平台等之间的关系,以及软件定义汽车的基本概念,本篇将继续深入,重点阐述三个问题: 智能电动汽车软件范畴软件+硬件升级的基础面向服务的软 ...
springmvc+spring+mybatis基于soa架构进行框架整合思路分析
springmvc也可以初始化一个容器,因此不必须在表现层整合spring. service打的是war包,其他关联的工程如interface,pojo,dao等最终的形式会被打为一个jar包,会放到 ...
服务端设置忽略更新_深入理解Kafka服务端之日志对象的读写数据流程
一.场景分析在前面几篇分析过,Log类用于管理服务端日志相关的各种操作,如: 日志段管理:滚动生成新日志段.组织并管理分区下的所有日志段等关键偏移量管理:如LogStartOffset.LEO等 ...
【软考系统架构设计师】系统安全分析与设计④ 安全保护等级
>>回到总目录<< 为了不辜负已经订阅了专栏的同学们的信任,所以本专栏不会有任何的优惠活动. 另外,当订阅人数每次达到 2 n ( n > 2 ) 2^n(n>2) ...
【软考系统架构设计师】系统安全分析与设计⑤ 安全防范体系的层次和信息安全体系结构
>>回到总目录<< 为了不辜负已经订阅了专栏的同学们的信任,所以本专栏不会有任何的优惠活动. 另外,当订阅人数每次达到 2 n ( n > 2 ) 2^n(n>2) ...
Java程序员必经的实践之路：微服务与SOA架构
而另一方面,微服务推崇执行的标准(例如HTTP)却是人们广泛了解并共同使用的.我们可以通过选择合适的语言或工具来构建某个组件微服务.SOA与微服务还有一个更大的区别:领域模型.在基于微服务的软件中,每 ...
软件的接口设计图_面向服务架构（SOA）的汽车软件分析和设计
--后台回复"资料",领取特斯拉专利技术解析报告-- 文章转自:联合电子本文将先重温下SOA架构的核心要素与优势,并重点讨论话题"面向服务架构(SOA)的汽车软件分析和 ...
一文读懂 SOA 架构和微服务架构的区别
点击关注公众号,回复"1024"获取2TB学习资源! 场景如果我们打开支付宝首页,去看我们的余额,它会展示你的总资产,昨日收益.累计收益等信息.假如这个页面所展示的信息,都来自各 ...

1.SOA架构：服务和微服务分析及设计--- 理解面向服务

1.SOA架构：服务和微服务分析及设计--- 理解面向服务相关推荐

最新文章

热门文章