2020年，从架构谈起，到 Mesh 结束中，Istio + k8s 的方案在向客户提供最佳实践之前

1.弹性与自恢复问题 使用系统度量、参数等触发弹性伸缩是常见的需求，这里我们是使用云监控？还是自己搭一套？我一直倾向数据与用途解耦，使用 pub sub 模式解决问题，比如 CPU 过高可能会触发多个行为：触发警报，触发弹性规则，展示在 dashboard 上。我们可以增加 pod 来分担服务的压力，或者因为某个 pod 异常退出后，启动新的 pod 来完成自恢复，这系列动作也是需要我们自己解决的。 2.监控与可观测性 日志、警报等可观测性的问题，这一方面的实践较多，唯一比较担心的是 ARMS 或者 Newrelic 这种 APM功能目前没在目标平台上实践过，我们希望能够清晰的看到每个服务的实时性能，目前这一部分还缺乏考虑与设计。 3.限流与降级的实践 Istio 的流量控制能力是非常强大的，如何对服务采取降级、限流这种常见的治理操作，也是需要总结出实践经验的。避免串流错误（cascadefailure）在微服务领域也很常见，也需要避免故障蔓延。 4.多种自动化 蓝绿、灰度、金丝雀，这些多样的部署方式也需要落地，我们可能会写一些 deployment util 之类的小脚本，部署的方式需要和 CICD 打通。一个部署工具，一个配置文件，一个 CICD 组成未来单个应用的部 署方式。 5.ABAC 与 OPA 基于属性的权限控制以及 OPA 的可定制性我们是非常看好的，而且 sidecar 可以在进程之外解决权限验证问题，的确值得尝试，刚好也学习下 golang 用于定制 OPA。 6.Saga 与补偿事件 分布式事务是微服务实践中的大坑，我曾经也写过类似的文章，项目经验中更多的是将事务放在单一的服务内，再加上我自己也没机会写过真正的网店系统。补偿事件也是常用的最终一致性方案，总之放在一起验证。 7.高可用和混沌工程 基于 K8s 实现应用的高可用应该不难，容器的天生优势就是易于启动与管理，如果随机杀掉 pod 不会影响系统可用性，这就算是实现了类似于 SLB + ECS + ASG 的能力，真正危险的是其他 非业务型 pod，比如 istio 的各种 supervisor。

答复内容摘自《云原生技术与架构实践年货小红书》，这本电子书收录开发者藏经阁 下载连接：https://developer.aliyun.com/topic/download?id=1127