03 | 初窥门径:我们要搭建一个怎样的微服务实战项目?

你好,我是姚秋辰。

在上一节课,我跟你介绍了Spring Cloud的发展背景以及各个组件库,此刻,你一定已经跃跃欲试想要立马开始动手编写实战项目了吧?别着急,今天咱先别忙着敲代码,让我先为你勾画出实战项目的全景蓝图。

这节课,我会跟你聊一聊我们这个优惠券平台项目的整体功能和模块,以及每个功能点的技术选型和背后的依据,让你从宏观的角度来了解一下我们整个项目的概貌和大致的走向,帮助你更轻松地学习后面的课程。首先,我来带你了解一下这个实战项目的业务功能。

优惠券平台项目介绍

相信你一定参与过双11或者618之类的电商大促活动,体验过各种眼花缭乱的优惠券和营销规则计算。而我们的实战项目,就是要搭建一个简化版的营销优惠计算系统,实现优惠券模板的创建、用户领取优惠券、下单核销优惠券和订单价格试计算等功能。

我曾经参与了一线电商新零售平台营销中心业务从0到1的搭建,与淘系营销优惠平台UMP对接过很多花式营销玩法。根据我过去的经验,如果我要实现一个“领取优惠券”的功能,那么我首先是要创建一个营销规则模板。这个模板就像是一个模具一样,每张优惠券都通过这个模具来铸造,并最终发放到用户手中。

使用模板的好处是可以对优惠券消费规则做一层抽象,比如满减类、打折类这些优惠券只是具体的优惠金额不同,但是玩法类似,我们把相类似的玩法功能抽象成一个模板,就可以简化具体优惠券的创建和核销流程。

在这个实战项目中,我也借鉴了之前的工作经验,把整个项目划分为了优惠券模板服务、计算服务、用户服务和平台类组件这四大模块。它们的功能是这样的:

  • 优惠券模板服务:模板规则是创建具体优惠券的前置条件,每种类型的模板都是一个计算公式,这个公式约定了优惠计算的方式。在这个项目中,模板服务实现了模板规则的创建、克隆、分页查找等功能。另外,我将在项目里定义满减、随机立减、满折、晚间双倍优惠等多种券模板类型。

  • 优惠计算服务:这个模块是根据用户购物车中的商品信息(单价、数量、所属门店)和优惠券信息,来计算当前订单优惠后的价格。另外,如果用户有多张优惠券,我还提供了“优惠金额试算”服务,帮助用户挑选最省钱的优惠券。

  • 用户服务:这是暴露给外部用户使用的接口,它依赖于模板服务和优惠计算服务完成底层逻辑,主要业务场景是用户领券、订单价格试算、下单核销和订单金额试算等功能。

  • 平台类组件:主要包括一些业务无关的中心化组件,比如Gateway网关等等,你将在Spring Cloud课程中逐渐接触到平台类组件的搭建。

从整体来看,优惠券模板服务和优惠计算服务是基础服务,用户服务是对用户开放的接口,它依赖于这两个基础服务来完成业务逻辑。而平台类组件则提供了横向的微服务特性支持,比如微服务网关、链路追踪功能等等,你可以把它们理解为“微服务中间件”。我们通过下面这幅图来看一下这四个模块之间的关联关系:

我们在开篇词中提到,为了帮你顺利过渡到Spring Cloud实战,我会先用Spring Boot搭建出这个优惠券平台的单体应用,然后在这个基础上做Spring Cloud改造。

Spring Boot实战项目规划

从项目实施的角度来看,Spring Boot阶段的任务相对简单。我们会用两节课搭建起优惠券平台的三个业务模块,并按照模块之间的先后依赖顺序进行改造。在第一节课中,我将带你搭建一个单体应用版的优惠券模板服务,在这个过程中我们会使用spring-data-jpa和spring-web实现系统搭建。其中,spring-data-jpa是用来实现数据库CRUD操作的组件,而spring-web是开发RESTFul风格的API接口所需要用到的组件。接着在第二节课中,我们将使用同样的技术搭建订单优惠计算服务和用户服务。

这里你要注意,在Spring Boot的阶段,用户服务是一个“超级单体应用”,我把优惠券模板服务和订单优惠计算服务都打包到了用户服务中,跨模块的服务调用都是通过本地方法完成的,因此你只用启动用户服务就可以执行所有模块的业务功能。

在搭建项目的过程中,我会带你重点掌握以下这三个技术点:

  1. 项目搭建:分层构建项目结构,并借助Maven实现依赖项管理;
  2. 数据操作:我会带你快速入门spring-data-jpa实战,分别通过接口声明、自定义SQL和JpaRepository三种方式实现数据库CRUD操作;
  3. 开放对外API:快速入门spring-web实战,通过注解对外暴露RESTful风格的API。

此外,我还会不断跟你分享一些我平时工作中积累的小技巧,比如防御型编程、如何借助插件自动生成代码和数据校验、JPA级联关系的误区、计算密集型服务的特点、模板设计模式的应用等等,相信这些内容可以给你一些工作上的启发。

Spring Boot的官方社区提供了一个非常简单的Hello World教程,如果你没有太多Spring Boot的使用经验,那么可以通过这个教程链接Spring Quickstart Guide来了解Spring Boot的搭建过程。

在Spring Boot阶段我们搭建好优惠券平台的单体应用后,接下来就可以进行Spring Cloud微服务化改造了。

Spring Cloud实战项目全景规划

我们先来看一下优惠券平台采用微服务架构,整体的技术方案规划和技术选型是怎样的。下面这张图里列举的技术框架都是目前一线广泛使用的开源组件。

看到图中的这些技术点,我想此刻的你一定很懵,不知道这些技术框架的用途,也不知道该从何处下手来做改造。那么,接下来让我跟你聊聊我如何设计Spring Cloud实战课程的技术选型以及总体的搭建流程,这样你就能做到心中有数,学起来也能得心应手了。

根据微服务学习的路径以及各个组件的难易程度,我把整个微服务框架由浅入深分为了三个不同的阶段:

第一阶段:搭建基础的微服务功能,实现微服务之间的通信

第二阶段:为各个模块构建服务容错分布式配置中心分布式链路追踪能力

第三阶段:进一步实现微服务网关消息驱动分布式事务

下面我们来看下每个阶段主要做些什么以及对应的技术选型。

第一阶段

在第一阶段,我们主要实现微服务之间的通信,将用户微服务、优惠券模板服务和订单优惠计算服务拆分为独立部署的业务系统,通过注册中心来实现服务注册和服务发现,让各个微服务之间可以互相调用。这个阶段涉及的关键技术是Nacos注册中心、Loadbalancer客户端负载均衡组件和OpenFeign服务间调用组件。

我们知道,微服务之间的服务通信有一个前提条件,就是你要知道将要调用的服务器地址是什么。这个寻址的任务是交由Nacos注册中心和Loadbalancer负载均衡器共同来完成的。

Nacos是Alibaba出品的服务治理组件,它作为一个注册中心组件,负责收集所有服务节点的地址信息并维护服务注册表,所有服务上线之后都会向它汇报状态。Loadbalancer则承担了负载均衡的任务,在客户端发起服务调用的时候,它会负责从Nacos的注册表中挑选一台目标服务器。而OpenFeign组件是一个“锦上添花”的组件,它能够简化基于HTTP的远程服务调用,让我们就像使用本地接口一样方便地发起远程服务调用。

为什么我会选择Nacos+Loadbalancer作为选型方案呢?其实,在早期版本的Spring Cloud微服务架构选型中,Eureka + Ribbon是一个使用最为广泛的组合,它们是Netflix公司贡献给Spring Cloud项目的服务治理+负载均衡组件。

我们在上节课中讲过,Netflix正在退出Spring Cloud的历史舞台。Eureka和Ribbon已经进入了维护状态。其中,Ribbon更是在Spring Cloud I 版之后,就从官方组件库中被移除了。这意味着Eureka和Ribbon已经进入了“暮年”,不会再有重大的功能更新,如果你在项目中使用Netflix组件库,那么在未来将无法享受Spring Cloud社区发布的新功能。

因此,在考虑技术选型的时候,我选择了后劲更足、功能更为强大的Nacos和Spring Cloud官方开源的Loadbalancer组件。大致来讲,在第一阶段,我会分为三个部分来带你搭建起微服务之间的通信:

  1. 服务治理:服务治理的重点是搭建基础的跨服务调用功能。我会把用户服务、优惠计算服务和订单服务改造成可以独立启动的微服务,并借助Nacos的服务发现功能,通过Webflux组件中的WebClient实现基于HTTP的跨服务间的调用;
  2. 负载均衡:在这部分,我们将在服务治理的基础上,引入Loadbalancer组件为跨服务调用添加负载均衡的能力。除此之外,我会对Loadbalancer组件的扩展接口做自定义开发,实现一个金丝雀测试的负载均衡场景;
  3. 简化服务调用:我将使用OpenFeign组件对用户服务进行改造,将原先复杂的WebClient调用替换为简洁的OpenFeign调用。

第二阶段

在第二阶段,我们的实战重点有三个:

  • 利用服务容错提高微服务架构的可用性;
  • 搭建全链路的分布式链路追踪能力;
  • 实现统一的配置管理和动态属性推送。

这个阶段涉及的技术组件是Nacos Config、Sentinel、Sleuth+Zipkin+ELK。

在微服务架构中,服务容错是保障服务高可用的一个重要手段。在这个项目中,我们选择用Sentinel作为服务容错组件,它也是Alibaba贡献给Spring Cloud的。Sentinel秉承了阿里系“大而全”的传统,只这一款组件就可以实现降级熔断流量整形等多种服务容错途径。

链路追踪也是微服务架构中一个很重要的功能,线上异常排查全靠它提供线索。我使用了Spring Cloud官方开源的Sleuth实现了日志打标功能,使用全局唯一标记将一次跨微服务调用链上的各个环节全部串联起来。

光打标还没用,我还结合了Zipkin组件实现调用链的可视化检索,将调用链上各个阶段的请求按顺序显示在页面上,这样,我们就可以一目了然定位到线上异常发生在哪个环节。另外,我使用了目前业界主流的ELK组合(Elastic Search + Logstash + Kibana)作为日志检索系统。

配置项管理的技术选型方面,我使用了Nacos Config作为最终方案。借助Nacos Config我们可以轻松实现配置项的远程获取和动态推送,在配置项的应用隔离和环境隔离方面Nacos也是一把好手,我将会在配置管理的实战环节讲述更多的配置项花式玩法。相比较Spring Cloud的另一款配置管理组件Spring Cloud Config来说,Nacos的搭建更加容易且更易于上手,而且可以更好地支持“配置项”回滚的功能。

在后面的课程中,我将按照下面的顺序来实现这些能力:

  1. 配置管理:配置管理的重点是将三个微服务应用接入到Nacos Config配置中心,使用远程配置中心存储部分配置项。
  2. 服务容错:搭建Sentinel Dashboard控制台,通过控制台将降级规则和流量整形规则应用到业务埋点中。
  3. 链路追踪:这部分的重点是搭建分布式链路追踪与日志系统。

第三阶段

在第三阶段,我们的实战重点有三个:

  • 搭建微服务网关作为统一流量入口;
  • 使用消息驱动组件对接RabbitMQ;
  • 通过分布式事务保证数据一致性。

这个阶段涉及的技术组件是Gateway、Stream和Seata。

微服务网关是架设在外部网关(如Ngnix)和内部微服务之间的一座桥梁,我选用Spring Cloud Gateway作为网关组件。Gateway不光担任了路由转发的重任,同时它提供了丰富的谓词组合实现复杂的路由判断逻辑。除此以外,你还可以在网关层定义拦截器,对来访请求执行一段特殊的业务逻辑。

曾经微服务网关的头把交椅是Netflix贡献的Zuul组件,但Zuul 2.0的开源发布一拖再拖,且性能并未达到预期效果。Spring Cloud官方迫不得已,还没等到Zuul 2.0发布,就自己发布了一款开源网关组件Spring Cloud Gateway。基于这些原因,Gateway当之无愧成为了网关层的不二选择。

消息队列和消息驱动是老牌技术了,它并不是微服务特有的功能,我之所以在课程中加入了消息驱动这个内容,主要有两个原因。一是我想让你了解Spring Cloud开源的消息驱动组件“Stream”,它可以大幅降低应用系统和消息组件之间的对接流程。二是消息组件在如今有非常丰富的使用场景,我希望将“消息组件的应用场景”作为一个知识拓展点,帮助你开阔眼界。

分布式事务是微服务环境下保证事务一致性的终极手段。在课程中我将主要介绍两种比较有代表性的Seata分布式事务解决方案,一种是没有代码侵入的Seata AT方案,另一种是蚂蚁金服贡献的资源锁定+补偿型的Seata TCC方案。

好,到这里,我们就完整了解了整个项目的全景规划,以及对应的技术选型。现在,我们来回顾一下这节课的重点内容。

总结

在整个项目中,我们先通过Spring Boot快速落地了优惠券平台的三个业务模块,然后,在Spring Cloud实战阶段,我们分为三个阶段对Spring Boot项目进行微服务化改造:

  • 第一个阶段使用Nacos、Loadbalancer和OpenFeign实现了跨服务的调用;
  • 第二阶段使用Sentinel、Nacos Config和Sleuth实现了服务容错、配置管理和分布式链路追踪;
  • 第三阶段使用Gateway、Stream和Seata实现了微服务网关、消息事件驱动和分布式事务。

在学习专栏的过程中,我不建议你“跳章节”学习,正确的姿势是顺着专栏的各个阶段稳步推进。因为每一个阶段的内容都有前后关系,后一个技术组件或多或少都依赖于前面课程中用到的组件,如果跳跃了几个章节,很容易漏掉一些关键步骤的配置和搭建过程,导致项目无法启动。

学习过程中我们难免会碰到各种问题,需要求助于搜索引擎。你也许用得比较多的是国内的搜索引擎,但经常查到千篇一律的文章,又或者看一个解决方案还需要注册会员或者付费,体验相当不好。

因此,我推荐你偶尔尝试使用Google和stackoverflow两个网站来查询解决方案。这两个网站是对我的工作最有帮助的两位老师,不仅能帮助你解决问题,还可以锻炼你的英文阅读能力。要知道英文能力对技术人员来说还是相当重要的,尤其是当你想要了解一些前沿技术或者阅读一些论文的时候。所以,提高英文阅读能力要靠你平时的不断积累才行。

思考题

最后,请你思考一下,还有哪些微服务的技术点是你想了解的,你可以在留言区提出感兴趣的技术,在后期我可以把呼声比较高的技术点通过加餐的形式分享给你,让我们这个课程能够持续更新和演进。我在留言区等你。

好啦,这节课就结束啦。欢迎你把这节课分享给更多对Spring Cloud感兴趣的朋友。我是姚秋辰,我们下节课再见!

精选留言

  • Pyr0man1ac

    2021-12-18 14:51:23

    姚老师 能否扩展下微服务中鉴权相关知识点
    作者回复

    行家,一眼就发现我漏掉的一个模块了,之前课程里我都会通过security组件做一个oauth鉴权模块。这次没有加上,我后期看考虑在代码里坐上这部分。

    话说同学,你的头像和我一位同事一样,不会是同一个人吧

    2021-12-18 18:26:09

  • chon

    2021-12-22 16:58:58

    我看前面有同学留言讨论优雅下线。我也有个相关问题。如果容器应用突然挂了,由于上游应用和注册中心同步需要时间,流量一段时间内还是会打到挂了的应用。这样500错误很多很难看。dubbo因为基于zookeeper就没这问题,能很快发现应用挂了。sc有啥好的方案能快速发现下游应用挂了,避免流量打到挂了的下游吗?
    作者回复

    其实就是在CP和AP之间做一个选择。如果用长会话做健康检查,并且用CP方案在注册中心集群内做状态同步,那么就是一种偏向一致性的实现模式。而大部分注册中心在一致性和可用性之间选择的是偏向可用性,AP方案,对一致性采取了一定的容忍,只要最终一致即可。如果要适当提高一致性,你可以调整心跳频率和剔除判定的时间,提高服务剔除的响应速度

    微服务下的很多场景都是偏向最终一致性

    2021-12-23 00:45:07

  • 李嘉颖

    2021-12-17 00:15:47

    我想深入一点了解一下限流降级熔断
    作者回复

    后面会讲到sentinel的流控和熔断规则,以及扩展sentinel实现基于来源的限流,dashboard二次开发接入nacos做规则持久化

    2021-12-17 14:24:19

  • 公号-技术夜未眠

    2021-12-18 09:42:56

    很接地气,请老师加餐讲讲基于k8s的微服务弹性落地方案,谢谢老师
    作者回复

    奥利给~

    2021-12-18 18:26:56

  • Layne

    2021-12-17 09:33:45

    希望老师讲解一些微服务部署相关方面的知识内容,如容器类似的知识,怎么与微服务结合使用。
    作者回复

    我考虑后面用加餐的方式,添加一部分容器的知识介绍。课程里在日志系统搭建这里也会简单介绍一下docker的使用

    2021-12-17 14:25:10

  • 卡特

    2021-12-18 07:42:36

    非侵入的Skywalking可以替换Zipkin吗?SDK侵入比较严重
    作者回复

    可以,不光skywalking,像jaegertracing之类的都可以用(jaeger也是受zipkin启发搞出来的)。zipkin本身不用集成SDK到项目代码里,只要通过sleuth-zipkin插件就可以间接集成,我在项目中会通过RabbitMQ接收链路信息,服务将链路信息发送给RMQ,zipkin通过监听RMQ来获取数据。只用添加三两行配置就能实现

    2021-12-18 18:31:45

  • 威威威小哥

    2021-12-20 13:06:24

    老师能在项目中顺带讲下接口幂等解决方案吗
    作者回复

    这部分我倒是没有涉及,很多公司是提供了一种平台化的服务来做幂等性检查,接口参数里带有的幂等ID字段,方法先用这个ID调用幂等校验服务做一层检查。我这里所说的平台化服务,就是公司层面开发的供给各个业务方使用的基础服务,比如像ID生成器这类服务。

    2021-12-20 19:54:01

  • 破发者

    2021-12-18 09:05:55

    老师,如果一笔业务交易是调用了多个服务之后才完成,每个服务都能单独部署,是不是这样就可以称之为使用了微服务?
    作者回复

    bingo,大体上就是这样。不过更深层次还要考虑以什么角度做服务切分,比如领域建模等等。像大厂里会供着一些领域建模的专家,比如订单域交易域这些核心领域的架构,还是挺吃经验的。

    独立拆分部署是微服务表现形式,是表象,不过为了支持这种表象,我们还有很多infra层面的技术支持,这就是后面我们要介绍的各个组件了

    2021-12-18 18:24:34

  • 胡杨

    2021-12-17 11:16:04

    能不能再加一个基础服务,就是ID生成器服务
    作者回复

    ID生成器是个很复杂的平台类服务,高并发的ID分发要求分段批量获取+预加载模式,每个发号器预先领取一个号段,在即将消耗完之前从中心节点继续领号。而且对于订单类场景,还要设置特殊的号段分发规则,否则竞争对手可以根据ID来大致估算出你一天的订单量。对于某些金融行业要求的“非跳号”的ID分发就更加麻烦一些。

    我们这个练手项目还不需要深入到发号器的业务逻辑,用DB incremental ID简单解决了

    2021-12-17 14:21:04

  • 来来

    2021-12-17 21:06:38

    老师有没有spring cloud优雅下线的方面的讲解
    作者回复

    这部分没有单独展开讲,优雅退出方案就是尽可能减少nacos instance下线和后台服务下线之间的时间差。这里要结合你的部署方案来看。现在大多公司都会选择k8s容器编排,新建POD然后等完全启动好之后关停老的POD,那么你可以在老的pod关闭之前设置一个hook,主动调用nacos服务的Delete方法做下线/nacos/v1/ns/instance,然后在执行关停POD的操作。

    2021-12-18 11:57:45

  • AYOU

    2021-12-17 17:20:27

    老师为啥不用dubbo做跨服务调用呢
    作者回复

    dubbo应用面没有想想的广,虽然阿里系在维护dubbo但在集团内部实际用的是另一套框架hsf,而且dubbo在国外应用也比较少,所以我用了更spring cloud原生的openfiegn。不过如果要替换dubbo是很平滑的,因为nacos本身和dubbo就可以无缝集成

    2021-12-17 20:41:34

  • bye_bug

    2022-02-08 17:15:56



    #笔记

    实战项目是一个“优惠券计算系统”

    项目组成:
    优惠券模板服务 + 优惠券计算服务 + 用户服务 + 基础平台服务,其中“用户服务”通过前两个服务的底层计算完成实际功能,“基础平台服务”为微服务相关服务。

    项目实施步骤:
    1. 先使用 Spring Boot 实现一个单体版本系统,完成前三个服务,其中服务调用在本地完成。
    2. 微服务拆分 - 基础部分:“服务注册”,“负载均衡”,“服务调用”。实现基本的“服务间通信”。
    3. 微服务拆分 - 进阶部分:“配置中心”,“服务容错”(限流等),“链路追踪”(ELK,方便系统排错)。实现进阶的“服务治理和异常排查”
    4. 微服务拆分 - 高级部分:“统一网关”,“消息队列”,“分布式事务”。实现更高级的“服务能力建设和管理”
    作者回复

    这个笔记流十分优秀啊!

    2022-02-13 18:37:14

  • NARUTO

    2021-12-30 23:37:45

    为什么不用RocketMQ讲解案例
    作者回复

    MQ大同小异,底层用metaq还是rabbitmq对上层应用来讲是无感知的,rabbitmq的应用更为广泛

    2021-12-31 13:22:51

  • leven.chen

    2021-12-17 18:16:53

    请问老师 springcloud 生产环境选用哪个版本啊?有没有好的脚手架通知
    作者回复

    如果是新项目的话,从0-1搭建,用最新的release版就可以了,如果是老项目就要考虑升级成本了,不同版本的升级成本差别很大,比如是G->H升版就相对很轻松,而H->I很多netflix组件已经被除名了,如果之前是用netflix组件库那就最好原地不动。

    2021-12-17 20:45:14

  • 一只奔跑的猪

    2022-08-03 22:08:04

    姚老师,完全没有spring的经验,看这个感觉好吃力,请问我还需要看吗
    作者回复

    没有sprint经验的话确实会比较吃力,那么同学先放下课程,我给你讲几个简单教程来学习一下,熟悉熟悉spring做了啥事儿

    1)最好的学习网站内往往是开源项目的主页,那就是https://spring.io/
    2)Spring官网大致了解下spring的一些功能模块都做了什么:https://spring.io/projects/spring-framework
    3)通过spring官方的quick start来一个小demo快速体验spring开发

    有了上面这几步,基本对spring有了个简单认识,接着尝试自己安装个mysql,通过spring-data试试怎么连DB做增删改查(可以发挥自学能力网上找点sample)

    到这里基本上spring的搬砖工作也都体验好了,下载个maven,尝试用maven的方式编译项目,理解mvn生命周期。

    有了这些基础,再来学习课程就会顺利不少

    2022-08-08 15:18:15

  • 会飞的鱼

    2022-01-10 15:07:03

    老师,可以讲下分布式Session、第三方登录+支付相关的内容吗
    作者回复

    分布式session很多大厂也在用redis来存登录态信息,不用标准框架自己手撸一个也不难。第三方登录基本都是用oauth2,spring cloud也提供了oauth2的依赖包,这部分我考虑后期做个扩展阅读来讲一下

    2022-01-10 21:20:29

  • ~

    2021-12-28 14:11:25

    老师,我看到 ump 这三个字母 DNA 都动了,alsc-ump 您有参与构建吗?小组里天天准备分享 ump 的内容,我还是实习生,感觉看不懂。。。。
    作者回复

    哦呦,这是遇到同行了呀,时过境迁,不知道ump现在还是不是ZH在带,又是否还在XX、YZ他们的共享事业部下面。往事如过眼云烟,那些痛的记忆,落在春的泥土里。什么alsc-ump,马什么梅?我已经忘掉过去,不在那个圈子里染味儿了。

    同学,别看咱只是实习生,别闷头写代码,有空也抬头跟主管抽几根烟,吃几顿饭。带坏小孩子(逃~)

    2021-12-28 14:49:10

  • 派崔克·韩

    2021-12-21 20:02:00

    老师有机会可否讲一下autoscaling,现在公司还停留在手动启动service的阶段,谢谢
    作者回复

    后面出完之后我在用加餐聊聊用k8s做弹性

    2021-12-21 20:25:06

  • 森林

    2021-12-17 17:33:11

    老师能对比下springcloud方案和kubernetes方案吗?感觉就算用springcloud组件实现微服务,但微服务大规模部署运维还得是k8s。
    作者回复

    是的,使用kubernetes做容器编排,不过限于篇幅的原因,这节专栏对运维部分没有重点涉及。看看如果类似需求的声音比较大的话,我后期可以写加餐介绍下k8s下的弹性方案

    2021-12-17 20:49:07

  • 被水淹没

    2022-05-18 00:25:36

    我在想 ,这个项目到时灰度发布是整合到负载均衡那边?

    有些方案是直接从网关那边做这些功能的,会不会耦合低一些呢?
    作者回复

    后面的金丝雀例子只是用来引导负载均衡部分的学习,真正做企业级负载均衡的话要依赖公司内部的灰度方案

    2022-06-03 14:12:39