Dubbo简介和微服务

单体架构

优缺点

修改后测试麻烦，迭代困难
修改工具类，其他的模块都受到影响
某个模块扩展扩容起来麻烦
部署和回滚不方便

微服务框架引入

概念

微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务。

架构图

微服务架构设计原则

拆分足够小
服务之间轻量级通信

微服务的优点

相对于单体架构，它的主要特点是组件化、松耦合、自治、去中心化，体现在以下几个方面：

一组小的服务服务粒度要小，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情。

独立部署运行和扩展
- 每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。
独立开发和演化
- 技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对单体架构，微服务架构是更面向业务创新的一种架构模式。
独立团队和自治
- 团队对服务的整个生命周期负责，工作在独立的上下文中，自己决策自己治理，而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。

微服务的缺点

服务拆分微服务架构可能带来过多的操作。
分布式系统可能复杂难以管理。
因为分布部署跟踪问题难。
分布式事务比较难处理
当服务数量增加，管理复杂性增加。

微服务拆分思路

横向拆分

纵向拆分

微服务的选择

Dubbo （RPC）（zookeeper）

Dubbo

长连接
- Dubbo是阿里集团开源的一个极为出名的RPC（Remote process call）框架，在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是及其鲜明的特色。同样的远程接口是基于Java Interface，并且依托于spring框架（管理Bean生命周期）方便开发。可以方便的打包成单一文件，独立进程运行，和现在的微服务概念一致。所以目前Dubbo是一种广泛使用的微服务架构框架。

RPC

RPC= Remote Process Call 跨进程调用

RPC的本质是提供了一种轻量无感知的跨进程通信的方式，在分布式机器上调用其他方法与本地调用无异（远程调用的过程是透明的，你并不知道这个调用的方法是部署在哪里，通过PRC能够解耦服务）。RPC是根据语言的API来定义的，而不是基于网络的应用来定义的，调用更方便，协议私密更安全、内容更小效率更高。

客户端（Client），服务的调用方。
服务端（Server），真正的服务提供者。
客户端存根，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法。
基于TCP/IP协议。速度快。

Springcloud （HTTP）服务的治理框架

Springcloud （HTTP/REST）

Spring Cloud来源于Spring，利用Spring Boot进行快捷开发。 Spring Cloud基本上都是使用了现有的开源框架进行的集成，学习的难度和部署的门槛就比较低，对于中小型企业来说，更易于使用和落地。Spring Cloud 核心组件Eureka是Netflix开源的一款提供服务注册和发现的产品，它提供了完整的Service Registry和Service Discovery实现。也是Spring Cloud体系中最重要最核心的组件之一。

http

应用层协议，简单。
http接口是在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议进行传输。
使用Http协议的微服务，通常返回json数据，然后把json转换为对象。

小结

RPC服务和HTTP服务还是存在很多的不同点的，一般来说，RPC服务主要是针对大型企业的，而HTTP服务主要是针对小企业的，因为RPC效率更高，而HTTP服务开发迭代会更快。总之，选用什么样的框架不是按照市场上流行什么而决定的，而是要对整个项目进行完整地评估。

微服务的基本概念

服务者提供者Provide

提供服务的具体实现

服务调用者Consumer

通过一些框架来调用服务提供者提供的服务

注意：同一个微服务，既可以是provider，也可以是consumer。

Dubbo引入

spring和Dubbo的结合

服务提供者

代码

先在服务端定义一个接口

然后在服务端提供这个接口的实现

配置

服务器使用者

代码

远程调用代码

配置

SpringBoot和Dubbo的结合

导包

<dependency>
   <groupId>com.alibaba.spring.boot</groupId>
   <artifactId>dubbo-spring-boot-starter</artifactId>
   <version>2.0.0</version>
</dependency>

提供者

配置：

spring.application.name=dubbo-spring-boot-starter
spring.dubbo.server=true
spring.dubbo.registry=N/A

使用者

也要实现一模一样的接口
在这里插入图片描述

然后在main方法里面测试

测试

先启动服务提供者

再启动使用者
这行log会出现在下面的空行位置

直连提供者

介绍

刚才使用的微服务的用法，实际上是一种最简单的点对点调用方式。这种方式通常用于测试环境。在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直联方式，将以服务接口为单位，忽略注册中心的提供者列表，A 接口配置点对点，不影响 B 接口从注册中心获取列表。

注意为了避免复杂化线上环境，不要在线上使用这个功能，只应在测试阶段使用。

弊端

不利于分布式的扩展

服务注册和服务发现

架构图

服务提供者去注册中心注册的时候告诉注册中心哪些内容？

1，服务提供者的IP地址

2，服务暴露的端口号

3，服务暴露的协议

4，服务暴露的接口名字（全类名）

5，服务提供者的服务的名字

dubbo://192.168.2.45:20880?applicationName=dubbo-provider&className=com.ciggar.common.DemoService&registerTime=……

服务发现和服务注册的过程

名词解释：

Zookeeper

是一个中间件，负责为分布式系统提供协调服务。服务注册和服务发现。

下载路径https://www.apache.org/dyn/closer.cgi/zookeeper/

下载解压之后

修改一个文件名

zoo_sample.cfg修改为zoo.cfg

Spring +dubbo项目如何整合zookeeper

导入依赖

    <groupId>com.101tec</groupId>
    <artifactId>zkclient</artifactId>
    <version>0.9</version>
</dependency>
<dependency>
    <groupId>org.apache.zookeeper</groupId>
    <artifactId>zookeeper</artifactId>
    <version>3.4.9</version>
    <type>pom</type>
</dependency>

修改服务端

启动：

没有报错，

Zookeeper那边的命令行会出现一些log

修改客户端

测试

Springboot 和 dubbo项目整合zookeeper

依赖

修改地址

spring.application.name=dubbo-spring-boot-starter
spring.dubbo.server=true
spring.dubbo.registry=zookeeper://localhost:2181

启动

使用端

<dependency>
   <groupId>com.101tec</groupId>
   <artifactId>zkclient</artifactId>
   <version>0.10</version>
</dependency>

配置文件：

spring.dubbo.registry=zookeeper://localhost:2181

代码

测试

负载均衡

概念

LoadBalance 中文意思为负载均衡，它的职责是将网络请求，或者其他形式的负载“均摊”到不同的机器上。避免集群中部分服务器压力过大，而另一些服务器比较空闲的情况。通过负载均衡，可以让每台服务器获取到适合自己处理能力的负载。在为高负载服务器分流的同时，还可以避免资源浪费，一举两得。

负载均衡策略

Random

随机加权

RandomLoadBalance 是加权随机算法的具体实现，它的算法思想很简单。假设我们有一组服务器 servers = [A, B, C]，他们对应的权重为 weights = [5, 3, 2]，权重总和为10。现在把这些权重值平铺在一维坐标值上，[0, 5) 区间属于服务器 A，[5, 8) 区间属于服务器 B，[8, 10) 区间属于服务器 C。接下来通过随机数生成器生成一个范围在 [0, 10) 之间的随机数，然后计算这个随机数会落到哪个区间上。权重越大的机器，在坐标轴上对应的区间范围就越大，因此随机数生成器生成的数字就会有更大的概率落到此区间内。

RoundRobin

我们有三台服务器 A、B、C。我们将第一个请求分配给服务器 A，第二个请求分配给服务器 B，第三个请求分配给服务器 C，第四个请求再次分配给服务器 A。这个过程就叫做轮询。轮询是一种无状态负载均衡算法，实现简单，适用于每台服务器性能相近的场景下。通常我们可以给轮询的机器设置不同的权重，经过加权后，每台服务器能够得到的请求数比例，接近或等于他们的权重比。比如服务器 A、B、C 权重比为 5:2:1。那么在8次请求中，服务器 A 将收到其中的5次请求，服务器 B 会收到其中的2次请求，服务器 C 则收到其中的1次请求。

LeastActive

LeastActiveLoadBalance 翻译过来是最小活跃数负载均衡。活跃调用数越小，表明该服务提供者效率越高，单位时间内可处理更多的请求。此时应优先将请求分配给该服务提供者。在具体实现中，每个服务提供者对应一个活跃数 active。初始情况下，所有服务提供者活跃数均为0。每收到一个请求，活跃数加1，完成请求后则将活跃数减1。在服务运行一段时间后，性能好的服务提供者处理请求的速度更快，因此活跃数下降的也越快，此时这样的服务提供者能够优先获取到新的服务请求、这就是最小活跃数负载均衡算法的基本思想。