这里是修真院前端小课堂,每篇分享文从
【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】
八个方面深度解析前端知识/技能,本篇分享的是:
【什么是SOA?什么是SCA?什么是微服务?】
大家好,我是IT修真院的学员,一枚正直纯洁善良的java程序员
今天给大家分享一下,修真院官网java任务九,深度思考中的知识点——什么是SOA?什么是SCA?什么是微服务?
背景介绍
平台随着业务的发展,All in one已经不能满足业务需求,需要把核心或共用的服务拆分出来,在这种需求推动下,产生了SOA、SCA、微服务等概念。
知识剖析
1:SOA
SOA(面向服务的软件架构、Service Oriented Architecture),是一种软件设计模式,主要应用于不同应用组件之间通过某种协议来互操作。例如典型的 通信网络协议。因此SOA是独立于任何厂商、产品、技术的。
面向服务的架构是一种软件体系结构,应用程序的不同组件通过网络上的通信协议向其他组件提供服务。通信可以是简单的数据传递,也可以是两个或多个服务彼此协调连接。这些独特的服务执行一些小功能,例如验证付款、创建用户帐户或提供社交登录等。
面向服务的架构不太关于如何对应用程序进行模块化构建,更多的是关于如何通过分布式、单独维护和部署的软件组件的集成来组成应用程序。这些通过技术和标准来实现,通过技术和标准使得组件能够更容易地通过网络(尤其是IP网络)进行通信和协作。
SOA架构中有两个主要角色:服务提供者(Provider)和服务使用者(Consumer)。而软件代理则可以扮演这两个角色。该Consumer层是用户(人、应用程序或第三方的其它组件)与SOA交互的点,和Provider层则由SOA架构内的所有服务所构成。
SOA首先在90年代中期得名,当时一家名为Gartner Group的公司认识到了这个软件架构的新趋势,并在全球推广。通过这样做,他们设法大大加快了这种架构模式的采用和进一步发展。然而,使用分布式服务作为软件体系结构的最早记录可追溯到二十世纪80年代初。
基于SOA的解决方案,SOA架构可分为五层水平:
用户界面层---- 这些GUI的最终用户或应用程序访问的应用程序/服务接口;
业务流程层---- 在应用方面的业务用例服务;
服务层---- 服务合并在一起,提供统一的实时服务;
服务组件层---- 用来建造服务的组件,如功能库、技术库、技术接口等;
操作系统---- 这层包含数据模型,企业数据仓库,技术平台等;
SCA
SCA全称Service Component Architecture,中文叫服务组件化架构。SCA是基于SOA开发的一个模型规范,由IBM领头提出的标准。
SCA中,最重要的一个概念是Service----服务,它的内涵式独立于具体的技术。因此,SCA不会称之为Java组件架构,或Web Service 组件架构。所谓的具体技术,主要有两层含义:一是程序语言,而是传输协议。
基于组件编程有很多不同的模型,为了给不同的接口提供统一的调用方式,IBM提出了WSIF,但WSIF没有一个基于组件的架构模型,所以IBM在此基础上提出了SCA。
服务组件是SCA最基本的功能单元,可以把service的实现方法,pojo等包装为SCA的服务组件。SCA服务组件的主要接口规范是基于WSDL的,另外为了给Java提供一个比较直接的接口,也提供了Java接口。
SCA服务组件的特点
服务组件一般是粗粒度。
服务组件的接口是标准的接口。
服务组件实现与语言无关,即不绑定语言。
服务组件由组件容器管理,提供服务,不由程序代码控制。
SCA是对目前组件编程的进一步升华,其目标是让服务组件能自由绑定各种传输协议,集成其他的组建与服务。
SCA与传统的业务组件最大区别在于SCA实现了两个功能:一是组件和传输协议的分离,二是接口和实现语言的分离。
SCA的本质是一种软件架构思想,SCA架构是独立于程序语言的SOA架构。
SCA的目标是创建一个可集成服务组件的运行环境。
服务模块由一个或多个具有内在业务联系的服务组件构成,是SCA中的运行单位,独立的部署单元。
一般应用是比较复杂的,实际应用需要多个模块满足要求,这些模块互相调用,模块提供两个端点,导入和导出,导入使模块可以调用外部的服务,导出使外部的应用可以调用模块内部的服务。
当我们在构建了多个模块的时候,如果有一些资源可以在不同模块之间共享,那么我们可以选择创建一份可以在不同模块之间进行共享的资源。共享库就是存放这些共享资源的地方。共享库包含的内容只有:数据定义,接口定义,数据映射和关系。与模块最大的区别是共享库不包含服务组件,因此也就不包含业务逻辑。
微服务
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步。基本上,这种架构类型是开发软件,网络或移动应用程序作为独立服务套件(又称微服务)的一种特殊方式。这些服务的创建仅限于一个特定的业务功能,如用户管理、用户角色、电子商务车、搜索引擎、社交媒体登录等。此外,它们是完全独立的,也就是说它们可以写入不同的编程语言并使用不同的数据库。集中式服务管理几乎不存在,微服务使用轻量级HTTP、REST或Thrift API进行通信。
这个词本身起源于2011年5月在威尼斯附近举行的软件架构师研讨会。他们第一次使用“微服务”这个术语来描述参与者看到的一个共同的架构风格,其中许多参会者都在探索相似的内容。2012年5月,同一个团队决定将“微服务”作为最合适的名称。然而实际上,微软、亚马逊、Netflix和Facebook等主要的科技公司已经在微服务架构方面工作了十多年。
乍一看,微服务架构似乎谈论的是与SOA相同的事情。不过,如果引用微软服务领域的先驱Martin Flower的话,他曾经说过,“我们应该把SOA看作微服务的超集”。
SOA 和微服务的异同:
SOA
微服务架构
应用程序服务的可重用性的最大化
专注于解耦
系统性的改变需要修改整体
系统性的改变是创建一个新的服务
DevOps和持续交付正在变得流行
,但还不是主流 强烈关注DevOps和持续交付
专注于业务功能重用
更重视“上下文边界”的概念
通信使用企业服务总线ESB
对于通信而言,使用较少精细和简单的消息系统
支持多种消息协议
使用轻量级协议,例如HTTP,REST或Thrift API
对部署到它的所有服务使用通用平台
应用程序服务器不是真的被使用,通常使用云平台
容器(如Docker)的使用不太受欢迎
容器在微服务方面效果很好
SOA服务共享数据存储
每个微服务可以有一个独立的数据存储
共同的治理和标准
轻松的治理,更加关注团队协作和选择自由
下面进一步解释上表所述的不同之处:
开发方面- 在这两种体系结构中,可以使用不同的编程语言和工具开发服务,从而将技术多样性带入开发团队。开发可以在多个团队中组织,但是在SOA中,每个团队都需要了解常见的通信机制。另一方面,使用微服务,服务可以独立于其他服务运行和部署。因此,频繁部署新版本的微服务或独立扩展服务会更容易。您可以在这里进一步阅读有关微服务的这些好处。
“上下文边界” - SOA鼓励组件的共享,而微服务尝试通过“上下文边界”来最小化共享。上下文边界是指以最小的依赖关系将组件及其数据耦合为单个单元。由于SOA依靠多个服务来完成业务请求,构建在SOA上的系统可能比微服务要慢。
通信- 在SOA中,ESB可能成为影响整个系统的单一故障点。由于每个服务都通过ESB进行通信,如果其中一个服务变慢,可能会阻塞ESB并请求该服务。另一方面,微服务在容错方面要好得多。例如,如果一个微服务存在内存错误,那么只有该微服务会受到影响。所有其他微服务将继续定期处理请求。
互操作性- SOA通过消息中间件组件促进了多种异构协议的使用。微服务试图通过减少集成选择的数量来简化架构模式。因此,如果您想要在异构环境中使用不同协议来集成多个系统,则需要考虑SOA。如果您的所有服务都可以通过相同的远程访问协议访问,那么微服务对您来说是一个更好的选择。
大小Size - 最后一点但并非最不重要的一点,SOA和微服务的主要区别在于规模和范围。微服务架构中的前缀“微”是指内部组件的粒度,意味着它们必须比SOA架构的服务往往要小得多。微服务中的服务组件通常有一个单一的目的,他们做得很好。另一方面,在SOA服务中通常包含更多的业务功能,并且通常将它们实现为完整的子系统。
常见问题
SCA的应用。SCA的简单示例。
编码实战
扩展思考
SOA和SOAP的异同;
SOA(面向服务的软件架构、Service Oriented Architecture),是一种软件设计模式,如同上文;
SOAP即简单对象访问协议(Simple Object Access Protocol),它是用于交换XML(标准通用标记语言下的一个子集)编码信息的轻量级协议。
它有三个主要方面:
1:XML-envelope为描述信息内容和如何处理内容定义了框架;
2:将程序对象编码成为XML对象的规则;
3:执行远程过程调用(RPC)的约定。
SOAP可以运行在任何其他传输协议上。
例如,你可以使用SMTP,即因特网电子邮件协议来传递SOAP消息,这可是很有诱惑力的。在传输层之间的头是不同的,但XML有效负载保持相同。
Web Service 希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用,打破了软件应用、网站和各种设备之间的格格不入的状态,实现“基于Web无缝集成”的目标。
参考文献
更多讨论
Q1:主流微服务框架有哪些?
A1:Dubbo和SpringCloud
Q2:简单介绍Duboo
A1:
dobbo就是一种RPC框架。它是由alibaba得工程师为java开发的一个RPC,有很高的性能以及简单的使用方法:
1、被远程调用的接口,需要在zookeeper中进行注册;
2、需要远程调用的服务在zookeeper中声明自己需要的接口;
3、zookeeper将已经注册的接口通知给需要的服务;
Q3:什么是CAP理论
CAP理论是:同时满足“一致性‘”可用性’和分区容错是不可能的事情;