首先看看 Istio 在服务访问的过程中都做了什么,简单起见,这里以一个天气预报应用中forecast服务对recommendation服务的访问为例,如图1-2所示。本书后面的大部分功能都会基于该应用来介绍。
图1-2 Istio服务访问示例
这个示例对两个服务的业务代码没有任何要求,可以用任何语言开发。在这个示例中,forecast服务是用Node.js开发的,recommendation服务是用Java开发的。在forecast服务的代码中通过域名访问recommendation服务,在两个服务中都不用包含任何服务访问管理的逻辑。
我们看看Istio在其中都做了什么:
◎ 自动通过服务发现获取recommendation服务实例列表,并根据负载均衡策略选择一个服务实例;
◎ 对服务双方启用双向认证和通道加密;
◎ 如果某个服务实例连续访问出错,则可以将该实例隔离一段时间,以提高访问质量;
◎ 设置最大连接数、最大请求数、访问超时等对服务进行保护;
◎ 限流;
◎ 对请求进行重试;
◎ 修改请求中的内容;
◎ 将一定特征的服务重定向;
◎ 灰度发布;
◎ 自动记录服务访问信息;
◎ 记录调用链,进行分布式追踪;
◎ 根据访问数据形成完整的应用访问拓扑;
◎……
所有这些功能,都不需要用户修改代码,用户只需在 Istio 的控制面做些配置即可,并且动态生效。以灰度发现为例,在 Istio 中是通过简单配置实现灰度发布的,其核心工作是实现两个版本同时在线,并通过一定的流量策略将部分流量引到灰度版本上。我们无须修改代码,只要简单写一个配置就可以对任意一个服务进行灰度发布了:
Istio采用了与Kubernetes类似的语法风格,即使不了解语法细节,也很容易明白其功能大意:将 group是 dev的流量转发到 recommendation服务的 v2版本,其他用户还是访问 recommendation服务的 v1版本,从而达到从 v1版本中切分少部分流量到灰度版本 v2的效果。对Istio提供的功能都进行类似配置即可,无须修改代码,无须额外的组件支持,也无须其他前置和后置操作。