微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚

转载

cnolnic 2024-11-07 19:27:28

文章标签 微服务 Cloud 数据 文章分类 运维

第一章微服务架构演进

1.1、单体架构

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_微服务

架构说明：

全部功能集中在一个项目内（All in one）。

架构优点：

架构简单，前期开发成本低、开发周期短，适合小型项目。

架构缺点：

全部功能集成在一个工程中，对于大型项目不易开发、扩展和维护。

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

系统性能扩展只能通过扩展集群节点，成本高。

1.2、垂直架构

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_Cloud_02

架构说明：

按照业务进行切割，形成小的单体项目。

架构优点：

技术栈可扩展（不同的系统可以用不同的编程语言编写）。

架构缺点：

功能集中在一个项目中，不利于开发、扩展、维护。

系统扩张只能通过集群的方式。

项目之间功能冗余、数据冗余、耦合性强。

1.3、SOA架构

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_数据_03

架构说明：

SOA全称为Service-Oriented Architecture，即面向服务的架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用，一个服务通常以独立的形式存在于操作系统进程中。站在功能的角度，把业务逻辑抽象成可复用的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。

将重复功能或模块抽取成组件的形式，对外提供服务，在项目与服务之间使用ESB（企业服务总线）的形式作为通信的桥梁。

架构优点：

重复功能或模块抽取为服务，提高开发效率。

可重用性高。

可维护性高。

架构缺点：

各系统之间业务不同，很难确认功能或模块是重复的。

抽取服务的粒度大。

系统和服务之间耦合度高。

1.4、微服务架构

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_微服务_04

架构说明：

微服务就是将一个单体架构的应用按业务划分为一个个的独立运行的程序即服务，它们之间通过 HTTP 协议进行通信，也可以采用消息队列来通信，例如 RabbitMQ，Kafaka 等，可以采用不同的编程语言，使用不同的存储技术，自动化部署（如 Jenkins）减少人为控制，降低出错概率。服务数量越多，管理起来越复杂，因此采用集中化管理。例如 Eureka，Zookeeper 等都是比较常见的服务集中化管理框架。

微服务是一种架构风格，一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。

架构优点：

服务拆分粒度更细，有利于提高开发效率。

可以针对不同服务制定对应的优化方案。

适用于互联网时代，产品迭代周期更短。

架构缺点：

粒度太细导致服务太多，维护成本高。

分布式系统开发的技术成本高，对团队的挑战大。

第二章微服务设计原则

2.1、CAP 定理原则

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_数据_05

CAP 原则又称 CAP 定理，指的是在一个分布式系统中必须具有以下其中两个特性：

Consistency （一致性）
Availability （可用性）
Partition tolerance（分区容错性）

CAP 由 Eric Brewer 在 2000 年 PODC 会议上提出，该猜想在提出两年后被证明成立，成为我们熟知的 CAP 定理，CAP 三者不可兼得。

特性	定理
Consistency	也叫做数据原子性，系统在执行某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读到最新的值，这样的系统被认为是具有强一致性的。等同于所有节点访问同一份最新的数据副本。
Availability	每一个操作总是能够在一定的时间内返回结果，这里需要注意的是"一定时间内"和"返回结果"。一定时间内指的是，在可以容忍的范围内返回结果，结果可以是成功或者是失败。
Partition tolerance	在网络分区的情况下，被分隔的节点仍能正常对外提供服务(分布式集群，数据被分布存储在不同的服务器上，无论什么情况，服务器都能正常被访问)。

CAP 三个特性只能满足其中两个，那么取舍的策略就共有三种：

CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃 P 的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。
CP without A：如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长（也就是等待数据同步完才能正常访问服务），一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成 CP 的系统其实不少，最典型的就是分布式数据库，如 Redis、HBase 等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。
AP without C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

2.2、AFK 拆分原则

业界对于可扩展的系统架构设计有一个朴素的理念，就是：通过加机器可以解决容量和可用性问题（如果一台不行就两台，两台不行就多台）。

用个段子描述就是：世界上没有什么事是一顿烧烤解决不了的，如果有，那就两顿。

这一理念在“云计算”概念疯狂流行的今天。得到了广泛的认可。对于一个规模迅速增长的系统而言。容量和性能问题当然是首当其冲的。但是随着时间的向前，系统规模的增长，除了面对性能与容量的问题外，还需要面对功能与模块数量上增长带来的系统复杂性问题。以及业务变化带来的提供差异化服务问题。而许多系统在架构设计时并未充分考虑到这些问题，导致系统的重构成为常态。从而影响业务交付能力，还浪费人力财力。对此《The Art of Scalability》一书提出了一个更加系统的可扩展模型—AKF 可扩展立方，这个立方体中沿着三个坐标轴设置分别为 X，Y，Z。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_Cloud_06

X 轴：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，成为集群加负载均衡的模式。
Y 轴：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。
Z 轴：是基于类似的数据分区，比如一个互联网打车应用突然火了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。

场景说明：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是乘客和车主访问量很大，就将打车应用拆成了三个，分别为乘客服务、车主服务、支付服务。三个服务的业务特点各不相同，独立维护，各自都可以再次按需扩展。

2.3、前后端分离原则

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_Cloud_07

前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果更好。
前后端分离模式下，前后端交互界面更清晰，就剩下了接口模型，后端的接口简洁明了，更容易维护。
前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支持多个前端：例如：微信小程序、PC 前端、Android 前端、IOS 前端。

2.4、无状态服务原则

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_数据_08

对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。场景说明：例如我们以前在本地内存中建立的数据缓存、Session 缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。

2.5、Restful通信风格

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_微服务_09

基于**“无状态服务原则”**，在这里我们直接推荐一个实践优选的 Restful 通信风格，因为他有很多好处：

无状态协议 HTTP，具备先天优势，扩展能力很强。例如需要安全加密时，有现成的成熟方案 HTTPS 可用。
JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
语言无关，各大热门语言都提供成熟的 Restful API 框架，相对其他的一些 RPC 框架生态更完善。

第三章 Spring Cloud介绍

Spring Cloud 是一个服务治理平台，提供了一些服务框架。包含了：服务注册与发现、配置中心、消息中心、负载均衡、数据监控等等。

Spring Cloud 是一个微服务框架，相比 Dubbo 等 RPC 框架，Spring Cloud 提供了全套的分布式系统解决方案。

Spring Cloud 对微服务基础框架 Netflix 的多个开源组件进行了封装，同时又实现了和云端平台以及 Spring Boot 框架的集成。

Spring Cloud 是一个基于 Spring Boot 实现的云应用开发工具，它为开发中的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

Spring Cloud 为开发者提供了快速构建分布式系统的工具，开发者可以快速的启动服务或构建应用、同时能够快速和云平台资源进行对接。微服务是可以独立部署、水平扩展、独立访问（或者有独立的数据库）的服务单元，Spring Cloud 就是这些微服务的大管家，采用了微服务这种架构之后，项目的数量会非常多，Spring Cloud 做为大管家需要管理好这些微服务，自然需要很多小弟（组件）来帮忙。

第四章 Spring Cloud组件介绍

4.1、第一代微服务

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_微服务_10

Netflix是一家美国公司，在美国、加拿大提供互联网随选流媒体播放，定制DVD、蓝光光碟在线出租业务。该公司成立于1997年，总部位于加利福尼亚州洛斯盖图，1999年开始订阅服务。2009年，该公司可提供多达10万部DVD电影，并有1千万的订户。2007年2月25日，Netflix宣布已经售出第10亿份DVD。HIS一份报告中表示，2011年Netflix网络电影销量占据美国用户在线电影总销量的45%。针对多种 Netflix 组件提供的开发工具包，其中包括 Eureka、Hystrix、Ribbon、Zuul、Archaius 等。

官方地址：https://github.com/spring-cloud/spring-cloud-netflix

Netflix Eureka：一个基于 Rest 服务的服务治理组件，包括服务注册中心、服务注册与服务发现机制的实现，实现了云端负载均衡和中间层服务器的故障转移。
Netflix Hystrix：容错管理工具，实现断路器模式，通过控制服务的节点，从而对延迟和故障提供更强大的容错能力。
Netflix Ribbon：客户端负载均衡的服务调用组件。
Netflix Feign：基于 Ribbon 和 Hystrix 的声明式服务调用组件。
Netflix Zuul：微服务网关，提供动态路由，访问过滤等服务。
Netflix Archaius：配置管理 API，包含一系列配置管理 API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。

4.2、第二代微服务

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_Cloud_11

Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。依托 Spring Cloud Alibaba，只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

官方地址：https://github.com/alibaba/spring-cloud-alibaba

Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。
Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架。
Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
Alibaba Cloud OSS: 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。
Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。
Alibaba Cloud SMS: 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。

第五章 Spring Cloud版本介绍

5.1、版本历史

采用伦敦的地铁站名称来作为版本号的命名，根据首字母排序，字母顺序靠后的版本号越大。

注意：以下数据截至到2021-01-31号之前。

5.2、版本说明

发布计划：

标识	含义	说明
BUILD-XXX	开发版	开发团队内部使用
M	里程碑版	MileStone，M1 表示第 1 个里程碑版本，一般同时标注 PRE，表示预览版
RC	候选发布版	Release Candidate，正式发布版的前一个观察期，不添加新功能，主要着重于除错
SR	正式发布版	Service Release，SR1 表示第 1 个正式版本，一般同时标注 GA，表示稳定版本
GA	稳定版	经过全面测试并可对外发行称之为GA（General Availability）

各版本号：

例如：Spring Cloud Alibaba 2.1.0.RELEASE

2：主版本号。当功能模块有较大更新或者整体架构发生变化时，主版本号会更新。
1：次版本号。次版本表示只是局部的一些变动。
0：修改版本号。一般是 bug 的修复或者是小的变动。
RELEASE：希腊字母版本号。标注当前版本的软件处于哪个开发阶段。

希腊字母：

Base：设计阶段。只有相应的设计没有具体的功能实现。
Alpha：软件的初级版本。存在较多的 bug。
Bate：表示相对 Alpha 有了很大的进步，消除了严重的 bug，还存在一些潜在的 bug。
Gamma：是 Beta 版做过一些修改，成为正式发布的候选版本（Release Candidate）。
Release：该版本表示最终版。

第六章 Spring Cloud版本要求

查看地址：https://start.spring.io/actuator/info

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_Cloud_12

6.1、Spring Cloud

具体版本要求地址：https://docs.spring.io/spring-cloud/docs/Hoxton.SR9/reference/html/

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_Cloud_13

注意：maven建议使用3.6.3，jdk应该保持1.8及以上。

6.2、Spring Cloud Alibaba

具体版本要求地址：https://github.com/alibaba/spring-cloud-alibaba/blob/master/README-zh.md

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_数据_14

注意：maven建议使用3.6.3，jdk应该保持1.8及以上。

第七章 Spring Cloud开发准备

7.1、idea创建父工程

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_Cloud_15

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_数据_16

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_微服务_17

7.2、idea统一编码集

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_微服务_18

7.3、idea注解的配置

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_微服务_19

7.4、idea排除的文件

*.hprof;*.pyc;*.pyo;*.rbc;*.yarb;*~;.DS_Store;.git;.hg;.svn;CVS;__pycache__;_svn;vssver.scc;vssver2.scc;*.idea;*.iml;

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_数据_20

7.5、idea热部署设置

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_微服务_21

按下 CTRL+ALT+SHITF+/ 会弹出一个窗口，请点击 Registry 。

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_微服务_22

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_微服务_23

微服务下A服务接口中需要B C服务如果任何一方出现错误如何回滚_Cloud_24

注意：这一步设置完成以后，请重新启动idea，为了让这些配置生效。

7.6、修改 POM 内容

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.caochenlei</groupId>
  <artifactId>spring-cloud-study</artifactId>
  <version>2021</version>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
  </properties>

  <dependencyManagement>
    <dependencies>
      <!--spring boot 2.3.5.RELEASE-->
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>2.3.5.RELEASE</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <!--spring cloud Hoxton.SR9-->
      <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dependencies</artifactId>
        <version>Hoxton.SR9</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <build>
    <plugins>
      <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
        <configuration>
          <fork>true</fork>
          <addResources>true</addResources>
        </configuration>
      </plugin>
    </plugins>
  </build>

</project>

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。

上一篇：android socket 沾包

下一篇：python根据rgbd图进行骨架跟踪

提问和评论都可以，用心的回复会被更多人看到评论

发布评论

相关文章

官方博客	全部文章	热门标签	班级博客
了解我们	网站地图	意见反馈

鸿蒙开发者社区	51CTO学堂
51CTO	软考资讯