Service Mesh 实战 
11858 人已学习
新⼈⾸单¥59
课程目录
已完结/共 41 讲
第一章：理论篇 (6讲)
时长 06:20
时长 03:15
时长 12:21
第二章：Istio入门篇 (5讲)
时长 14:32
时长 08:51
时长 08:50
时长 08:27
第三章：实验篇 (19讲)
时长 17:50
时长 08:25
时长 09:17
时长 08:32
时长 09:14
时长 12:41
时长 09:43
时长 10:22
时长 09:50
时长 10:06
时长 12:03
时长 13:07
时长 09:23
时长 12:35
时长 14:16
时长 11:30
时长 10:28
时长 12:07
第四章：实战篇 (11讲)
时长 20:47
时长 21:30
时长 16:36
时长 14:20
时长 16:25
时长 14:09
时长 17:23
时长 22:44
时长 19:12
时长 15:26
时长 06:58
Service Mesh 实战
登录|注册
当前播放: 08 | Istio的自我救赎：为什么Istio发生了两次重大的架构变更？
00:00 / 00:00
高清
- 高清
1.0x
- 2.0x
- 1.5x
- 1.25x
- 1.0x
- 0.75x
- 0.5x
付费课程，可试看
01 | 课程介绍
02 | 内容综述
03 | Service Mesh的起源：为什么会出现Service Mesh技术？
04 | Service Mesh的发展：Service Mesh技术是如何演进的？
05 | 微服务通信的济世良方：什么是Service Mesh？它能帮你做什么？
06 | 列王的纷争：市面上有哪些主流的Service Mesh产品？
07 | 王者的诞生：为什么Istio有如此高的呼声？
08 | Istio的自我救赎：为什么Istio发生了两次重大的架构变更？
09 | 核心功能之流量控制：Istio是如何实现流量控制功能的？
10 | 服务的可观察性：如何理解服务可视化的重要性？
11 | 保卫你的网格：Istio是如何设计安全架构的？
12 | 安装与部署：如何安装Istio？它都支持哪些环境和部署方式？
13 | 动态路由：用Virtual Service和Destination Rule设置路由规则
14 | 网关：用Gateway管理进入网格的流量
15 | 服务入口：用Service Entry扩展你的网格服务
16 | 流量转移：灰度发布是如何实现的？
17 | Ingress：控制进入网格的请求
18 | Egress：用Egress实现访问外部服务
19 | 超时重试：提升系统的健壮性和可用性
20 | 熔断：“秒杀”场景下的过载保护是如何实现的？
21 | 故障注入：在Istio中实现一个“Chaos Monkey”
22 | 流量镜像：解决线上问题排查的难题
23 | 洞察你的服务：使用Kiali观测你的微服务应用
24 | 指标：使用Prometheus收集指标
25 | 监控：使用Grafana查看系统的整体状态
26 | 日志：如何获取Envoy的日志并进行调试
27 | 分布式追踪：使用Jeager对应用进行分布式追踪
28 | 守卫网格：配置TLS安全网关
29 | 双重保障：为应用设置不同级别的双向TLS
30 | 授权策略：如何实现JWT身份认证与授权？
31 | 实战演练（一）：项目准备和构建过程
32 | 实战演练（二）：实现自动化灰度发布
33 | 实战演练（三）：提升系统的弹性能力
34 | 实战演练（四）：配置安全策略
35 | 实战演练（五）：收集指标并监控应用
36 | 实战演练（六）：集成 ELK Stack 日志套件
37 | 实战演练（七）：集成分布式追踪工具
38 | 调试工具和方法：调试网格的工具和方法有哪些？
39 | 实践经验总结：实际落地中的常见问题有哪些？
40 | 未来架构——从Service Mesh迈向云原生
41 | 结果测试&结束语
本节摘要
登录 后留言
全部留言(14)
- 最新
- 精选
百行吴书
只有了解了它的过去，才能理解它的未来及使命。还有老师快点更新啦，在开发的项目就是基于istio。（遗憾的是项目可能会被裁掉或减少投入，因为市场还不成熟，但相信明年istio的产品落地将会爆发）
作者回复: "只有了解了它的过去，才能理解它的未来及使命。" ~ 说的很好！也感谢认可！
2020-04-14
4
xcbeyond
在最新版本istio中，早已将Citadel组件合并到istiod中了，但从istiod Pod中去看，只有discovery容器（pilot），并没有Citadel容器。目前Citadel只是作为一个概念存在么，并不单独存在，或者是什么样的，比如这些组件(Citadel、Galley) 我在实际使用时，从哪块能直观的体现出来等？
作者回复: 整个控制面整合成了单体，istiod就是暴露出来的进程，citedal这些原本的独立进程都整合进去以功能模块的形式存在。可以看一下源码结构能大概知道一二。
2021-03-15
2
2
008
两倍速过了一遍，非常有兴趣，虽然很可能不会具体实践，但一直认为Sidecar模式可以解决我们老旧系统的一些控制问题，我们也一直在这方面发力，学习service mesh的理念也可以有助于我们对现有基础设施层进行更清晰的定义。
作者回复: 谢谢认可😋
2020-04-15
1
我来也
哈哈，老师的比喻很形象。
前面的版本比较，拿F22和三代机型比较。
后面的mvp，拿顿挫和烧机油举例，很形象生动。
作者回复: 谢谢认可😀
2020-04-13
1
朱晔
说的非常好
作者回复: 感谢朱老师的认可！😋
2020-04-13
1
Geek_66dcc6
谢谢老师，但是我在部署istio1.6 后，发现解析jwt 并添加到http header 这个rule 功能并不能用，用示例也是不能用的，不知道您那边有遇到过吗。因为目前 插件形式1.6 支持的并不好，想先用之前的rule 的方式过渡一下，谢谢您的指导
-----------------------------------------------------------------
老师您好，在mixer 这个问题上，我有个疑问，因为istio 1.5 已经废弃掉这个应用，在文档https://istio.io/latest/docs/tasks/policy-enforcement/control-headers/#request-header-operations 中，我有试过用推荐的envoy 的插件尝试加header，但是目前插件那边只支持1.5 版本，而我部署的是1.6 版本，所以我想继续用连接中adapter 的方式增加rule ，我想问下，官方说废弃掉，是以后不继续更新mixer，但是目前还可以使用？还是目前1.6 的版本完全不支持这种部署方式了呢，因为我查看kubectl -n istio-system get cm istio -o jsonpath="{@.data.mesh}" | grep disablePolicyChecks
结果是disablePolicyChecks: false，所以1.6版本目前还是支持policy的方式
作者回复: 是的，肯定有一定的兼容期，不可能一下就废弃掉，这会让一部分用户没法迁移到新版本。据说是到1.7版本会彻底废弃。
作者回复: 报什么错？贴一下配置。排除法先用最简单的例子试，慢慢加
2020-07-24
2
Geek_66dcc6
老师您好，在mixer 这个问题上，我有个疑问，因为istio 1.5 已经废弃掉这个应用，在文档https://istio.io/latest/docs/tasks/policy-enforcement/control-headers/#request-header-operations 中，我有试过用推荐的envoy 的插件尝试加header，但是目前插件那边只支持1.5 版本，而我部署的是1.6 版本，所以我想继续用连接中adapter 的方式增加rule ，我想问下，官方说废弃掉，是以后不继续更新mixer，但是目前还可以使用？还是目前1.6 的版本完全不支持这种部署方式了呢，因为我查看kubectl -n istio-system get cm istio -o jsonpath="{@.data.mesh}" | grep disablePolicyChecks
结果是disablePolicyChecks: false，所以1.6版本目前还是支持policy的方式
作者回复: 是的，肯定有一定的兼容期，不可能一下就废弃掉，这会让一部分用户没法迁移到新版本。据说是到1.7版本会彻底废弃。
2020-07-22
szpzs
请问马老师，关于“Istio 中的 Mixer 需要和数据平面进行两次通讯，具体是那两次通讯呢？”这个问题，我还是有些疑惑。这两次通讯是在请求方的sidecar里发起的，还是在服务方的sidecar里发起的？或者说，预检是在请求方的sidecar里发起，遥测是在服务方的sidecar里发起？请马老师指点迷津。
作者回复: 参考我在部落的回答，这里面有官方的解释：https://horde.geekbang.org/message/detail/UQUvVF3G3wTcu9L8ARUhk9l8vhbaTASyI1XlXDPM9jQ?tab=0 你可以理解为只要有请求流经sidecar，这个sidecar就需要和mixer进行2次通信。不过1.5版本后mixer已经废弃了，可以不必纠结这个问题。
2020-04-17
dream
老师，请问一下，在 1.0 版本中有提到 mixer 有一个问题是性能，降低了性能的原因之一是 : mixer 需要和数据平面进行两次通讯，请问这里为什么是两次通讯呢？具体是那两次通讯呢？
作者回复: 参考这里：https://istio.io/docs/reference/config/policy-and-telemetry/mixer-overview/ “The Envoy sidecar logically calls Mixer before each request to perform precondition checks, and after each request to report telemetry. ” - 两次分别是预检和遥测。预检的时候可以做限流；遥测的时候收集指标数据，这也正好对应mixer的两个核心功能。
2020-04-15
思维决定未来
不够看啊，求快更
2020-04-13
6
收起评论