在完成 k8s 上快速部署 go 服务 和 k8s: istio 入门 后, 继续 膨胀 , 使用 go 来实现 istio 提供的 bookinfo 微服务 demo
快速回顾之前的 blog:
涉及到的问题:
简单实践步骤:
先回顾一下 bookinfo 微服务应用的端到端架构:
包含 4 个微服务:
可以参考 k8s 上 go 服务实战: 使用 helm 快速构建云原生应用 快速部署 rating 服务
同理, 实现 productpage detail 服务
istio 几乎涵盖了 服务治理/流量控制 的方方面面, 作为服务治理层的基础设施 完全够用 , 问题开始从 行不行 , 转向 用哪些 , 让 业务层/devops工作流/k8s基础设施 用起来更爽
还需要解决的问题:
Istio是由Google、IBM和Lyft开源的微服务管理、保护和监控框架。Istio为希腊语，意思是”起航“使用istio可以很简单的创建具有负载均衡、服务间认证、监控等功能的服务网络，而不需要对服务的代码进行任何修改。你只需要在部署环境中，例如Kubernetes的pod里注入一个特别的sidecar proxy来增加对istio的支持，用来截获微服务之间的网络流量。
特性：
使用istio的进行微服务管理有如下特性：
流量管理：控制服务间的流量和API调用流，使调用更可靠，增强不同环境下的网络鲁棒性。可观测性：了解服务之间的依赖关系和它们之间的性质和流量，提供快速识别定位问题的能力。
策略实施：通过配置mesh而不是以改变代码的方式来控制服务之间的访问策略。
服务识别和安全：提供在mesh里的服务可识别性和安全性保护。
未来将支持多种平台，不论是kubernetes、Mesos、还是云。同时可以集成已有的ACL、日志、监控、配额、审计等。
正是 Istio 的出现使 “Service Mesh”（ 服务网格 ） 这一概念开始流行起来。在深入介绍 Istio 的细节之前，让我们首先简单地了解一下 Service Mesh 是什么，以及它的重要性体现在哪里。我们都已经了解单体应用所面对的挑战，一种显而易见的方案是将其分解为多个微服务。虽然这种方式简化了单个服务的开发，但对于成百上千的微服务的通信、监控以及安全性的管理并不是一件简单的事。
直至目前，对于这些问题的解决方案也只是通过自定义脚本、类库等方式将服务串联在一起，并且投入专门的人力以处理分布式系统的管理任务。但这种方式降低了各个团队的效率，并且提高了维护的成本。这正是 Service Mesh 大显身手的时机
Istio以及Service Mesh的未来
