Spring Cloud

Spring Cloud 自 2016 年 1 月发布第一个 Angel.SR5 版本-到目前 2020 年 3 月发布 Hoxton.SR3 版本-已经历经了 4 年时间。这 4 年时间里-Spring Cloud 一共发布了 46 个版本-支持的组件数从 5 个增加到 21 个。Spring Cloud 在 2019 年 12 月对外宣布后续 RoadMap：

  • 下一个版本 Ilford 版本是一个大版本。这个版本基于 Spring Framework 5.3 & Spring Boot 2.4-会在 2020 Q4 左右发布；
  • Ilford 版本会删除处于维护模式的项目。目前处于维护模式的 Netflix 大部分项目都会被删除（spring-cloud-netflix Github 项目已经删除了这些维护模式的项目）；
  • 简化 Spring Cloud 发布列车。后续 IaasS 厂商对应的 Spring Cloud 项目会移出 Spring Cloud 组织-各自单独维护（spring-cloud-azure 一直都是单独维护-spring-cloud-alibaba 孵化在 Spring Cloud 组织-毕业后单独维护）；
  • API 重构-会带来重大的改变（Spring Cloud Hoxton 版本新增了 Spring Cloud Circuit Breaker 用于统一熔断操作的编程模型和 Spring Cloud LoadBalanacer 用于处理客户端负载均衡并代替 Netflix Ribbon）。

    • 这个 RoadMap 可以说是对 Spring Cloud 有着非常大的变化。

    SpringCloud替代实现

    !img

    SpringCloud Alibaba

    组件

    Sentinel：把流量作为切入点-从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

    Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

    RocketMQ：一款开源的分布式消息系统-基于高可用分布式集群技术-提供低延时的、高可靠的消息发布与订阅服务。

    Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架。

    Seata：阿里巴巴开源产品-一个易于使用的高性能微服务分布式事务解决方案。

    Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。

    Alibaba Cloud OSS: 阿里云对象存储服务（Object Storage Service-简称 OSS）-是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。

    Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品-提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。

    Alibaba Cloud SMS: 覆盖全球的短信服务-友好、高效、智能的互联化通讯能力-帮助企业迅速搭建客户触达通道。

    第一阶段课程Spring Cloud技术点

    Eureka：服务注册与发现-用于服务管理。

    Feign： web调用客户端-能够简化HTTP接口的调用。

    Ribbon：基于客户端的负载均衡。

    Hystrix：熔断降级-防止服务雪崩。

    Zuul：网关路由-提供路由转发、请求过滤、限流降级等功能。

    Config：配置中心-分布式配置管理。

    Sleuth：服务链路追踪

    Admin：健康管理

    服务进化概述

  • 传统服务到微服务进化。

    • > 《传统到分布式演进》

  • 单体应用-> SOA ->微服务（下面讲）

    • ``plain 课外扩展：持续集成-持续部署-持续交付。集成:是指软件个人研发的部分向软件整体部分集成-以便尽早发现个人开发部分的问题；部署: 是代码尽快向可运行的开发/测试节交付-以便尽早测试；交付: 是指研发尽快向客户交付-以便尽早发现生产环境中存在的问题。 如果说等到所有东西都完成了才向下个环节交付-导致所有的问题只能在最后才爆发出来-解决成本巨大甚至无法解决。而所谓的持续-就是说每完成一个完整的部分-就向下个环节交付-发现问题可以马上调整。使问题不会放大到其他部分和后面的环节。 这种做法的核心思想在于：既然事实上难以做到事先完全了解完整的、正确的需求-那么就干脆一小块一小块的做-并且加快交付的速度和频率-使得交付物尽早在下个环节得到验证。早发现问题早返工。上面的3个持续-也都随着微服务的发展而发展-当架构师的同学-可以参考这种方式。持续集成的工具-向大家推荐：https://jenkins.io/doc/book/pipeline/ `

    单体应用

  • 概念：所有功能全部打包在一起。应用大部分是一个war包或jar包。我参与网约车最开始架构是：一个乘客项目中有 用户、订单、消息、地图等功能。随着业务发展-功能增多-这个项目会越来越臃肿。
  • 好处：容易开发、测试、部署-适合项目初期试错。
  • 坏处：

    • ​ 随着项目越来越复杂-团队不断扩大。坏处就显现出来了。 - 复杂性高：代码多-十万行-百万行级别。加一个小功能-会带来其他功能的隐患-因为它们在一起。 - 技术债务：人员流动-不坏不修-因为不敢修。 - 持续部署困难：由于是全量应用-改一个小功能-全部部署-会导致无关的功能暂停使用。编译部署上线耗时长-不敢随便部署-导致部署频率低-进而又导致两次部署之间 功能修改多-越不敢部署-恶性循环。 - 可靠性差：某个小问题-比如小功能出现OOM-会导致整个应用崩溃。 - 扩展受限：只能整体扩展-无法按照需要进行扩展- 不能根据计算密集型（派单系统）和IO密集型（文件服务） 进行合适的区分。 - 阻碍创新：单体应用是以一种技术解决所有问题-不容易引入新技术。但在高速的互联网发展过程中-适应的潮流是：用合适的语言做合适的事情。比如在单体应用中-一个项目用spring MVC-想换成spring boot-切换成本很高-因为有可能10万-百万行代码都要改-而微服务可以轻松切换-因为每个服务-功能简单-代码少。

    SOA

    ` 对单体应用的改进：引入SOA（Service-Oriented Architecture）面向服务架构-拆分系统-用服务的流程化来实现业务的灵活性。服务间需要某些方法进行连接-面向接口等-它是一种设计方法-其中包含多个服务- 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在于操作系统进程中。各个服务之间 通过网络调用。但是还是需要用些方法来进行服务组合-有可能还是个单体应用。 `

    所以要引入微服务-是SOA思想的一种具体实践。

    微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想

    微服务

    #### 微服务概况

  • 无严格定义。
  • 微服务是一种架构风格-将单体应用划分为小型的服务单元。
  • 微服务架构是一种使用一系列粒度较小的服务来开发单个应用的方式；每个服务运行在自己的进程中；服务间采用轻量级的方式进行通信(通常是HTTP API)；这些服务是基于业务逻辑和范围-通过自动化部署的机制来独立部署的-并且服务的集中管理应该是最低限度的-即每个服务可以采用不同的编程语言编写-使用不同的数据存储技术。
  • 英文定义：

    • `sh 看这篇文章：http://www.martinfowler.com/articles/microservices.html `

  • 小类比

    • 合久必分。分开后通信-独立部署-独立存储。

    `sh 分封制：服从天子命令：服从服务管理。有为天子镇守疆土的义务：各自完成各自的一块业务。随从作战：服务调用。交纳贡献：分担流量压力。 `

  • 段子（中台战略）

    • `plain Q：大师大师-服务拆多了怎么办？A：那就再合起来。Q：那太没面子了。A：那就说跨过了微服务初级阶段-在做中台（自助建站系统）。 `

    #### 微服务特性

    独立运行在自己进程中。

    一系列独立服务共同构建起整个系统。

    一个服务只关注自己的独立业务。

    轻量的通信机制RESTful API

    使用不同语言开发

    全自动部署机制

    #### 微服务组件介绍

    不局限与具体的微服务实现技术。

  • 服务注册与发现：服务提供方将己方调用地址注册到服务注册中心-让服务调用方能够方便地找到自己；服务调用方从服务注册中心找到自己需要调用的服务的地址。
  • 负载均衡：服务提供方一般以多实例的形式提供服务-负载均衡功能能够让服务调用方连接到合适的服务节点。并且-服务节点选择的过程对服务调用方来说是透明的。
  • 服务网关：服务网关是服务调用的唯一入口-可以在这个组件中实现用户鉴权、