SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元(服务)模型的方法。 SOA 并不是一个新鲜事物,而只是面向对象模型的一种替代。虽然基于 SOA 的系统并不排除使用 OOD 来构建单个服务,但是其整体设计却是面向服务的。由于 SOA 考虑到了系统内的对象,所以虽然 SOA 是基于对象的,但是作为一个整体,它却不是面向对象的。
SOA 系统原型的一个典型例子是 CORBA,它已经出现很长时间,其定义的概念与 SOA 相似。SOA 建立在 XML 等新技术的基础上,通过使用基于 XML 的语言来描述接口,服务已经转到更动态且更灵活的接口系统中,CORBA 中的 IDL 无法与之相比。
在 SOA 模型中,所有的功能都定义成了独立的服务。服务之间通过交互和协调完成业务的整体逻辑。所有的服务通过服务总线或流程管理器来连接。这种松散耦合的架构使得各服务在交互过程中无需考虑双方的内部实现细节,以及部署在什么平台上。
SOA三大特点:松散耦合、粗粒度、标准化接口
SOA有6个服务类型:
由服务请求者、服务提供者、服务注册中心三个角色构成, 支持服务发布、查找和绑定。
动态绑定(调用地址从注册中心获取)与静态绑定(调用地址写死)。
关键技术: UDDI / WSDL / SOAP / REST /XML。
UDDI(universal description,discovery,intergration)统一描述、发现和集成:用于 Web 服务注册和服务查找;
WSDL(web service description language)web服务描述语言:用于描述 Web 服务的接口和操作功能;
SOAP(simple object access protocol)简单对象访问协议:为建立 Web 服务和服务请求之间的通信提供支持;
BPEL(business process execution language) 企业过程执行语言:用来将分散的、功能单一的web服务组织成一个复杂的有机应用.
REST(representational state transfer)表述性状态转移:REST是一种使用HTTP、XML技术进行基于web通信的技术,它将网络中所有的事物抽象为资源,每个资源对应唯一的统一资源标识符URI。客户端通过URI获取资源的表述,并通过获得资源的表述使得其状态发生改变。REST将资源/资源的表述/获取资源的动作三者进行分离。
ESB 是由中间件技术实现并支持 SOA的一组基础架构,是传统中间件技术与 XML、 Web Service 等技术结合的产物,是在整个企业集成架构下的面向服务的企业应用集成机制。
主要支持异构系统集成。ESB基于内容的路由和过滤,具备复杂数据的传输能力,并可以提供一系列标准接口。
微服务顾名思义,就是很小的服务,所以它属于面向服务架构的一种。通俗一点来说,微服务类似于古代著名的发明,活字印刷术,每个服务都是一个组件,通过编排组合的方式来使用,从而真正做到了独立、解耦、组件化、易维护、可复用、可替换、高可用、最终达到提高交付质量、缩短交付周期的效果。
从专业的角度来看,微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于 HTTP 协议的 RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。另外,应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。
微服务的核心特点为:小, 且专注于做⼀件事情、轻量级的通信机制、松耦合、独立部署。
微服务的优势:
技术异构性
在微服务架构中,每个服务都是一个相对独立的个体,每个服务都可以选择适合于自身的技术来实现。可以混合使用多种编程语言、开发框架以及数据存储技术.
弹性
弹性主要讲的是系统中一部分出现故障会引起多大问题。在单块系统中,一个部分出现问题,可能导致整体系统的问题。而微服务架构中,每个服务可以内置可用性的解决方案与功能降级方案,所以比单块系统强。
扩展
单块系统中,我们要做扩展,往往是整体进行扩展。而在微服务架构中,可以针对单个服务进行扩展。
简化部署
简单的服务更容易部署, 每个服务的部署都是独立的, 单个服务出问题不会导致整个系统的故障。
在大型单块系统中,即使修改一行代码,也需要重新部署整个应用系统。这种部署的影响很大、风险很高,因此不敢轻易地重新部署。而微服务架构中,每个服务的部署都是 独立的,这样就可以更快地对特定部分的代码进行部署。
与组织结构相匹配
为服务强调模块化的结构, 可以将架构与组织结构相匹配,避免出现过大的代码库,从而获得理想的团队大小及生产力。
可组合性
在微服务架构中,系统会开放很多接口供外部使用。当情况发生改变时,可以使用不同的方式构建应用,而整体化应用程序只能提供一个非常粗粒度的接口供外部使用。
对可替代性的优化
在单块系统中如果删除系统中的上百行代码,也许不知道会发生什么,引起什么样的问题,因为单块系统中关联性很强。但在微服务架构中,我们可以在需要时轻易地重写服务,或者删除不再使用的服务。
使用模型完成软件的分析、设计、构建、部署、维护等各开发活动。MDA起源于分离系统规约和平台实线的思想。
MDA的主要目标:Portability(可移植性)、Interoperability(互通性)、Reusability(可重用性)。
MDA的3中核心模型:
ADL是这样一种形式化语言,他在底层语义模型的支持下,为软件系统的概念体系结构建模提供了具体语法和概念框架。基于地城语义的工具体系结构的表示、分析、演化、设计过程等提供支持。
ADL的三个基本元素:
ADL主要的架构描述语言:
Aesop、MetaH、C2、Rapide、SADL、Unicon、Wright。
以一个特定问题领域为对象,形成由领域参考模型、参考需求、参考架构等组成的开发基础架构,其目标是支持一个特定领域中多个应用的生成。
(1)领域分析:主要目标是获得领域模型。即通过分析领域中系统的需求(领域需求),确定哪些需求是被领域中的系统广泛共享的,从而建立领域模型。
(2)领域设计:这个阶段的目标是获得 DSSA,它是一个能够适应领域多个系统的需求的一个高层次的设计。由于领域模型中的领域需求具有一定的变化性,DSSA 也要相应地具有变化性,它可以通过表示多选一的、可选的解决方案等来做到这一点。
(3)领域实现:主要目标是依据领域模型和 DSSA 开发与组织可复用信息。这些复用信息可以是从现有系统中提取得到的,也可能通过新的开发得到。这个阶段可以看作复用基础设施的实现阶段。
领域专家: 主要任务包括提供关于领域中系统的需求规约和实现的知识,帮助组织规范的一致的领域字典,帮助选择样本系统作为领域工程的依据,复审领域模型、DSSA等领域工程产品。
领域分析人员: 主要任务包括控制整个领域分析过程,进行知识获取,将获取的知识组织到领域模型中,根据现有系统、标准规范等验证领域模型的准确性和一致性,维护领域模型。
领域设计人员: 主要任务包括控制整个软件设计过程,根据领域模型和现有的系统开发出DSSA,对DSSA的准确性和一致性进行验证,建立领域模型和DSSA之间的联系。
领域实现人员: 主要任务包括根据领域模型和DSSA,或者从头开发可重用构件或者利用再工程的技术从现有系统中提取可重用构件,对可重用构件进行验证,建立 DSSA 与可重用构件间的联系。