JAVA后端知识点碎片化整理 基础篇(九) 微服务(dubbo)

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/weixin_39893439/article/details/81005924

因为马上开始2019秋招、平时的学习比较琐碎、JAVA后端博大精深,想在暑假这段时间从头开始整理JAVA知识点查缺补漏,迎战2019秋招。主要参考(微信公众号)JAVA团长与(博客园)五月的仓颉的知识点复习线,对其列出的每一个的知识点再一次的咀嚼并谈谈自己的理解。(平时从这两位学到很多,也非常感谢身边同行的人)补充一下:其中知识点的讲解参考了之前看过的博客讲解或者书籍,之所以称之为基础篇,主要是加深对Java技术栈的宏观认识。

微服务:小:微服务体积小;独:能独立部署与运行;轻:使用轻量级的通信机制与架构;松:为各个服务之间松耦合。

分布式领域的CAP理论:Consistency一致性:数据一致性更新,所有数据变动都是同步的;Availability 好的响应性能;Partition tolerance分区容忍性可靠性。定理就是任何分布式系统只能兼顾只其中两点,而我们现有的网络架构必须一般保证分区容忍性,因为必须考虑网络的不可靠性。

 

分布式场景:

解决java集群session共享问题的解决方案:

客户端cookie加密(一般用于内网企业级的系统中,要求用户流浪器端的cookie不能禁用)

集群中,各个服务器提供session复制功能,tomcat和jboss都实现了这样的功能,性能随着服务器增加急剧下载容易引起广播风暴,数据库保存session 需要序列化,影响性能。

session的持久化,使用数据库来保存session。就算服务器宕机也没事儿,数据库中的session照样存在。特点:每次请求session都要读写数据库,会带来性能开销。使用内存数据库,会提高性能,但是宕机会丢失数据(像支付宝的宕机,有同城灾备、异地灾备)。

用共享存储来保存session。和数据库类似,就算宕机了也没有事儿。其实就是专门搞一台服务器,全部对session落地。特点:频繁的进行序列化和反序列化会影响性能。

 

RPC框架:RPC目的是本地调用远程的方法,而对你老说这个调用是透明的,并不需要聊着这个方法在哪部署,通过RPC能够解耦服务,Remote Rprocedure call 远程过程调用,允许一台计算机调用另一台计算机上的结果,而不希望额外的编程。

RPC框架原理:Provider(服务的提供方)、Consumer(服务的消费方)和Registry(服务注册与发现中心)

RPC的详细调用过程就是:1、服务消费方调用以本地调用方式调用服务;2、client stub接受到调用后负责将方法、参数组装打包在消息体中;3、client stub找到服务地址,并将消息发送到服务端、4、server stub收到消息后进行解码 ;5、server stub根据解码结果调用本地服务;6、本地服务执行并将结果返回给server stub7、server stub将返回结果打包成消息并发送至消费方8、client stub接收到消息,并进行解码9服务消费方得到最终结果。

使用到的技术:1、动态代理(拦截调用)生成client stub和Server stub需要用到JDK动态代理技术,2、序列化:为了能在网络上传输和接受Java对象,我们需要对他进行序列化和反序列化操作。3、NIO 当前很多RPC框架都基于netty这一IO通信框架。4、服务注册中心 可选技术Redis Zookeeper等

如何理解RESTFUL

Rest是一种软件架构风格,设计风格,他是面向资源的网络化超媒体应用的架构风格。他主要是用于构建轻量级的可维护的可伸缩的WEB的服务。基于REST的服务被称为RESTFUL服务,不依赖与任意协议,但每一个Restful使用HTTP作为底层协议。幂等性:对统一REST接口的多次访问,得到的资源状态的是相同的,  安全性:对该REST接口访问,不会使服务器的资源状态发生改变。

Dubbo基本概念 dubbo开发者手册的架构图

说说Dubbo的实现原理:Consumer服务消费者,Container服务容器、消费者就是invoke提供者,invoke这条线按照图上说明当然是同步的意思,多说一句,在实际调用过程中,provider的位置对于Consumer来说是透明的,这一次调用服务位置和下一次调用服务是不同的,这里是软件负载均衡。服务提供者先启动start,然后注册register服务。消费订阅subscribe服务,如果没有订阅到自己想象的服务,他会不断的尝试订阅,新的服务注册到服务中心之后,以后注册中心会将这些服务通过notify到消费者,Monitor是一个监控,图中虚线表名Consumer和Provider通过异步的方式发送到Monitor,Consumer和Provider会将信息放到本地磁盘,Monitor功能需要单独配置,不配置或者配置以后,Monitor过掉并不会影响服务的调用。

dubbo的系统架构:每层关注点不同,具体看官方文档

 

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

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

3、服务代理层Proxy:封装服务地址的注册和发现,以服务URL为中心,扩展接口为RegistryFactory、Registry和RegistryService,可以没有服务注册中心,以时服务提供方直接暴露服务。

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

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

6、监控层(Moniitor)RPC调用次数与调用监控时间。

7、远程调用层(Protocol)封装RPC调用,以Invovaton和Result为中心,扩展接口为Protocol,Invoker和Exporter。Protocol是服务域,他是Invoker暴露和引用的的主功能入口,他负责Invoker的声明管理周期。Invoker是实体域,他是Dubbo的核心模型,其他模型向他靠拢,或者装换成他,他代表一个执行体,就是服务的集合,可以向他发出invoke调用,他可以是本地的实现也可以是远程的实现,

8、信息调用层(Exchange):封装了请求响应模式,同步转异步,以Request和Response为中心,扩展接口Exchanger等

9、网络传输层(Transport):抽象mina与netty作为统一接口,以Message为中心,扩展接口channel等

10、数据序列化层(Serialize):可以复用的一些工具,扩展接口为Serialization等

 

服务定义:服务是围绕服务提供方和服务消费方的,服务提供方实现服务,而服务消费方调用服务。

服务注册:通过服务提供方和服务消费方的,服务提供方实现服务,服务消费方调用服务;

服务注册:对于服务提供方,他需要发布服务,而且由于应用系统的复杂性,服务的数量,类型也不断膨胀,而对于服务消费方,它最关心如何获取他需要的服务,而面对复杂的应用系统,需要大量的服务调用,并且,对于服务提供方和服务消费方来说,他们还可以可能兼具这两种角色,即需要提供服务也需要消费服务。通过服务统一管理起来,可以有效优化内部应用对服务发布使用流程和管理。服务注册中心可以通过特定的协议完成服务的对外统一。如zookeeper注册中心,redis注册中心。。

服务监控:无论服务提供方,还是服务消费方,他们都需要对服务的调用的实际状态进行有效监控,从而改变服务质量。

远程通信与信息交换:远程通信需要双方所约定的协议,在保证通信双方理解协议的语义的基础上,还要保证高效稳定的消息创术,dubbo主要通信框架有netty mina Grizzly

服务调用:基于RPC层,服务提供方和服务消费方之间的调用关系,服务提供方发布服务到服务中心,服务消费方去订阅服务,服务消费方调用已注册的可用业务。

协议支持:。。。dubbo、thrift、Redis等等

初始化过程细节

上图中的start就是讲服务装载带容器中,然后准备注册服务,和spring启动过程类似,spring启动时,将bean装载进容器中的时候,首先要解析bean,所以dubbo也是先读配置文件的解析服务。

(1)解析服务:dubbo的jar包中Meta-inf/spring。handler配置,spring在遇到dubbo名称空间时,会调用DubboNamespaceHandler类。   所有的dubbo标签都统一用dubboBeanDefinitionParser进行解析,基于一对一属性映射,将XML标签解析成Bean对象。 然后Bean对象会被转换成url格式,将所有Bean属性转成url的参数,将url传给Protocol扩展点,再更具URL协议头对不同协议的服务进行暴露于引用。

(2)暴露服务:一、只暴露服务,在没有使用注册中心的情况下,这种情况一般适用在开发环境下,调用与提供在同一个IP上,只需打开服务的端口即可。URL格式Dubbo://service-host/com.xxx.TxxService?version=1.0.0  二、向注册中心暴露服务:需要服务的IP和端口异同暴露给注册中心。registry://registry-host/com.alibaba.dubbo.registry.RegistryService?export=URL.encode(“dubbo://service-host/com.xxx.TxxService?version=1.0.0”)

(3)引用服务:a、直接引用服务:在没有注册中心,直连提供者情况下,基于扩展点的Adaptive机制,直接嗲用DubboProtocol的refer方法返回提供者。b、从注册中心发现服务,多个提供者的应用将通过RegistryProtocol将多个提供者引用,通过Cluster扩展点,伪装成单个提供返回。

对于Protocol扩展的使用,URL传给Protocol扩展点,基于扩展点的Adaptive机制,根据URL的协议头,进行不同协议的服务暴露或引用。

服务提供者暴露一个服务的详细过程:

ServiceConfig类拿到对外服务的实际类ref,然后通过ProxyFactory类的getInvoker方法使用ref生成一个AbstractProxyInvoker实例,到这一步就完成具体服务到invoker的转化。接下来就是invoker转换到Exporter的过程。

 

 

展开阅读全文

没有更多推荐了,返回首页