SOA详解微服务与SOA的关系

单体应用
单体应用优化

SOA 面向服务的架构

SOA描述
SOA维基百科翻译
面向服务的体系结构（SOA）是一个式的软件设计风格，是通过应用组件的方式向其他组件提供服务，基于网络的的一个通讯协议。SOA基本原理是独立的供应商，产品和技术。服务 一个独立单元的功能是可以被远程访问可以被独立的操作和更新的，如获取一个在线的账单
甲服务具有4个特性根据给一个的许多定义的SOA：[2]

它在逻辑上代表了一个商业活动与一个特定的结果。
它 是独立的(服务本身是自我包含的)。
这 是 一个黑盒子为它的消费者（里面内容消费者不用管）
它可能包括的其他基本服务。[3]

不同的服务可以联合使用 来构建一个大型软件应用程序。[4]面向服务的体系结构使得它更容易为软件组件，以进行通信和合作过的网络，而不需要任何人类交互或改变在所述底层程序，所以该 服务 考生 可以 被重新设计之前，他们的执行。

总览

在SOA中，服务使用协议来描述它们如何使用描述元数据传递和解析消息。此元数据描述两者的功能特性的所述服务和质量的服务的特性。面向服务的体系结构的目标，以允许用户以结合大数据块的功能，以形成 应用 这 是 构建 纯粹 从 现有的 服务 ，并 结合 他们 在 一个 广告特别的方式**。一个服务提出了一个简单的接口来对请求者是抽象底层的复杂性作为一个黑盒子**，而且用户可以同时访问这些独立的服务并不用了解内部实现。

定义概念

在 相关的 面向服务 ==促进服务之间 的松耦合= 。 SOA 将某个模块功能分离 到 不同的 单位， 或服务，，其开发使访问过一个网络中为了以允许用户以组合和重用他们在该产品的应用。这些服务和它们对应的 消费者 沟通 与 每个 其他 通过传递数据在一明确定义的，共享的格式，或由协调的活动之间2个或更多服务。

原则

目前 有 没有行业标准，涉及到的确切组成的一个面向服务的架构，但许多业内人士都发表了自己的原则。一些的这些包括了以下内容：

标准化 服务 合同
服务 坚持 以 一个标准通讯协议，如定义共同通过一个或多个服务描述文档中一个给定一组的服务。
服务 参考 自治 （一个 方面 的松散耦合）
在 关系 之间的 服务 被最小化到该水平是他们都只是了解的他们的存在。（黑盒 服务之间只是知道其存在不知其实现）
服务 位置 透明度 （一个 方面 的松散耦合）
服务 可以 被称为从任何地方内的网络是它是位于任何事情在那里它是存在。（服务必须存在并且运行）
服务 抽象
该 服务 行为 为黑盒子，那是他们的内在逻辑是隐藏从该消费者。
服务 自治
服务 是 独立 和 控制 的 功能， 它们 封装， 从 一个设计时和一个运行时的观点。（不管运行还是设计，服务都是独立控制的）
服务 无状态
服务 是 无状态的（重要）， 即 是无论是返回的请求的值或者给一个例外，因此最大限度地减少资源的使用。
无状态和有状态的区别
服务 粒度
一个原则，以确保服务有一个适当的大小和范围。该功能提供由该服务来的用户必须是相关的。（功能必须是与用户提供的的相关）
服务 规范化
服务 被 分解 或合并（规范化）以最小化冗余。在一些，这可能不来完成，这是的情况下，其中的性能优化，接入，并汇聚的需要。[15]
服务 可组合性
服务 可以 被使用，以构成其他服务。
服务发现
服务是通过元数据进行交流和补充，他们可以被有效地发现和解析。（重要）

• 元数据（Meta Data）是关于数据的数据，当人们描述现实世界的现象时，就会产生抽象信息，这些抽象信息便可以看作是元数据，元数据主要用来描述数据的上下文信息。通俗的来讲，假若图书馆的每本书中的内容是数据的话，那么找到每本书的索引则是元数据

服务 可重用性
逻辑 被划分成不同的服务，以促进重用的代码。（不通服务提高代码重用性）
服务 封装
许多 服务 这 是 不是 最初 计划 在 SOA， 可以 得到 封装 或成为一个部分的SOA。（SOA逐步更新迭代增加功能）

模式

每个 SOA 构建块 都可以 扮演 以下三个角色中的任何 一个(三个共同构造)：

服务提供者
它创建了一个网络服务（web），并提供其信息到该服务的注册表。每个提供者的辩论在一个很大的怎么样了和个为什么喜欢它服务于暴露，其中，以给更多的重视：安全和方便的可用性，什么样的价格来提供该服务的和许多更多。 该 提供者根据自己的特性和消费者的需求来提供服务，以使用该服务。
服务代理， 服务注册表 或服务存储库
它的 主要 功能 是 ，以使该信息有关（webservice）的网络服务提供给任何潜在的请求者都是可用的。谁实施的经纪人决定的范围中的经纪人。公共经纪人都可以在任何地方和任何地方都可以请求，但私人经纪人都仅提供给一个有限数量的公众。 UDDI 是 一个早期的，没有再积极支持试图以提供Web服务发现。
服务 请求者/消费者
它位于条目中的经纪人注册表使用不同的查找操作和再结合到了服务提供商的顺序来调用一个的它的网络服务。无论服务的服务消费者的需要，他们必须要承担它进入的经纪人，结合其与相应的服务和再 使用 它。 他们 可以 访问 多种 服务 ，如果该服务提供了多种服务。
如：A调用B要通过一个C组件 A是消费者，B是提供者,C是服务代理（微服务中就是注册中心）

该 服务 的消费者和提供者 的关系 是由一个服务合同支配，其中有一个业务部分，一个功能部分和一个技术的一部分。可能一流服务组合物的图案是2下侧的的相同硬币。这些模式是普遍事件驱动：

• 编排 通常是分散执行和执行的
• 编舞 是制定由所有参与者，并可以被实现与一个中央工作流管理系统[16]

低 级别 企业集成模式 是 在 不 绑定 到 一个特定的建筑风格延续到是相关和有资格的SOA 设计。

实施方法

面向服务的 体系结构 可以 被实现与Web服务。这是做以使该功能构建模块访问了标准的互联网协议，这是独立的平台和编程语言。这些服务可以代表任何新的应用程序或只是封装协议围绕现有遗留系统 以使它们具有网络功能（网上被调用）。

实施者 共同 构建 SOA的 使用 网络 服务 标准 （用于 例如， SOAP） 是 已经 获得了 广泛的 行业 认可 后 推荐 的版本1.2 ，从该W3C（万维网的Web Consortium）组织在2003年，这些标准（也称为以作为Web服务规范）还提供了更大的互操作性 以及 从锁定到专有供应商软件的某种 保护 。一个可以，但是，实施SOA 使用任何基于服务的技术，例如如Jini的，CORBA或者REST。

架构 可以 操作 独立 的具体技术和可因此被实现使用一个宽范围的技术，其中包括：

• 网络 服务 基础 上的WSDL 和SOAP
• 消息传递， 例如， 使用 ActiveMQ， JMS， RabbitMQ
• RESTful HTTP， 具有 表示状态传输 （REST） 构成 其 自身 基于约束的 体系结构 样式
• OPC-UA
• WCF （微软 实现 的网络服务，形成一个部分的WCF）
• Apache Thrift
• SORCER
  实施方式 可以 使用 一个 或更多的这些协议，并为例如，可能使用一个文件系统机制以通信数据以下一个定义接口规范之间的过程符合于所述SOA 的概念。该键是独立的服务与定义的接口，即可以被称为以执行 他们的 任务 在 一个标准的方式下，没有一个服务有先见之明的的调用应用程序，而无需对应用有或需要了解的是如何在服务实际执行它的任务（不需要了解内部实现）。SOA 能够在开发的应用程序是在建立通过结合松散的耦合和互操作 服务。（SOA是松散的耦合和互操作的服务）

这些 服务 互操作的 基础 上 一个正式的定义（或合同，如WSDL）即是独立的的底层平台和编程语言。**该接口定义隐藏了实现的的特定语言的服务。基于SOA的系统（每个模块）能因此发挥独立的开发技术和平台（如 例如Java，.NET 等）。**服务写在C＃运行在.NET 平台和服务编写的Java的运行上的Java EE 平台，为例如，可以既可以消耗由一个共同的复合应用程序（或客户）。应用程序运行在任何平台上可以同时消费服务运行上的 其他 的网络服务是方便的重用。托管环境还可以包装COBOL 旧系统，并将其作为软件服务呈现
高级编程语言 ，例如 如BPEL 和规格等作为WS-CDL 和WS-Coordination的延长的服务理念通过提供一个方法的定义和支持业务流程的细粒度服务到更粗粒度的业务服务，其建筑师可以在转结合到工作流程和业务流程 实现 在复合应用或门户[24]

面向服务的建模 是 一个SOA 框架是确定的各学科是指导SOA 从业者以概念化，分析，设计，和建筑师他们的面向服务的资产。在面向服务的建模框架（SOMF）提供一个建模语言和一个工作结构或“图” 描绘的各种部件是有助于对 一个成功的面向服务的建模方法。它说明了主要的要素是确定的“什么到做” 方面的一个业务发展计划。该模式使从业人员对手艺一个项目计划，并以确定的里程碑的一个面向服务的积极性。SOMF 还提供了通用的建模 用于解决业务和 IT 组织之间一致性的符号。

批评

SOA 已经 被 混为一谈 与 Web服务。[30] 但是， 网络 服务 是 唯一的 一个 选项 ，以实现该模式是包含了SOA 的风格。在该不存在的天然或二进制形式的远程过程调用（RPC），应用程序可以运行更慢和需要更多的处理能力， 成本 增加。大多数 实现 不承担这些费用，但SOA 可以被实现利用技术（用于例如，Java业务集成（JBI），Windows通讯基础（WCF）和数据分发服务（DDS））是做不依赖于远程过程调用或翻译通过XML。在与同时间，新兴的开源 XML 解析 技术 （例如 如VTD-XML）和各种XML兼容的二进制格式的承诺，以显著提高SOA 性能。服务实现使用JSON 代替的XML也不会吃亏从这个性能问题。[31] [32] [33]

有状态的 服务 要求 都 在 消费者 和 该 供应商 来分享的同一个特定的消费背景下，这是任何包含于或引用的信息交换之间的提供者和该消费者。这种约束具有的缺点是它可以减少的整体可扩展性的的服务 供应商 如果对服务提供商的需要，以保留的共享方面的每一个消费者。这也增加了耦合之间的一个服务提供商和一个消费者，并使得切换服务提供商更加困难。[34]最后，一些批评者觉得是SOA 服务都还太限制由 他们 代表的应用程序。[35]

甲初级挑战面临由面向服务的体系结构是管理的元数据。环境基础上的SOA 包含许多服务，其中通信中的每个其他来执行任务。由于到的事实，即该设计可以涉及多个服务工作的结合，一个应用程序可能会产生数以百万计 的消息。而且服务可能属于以不同的组织或者甚至是竞争的企业创造一个巨大的信任问题。因此，SOA 治理涉及到的计划的事情。[36]

另一个 主要 问题 面临 的SOA是在缺乏的一个统一的测试框架。有是没有工具是提供了所需的功能，用于测试这些服务的一个服务导向的架构。的主要起因的困难是：[37]

异质性 和 复杂性 的解决方案。
大量的的组合测试（abc服务一起测试）因于一体的自主服务。
包容性 的服务，从不同的和相互竞争的供应商。
平台 是不断变化的，由于对可用性的新功能和服务。

微服务（Microservice）

微服务 是 一个现代诠释的面向服务的体系结构中使用，以构建分布式软件系统。服务于一个微服务体系结构是处理该通信与每个其他过的网络中以便于满足一个目标（微服务位于一个个进程通过网络通讯进行构建满足一个目标）。这些服务采用技术无关的协议（每个服务使用什么技术和协议都可以），其中 帮助 在封装选择的语言和框架，使他们选择一个关注内部到的服务。微服务对于SOA来说是SOA一种新的实现方式，这已成为流行，因为2014 （以及之后的推出的的DevOps），这也强调了持续的部署和 其他 敏捷 实践。[43]

这里 是 没有单一的普遍同意的定义的微服务。的下列特征和原理可以被发现在该文献中：

• 细粒度的 接口 （用于 独立 部署的 服务），
• 业务驱动的 开发 （例如 域驱动的 设计），
• 理想的云应用架构
• 多语言编程和持久性，
• 轻量级的 容器 部署，
• 去中心化的连续 交付， 以及具有 整体 服务 监控功能的DevOps 。

微服务与SOA区别

SOA（面向服务的架构）：面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

微服务：微服务架构是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。这些服务的集中管理最少（去中心化），可以用不同的编程语言编写，并使用不同的数据存储技术。

SOA和微服务的主要区别：（重要）

• 微服务剔除SOA中复杂的ESB企业服务总线（类似cloud网关），所有的业务智能逻辑在服务内部处理，使用Http（Rest API）进行轻量化通讯
  SOA通过规定的服务总线进行通信而微服务服务与服务之间可以直接进行通讯
  
• SOA强调按水平架构（项目模块化）划分为：前、后端、数据库、测试等，微服务强调按垂直架构划分（每个业务本身），按业务能力划分，每个服务完成一种特定的功能，服务即产品
  SOA共享数据存储而微服务每个业务都有自己的数据存储
• SOA将组件以library的方式和应用部署在同一个进程中运行，微服务则是各个服务独立运行。
• 传统应用倾向于使用统一的技术平台来解决所有问题，微服务可以针对不同业务特征选择不同技术平台，去中心统一化，发挥各种技术平台的特长。
• SOA架构强调的是异构系统之间（关注企业级）的通信和解耦合；（一种粗粒度、松耦合的服务架构）
• 微服务架构强调的是系统按（关注业务本身）边界做细粒度的拆分和部署。

微服务架构的不足之处：

（1） 微服务把原有的项目拆分成多个独立工程，增加了开发、测试、运维、监控等的复杂度。

（2） 微服务架构需要保证不同服务之间的数据一致性，引入了分布式事务和异步补偿机制，为设计和开发带来一定挑战。

所以微服务适用于复杂的大系统，小应用盲目的拆分只会增加其维护和开发成本…