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

因为马上开始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的过程。