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　平衡范围 ：需要实现所需的团队协作，教育和纪律水平程度由有意义但可管理的范围来表示