大家好,我是IT修真院郑州分院第十期的学员,一枚正直纯洁善良的java程序员
今天给大家分享一下,修真院官网java任务九,深度思考中的知识点——什么是SOA?什么是SCA?什么是微服务?
背景介绍
平台随着业务的发展,All in one已经不能满足业务需求,需要把核心或共用的服务拆分出来,在这种需求推动下,产生了SOA、SCA、微服务等概念。
知识剖析
SOA
SOA全称Service-Oriented Architecture,中文叫面向服务架构。
SOA没有权威的定义,统一的标准,不同角度和组织的定义也不相同,这里采用了百度百科的定义,更接近大家目前的理解。
面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
SCA
SCA全称Service Component Architecture,中文叫服务组件化架构。
SCA是基于SOA开发的一个模型规范,由IBM领头提出的标准。
基于组件编程有很多不同的模型,为了给不同的接口提供统一的调用方式,IBM提出了WSIF,但WSIF没有一个基于组件的架构模型,所以IBM在此基础上提出了SCA。
服务组件是SCA最基本的功能单元,可以把service的实现方法,pojo等包装为SCA的服务组件。SCA服务组件的主要接口规范是基于WSDL的,另外为了给Java提供一个比较直接的接口,也提供了Java接口。
SCA服务组件的特点
- 服务组件一般是粗粒度。
- 服务组件的接口是标准的接口。
- 服务组件实现与语言无关,即不绑定语言。
- 服务组件由组件容器管理,提供服务,不由程序代码控制。
服务模块由一个或多个具有内在业务联系的服务组件构成,是SCA中的运行单位,独立的部署单元。
一般应用是比较复杂的,实际应用需要多个模块满足要求,这些模块互相调用,模块提供两个端点,导入和导出,导入使模块可以调用外部的服务,导出使外部的应用可以调用模块内部的服务。
当我们在构建了多个模块的时候,如果有一些资源可以在不同模块之间共享,那么我们可以选择创建一份可以在不同模块之间进行共享的资源。共享库就是存放这些共享资源的地方。共享库包含的内容只有:数据定义,接口定义,数据映射和关系。与模块最大的区别是共享库不包含服务组件,因此也就不包含业务逻辑。
微服务
微服务最早由Martin Fowler与James Lewis于2014年共同提出,微服务架构风格是一种使用一套小服务来开发单个应用的方式途径,每个服务运行在自己的进程中,并使用轻量级机制通信,通常是HTTP API,这些服务基于业务能力构建,并能够通过自动化部署机制来独立部署,这些服务使用不同的编程语言实现,以及不同数据存储技术,并保持最低限度的集中式管理。
常见问题
SCA的应用。SCA的简单示例。
扩展思考
SOA和微服务的对比
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步。
开发方面 - 在这两种体系结构中,可以使用不同的编程语言和工具开发服务,从而将技术多样性带入开发团队。开发可以在多个团队中组织,但是在SOA中,每个团队都需要了解常见的通信机制。另一方面,使用微服务,服务可以独立于其他服务运行和部署。因此,频繁部署新版本的微服务或独立扩展服务会更容易。您可以在这里进一步阅读有关微服务的这些好处。
“上下文边界” - SOA鼓励组件的共享,而微服务尝试通过“上下文边界”来最小化共享。上下文边界是指以最小的依赖关系将组件及其数据耦合为单个单元。由于SOA依靠多个服务来完成业务请求,构建在SOA上的系统可能比微服务要慢。
通信 - 在SOA中,ESB可能成为影响整个系统的单一故障点。由于每个服务都通过ESB进行通信,如果其中一个服务变慢,可能会阻塞ESB并请求该服务。另一方面,微服务在容错方面要好得多。例如,如果一个微服务存在内存错误,那么只有该微服务会受到影响。所有其他微服务将继续定期处理请求。
互操作性 - SOA通过消息中间件组件促进了多种异构协议的使用。微服务试图通过减少集成选择的数量来简化架构模式。因此,如果您想要在异构环境中使用不同协议来集成多个系统,则需要考虑SOA。如果您的所有服务都可以通过相同的远程访问协议访问,那么微服务对您来说是一个更好的选择。
大小Size - 最后一点但并非最不重要的一点,SOA和微服务的主要区别在于规模和范围。微服务架构中的前缀“微”是指内部组件的粒度,意味着它们必须比SOA架构的服务往往要小得多。微服务中的服务组件通常有一个单一的目的,他们做得很好。另一方面,在SOA服务中通常包含更多的业务功能,并且通常将它们实现为完整的子系统。
不能简单地说一种架构比另一种架构更好。这主要取决于您正在构建的应用程序的目的。SOA更适合需要与许多其他应用程序集成的大型复杂企业应用程序环境。这就是说,小型应用程序不适合SOA架构,因为它们不需要消息中间件组件。而微服务架构,在另一方面,是更适合于较小和良好的分割,基于Web的系统。
参考文献
https://www.ibm.com/developerworks/cn/webservices/ws-sca/
https://blog.csdn.net/chszs/article/details/78515231
更多讨论
Q1:如何将一个产品拆解为微服务(组件),每个微服务应包括哪些元素?
A1:要把单体式应用拆分成微服务组件,并没有一个具像的标准说这个组件应该包括哪些元素。而是需要从业务的角度去分析:某一些功能是否逻辑相对独立、可复用性高、使用频度高等等,根据这些因素判断是否该拆分出来作为一个微服务组件。
微服务设计强调服务的独立性:不同微服务使用不同的数据,与外部交互通过消息或API而不是耦合的依赖关系;此外,微服务组件的设计需要把握“微”的度,所以不宜在基础的功能上做过多的堆叠,否则每个微服务组件可能又变成了大的单体应用。
具体来说,微服务设计需要可从以下几个方面着手:
- 实现前后端分离,可把代码分为前端、服务层、底层代码;
- 根据业务逻辑及技术层面的系统架构综合考虑,抽取模块成服务;
- 打造服务间的轻量通信基础组件及协议,例如REST或消息队列
Q2:SCA与传统的业务组件最大区别
A2:一是组件和传输协议的分离,二是接口和实现语言的分离。
Q3:主流微服务框架有哪些?
A3:Dubbo和SpringCloud