【面向服务体系架构】

什么是SOA

SOA:面向服务架构(Service Oriented Architecture)

关注点在业务,而不是在对象的变化上

必然性:编程技术的发展

  • 开始,基于过程式编程,使用大量函数
  • 面向对象编程出现,一切皆为对象
  • 面向组件编程出现,对可重用的对象组合成一个组件
  • 面向服务,

也可以看成是一个越来越抽象化的发展

 

功能浪费:多个系统中,各个系统有不少部分是相同或者类似的;SOA可以通过共用服务,减少这部分的开发

效率低下:因为重复做轮子,所以效率低下

架构复杂:因为各个系统架构都不同,增加复杂度

集成困难:不同系统是独立的,要集成的时候很困难

设计复杂:设计的对象不止是一个系统,而是对一对系统的统筹考虑

缺乏标准:业界缺少SOA的规范

自上而下设计(全局推动):要领导说话,决定,才能这么做

服务治理:很多服务开发出来,如何管理这些服务

提供了以上这些一些规范和原则

有大家都认可的契约,才能共同合作

服务自己管理自己,不应该和其他功能耦合

自己能控制自己的运行环境

2、Protobuf,一个关于数据序列化,数据传输、存储的一个工具,为了在SOA中更高效地处理数据;不完整的RPC组件

3、Thrift,一个RPC组件

 

4、Dubbo

Protobuf和Thrift面向跨语言,对Java支持没有那么好

DubboRPC框架

出现背景:

RPC,是客户端可以动态请求不同服务器的服务

SOA,是对服务的管理和治理

RPC,上面2个组件可以实现;而为了实现SOA,阿里巴巴开发出了Dubbo

简介和基础实例:

 

实现第三层和第四层开发需求

服务注册器,面向服务提供者,服务消费者

其中有一个包是api,这里是十分稳定的包,需要给消费者和提供者引用。

然后在消费者和提供者中通过xml配置即可配置好这个关系。

 Dubbo提供了3种协议

 

Dubbo使用3种传输方式,推荐Netty

Dubbo提供4种序列化方式

Dubbo提供2种动态代理方式,优先第一种,使用字节码

Dubbo支持3种容器

Dubbo基本功能上

通过XML即可构建Dubbo架构,

 

一般建议通过XML集中管理

 

一般在设计上避免这种情况,例如分开2个接口

 

dubbo提供4种注册中心的实现

 

 dubbo基本功能下

另外一种配置方式:在类路径下添加一个dubbo.properties即可

 

1、服务器角度控制,只有10个请求

2、客户端角度控制,支持多少活跃客户端

3、负载均衡,优先级

有3种缓存策略,可以选用

 

直接通过GenericService,加上方法名,参数发送,暴露

客户端消费:

一般不会通过API来做

服务治理:

Dubbo基本原理

其它暂略

架构设计原则(上)

总结上面的工具,如何设计这个框架

 分包:以下是主流的方法论

分包中最重要的2块

内聚:

为了实现支持插件化,Dubbo从上往下发展,都进行了尝试

 微内核,Dubbo使用的架构风格

Dubbo的插件,配置都是使用微内核的SPI来实现

 架构设计原则(下)

略:

原文地址:https://www.cnblogs.com/LiveYourLife/p/9277006.html