初识微服务框架——Dubbo

一，软件技术架构演变之路

1，架构的整体分类：

​ 单体式架构——》垂直应用架构——》分布式架构——》SOA架构（面向服务开发）——》微服务

2，单体式架构

1，什么是单体架构？

​         单体架构就是将所有业务场景中的表示层、业务层和数据访问层放在一个工程中，最终 经过编译、打包为war包或者jar包，部署在一台服务器上。

​         通俗的说法：如果一个war包或者jar包包含了一个应用的所有功能，则就是单体式架构。

​         最早的ssh、ssm项目就是单体式架构的项目

2，单体架构的优点？

        架构简单、运维简单。开发成本低，开发周期短。

3，单体架构的缺点？

        a，系统启动慢，一个进程包含了所有的业务逻辑，涉及到的模块多，导致系统启动时间过长。

​         b，系统错误，隔离性差、可用性差，任何一个模块的错误都有可能导致整个系统的宕机。

​         c，可伸缩性差。系统的扩容只能对整个应用程序扩容，成本高，不能做到对某个功能点进行扩容。

​         e，技术栈受限。只能使用1种语言开发。

4，单体架构的适用场景

​         a，业务不复杂、访问量小的项目

​         b，例如：政府项目、管理系统、crm客户关系管理系统

5，问题：

​         由于单体系统可伸缩性差、隔离性也差，为了能够创造更大的价值，所以我们要优化她，可以通过横向添加服务器，把单台变成多台机器的集群。也可以按照业务维度进行拆分，减少业务的耦合度，以及降低单个war包或者jar包带来的伸缩性困难的问题。所以，集群出现了。

3，集群及业务拆分

1，什么是集群？

​          集群就是单机的多实例，在多个服务器上部署多个服务，每个服务就是一个节点，这些节点的集合就是集群。

2，集群的优点：

​         操作简单，容易部署

3，集群的缺点：

​         每个节点负载相同（耦合度高），每个具体业务的访问量可能差异很大。

4，适用场景

​         单击处理达到瓶颈的时候，把单机赋值积分，就构成了一个“集群”。

4，分布式架构

1，什么是分布式架构？

​         分布式架构，就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被成为“服务”。这些子系统能够独立运行在web容器中，他们之间通过RPC（远程调用）方式通信。

2，分布式的优点

​         a，对基础服务进行了抽取，服务之间可以相互调用，提高了代码复用和开发效率。

​         b，提高了资源利用率。

3，分布式的缺点

​         a，业务之间的耦合度高，调用关系错综复杂。

​         b，可靠性比较低，如果一台服务器出现问题的话，整个系统就会崩塌。

5，分布式和集群的区别？

         1，集群是个物理形态，分布式是个工作方式。

​         集群：同一个业务，部署在多个服务器上

​         分布式：一个业务分拆多个子业务，部署在不同的服务器上。

         2，分布式是以缩短单个任务的执行时间来提升效率的；而集群是通过提高单位时间内执行的任务数来提高效率的

6，SOA架构

1，什么是SOA架构？

​         SOA是基于分布式架构演变而来的，俗称服务化，也就是面向服务开发，将共同存在的业务逻辑抽取成一个公共的服务，提供给其他结构实现调用，服务于服务之间采用RPC远程调用来通信。

2，特点：

​         a，SOA架构模式传输协议采用SOAP协议（HTTP/HTTPS+XML）实现传输，在高并发情况下实现通讯该协议存在大量的冗余性传输，非常占用宽带。

​         b，SOA架构模式实现方案是Web Service或者ESB企业服务总线。

3，缺点：

​         a，SOA协议实现通讯，XML传输非常重，效率比较低

​         b，服务化管理和治理设施不够完善

​         c，依赖于中心服务发现机制。

​         d，不适合前后端分离架构模式

7，微服务架构

1，什么是微服务架构？

​         a，微服务起源于Martin Fowler（马丁·福勒，微服务的提出者） 所写的一篇文章Microservices （https://martinfowler.com/microservices/）

​         b，微服务架构风格是一种将一个单体应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制（通常是基于HTTP协议的RESTful API）。这些服务围绕业务能力构建，并且可通过全自动不部署机制独立部署。这些服务公用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
​

2，微服务架构的特征:

​         a，每个服务按照业务划分

​         b，服务之间通过轻量级API调用

​         c，可用使用不同语言开发

​         d，可用使用不同的数据存储技术

​         e，可以独立部署，服务之间互相不影响

​         f，可以针对用户访问流量大的服务单独扩展，从而能够节约资源

​         g，管理自动化

3，优点：

​         a，逻辑清晰，项目复杂度降低：通过对共享业务更加细粒度的拆分，一个服务只需要关注一个特定的业务领域即可，并通过定义良好的接口清晰表述服务边界。

​         b，技术选型更加灵活：每个微服务都有不同的团队来维护，所以可以结合业务特性自由选择技术栈

​         c，可扩展性更强： 可以根据每个微服务的性能要求和业务特点对服务进行灵活扩展。

​         d，独立部署：单个微服务的代码量比较小，使得发布更加高效。

​         e，容错性：如果一个服务发生故障，可以通过重试、降级等机制实现容错。

4，缺点：

​         a，性能降低，微服务之间通过REST、RPC等形式进行交互，通信的延时会受到较大的影响

​         b，提升了运维的难度（版本发布、问题排查、配置管理、监控）

​         c，数据一致性的问题

5，挑战

​ 微服务架构面临的挑战

​         1，微服务粒度大小难以划分，需要设计人员对业务有很好的掌握；

​         2，分布式复杂性，主要体现在分布式事务、网络延迟、系统容错等问题解决难度较大；

​         3，微服务之间通信成本较高，对微服务之间网络稳定性、通信速度要求较高；

​         4，由于微服务数量较大，运维人员运维、部署有较大的挑战

​ 技术挑战

​         1，微服务架构的主要目的是实现业务服务的解耦；

​         2，对服务进行治理（服务的注册与发现、服务与服务之间的调用、熔断限流、负载均衡、 链路追踪、分布式配置中心、服务路由等）；

6，分布式微服务架构的相关概念：

​         a，提供者（Provider）：提供接口供其他项目调用的项目

​          b，消费者（Consumer）：调用提供者接口的项目

​         c，RPC：远程过程调用，主要是基于TCP/IP协议的

​         d，RESTful：是一种网络应用程序的设计风格和开发方式，基于HTTP协议，可以使用XML格式定义或JSON格式定义。

​         e，集群：集群就是单机的多实例，在多个服务器上部署多个服务，每个服务就是一个节点，这些节点的集合就叫做集群。

​         f，分布式：分布式结构就是讲一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC或者RESTful方式通信。

7，官方网址：

​         Dubbo： http://dubbo.io/

​          Spring Cloud ：https://spring.io/projects/spring-cloud

​         Spring Cloud Alibaba：https://spring.io/projects/spring-cloud-alibaba

二，Dubbo简介

1，介绍一下Dubbo

​         a，Dubbo是阿里巴巴公司开源的基于java的高性能RPC分布式服务框架 ，现在已经成为apache基金会孵化项目。

​         b，Dubbo是一款高性能、轻量级的开源Java RPC 框架，它提供了三大核心能力：面向接口的远程方法调用、智能容错和负载均衡以及服务自动注册和发现。

2，Dubbo 和Dubbox的区别

​         Dubbo：http://dubbo.io/

​         Dubbox：https://github.com/dangdangdotcom/dubbox

​          dubbo：使用Dubbo的RPC调用方式，服务间仍然会存在API强依赖；

​          dubbox：相对于Dubbo支持了REST风格的原创调用（HTTP +JSON/XML）；

3，Dubbo的特性：

​         a，注册与发现：Dubbo使用Zookeeper做服务的注册中心，就是服务的提供者以临时节点的形式将服务Server 信息注册保存到Zookeeper的dubbo目录下的provider的节点下，供消费者发现调用。

​         b，负载均衡：Dubbo支持负载均衡策略，就是同一个Dubbo服务被多台服务器启用后，会在在Zookeeper提供者节点下显示多个相同接口名称节点。

​         c，容错机制：Dubbo的提供者在Zookeeper上使用的是临时节点，一旦提供者所在服务挂掉，该节点的客服端连接将会关闭，故节点自动消失。所以消费者调用接口时将不会轮询到已经挂掉的接口上 （延迟例外）。

​         d，Dubbo协议：Dubbo 缺省协议是dubbo协议，采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的 服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。

​         e，Dubbo容器：Dubbo在java jvm中有自己的容器，和Spring的bean一样，将服务对象保存到自己的容器中。

​          f，Dubbo协议监控中心：服务治理包含：负载均衡策略、服务状态、容错、路由规则限定、服务降级等
​

4，Dubbo运行的原理

​         a，Provider：暴露服务的服务提供方

​         b，Consumer：调用远程服务的服务消费方

​         c，Registry：提供注册与调用服务的注册中心

​         d，Monitor：统计服务的调用次数和调用时间的监控中心
​

5，Dubbo组件的调用关系：

​         a，服务容器负责启动、加载、运行服务提供者。

​         b，服务提供者在启动时，向注册中心注册自己提供的服务。

​         c，服务消费者在启动时，向注册中心订阅自己所需的服务。

​         d，注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心 将基于长连接推送变更数据给消费者。

​         e，服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

​         f，服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。