百度网站收录提交入口在哪,photoshop基础入门教程,辽宁住房和建设厅网站,多软件网站下载安装一、面向服务的架构SOA
SOA代表了面向服务的架构。 SOA是一种使用松耦合的黑盒子服务构建业务应用的体系架构#xff0c;这些服务可以通过编排连接在一起以实现特定的功能。
面向服务的架构#xff08;Service-Oriented Architecture#xff09;是一种软件体系结构#x…一、面向服务的架构SOA
SOA代表了面向服务的架构。 SOA是一种使用松耦合的黑盒子服务构建业务应用的体系架构这些服务可以通过编排连接在一起以实现特定的功能。
面向服务的架构Service-Oriented Architecture是一种软件体系结构应用程序的不同组件通过网络上的通信协议向其他组件提供服务。通信可以是简单的数据传递也可以是两个或多个服务彼此协调连接。这些独特的服务执行一些小功能例如验证付款、创建用户帐户或提供社交登录等。
面向服务的架构不太关于如何对应用程序进行模块化构建更多的是关于如何通过分布式、单独维护和部署的软件组件的集成来组成应用程序。这些通过技术和标准来实现通过技术和标准使得组件能够更容易地通过网络尤其是IP网络进行通信和协作。
SOA架构中有两个主要角色服务提供者Provider和服务使用者Consumer。而软件代理则可以扮演这两个角色。该Consumer层是用户人、应用程序或第三方的其它组件与SOA交互的点和Provider层则由SOA架构内的所有服务所构成。
SOA首先在90年代中期得名当时一家名为Gartner Group的公司认识到了这个软件架构的新趋势并在全球推广。通过这样做他们设法大大加快了这种架构模式的采用和进一步发展。然而使用分布式服务作为软件体系结构的最早记录可追溯到二十世纪80年代初。
1.1 什么是合同地址和绑定
这是三个SOA的标准术语。每个服务都必须公开一个或多个端点以便让该服务提供给客户端调用。
合同是两方或多方之间的协议。它定义了一种客户端如何与服务通信的协议。从技术上讲它有描述参数和返回值的方法。地址表明在哪儿能找到这种服务。地址是一个URL它指向服务的位置。绑定是决定这个端点如何可以访问。它决定了如何完成通信。例如你暴露你的服务可以使用SOAP over HTTP或通过TCP的BINARY进行访问。因此对于这些通信介质将被创建两个绑定。
二、微服务架构
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步。基本上这种架构类型是开发软件网络或移动应用程序作为独立服务套件又称微服务的一种特殊方式。这些服务的创建仅限于一个特定的业务功能如用户管理、用户角色、电子商务车、搜索引擎、社交媒体登录等。此外它们是完全独立的也就是说它们可以写入不同的编程语言并使用不同的数据库。集中式服务管理几乎不存在微服务使用轻量级HTTP、REST或Thrift API进行通信。
这个词本身起源于2011年5月在威尼斯附近举行的软件架构师研讨会。他们第一次使用“微服务”这个术语来描述参与者看到的一个共同的架构风格其中许多参会者都在探索相似的内容。2012年5月同一个团队决定将“微服务”作为最合适的名称。然而实际上微软、亚马逊、Netflix和Facebook等主要的科技公司已经在微服务架构方面工作了十多年。
乍一看微服务架构似乎谈论的是与SOA相同的事情。不过如果引用微软服务领域的先驱Martin Flower的话他曾经说过“我们应该把SOA看作微服务的超集”。
三、架构演进
技术为业务而生架构也为业务而出现当然SOA和微服务也是因为业务的发展而出现。出现SOA和微服务框架与业务的发展、平台的壮大密不可分下面借用dubbo的网站架构发展图和说明 单一应用架构 当网站流量很小时只需一个应用将所有功能都部署在一起以减少部署节点和成本。 此时用于简化增删改查工作量的 数据访问框架(ORM) 是关键。 垂直应用架构 当访问量逐渐增大单一应用增加机器带来的加速度越来越小将应用拆成互不相干的几个应用以提升效率。 此时用于加速前端页面开发的 Web框架(MVC) 是关键。 分布式服务架构 当垂直应用越来越多应用之间交互不可避免将核心业务抽取出来作为独立的服务逐渐形成稳定的服务中心使前端应用能更快速的响应多变的市场需求。 此时用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。 流动计算架构 当服务越来越多容量的评估小服务资源的浪费等问题逐渐显现此时需增加一个调度中心基于访问压力实时管理集群容量提高集群利用率。 此时用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。
平台随着业务的发展从 All in One 环境就可以满足业务需求以Java来说可能只是一两个war包就解决了发展到需要拆分多个应用并且采用MVC的方式分离前后端加快开发效率在发展到服务越来越多不得不将一些核心或共用的服务拆分出来其实发展到此阶段如果服务拆分的足够精细并且独立运行我觉得就可以将之理解为一个微服务了。
那么SOA与微服务差异在哪里呢可以说两种架构比起不同的架构有更多的相似之处然而它们是两种不同类型的架构。下面会详细分析这一点。
三、区别 下面进一步解释上表所述的不同之处 开发方面 - 在这两种体系结构中可以使用不同的编程语言和工具开发服务从而将技术多样性带入开发团队。开发可以在多个团队中组织但是在SOA中每个团队都需要了解常见的通信机制。另一方面使用微服务服务可以独立于其他服务运行和部署。因此频繁部署新版本的微服务或独立扩展服务会更容易。 “上下文边界” - SOA鼓励组件的共享而微服务尝试通过“上下文边界”来最小化共享。上下文边界是指以最小的依赖关系将组件及其数据耦合为单个单元。由于SOA依靠多个服务来完成业务请求构建在SOA上的系统可能比微服务要慢。 通信 - 在SOA中ESB可能成为影响整个系统的单一故障点。由于每个服务都通过ESB进行通信如果其中一个服务变慢可能会阻塞ESB并请求该服务。另一方面微服务在容错方面要好得多。例如如果一个微服务存在内存错误那么只有该微服务会受到影响。所有其他微服务将继续定期处理请求。 互操作性 - SOA通过消息中间件组件促进了多种异构协议的使用。微服务试图通过减少集成选择的数量来简化架构模式。因此如果您想要在异构环境中使用不同协议来集成多个系统则需要考虑SOA。如果您的所有服务都可以通过相同的远程访问协议访问那么微服务对您来说是一个更好的选择。 大小Size - 最后一点但并非最不重要的一点SOA和微服务的主要区别在于规模和范围。微服务架构中的前缀“微”是指内部组件的粒度意味着它们必须比SOA架构的服务往往要小得多。微服务中的服务组件通常有一个单一的目的他们做得很好。另一方面在SOA服务中通常包含更多的业务功能并且通常将它们实现为完整的子系统。
四、总结
我们不能简单地说一种架构比另一种架构更好。这主要取决于您正在构建的应用程序的目的。SOA更适合需要与许多其他应用程序集成的大型复杂企业应用程序环境。这就是说小型应用程序不适合SOA架构因为它们不需要消息中间件组件。而微服务架构在另一方面是更适合于较小和良好的分割基于Web的系统。另外如果您正在开发移动或Web应用程序那么微服务作为开发人员可以为您提供更大的控制权。最后我们可以得出结论因为它们服务于不同的目的微服务和SOA确实是不同类型的体系结构。
