springcloud

参考

系统架构演变

单一应用

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简 化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。

  • 无法针对不同模块进行针对性优化
  • 无法水平扩展（负载均衡可以解决）
  • 单点容错率低，并发能力差（负载均衡可以解决）

垂直拆分

当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能 对系统进行拆分

优点：

  • 系统拆分实现了流量分担，解决了并发问题
  • 可以针对不同模块进行优化
  • 方便水平扩展，负载均衡，容错率提高

缺点：

  • 系统间相互独立，会有很多重复开发工作，影响开发效率

分布式服务

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定 的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式调 用是关键。

优点：

  • 将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率

缺点：

  • 系统间耦合度变高，调用关系错综复杂，难以维护

SOA服务治理

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问 压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是 关键

以前出现了什么问题？

  • 服务越来越多，需要管理每个服务的地址
  • 调用关系错综复杂，难以理清依赖关系
  • 服务过多，服务状态难以管理，无法根据服务情况动态管理
  • 服务治理要做什么？
  • 服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
  • 服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系
  • 动态监控服务状态监控报告，人为控制服务状态
  • 缺点：
  • 服务间会有依赖关系，一旦某个环节出错会影响较大 服务关系复杂，运维、测试部署困难，不符合DevOps思想

，微服务架构

前面说的SOA，英文翻译过来是面向服务。微服务，似乎也是服务，都是对系统进行拆分。因此两者非 常容易混淆，但其实缺有一些差别：

  • 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
  • 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五 脏俱全”。
  • 面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与 平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
  • 自治：自治是说服务间互相独立，互不干扰
    • 团队独立：每个服务都是一个独立的开发团队，人数不能过多。
    • 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
    • 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同 接口
    • 数据库分离：每个服务都使用自己的数据源
    • 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续 交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

Service Mesh

远程调用方式

无论是微服务还是SOA，都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢？ 常见的远程调用方式有以下几种： RPC：Remote Produce Call远程过程调用，类似的还有RMI。自定义数据格式，基于原生TCP通 信，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型

Http：http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服 务端通信基本都是采用Http协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。 现在热门的Rest风格，就可以通过http协议来实现。

RPC

RPC，即 Remote Procedure Call（远程过程调用），是一个计算机通信协议。 该协议允许运行于一台 计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。说得通俗一点就 是：A计算机提供一个服务，B计算机可以像调用本地服务那样调用A计算机的服务。

通过上面的概念，我们可以知道，实现RPC主要是做到两点：

  • 实现远程调用其他计算机的服务
    • 要实现远程调用，肯定是通过网络传输数据。A程序提供服务，B程序通过网络将请求参数传 递给A，A本地执行后得到结果，再将结果返回给B程序。这里需要关注的有两点：
      • 1）采用何种网络通讯协议？ 现在比较流行的RPC框架，都会采用TCP作为底层传输协议
      • 2）数据传输的格式怎样？
        • 两个程序进行通讯，必须约定好数据传输格式。就好比两个人聊天，要用同一种语 言，否则无法沟通。所以，我们必须定义好请求和响应的格式。另外，数据在网路 中传输需要进行序列化，所以还需要约定统一的序列化的方式。
  • 像调用本地服务一样调用远程服务
    • 如果仅仅是远程调用，还不算是RPC，因为RPC强调的是过程调用，调用的过程对用户而言 是应该是透明的，用户不应该关心调用的细节，可以像调用本地服务一样调用远程服务。所 以RPC一定要对调用的过程进行封装

Http

Http协议：超文本传输协议，是一种应用层协议。规定了网络传输的请求格式、响应格式、资源定位和 操作的方式等。但是底层采用什么网络传输协议，并没有规定，不过现在都是采用TCP协议作为底层传 输协议。说到这里，大家可能觉得，Http与RPC的远程调用非常像，都是按照某种规定好的数据格式进 行网络通信，有请求，有响应。没错，在这点来看，两者非常相似，但是还是有一些细微差别。

  • RPC并没有规定数据传输格式，这个格式可以任意指定，不同的RPC协议，数据格式不一定相同。
  • Http中还定义了资源定位的路径，RPC中并不需要
  • 重要的一点：RPC需要满足像调用本地服务一样调用远程服务，也就是对调用过程在API层面进 行封装。Http协议没有这样的要求，因此请求、响应等细节需要我们自己去实现。
    • 优点：RPC方式更加透明，对用户更方便，更安全。Http方式更灵活，没有规定API和语言， 跨语言、跨平台
    • 缺点：RPC方式需要在API层面进行封装，限制了开发的语言环境。Http方式比RPC慢。
    例如我们通过浏览器访问网站，就是通过Http协议。只不过浏览器把请求封装，发起请求以及接收响 应，解析响应的事情都帮我们做了。如果是不通过浏览器，那么这些事情都需要自己去完成

如何选择

既然两种方式都可以实现远程调用，我们该如何选择呢？

  • 速度来看，RPC要比http更快，虽然底层都是TCP，但是http协议的信息往往比较臃肿，不过可以 采用gzip压缩。
  • 难度来看，RPC实现较为复杂，http相对比较简单
  • 灵活性来看，http更胜一筹，因为它不关心实现细节，跨平台、跨语言。

因此，两者都有不同的使用场景：

  • 如果对效率要求更高，并且开发过程使用统一的技术栈，那么用RPC还是不错的。
  • 如果需要更加灵活，跨语言、跨平台，显然http更合适

那么我们该怎么选择呢？ 微服务，更加强调的是独立、自治、灵活。而RPC方式的限制较多，因此微服务框架中，一般都会采用 基于Http的Rest风格服务

Http客户端工具

既然微服务选择了Http，那么我们就需要考虑自己来实现对请求和响应的处理。不过开源世界已经有很 多的http客户端工具，能够帮助我们做这些事情，例如：

  • HttpClient
  • OKHttp
  • URLConnection 接下来，我们就一起了解一款比较流行的客户端工具：HttpClient

介绍

HttpClient是Apache公司的产品，是Http Components下的一个组件。

  • 基于标准、纯净的Java语言。实现了Http1.0和Http1.1
  • 以可扩展的面向对象的结构实现了Http全部的方法（GET, POST, PUT, DELETE, HEAD, OPTIONS, and TRACE）
  • 支持HTTPS协议。 通过Http代理建立透明的连接。
  • 自动处理Set-Cookie中的Cookie。

使用

初始springcloud

微服务是一种架构方式，终肯定需要技术架构去实施。 微服务的实现方式很多，但是火的莫过于Spring Cloud了。为什么？

  • 后台硬：作为Spring家族的一员，有整个Spring全家桶靠山，背景十分强大。
  • 技术强：Spring 作为Java领域的前辈，可以说是功力深厚。有强力的技术团队支撑，一般人还真 比不了
  • 群众基础好：可以说大多数程序员的成长都伴随着Spring框架，试问：现在有几家公司开发不用 Spring？SpringCloud与Spring的各个框架无缝整合，对大家来说一切都是熟悉的配方，熟悉的味 道。
  • 使用方便：相信大家都体会到了SpringBoot给我们开发带来的便利，而SpringCloud完全支持 SpringBoot的开发，用很少的配置就能完成微服务框架的搭建

SpringCloud是Spring旗下的项目之一，官网地址：http://projects.spring.io/spring-cloud/

Spring擅长的就是集成，把世界上好的框架拿过来，集成到自己的项目中。

SpringCloud也是一样，它将现在非常流行的一些技术整合到一起，实现了诸如：配置管理，服务发 现，智能路由，负载均衡，熔断器，控制总线，集群状态等等功能。其主要涉及的组件包括： netflix（https://netflix.github.io/）

Eureka：注册中心

Zuul：服务网关

Ribbon：负载均衡

Feign：服务调用

Hystrix：熔断器

SpringCloud的版本命名比较特殊，因为它不是一个组件，而是许多组件的集合，它的命名是以A到Z的 为首字母的一些单词组成：

我们在项目中，会是以Finchley的版本。 其中包含的组件，也都有各自的版本，如下表：

微服务场景模拟

首先，我们需要模拟一个服务调用的场景。方便后面学习微服务架构

服务提供者

我们新建一个项目，对外提供查询用户的服务。

借助于Spring提供的快速搭建工具：

  • New Module > Spring Initializr>选择Default
  • 填写项目信息
  • 添加web依赖
  • 添加mybatis依赖
  • 填写项目位置

编写代码

  • 添加一个对外查询的接口
    • controller
    • service
    • mapper
    • 实体类
  • 属性文件，采用yaml语法
  • 准备数据库表

启动并测试：http://localhost:8081/user/16

服务调用者

与上面类似，这里不再赘述，需要注意的是，我们调用user-service的功能，因此不需要mybatis相关依 赖了。

编写代码

  • 首先在启动类中注册 RestTemplate
  • 然后编写UserDao，注意，这里不是调用mapper查数据库，而是通过RestTemplate远程查询userservice-demo中的接口
  • 然后编写user-service，循环查询UserDAO信息
  • 编写controller

启动测试：http://localhost:8080/consume?ids=16,17,18

Eureka注册中心

问题分析

在刚才的案例中，user-service对外提供服务，需要对外暴露自己的地址。而consumer（调用者）需要 记录服务提供者的地址。将来地址出现变更，还需要及时更新。这在服务较少的时候并不觉得有什么， 但是在现在日益复杂的互联网环境，一个项目肯定会拆分出十几，甚至数十个微服务。此时如果还人为 管理地址，不仅开发困难，将来测试、发布上线都会非常麻烦，这与DevOps的思想是背道而驰的。

网约车

这就好比是 网约车出现以前，人们出门叫车只能叫出租车。一些私家车想做出租却没有资格，被称为黑 车。而很多人想要约车，但是无奈出租车太少，不方便。私家车很多却不敢拦，而且满大街的车，谁知 道哪个才是愿意载人的。一个想要，一个愿意给，就是缺少引子，缺乏管理啊。 此时滴滴这样的网约车平台出现了，所有想载客的私家车全部到滴滴注册，记录你的车型（服务类 型），身份信息（联系方式）。这样提供服务的私家车，在滴滴那里都能找到，一目了然。 此时要叫车的人，只需要打开APP，输入你的目的地，选择车型（服务类型），滴滴自动安排一个符合 需求的车到你面前，为你服务，完美！

Eureka做什么

Eureka就好比是滴滴，负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务，而是把自己 的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。 同时，服务提供方与Eureka之间通过 “心跳” 机制进行监控，当某个服务提供方出现问题，Eureka自然 会把它从服务列表中剔除。 这就实现了服务的自动注册、发现、状态监控。

  • Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址
  • 提供者：启动后向Eureka注册自己信息（地址，提供什么服务）
  • 消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定 期更新
  • 心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态

入门案例

接下来我们创建一个项目，启动一个EurekaServer：

依然使用spring提供的快速搭建工具：

  • 选择依赖：New Module>E
posted @ 2023-04-19 09:03  挖洞404  阅读(19)  评论(0)  编辑  收藏  举报