Spring Boot 与 Kubernetes 云原生微服务实践
杨波
前携程 / 拍拍贷技术总监,微服务技术专家
28227 人已学习
新⼈⾸单¥98
课程目录
已完结/共 94 讲
第一章:课程介绍和案例需求 (5讲)
第十章:项⽬复盘、应用和扩展环节 (2讲)
第十一章:附录 Staffjoy 项目源代码解析 (8讲)
时长 14:53
时长 10:29
时长 10:52
时长 05:09
时长 15:06
时长 16:17
Spring Boot 与 Kubernetes 云原生微服务实践
登录|注册
留言
6
收藏
沉浸
阅读
分享
手机端
回顶部
当前播放: 83 | Kubernetes应用金丝雀发布实验
00:00 / 00:00
高清
  • 高清
1.0x
  • 2.0x
  • 1.5x
  • 1.25x
  • 1.0x
  • 0.75x
  • 0.5x
网页全屏
全屏
00:00
付费课程,可试看
01 | 课程介绍
02 | 背景说明
03 | 课程目标和主要内容
04 | 课程案例需求
05 | 课程补充说明
06 | 为何采用微服务架构?
07 | 架构设计和技术栈选型
08 | 数据和接口模型设计:账户服务
09 | 数据和接口模型设计:业务服务
10 | Dubbo、Spring Cloud和Kubernetes该如何选型(上)
11 | Dubbo、Spring Cloud和Kubernetes该如何选型(中)
12 | Dubbo、Spring Cloud和Kubernetes该如何选型(下)
13 | 技术中台到底讲什么?
14 | Staffjoy项目结构组织
15 | 谷歌为何采用单体仓库(Mono-Repo)?
16 | 微服务接口参数校验为何重要?
17 | 如何实现统一异常处理?
18 | DTO和DMO为什么要互转?
19 | 如何实现基于Feign的强类型接口?
20 | 为什么框架层就要考虑分环境配置?
21 | 异步处理为何要复制线程上下文信息?
22 | 为你的接口添加Swagger文档
23 | 主流微服务框架概览
24 | 网关和BFF是如何演化出来的(上)
25 | 网关和BFF是如何演化出来的(下)
26 | 网关和反向代理是什么关系?
27 | 网关需要分集群部署吗?
28 | 如何设计一个最简网关?
29 | Faraday网关代码解析(上)
30 | Faraday网关代码解析(下)
31 | 生产级网关需要考虑哪些环节?
32 | 主流开源网关概览
33 | 安全认证架构演进:单块阶段(上)
34 | 安全认证架构演进:单块阶段(下)
35 | 安全认证架构演进:微服务阶段
36 | 基于JWT令牌的安全认证架构
37 | JWT的原理是什么?
38 | JWT有哪两种主要流程?
39 | Staffjoy安全认证架构和SSO
40 | 用户认证代码剖析
41 | 服务调用鉴权代码剖析
42 | 如何设计用户角色鉴权?
43 | Spring Boot微服务测试该如何分类?
44 | 什么是契约驱动测试?
45 | 什么是测试金字塔?
46 | 单元测试案例分析
47 | 集成测试案例分析
48 | 组件测试案例分析
49 | Mock vs Spy
50 | 何谓生产就绪(Production Ready)?
51 | Spring Boot如何实现分环境配置
52 | Apollo vs SpringCloudConfig vs K8s ConfigMap
53 | CAT vs Zipkin vs Skywalking(上)
54 | CAT vs Zipkin vs Skywalking(下)
55 | 结构化日志和业务审计日志
56 | 集中异常监控和Sentry
57 | EFK & Prometheus & Skywalking + Kubernetes 集成架构
58 | 本地开发部署架构和软件需求
59 | 手工服务部署和测试(上)
60 | 手工服务部署和测试(中)
61 | 手工服务部署和测试(下)
62 | SkyWalking调用链监控实验
63 | Docker和Docker Compose简介
64 | 容器镜像构建Dockerfile解析
65 | Docker Compose服务部署文件剖析
66 | 将Staffjoy部署到本地Docker Compose环境(上)
67 | 将Staffjoy部署到本地Docker Compose环境(下)
68 | 到底什么是云原生架构?
69 | Kubernetes背景和架构
70 | Kubernetes有哪些基本概念(上)
71 | Kubernetes有哪些基本概念(下)
72 | 理解Kubernetes节点网络和Pod网络
73 | 深入理解Service和ServiceDiscovery
74 | NodePort vs LoadBalancer vs Ingress
75 | 本地测试Kubernetes部署文件剖析
76 | 本地测试Kubernetes环境搭建
77 | 将Staffjoy部署到本地Kubernetes环境(上)
78 | 将Staffjoy部署到本地Kubernetes环境(下)
79 | 生产环境Kubernetes部署文件剖析
80 | 阿里云Kubernetes环境创建
81 | 将Staffjoy部署到阿里云Kubernetes环境
82 | Kubernetes应用动态配置实验
83 | Kubernetes应用金丝雀发布实验
84 | 阿里云资源释放
85 | 课程复盘
86 | 项目扩展和应用
87 | Account服务
88 | Company服务
89 | Mail、SMS和Bot服务
90 | Faraday服务
91 | WhoAmI服务
92 | WWW服务
93 | 前端应用
94 | 结课测试&结束语
登录 后留言

全部留言(6)

  • 最新
  • 精选
stone
滚动发布是什么流程呀。波波老师能不能简单说一下呢

作者回复: k8s默认支持的就是滚动发布(rolling update),假设你有一个svc v1版本已经发布到k8s,svc v1假设有10个pod实例,那么下次你发布svc的v2新版本,在deployment yml文件中只需修改镜像版本,然后kubectl apply这yml文件,k8s就会自动进行滚动发布,将v2的pod实例陆续拉入,v1的pod实例陆续拉出,例如,k8s会先拉入2个v2的pod实例,然后拉出2个v1的pod实例,间隔一段时间,再拉入2个v2的pod实例,然后拉出2个v1的pod实例,间隔一段时间,依次类推,一直到v2的pod实例全部拉入,v1的pod实例全部拉出,这就是滚动发布的过程,每次拉入拉出的数量(maxSurge)是可以配置的,具体可参考k8s文档:https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

2019-09-12
4
JefferLiu
再升级,谁是金丝雀呢

作者回复: 金丝雀是很好理解的,升级时候先上一台新版本去试水,这台新版本就是金丝雀,金丝雀没有问题,继续发全量新版本,同时下老版本;如果金丝雀有问题,则下金丝雀,取消升级。再升级还是这样做。 金丝雀源于过去矿工下矿井前,为防止一氧化碳等中毒,先放一个金丝雀下去试,用在发布上也是这个道理,先上一台新版本去试。

2019-09-09
4
hunterlodge
老师,金丝雀全量发布以后,线上的deployment就都是www-web-deployment-canary了,这样的话,下次如果再发版,当如何处理呢?回过来再使用www-web-deployment吗?显然这会有点怪。感觉应该有一个机制维持线上最终仍然是www-web-deployment,这样每一次发版,都只是在并存阶段同时存在两种deployment

作者回复: 课程只是为了演示形象才用了“www-web-deployment-canary”这样一个名字,实际后面可以跟版本号,例如原来是www-web-v1.0,然后下一版是www-web-v1.1,再下一版www-web-v1.2,诸如此类。不管用哪种版本机制,上新版前都可以先上一个做金丝雀测试,而且这个版本号留着的话发布历史也很清晰。

2020-12-03
2
波波老师要是在线上发布的话,一些用户正在用老的服务,那么全部切换的时候,老的版本停掉,那会影响一些用户正在调用老的版本,这个怎么解决

作者回复: 采用金丝雀发布进行切换的时候,新老版本是要求同时并存一段时间的(老版本不能马上停掉,需要等一个周期时间,例如观察5分钟后下线,这样也是为了后面可以按需回滚),切换以后,新的流量会到新版本,切换瞬间有些老的流量还是会连在老服务上,可以不受影响,等这些老流量下次再请求的的时候,就会被切到新版本服务上去。

2020-10-25
1
恰饭哒
波波老师,这个怎么解决请求了一半的服务了,一个服务请求在路上,突然把来版本kill的问题

作者回复: 蓝绿切换后,老版是继续留着一段时间,不是马上kill掉的,这样那些连着老版本的请求将继续得到处理,直到处理完毕,但是新的请求将不会再路由到老版本,而是都路由到新版本,所以蓝绿发布一般是安全的。

2019-12-17
1
狼鱼
如果采用SpringBoot+K8S的方式进行微服务部署,如果想实现服务的多版本控制有什么好方法吗? 如果采用Spring Cloud 可使用 metadata 在加版本号,然后扩展ribbon的路由策略来实现。 基于K8S 除了使用Istio 还有其他方法吗?

作者回复: Istio/ServiceMesh是K8s推荐的流量治理(或多版本控制)机制,这个机制的好处是可以做到应用无关,不足是运维门槛成本较高。 其它方案可以考虑软件方式实现,一般采用功能开关或A/B测试技术实现,这个机制需要侵入代码,但是灵活性更高,参考项目: https://github.com/checkr/flagr https://github.com/markphelps/flipt https://github.com/intuit/wasabi

2019-09-30
1
收起评论