Soa

玩过 Dubbo 的小伙伴应该都有据说过一个概念叫做 SOA，每当咱们说起微服务的时候，很多人就会去纠结这和 SOA 有啥关系呀？感觉换汤不换药呀。 明天松哥来略微和小伙伴们探讨下这个话题，咱们一起来看看 SOA 和微服务到底有何异同。 1. SOASOA，英文全称是 Service-Oriented Architecture (SOA) governance，单纯从字面来看，是面向服务的架构治理。然而小伙伴们在网上应该很难看到比拟权威的对于 SOA 通俗易懂的解释。我这里还是以 TienChin 我的项目为例，来和大家捋一捋 SOA。 假如 TienChin 中有一个用户注册的性能，当初前端的注册有三个端： 网页手机 App小程序 如果采纳传统的 JavaWeb 开发方式，那么我可能得写三遍注册性能，为三个 Client 各自提供一个接口，然而小伙伴们略微思考一下就会发现，注册逻辑其实都差不多，区别可能仅仅是接口返回的数据格式有差别而已。因而，咱们能够将注册性能抽取进去，写成一个独自的服务，而后通过近程服务调用如 HTTP 或者 Socket 等，去调用这个注册的功能模块。这就是一个简略的 SOA 架构设计。 然而看了这个很多小伙伴都懵了，这不就是微服务吗？ 接下来咱们就来说说 SOA 和微服务到底哪里不一样。 2. SOA PK 微服务2.1 服务间通信首先第一点，就是服务之间的通信形式不同。 玩过 Dubbo 的小伙伴都晓得，Dubbo 中罕用的通信协议就是 Dubbo 协定，Dubbo 协定实质上其实就是 socket 通信。在 SOA 中，服务之间的通信往往都是采纳的重量级协定如 SOAP 等。 而咱们罕用的微服务框架 Spring Cloud，小伙伴们晓得，这里的通信基本上都是 REST 这种轻量级协定，有时候咱们甚至是基于音讯来驱动微服务，无论哪一种，微服务中服务之间的通信协议都更加轻量级。 2.2 数据库设计在 SOA 中，一般来说不太会进行分库设计，也就是说整个零碎还是应用的一个库，零碎可能会分为不同的服务，然而不同的服务操作的都是同一个库。 微服务则不同，昨天的文章中，松哥画的上面这张图，基本上是每一个服务都有一个本人的库，每个服务都是操作本人的库，合同治理中须要调用用户治理的数据，不能间接调用库，得通过用户治理提供的 REST 接口去调用。 ...

【注】本文译自： Overview of Resource-Oriented Architectures (ROA) | Developer.com 理解面向资源的架构 (ROA)、其价值以及最佳实际。 面向服务的架构 (Service-Oriented Architecture，SOA) 和面向资源的架构 (Resource-Oriented Architecture，ROA) 是用于实现强壮、可扩大的分布式应用程序架构的架构设计模式。分布式架构由通过定义良好的接口在网络上应用的组件组成。在 ROA 中，这些组件被称为资源，而在 SOA 中，它们被称为服务。本文概述了面向资源的体系结构。 什么是面向资源的架构 (ROA)？ 面向资源的架构 (ROA) 是一种架构格调，它扩大了 REST 架构格调，并提供了更宽泛、可扩大、灵便且与传输无关的架构。面向资源的架构 (ROA) 范式建设在资源的概念之上。资源是一个独立的、可辨认的实体，其状态能够被调配一个对立的资源定位符 (URI)。服务代表所申请操作的执行，而资源代表可通过统一的标准化接口进行治理的分布式组件。 面向资源架构的特色之一是与传输无关。因而，必须有特定的机制将面向资源的服务裸露给内部世界。当消费者申请对立资源定位器（Uniform Resource Locator，URL）并指定拜访办法（例如，GET、PUT、POST 和 DELETE）时，该 URL 将转换为绝对的外部 URI。拜访办法被转化为动作。 面向资源的架构仅围绕四个概念建模： 资源URI表述链接和连通性 以下是面向资源架构的四个属性： 可寻址性无状态性连通性对立的接口面向资源的架构：资源 资源是 ROA 的基石；资源是信息的逻辑示意。例如，学生是数据点的形象汇合，能够用多种形式示意，包含 XHTML、JSON 和 XML。 资源名称包含以下内容： 资源的类型资源标识符父元素的资源名API 服务的名称 资源是 REST 或 RESTful 架构中最重要的信息形象。术语“资源”是指任何可辨认的信息。这些信息能够是文档、计算机、汽车、长期服务（例如“俄亥俄州明天的天气”）、其余资源的汇合、集体、学生等。 每个不可变资源示意都能够通过绝对的对立资源批示符 (URI) 来标识，它可能包含到其余资源以及其余不可变资源的连贯。请留神，一个资源也能够有多个 URI。 每种资源应具备以下特色： 是惟一的必须至多有一个表述具备属性，模式能够被拜访并提供上下文对立资源标识符（URI） 对立资源标识符 (Uniform Resource Identifier，URI) 是蕴含资源名称和地址的字符序列，用于标识逻辑或物理资源。请留神，资源必须具备一个或多个 URI。 没有 URI，一条信息不被视为资源，因为它不能被援用或拜访。 您能够应用 URI 来标识任何事物，例如事实世界的对象、网页、书籍等。 上面是一个 URI 的例子：语法：:示例：http://payroll/employee/1234 下表阐明了如何指定资源的绝对 URI： ...

阿里妹导读：从十余年前的各种分布式系统研发到现在的容器云，从支撑原有业务到孵化各个新业务，企业的发展离不开统一的、与时俱进的技术架构。本篇文章从企业分布式应用架构层面介绍了云原生计算架构带来的变化，希望能够帮助更多企业的 IT 转型，利用云计算技术推动其成为市场竞争中的敏捷力量。进入 21 世纪以来，我们见证了企业分布式应用架构从 SOA (Service-oriented Architecture)，到微服务架构，再到云原生应用架构的演化。 为了说明企业架构演化背后的思考，我们先谈一些玄学。 第一，企业 IT 系统的复杂性（熵）符合热力学第二定律。随着时间的推演，业务的变化，企业 IT 系统的复杂度会越来越高；第二，在计算机交互设计中有一个著名的复杂性守恒定律[1]。应用交互的复杂性不会消失，只会换一种方式存在。这个原理也同样适用于软件架构。引入新的软件架构，不会降低IT系统的整体复杂性。听到这里，是否让生命不息、折腾不止的我们感到一丝凉凉？ 现代软件架构的核心任务之一就是定义基础设施与应用的边界，合理切分复杂性，减少应用开发者需要面对的复杂性。换句话说，就是让开发者专注在核心价值创新上，而把一些问题交给更合适的人和系统来解决。 我们就从下面这张图开始，探究企业分布式应用架构演进背后的逻辑。 本图来自 Bilgin Ibryam 的 twitter[2] 蜕变之痛：SOA2004 年，IBM 建立 SOA 全球设计中心，我作为研发 TL 和架构师参与了一系列全球客户的 pilot 项目，帮助 Pepboys, Office Depot 等国际企业利用 SOA 优化企业内部和企业间的业务流程，提升业务敏捷性。 当时的大背景是：随着经济全球化逐渐深入，企业面对的竞争加剧，商业变革也开始提速。在大型企业内部的 IT 系统已经经过了数十年的演化，整个的技术体系变得异常复杂，并存着诸如主机系统上的 CISC/COBOL 交易应用，小型机 AS400 中的 RPG 业务系统，和 X86/Power 等分布式系统的 C/JEE/.Net 应用。 大量应用系统由三方供应商提供，一些系统甚至已经无人维护。而且随着业务迭代，一些新的业务系统被持续构建出来，由于缺乏合理的方法论指导，系统之间缺乏有机的链接，形成了若干的孤岛，持续加剧了 IT 架构的复杂性，无法支撑业务的发展诉求。这就仿佛各派高手为了帮助受伤的令狐冲，把异种真气输入体中，虽然短时间可以缓解伤势。可是多道真气无法融合，互相激荡，长时间下来会伤上加伤。 因此，企业 IT 所面临的首要挑战就是整合企业中大量竖桶型（silo-ed）的 IT 系统，支撑日益复杂的业务流程，进行高效的业务决策和支撑业务快速变化。 在这种背景下，IBM 等公司提出了 SOA（面向服务的架构）理念，将应用系统抽象成一个个粗粒度的服务，构建松耦合服务架构，可以通过业务流程对服务进行灵活组合，提升企业 IT 资产复用，提高了系统的适应性、灵活性和扩展性，解决“信息孤岛”问题。 SOA 提出了一系列构建分布式系统的原则，这些思考直到今天也依然适用： 服务具备明确定义的标准化的接口。通过服务定义描述，将服务消费者（Service Consumer）和服务提供者 (Service Provider) 的实现进行解耦，并且服务应该采用 contract-first 而非 code-first 方式进行开发。服务间通信采用面向文档的消息而非特定语言 RPC 协议，一方面可以解决服务与实现语言的解耦，另一方面可以灵活选择同步或者异步的通信实现，提升系统可用性和可伸缩性；服务应该是松耦合的，服务之间不应存在时间、空间、技术、团队上的依赖；服务应该是无状态的，使得服务调用与会话上下文状态实现解耦；服务应该是自治和自包含的，服务的实现是可以独立进行部署、版本控制、自我管理和恢复；服务是可发现、可组合的。比如可以通过 Service Registry 进行服务发现，实现了服务消费者和服务提供者的动态绑定。业务流程中可以对来自不同系统的的业务服务进行编排组装。在初始构建 SOA 系统的时候，大多采用点对点的通信连接，服务调用和集成逻辑被内嵌在应用实现中。这种方式在服务数量比较少的时候，确实是一种简单和高效的开发方式。但其最大的问题是，随着服务规模的增长，服务之间通信愈发复杂，连接路径和复杂性会剧增，给服务治理带来巨大的挑战。 ...

作者 | 易立 阿里云资深技术专家 导读：从十余年前的各种分布式系统研发到现在的容器云，从支撑原有业务到孵化各个新业务，企业的发展离不开统一的、与时俱进的技术架构。本篇文章从企业分布式应用架构层面介绍了云原生计算架构带来的变化，希望能够帮助更多企业的 IT 转型，利用云计算技术推动其成为市场竞争中的敏捷力量。 进入 21 世纪以来，我们见证了企业分布式应用架构从 SOA(Service-oriented Architecture)，到微服务架构，再到云原生应用架构的演化。 为了说明企业架构演化背后的思考，我们先谈一些玄学。 第一，企业 IT 系统的复杂性（熵）符合热力学第二定律。随着时间的推演，业务的变化，企业 IT 系统的复杂度会越来越高。第二，在计算机交互设计中有一个著名的复杂性守恒定律。应用交互的复杂性不会消失，只会换一种方式存在。这个原理也同样适用于软件架构。引入新的软件架构，不会降低IT系统的整体复杂性。听到这里，是否让生命不息、折腾不止的我们感到一丝凉凉？:-) 现代软件架构的核心任务之一就是定义基础设施与应用的边界，合理切分复杂性，减少应用开发者需要面对的复杂性。换句话说，就是让开发者专注在核心价值创新上，而把一些问题交给更合适的人和系统来解决。 我们就从下面这张图开始，探究企业分布式应用架构演进背后的逻辑。 本图来自 Bilgin Ibryam 的 twitter 蜕变之痛 - SOA2004 年，IBM 建立 SOA 全球设计中心，我作为研发 TL 和架构师参与了一系列全球客户的 pilot 项目，帮助 Pepboys, Office Depot 等国际企业利用 SOA 优化企业内部和企业间的业务流程，提升业务敏捷性。 当时的大背景是：随着经济全球化逐渐深入，企业面对的竞争加剧，商业变革也开始提速。在大型企业内部的 IT 系统已经经过了数十年的演化。整个的技术体系变得异常复杂，并存着诸如主机系统上的 CISC/COBOL 交易应用，小型机 AS400 中的 RPG 业务系统，和 X86/Power 等分布式系统的 C/JEE/.Net 应用。 大量应用系统由三方供应商提供，一些系统甚至已经无人维护。而且随着业务迭代，一些新的业务系统被持续构建出来，由于缺乏合理的方法论指导，系统之间缺乏有机的链接，形成了若干的孤岛，持续加剧了 IT 架构的复杂性，无法支撑业务的发展诉求。这就仿佛各派高手为了帮助受伤的令狐冲，把异种真气输入体中，虽然短时间可以缓解伤势。可是多道真气无法融合，互相激荡，长时间下来会伤上加伤。 因此，企业 IT 所面临的首要挑战就是整合企业中大量竖桶型（silo-ed）的 IT 系统，支撑日益复杂的业务流程，进行高效的业务决策和支撑业务快速变化。在这种背景下，IBM 等公司提出了 SOA（面向服务的架构）理念，将应用系统抽象成一个个粗粒度的服务，构建松耦合服务架构，可以通过业务流程对服务进行灵活组合，提升企业 IT 资产复用，提高了系统的适应性、灵活性和扩展性，解决“信息孤岛”问题。 ...