分布式、微服务、SOA

分布式:分散压力

按功能点把一个完整的系统按照业务功能,拆分成 一个个独立的子系统 ,单独为某一节点添加服务器(不同模块部署在不同服务器上 ),需系统之间配合才能完成整个业务逻辑。    多个子系统之间相互协作,系统之间需要进行通信。(接口通信)==>各系统之间可以通过webservices进行通信,如使用服务中间件dubbo(RPC常用框架之一)效率更高。

在分布式结构中,每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中,它们之间可通过RPC(Remote Procedure Call Protocol  远过程调用协议,通信协议大多采用二进制方式)方式通信。

HTTP是一种协议,RPC可以通过HTTP来实现,也可以通过Socket自己实现一套协议来实现.

论复杂度,RPC框架肯定是高于简单的HTTP接口的。但毋庸置疑,HTTP接口由于受限于HTTP协议,需要带HTTP请求头,导致传输起来效率或者说安全性不如RPC。

http接口是在接口不多、系统与系统交互较少的情况下,解决信息孤岛初期常使用的一种通信手段;优点就是简单、直接、开发方便。利用现成的http协议 进行传输。但是如果是一个大型的网站,内部子系统较多、接口非常多的情况下,RPC框架的好处就显示出来了,首先就是长链接,不必每次通信都要像http 一样去3次握手什么的,减少了网络开销;其次就是RPC框架一般都有注册中心,有丰富的监控管理;发布、下线接口、动态扩展等,对调用方来说是无感知、统 一化的操作。第三个来说就是安全性。最后就是最近流行的服务化架构、服务化治理,RPC框架是一个强力的支撑。rpc是一种概念,http也是rpc实现的一种方式。论复杂度,dubbo/hessian用起来是超级简单的。最近用dubbo和hessian比较多,http的几乎都被废弃了。    可参考如下链接:

http://www.javashuo.com/article/p-uczfydog-n.html

https://blog.csdn.net/xiaohubeiplus/article/details/78201249

https://blog.csdn.net/wyongqing/article/details/80552638

https://blog.csdn.net/chen213wb/article/details/81747573

 

作用:解决网站高并发带来问题

  • 系统之间的耦合度大大降低,可以独立开发、独立部署、独立测试,系统与系统之间的边界非常明确,排错也变得相当容易,开发效率大大提升。
  • 系统之间的耦合度降低,从而系统更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促,下单量可能会大大提升,因此我们可以针对性地提升订单系统、产品系统的节点数量,而对于后台管理系统、数据分析系统而言,节点数量维持原有水平即可。
  • 服务的复用性更高。比如,当我们将用户系统作为单独的服务后,该公司所有的产品都可以使用该系统作为用户系统,无需重复开发。

 

集群:同一个业务,部署在多个服务器上

集群就是一组相互独立的计算机,通过高速的网络组成一个计算机系统,每个集群节点都是运行其自己进程的一个独立服务器。对网络用户来讲,网站后端就是一个单一的系统,协同起来向用户提供系统资源,系统服务。通过网络连接组合成一个组合来共同完一个任务。分布式中的每一个节点,都可以做集群。 而集群并不一定就是分布式的。 

作用:通过负载均衡设备共同对外提供服务;各服务可独立应用,组合服务也可系统应用

优势:高性能(performance)、价格有效性(性价比)、可伸缩性、高可用性

-负载均衡能把任务比较均衡地分布到集群环境下的计算和网络资源。

负载均衡集群为企业提供了更为实用,性价比更高的系统架构解决方案。负载均衡集群把很多客户集中访问的请求负载压力尽可能平均的分摊到计算机集群中处理。客户请求负载通常包括"应用程度处理负载"和"网络流量负载"。这样的系统非常适合向使用同一组应用程序为大量用户提供服务。每个节点都可以承担一定的访问请求负载压力,并且可以实现访问请求在各节点之间动态分配,以实现负载均衡。

负载均衡运行时,一般通过一个或多个前端负载均衡器将客户访问请求分发到后端一组服务器上,从而达到整个系统的高性能和高可用性。这样计算机集群有时也被称为服务器群。一般高可用性集群和负载均衡集群会使用类似的技术,或同时具有高可用性与负载均衡的特点。

|负载均衡集群的作用|:

分担访问流量(负载均衡)

保持业务的连续性(高可用性)

集群结构的好处就是系统扩展非常容易。如果随着你们系统业务的发展,当前的系统又支撑不住了,那么给这个集群再增加节点就行了。但是,当你的业务发展到一定程度的时候,你会发现一个问题——无论怎么增加节点,貌似整个集群性能的提升效果并不明显了。这时候,你就需要使用微服务结构了。

高可用性集群|:

一般是指当集群中的任意一个节点失效的情况下,节点上的所有任务自动转移到其他正常的节点上,并且此过程不影响整个集群的运行,不影响业务的提供。

类似是集群中运行着两个或两个以上的一样的节点,当某个主节点出现故障的时候,那么其他作为从节点的节点就会接替主节点上面的任务。从节点可以接管主节点的资源(IP地址,架构身份等),此时用户不会发现提供服务的对象从主节点转移到从节点。

|高可用性集群的作用|:

当一个机器宕机另一台进行接管。

比较常用的高可用集群开源软件有:keepalive,heardbeat

 

SOA :Service Oriented  Architecture  

在分布式机构基础上再次拆分为服务层、表现层

业务系统分解为多个组件,让每个组件都独立提供离散,自治,可复用的服务能力,

通过服务的组合和编排来实现上层的业务流程 

面向服务的架构是一种软件体系结构,应用程序的不同组件通过网络上的通信协议向其他组件提供服务。通信可以是简单的数据传递,也可以是两个或多个服务彼此协调连接。SOA架构中有两个主要角色:服务提供者(Provider)和服务使用者(Consumer)。而软件代理则可以扮演这两个角色。该Consumer层是用户(人、应用程序或第三方的其它组件)与SOA交互的点,和Provider层则由SOA架构内的所有服务所构成


作用:简化维护,降低整体风险,伸缩灵活

微服务:分散能力

架构设计概念,各服务间隔离(分布式也是隔离),自治(分布式依赖整体组合)其它特性(单一职责,边界,异步通信,独立部署)是分布式概念的跟严格执行SOA到微服务架构的演进过程 

微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步。基本上,这种架构类型是开发软件,网络或移动应用程序作为独立服务套件(又称微服务)的一种特殊方式。这些服务的创建仅限于一个特定的业务功能,如用户管理、用户角色、电子商务车、搜索引擎、社交媒体登录等。此外,它们是完全独立的,也就是说它们可以写入不同的编程语言并使用不同的数据库。集中式服务管理几乎不存在,微服务使用轻量级HTTP、REST或Thrift API进行通信。

 

SOA更适合需要与许多其他应用程序集成的大型复杂企业应用程序环境。微服务架构更适合于较小和良好的分割,基于Web的系统。因为它们服务于不同的目的,微服务和SOA确实是不同类型的体系结构。

ORM  ==>>  MVC (垂直架构)==>>  RPC ==>> SOA

本文部分内容参考自 资深架构师 的CSDN 博客 ,全文地址请点击:https://blog.csdn.net/chszs/article/details/78515231