课件及源代码地址

另外，请教下老师，就是面对chaos engineering，目前我看到蔡老师设计文档中chaos engineering decorator主要是模拟了慢响应、异常响应，我们的系统设计层面是否主要是基于design for fail的思想来做设计？我的收获是，看完老师的service decorate设计，对design for fail的思想有了更多的理解！ 另外一点思考在另外一条评论中也有提及，对比目前成熟的服务网格，design for fail的实现更多的放在了基于sidecar落地的类似envoy代理实现，做到了很好的解耦和异构服务标准化这块。 最后，还想到一个点就是除了基于decorator设计模式包了很多层，是否还可以基于责任链的设计模式实现？至少之前看laravel框架就是将请求逐步逐步的往后续请求，其很多中间组件就是做了类似的断路器、限流的功能，老师能谈下你对两种设计模式的选择考虑呢？

老师，我看了你写的service_decorators，这类实际上还是对代码有一定耦合，但是与现在istio的envoy类似的sidecar模式相比，少了一次通信开销。目前的service mesh也是强调把服务装在服务网格，让研发专注基础设施外的核心业务开发，从长期看，把熔断、限流、可观测性放在基础设施层来做，解耦业务逻辑和基础设施，长期来看，更有利于微幅系统的维护，不知道这样理解有没有问题？

请问老师，如果开发的Go系统就是用于k8s环境，而且会配有Istio这样的服务网格，那是不是类似限流，熔断这样的功能就不需要使用库直接集成到自己的服务中了？自己就服务可以比较单纯的处理RESTful API或者gRPC调用就行了（当然日志之类的还是自己服务要有）？

开阔技术视野，谢谢老师