导读
近期与几位企业用户交流服务网格及其相关技术,大家对于它所展现的形态以及未来发展都表示出极大的兴趣。但对当下企业应用现状如何与服务网格整合到一起又表现出极大的困惑。本文力图结合服务网格技术特性与企业应用的实际情况,就服务网格如何应对企业应用给出博云自身的思考,欢迎有兴趣的朋友一起讨论。
在进行详细探讨之前,我们首先回顾一下服务网格的定义:服务网格是一个用于处理服务间通信的基础设施层,它负责为构建复杂的云原生应用传递可靠的网络请求。在实践中,服务网格通常实现一组与应用程序部署在一起的轻量级的网络代理,但对应用程序来说是透明的。
从定义中我们可以清晰地看到服务网格的技术定位:“处理服务间通信的基础设施层”。因此我们不能希望它帮我们简化开发测试场景面临的挑战(DevOps或者应用服务化,当然一定程度上可以解耦应用与基础中间件的调用关系,稍后会详细说明),或者解决应用部署场景的问题(部署问题由容器编排平台处理更加合适)。
总体来说,服务网格专注业务应用部署上线后期的通信领域问题,同时一定程度上解耦业务单元与基础中间件的调用关系(例如服务注册中心)。如图所示:
围绕服务网格所聚焦的领域以及如何服务于企业级应用,本文重点探讨4个问题:
·服务网格的技术特性;
·服务网格与企业应用的整合之道;
·服务网格的部署管理形态;
·服务网格的远景形态。
服务网格技术特性
考虑到目前服务网格落地方式集中在以容器化为首的PaaS领域之内,因此我们也将重点基于容器化方案探讨服务网格所具备的技术特性。
从服务网格发展来看,无论是基础的码头工人运行环境,还是以Kubernetes为“事实标准”的容器编排环境,都是服务网格能够快速发展的基石。以Kubernetes为例,服务网格并非技术上的创新,更多是利用CRD特性对Kubernetes的扩展以及传统技术的整合(防火墙,DNS服务发现等)。以Isito为例,Istio基于引入的标准规范以及Kubernetes CRD特性自定义几十种自身的资源,并依赖kubectl CLI命令工具对这些CRD进行统一管理。
我们发现服务网格的技术特性主要体现在5个方面:容器编排环境;数据代理控制;配置管理分发;服务链路追踪;服务通信安全。
容器编排环境
结网落合服务地的几个方案来看,容器编排环境是服务网格能够落地的必备要素之一(这里暂时不深入讨论容器化采用的技术原理,如命名空间,再见,等)。容器化编排环境的特性能够将企业应用或者业务实例组织成方便管理和寻址的业务单元,方便系统化的方式访问这些单元。这里同样暂时忽略网外围对接的各种适配器。
数据代理控制
从服务网格定义中可知,其本身是一个与应用绑定在一起的轻量级网络代理,该代理拦截所有服务请求的出站和入站流量,并依赖控制层面标准化接口提供的规则信息(最终转化成防火墙内的路由配置)进行流量的转发和控制,同时对调用日志,调用链路,响应时长进行记录和汇报。
配置管理分发
服务网格为了保证数据代理功能的独立性,将配置与数据代理进行解耦。配置也称作控制层面,负责从容器环境搜集服务信息,并且以高度抽象化的标准接口提供给数据代理服务,为流量转发提供可靠的路由依赖。同时控制层面面向用户提供”声明式”的规则定义,这些规则会存储在容器平台中,同时生成路由转发的流量控制规则,并且以接口的形式提供给数据代理服务,为路由转发的流量控制提供管理依据。例如在Istio中规则定义表现为Istio定义的CRD资源,规则生效接口表现为政策提供的XDS接口。
服务链路追踪
服务链路在服务网格中是基础必备的功能。它的实现依赖两部分:数据采集和链路呈现。数据采集主要依赖数据代理服务进行服务请求拦截或者转发时记录服务请求的源IP地址,目的IP地址和对应的服务名称等有效信息;链路呈现依赖于分布式跟踪系统,将采集的服务调用链路信息存储在分布式跟踪系统中,做集中呈现,例如Zipkin等。
服务通信安全
安全是企业应用必然关注的因素之一,那么服务网格在安全领域提供哪些技术特性呢?服务网格作为PaaS的扩展实现,主要从3个层面为企业应用安全保驾护航:
