码迷,mamicode.com
首页 > 其他好文 > 详细

SOA架构设计案例分析

时间:2019-05-25 09:14:07      阅读:120      评论:0      收藏:0      [点我收藏+]

标签:microsoft   ons   交换   ref   net   逻辑   Stub   服务注册   actor   

   面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)进行拆分,并通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。这边文章以淘宝的SOA框架Dubbo为案例进行分析。淘宝为什么会应用SOA框架Dubbo呢?因为淘宝调用的服务越来越多,用以前的服务URL配置管理非常困难,并且硬件的压力页越来越大。这时需要一个服务注册中心,动态管理服务。继续发展,服务之间的关系页越来越复杂,描述服务之间的架构也越来越难。并且服务的调用越来越多,承载服务的机器越来越多。在这样的情况下,淘宝应用了SOA框架Dubbo。Dubbo是一个分布式服务框架,本质上是用来调用服务的方法,它能够有序、科学的调用机器上的服务,解决了淘宝调用服务越来越复杂的问题。

    Dubbo框架设计一共划分了10个层:

(1)服务接口层(Service):该层是与实际业务逻辑相关的,根据服务提供方和服务消费方的业务设计对应的接口和实现。

(2)配置层(Config):对外配置接口,以ServiceConfig和ReferenceConfig为中心,可以直接new配置类,也可以通过spring解析配置生成配置类。

(3)服务代理层(Proxy):服务接口透明代理,生成服务的客户端Stub和服务器端Skeleton,以ServiceProxy为中心,扩展接口为ProxyFactory。

(4)服务注册层(Registry):封装服务地址的注册与发现,以服务URL为中心,扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心,此时服务提供方直接暴露服务。

(5)集群层(Cluster):封装多个提供者的路由及负载均衡,并桥接注册中心,以Invoker为中心,扩展接口为Cluster、Directory、Router和LoadBalance。将多个服务提供方组合为一个服务提供方,实现对服务消费方来透明,只需要与一个服务提供方进行交互。

(6)监控层(Monitor):RPC调用次数和调用时间监控,以Statistics为中心,扩展接口为MonitorFactory、Monitor和MonitorService。

(7)远程调用层(Protocol):封将RPC调用,以Invocation和Result为中心,扩展接口为Protocol、Invoker和Exporter。Protocol是服务域,它是Invoker暴露和引用的主功能入口,它负责Invoker的生命周期管理。Invoker是实体域,它是Dubbo的核心模型,其它模型都向它靠扰,或转换成它,它代表一个可执行体,可向它发起invoke调用,它有可能是一个本地的实现,也可能是一个远程的实现,也可能一个集群实现。

(8)信息交换层(Exchange):封装请求响应模式,同步转异步,以Request和Response为中心,扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。

(9)网络传输层(Transport):抽象mina和netty为统一接口,以Message为中心,扩展接口为Channel、Transporter、Client、Server和Codec。

(10)数据序列化层(Serialize):可复用的一些工具,扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool。

 

 

 

 

 

SOA架构设计案例分析

标签:microsoft   ons   交换   ref   net   逻辑   Stub   服务注册   actor   

原文地址:https://www.cnblogs.com/wl2017/p/10920956.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!