中国建设银行报名网站,即墨今天新闻大事,页面访问,设计网站公司可去亿企邦来源 | 无敌码农责编 |贾凯强头图 | 下载于视觉中国新一代微服务架构——Service Mesh已经引发了诸多关注。在微服务架构盛行的今天#xff0c;像Spring Cloud这样的微服务框架大家已然耳熟能详 #xff0c;因为大部分互联网公司都在此基础上构建过第一代微服务体系#xff… 来源 | 无敌码农责编 |贾凯强头图 | 下载于视觉中国新一代微服务架构——Service Mesh已经引发了诸多关注。在微服务架构盛行的今天像Spring Cloud这样的微服务框架大家已然耳熟能详 因为大部分互联网公司都在此基础上构建过第一代微服务体系所以对于做Java 的同学来说Spring Cloud微服务体系应该是非常熟悉了。这里并不是说其他语言栈就没有构建微服务体系的框架例如Go语言也有像Go-Micro这样的微服务框架只不过目前除了像头条这样重度使用Go语言的公司外其他绝大多数互联网公司的服务端语言依然还是Java的天下所以对于目前大部分已经或打算采用微服务架构的公司来说Spring Cloud框架依然是它们的首选但如果我说这套体系发展到今天已经快过时了你会不会觉得我是在瞎掰呢因为毕竟咱们现在天天玩的微服务还都是Spring Cloud这一套啊难道像Spring Cloud GateWay、Zuul、Eureka、Consul、Nacos、Feign/Ribbon、Hystrix、Sentinel、Spring Cloud Config、Apollo...这些涵盖了微服务体系——服务注册与发现、限流、熔断降级、负载均衡、服务配置等服务治理各个方面的牛逼开发框架或服务组件们都快要过时了吗虽然这很难让人接受毕竟这些技术才刚刚捂热但在下一代微服务架构Service Mesh 面前它们中的绝大部分组件确实是快要过时了倒不是说这些开源组件在技术上不牛逼或者没有深入学习研究的价值了而是它们所面向的微服务体系结构在设计理念上与Service Mesh已经存在代差这种差距夸张点说就像歼-20与歼-10的差别。这听起来可能有点耸人听闻但从目前微服务技术发展趋势和实践上看这就是历史潮流接下来我将从理论和实践层面对此进行分析和演示为什么要进入Service Mesh时代前面我略微夸张的说到以Spring Cloud为代表的微服务体系相比Service Mesh而言已经存在技术代差那凭什么这么说呢接下来我们回顾下使用Spring Cloud构建微服务体系的大致技术流程要构建微服务体系首先我们需要独立部署一款实现服务注册/发现功能的组件服务目前可供选择的主流方案一般有Eureka、Consul、Nacos等搞定服务注册/发现后我们编写一个Java微服务此时为了将该服务注册到服务注册中心一般会引入Spring Cloud提供的支持对应注册中心接入的SDK并在应用入口类中通过EnableDiscoveryClient注解的方式标注之后SDK中的逻辑就会在应用启动时执行服务注册动作并提供给注册中心相应地探测接口以此实现微服务与服务注册中心之间的连接。以此类推我们可以通过这种方式将一组微服务都注册到服务注册中心而如果服务之间要互相调用怎么办呢一般我们会通过编写FeignClient接口来实现微服务之间的调用而其底层的逻辑则是通过Feign所集成的Ribbon组件去注册中心中获取目标服务的服务地址列表之后Ribbon根据服务地址列表进行负载均衡调用。至于服务与注册中心之间如何保证连接有效性则依赖于服务注册中心与其SDK之间的协作机制。而高级一点服务之间的调用除了实现负载均衡还要实现熔断限流、那么此时可以通过部署服务网关组件例如Zuul/Spring Cloud GateWay来实现微服务入口的熔断限流、内部服务之间的限流熔断则通过集成Hystrix或Sentinel组件以客户端本地配置或远程配置中心的方式来实现。上述过程基本就是我们使用Spring Cloud构建微服务体系的大致过程了如果仔细思考下这个过程我们会发现在该微服务体系的构造过程中与服务治理相关的大部分逻辑都是以SDK的方式耦合在具体的微服务应用之中服务注册需要引入SDK、服务调用需要引入SDK、服务熔断限流也需要SDK除此之外为了保证这套体系的正常运行我们还需要额外维护服务注册中心、服务网关这样的基础服务。这样的结构会导致什么弊端呢具体有以下几点1、框架/SDK太多后续升级维护困难在这套体系中与服务治理相关的逻辑都是以SDK代码依赖的方式嵌入在微服务之中如果某天我们想升级下服务注册中心的SDK版本或者熔断限流组件Hystrix或Sentinel的版本那么需要升级改造的微服务可能会是成百上千且由于这些组件都与业务应用绑定在一起在升级的过程中会不会影响业务稳定这都是需要谨慎对待的事情所以对SDK的升级难度可想而知的2、多语言微服务SDK维护成本高试想下如果构建的微服务体系也要支持像Go、Python或者其他语言编写的微服务的话那么上述这些微服务治理相关的SDK是不是得单独再维护几套呢所以在这种体系结构中对多语言微服务的支持就成了一个问题3、服务治理策略难以统一控制基于该套体系构建的微服务体系在对像熔断、限流、负载均衡等服务治理相关的策略管理上都是比较分散的可能有人会写到自己的本地配置文件有人会硬编码到代码逻辑中也可能有人会将其配置到远程配置中心总之对于服务治理策略逻辑都是由对应的开发人员自己控制这样就很难形成统一的控制体系4、服务治理逻辑嵌入业务应用占有业务服务资源在这套微服务体系中服务治理相关的逻辑都是在微服务应用进程中寄生运行的这多少会占有宝贵的业务服务器资源影响应用性能的发挥5、额外的服务治理组件的维护成本无论是服务注册中心、还是服务网关这些除了微服务应用本身之外服务治理组件都需要我们以中间件基础服务的方式进行维护需要额外的人力、额外的服务器成本以上就是以Spring Cloud为代表的传统微服务体系的弊端如果我说在Service Mesh体系下以上几点都不再是问题甚至都不需要研发人员再进行任何关注我们只需要写一个普通的Spring Boot服务也不需要引入服务注册SDK、熔断限流SDK组件总之你写一个普普通通的服务就能实现像之前Spring Cloud微服务体系所能支持的大部分服务治理功能你会相信吗你会不会觉得这跟之前写单体应用没啥差别了呢不管你怎么想这些就是Service Mesh要干的事情Service Mesh的目标就是要将微服务治理体系下沉为一套与业务无关的基础设施。从这个角度看如果咱们不认真学习下Service Mesh那么以后将变得越来越低智因为Spring Cloud好歹还能让我们感知下微服务的存在而在Service Mesh中微服务治理体系作为基础设施的一部分对普通研发人员将越来越透明Service Mesh的解决方案是什么在前面我们说到Service Mesh的目标是要将微服务治理体系下沉为与业务无关的基础设施。这句话怎么理解呢实际上Service Mesh微服务治理技术的诞生也不是凭空产生的而是在以Kubernetes为代表的容器编排技术逐步成为软件运行主流基础环境的背景下以及以Spring Cloud框架为代表的传统微服务技术体系弊端逐步显现的情况下技术自然迭代发展的结果。总之就是有点万事具备只欠东风的感觉所以我们看到目前落地的Service Mesh方案中大多都是与Kubernetes深度结合的方案例如最受瞩目的Istio接下来我们具体看看在Service Mesh中微服务治理的核心逻辑是怎么实现的以IstioEnvoy为例要理解在Service Mesh中的微服务治理逻辑的具体实现就不得不上一张关于服务网格概念很经典但刚开始看着又很难理解的图如下如果你之前大致了解过Service Mesh的概念那么这张图相信你一定见过。其中绿色的正方形表示正常部署的微服务而蓝色的正方形表示一个网络代理也就是大家通常所说的SideCar。在Service Mesh架构下每部署一个微服务都需要部署一个与之相对应的代理服务所有与微服务本身的交互都通过SideCar代理而SideCar之间会形成一张形似网格的交互链路这就是服务网格名称的来由在Service Mesh中当我们将一个服务部署在Kubernetes之后安装在Kubernetes中的Service Mesh组件例如Istio就会自动在该微服务的同一个Pod之中启动一个与之对应的代理进程例如istio-proxy这个保姆式的代理进程会代替微服务本身去实现原先在Spring Cloud体系中需要微服务自身完成的服务注册、负载均衡、熔断限流等微服务治理功能。并且这些代理进程并不是孤军奋战而是会通过像xDS协议Service Mesh中数据面与控制面通信的通用协议与Service Mesh控制组件保持连接。这也就引出了Service Mesh架构中关键的两个概念控制面与数据面。前面我们所示的Sidecar例如istio-proxy实际上是envoy就是数据面与微服务治理逻辑相关的信息都存储在数据面中而控制面则是Service Mesh的中心控制组件例如Istio中的Pilot组件控制面可以通过xDS协议具体又分为LDS、CDS...向数据面下发各种服务治理相关的规则例如限流规则、路由规则、服务节点更新信息等等。这种设计方式就是Service Mesh最核心的设计逻辑——通过Sidecar的方式代理微服务进行服务治理逻辑数据面通过控制面感知外界环境的变化并通过xDS协议支持各种微服务治理策略规则的集中管理和下发而这里的控制面和数据面都会被融合进像Kubernetes这样的基础架构环境中对于普通微服务的开发研发人员要做的只是将一个应用以编排的方式部署进k8s集群即可而所有与微服务治理相关的逻辑都由代理数据面与控制面协作完成。这里我们以Service Mesh最著名的开源方案Istio的架构图来解释上面所说的逻辑具体如下其中服务注册发现可以直接利用Kubernetes的内部发现机制通过监听Kubernetes Pod的变化来实现具体示意图如下而微服务治理相关的逻辑以Istio为例流程大致是这样的管理员通过Pilot配置治理规则并通过xDS协议向Envoy下发治理规则而Envoy从Pilot获取微服务治理规则后就可以在流量访问的时候按照规则执行相应的限流、路由等微服务治理逻辑了IstioEnvoy的Service Mesh架构玩法前面我们从原理层面大致介绍了Service Mesh微服务架构的核心概念及流程逻辑如果你玩过Service Mesh架构那么理解起来是很容易的但是如果没有具体实践过特别是如果对Kubernetes没有基本的了解那么上面的概念可能也并不好理解例如你可能会竭力地想象我到底应该怎么部署那个所谓的Sidecar代理在Service Mesh架构下怎么去开发服务等这样的问题而如果我写到这里不写了那么这篇文章也只是与大部分介绍过Service Mesh的文章一样要么就是各种高大上不接地气的原理介绍要么就是翻过来覆过去的概念介绍或者好不容易找到一篇带有示例的文章但大多数也是基于Istio官方Demo的演示而对于开发过Spring Cloud微服务应用的同学来说其实并不是很好理解所以接下来的玩法实践我将以最接近实际开发场景的方式、站在一个曾经使用Spring Cloud框架开发过微服务的研发人员角度来整体介绍如何用平常工作中所使用的Java流行框架(如Spring Boot)来开发基于Service Mesh体系的微服务应用01 k8s环境准备及Istio安装具体过程及步骤如下要玩转Service Mesh微服务架构基本的前提是需要一个功能完整的Kubernetes环境这里我所使用的k8s环境是在开发本上安装一个Linux虚拟机并在其之上部署一个只有Master节点的Kubernetes单节点集群另外由于Istio对Kubernetes的版本是有要求的这里所使用的k8s版本是v1.18.6。如果对安装Kubernetes环境还有疑惑也可以参考本号早前发布的文章《如何部署一个Kubernetes集群》这里我先假设你已经搞定了Kubernetes环境接下来开始安装Istio选择的版本是istio-1.8.4具体步骤如下1)、下载Istio发布包由于官方提供的下载脚本执行速度比较慢可以直接在github找到相应的istio发布版本后通过wget命令将其下载至主机指定目录(能正常连接k8s集群)wget https://github.com/istio/istio/releases/download/1.8.4/istio-1.8.4-linux-amd64.tar.gz下载成功后解压安装包tar -zxvf istio-1.8.4-linux-amd64.tar.gz进入解压安装包目录cd istio-1.8.4/2)、将istioctl客户端添加到系统可执行路径在具体安装istio时需要使用istioctl命令因此需要先将该命令加入系统可执行路径命令如下export PATH$PWD/bin:$PATH3)、执行安装istio命令这里使用istioctl命令执行安装命令具体如下istioctl install --set profiledemo
这里--set profiledemo表示安装一个istio测试环境成功安装后的信息输出如下Detected that your cluster does not support third party JWT authentication. Falling back to less secure first party JWT. See https://istio.io/v1.8/docs/ops/best-practices/security/#configure-third-party-service-account-tokens for details.
This will install the Istio 1.8.4 demo profile with [Istio core Istiod Ingress gateways Egress gateways] components into the cluster. Proceed? (y/N) Y
✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Egress gateways installed
✔ Installation complete 如果安装成功则可以通过kubectl命令查看istio相关组件是否已经安装在Kubernetes环境之中命令如下kubectl get svc -n istio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-egressgateway ClusterIP 10.101.134.226 none 80/TCP,443/TCP,15443/TCP 8m12s
istio-ingressgateway LoadBalancer 10.96.167.106 pending 15021:31076/TCP,80:31032/TCP,443:31438/TCP,31400:32751/TCP,15443:31411/TCP 8m11s
istiod ClusterIP 10.102.112.111 none 15010/TCP,15012/TCP,443/TCP,15014/TCP 此时可以看到istio的核心组件istiod以及入口网关ingressgateway、出口网关egressgateway已经成功以Service资源的方式运行在了Kuberntes集群之中4)、k8s默认命名空间开启自动注入Envoy Sidecar这是一个关键的步骤如果我们的微服务应用未来是默认部署在k8s的default命名空间那么在安装istio是需要开启该空间的Sidecar自动注入功能。这是我们前面提到每启动一个微服务应用k8s就会默认在相同的Pod中自动启动一个代理进程的关键设置具体命令如下$ kubectl label namespace default istio-injectionenabled
namespace/default labeled5)、Istio可观测性部署Kiali是一个基于服务网格的Istio管理控制台它提供了一些数据仪表盘和可观测能力同时也可以让我们去操作网格的配置。使用如下方式快速部署一个用于演示的Kiali命令如下$ kubectl apply -f samples/addons
serviceaccount/grafana created
configmap/grafana created
service/grafana created
deployment.apps/grafana created
configmap/istio-grafana-dashboards created
configmap/istio-services-grafana-dashboards created
deployment.apps/jaeger created
service/tracing created
service/zipkin created
service/jaeger-collector created
Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16, unavailable in v1.22; use apiextensions.k8s.io/v1 CustomResourceDefinition
customresourcedefinition.apiextensions.k8s.io/monitoringdashboards.monitoring.kiali.io created
serviceaccount/kiali created
configmap/kiali created
clusterrole.rbac.authorization.k8s.io/kiali-viewer created
clusterrole.rbac.authorization.k8s.io/kiali created
clusterrolebinding.rbac.authorization.k8s.io/kiali created
role.rbac.authorization.k8s.io/kiali-controlplane created
rolebinding.rbac.authorization.k8s.io/kiali-controlplane created
service/kiali created
deployment.apps/kiali created
serviceaccount/prometheus created
configmap/prometheus created
clusterrole.rbac.authorization.k8s.io/prometheus created
clusterrolebinding.rbac.authorization.k8s.io/prometheus created
service/prometheus created
deployment.apps/prometheus created
....其中具体会安装部署Promethues、Grafana、Zipkin等指标及链路采集服务因为安装的组件比较多也比较耗费资源如果集群资源不是很充足可能会出现启动比较慢的情况。如果正常部署成功可以查看Pod状态命令如下# kubectl get pod -n istio-system -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
grafana-94f5bf75b-4mkcn 1/1 Running 1 30h 10.32.0.11 kubernetes none none
istio-egressgateway-7f79bc776-w6rqn 1/1 Running 3 30h 10.32.0.3 kubernetes none none
istio-ingressgateway-74ccb8977c-gnhbb 1/1 Running 2 30h 10.32.0.8 kubernetes none none
istiod-5d4dbbb8fc-lhgsj 1/1 Running 2 30h 10.32.0.5 kubernetes none none
jaeger-5c7675974-4ch8v 1/1 Running 3 30h 10.32.0.13 kubernetes none none
kiali-667b888c56-8xm6r 1/1 Running 3 30h 10.32.0.6 kubernetes none none
prometheus-7d76687994-bhsmj 2/2 Running 7 30h 10.32.0.14 kubernetes none none由于前面安装istio时我们并没有在istio-system空间开启自动注入Sidecar(其label istio-injectiondisabled)这里为了在k8s集群之外正常访问Kiali、Prometheus、Granfana、Tracing的控制面板它们共同组成了Service Mesh的可观测体系可以通过nodePort的方式对外暴露端口。Kiali的NodePort访问操作方式将部署的Kiali的Service文件导出到主机的某个目录例如kubectl get svc -n istio-system kiali -o yaml kiali-nodeport.yaml之后编辑导出的文件删除metadata下的annotation、resourceVersion、selfFlink、uid等信息并修改下spec下的type类型值将ClusterIP修改为NodePort并指定nodePort端口信息同时删除status状态字段即可。具体如下spec:...ports:- name: httpnodePort: 31001...type: NodePort编辑完成后执行执行命令kubectl apply -f kiali-nodeport.yaml之后查看服务端口命令如下kubectl get svc -n istio-system kiali
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kiali NodePort 10.100.214.196 none 20001:31001/TCP,9090:30995/TCP 41h此时通过k8s的集群外部IP31001端口就能访问Kiali控制面板了效果如下图所示与Kiali的操作方式类似我们也可以通过获取修改部署的Promethues、Granfana、Tracing、Zipkin等服务的发布文件通过设置NodePort端口从而在k8s集群外部进行可观测界面的访问例如#Prometheus
kubectl get svc -n istio-system prometheus -o yaml prometheus-nodeport.yaml
kubectl apply -f prometheus-nodeport.yaml #Granfana
kubectl get svc -n istio-system grafana -o yaml grafana-nodeport.yaml
kubectl apply -f grafana-nodeport.yaml#Jaeger(分布式链路)
kubectl get svc -n istio-system tracing -o yaml tracing-nodeport.yaml
kubectl apply -f tracing-nodeport.yaml
...其中Granfana的访问效果示意图如下02 Spring Boot微服务开发经过前面的步骤我们已经从基础架构环境的角度完成了基于Istio的Service Mesh微服务体系的构建如果类比之前基于Spring Cloud框架的微服务开发体验那么在Istio体系下应该如何进行微服务应用的开发呢接下来我们通过一个实际的应用示例来演示如何开发基于Istio的Service Mesh微服务应用服务链路如下如上所示链路具体说明如下1)、为了完整演示在Service Mesh架构下微服务的研发过程这里我们定义3个微服务其中micro-api服务是面向外部客户端接入的Api服务提供Http协议访问2)、而micro-api与micro-order之间则基于微服务的注册发现机制进行内部服务调用具体采用Http协议3)、而micro-order与micro-pay之间也基于微服务注册发现机制进行内部微服务调用为了演示更多的研发场景这两个微服务之间的通信我们采用Grpc协议规划好了微服务应用架构接下来就可以具体开发了具体的服务代码层面的构建这里并不需要做任何微服务框架的引入你只需要通过Spring Boot构建几个基本的Spring Boot应用即可不需要引入任何服务治理相关的组件只是一个简单且单纯的Spring Boot应用不需要连接注册中心也不需要引入什么OpenFeign、Hystrix、Sentinel之类的组件。具体的代码结构如下图所示可以看到应用的入口类中已经没有服务发现之类的注解接下来我们讲重点首先在之前基于Spring Cloud的微服务调用中如果通过Http协议进行服务调用一般我们是通过引入OpenFeign来实行服务方提供一个FeignClient接口定义调用方代码直接引入即可而具体的运行逻辑则是OpenFeign中集成的Ribbon组件会从注册中心获取目标服务地址列表然后进行负载均衡调用。但在Service Mesh架构下负载均衡及服务发现的逻辑已经由Istio中的Sidecar帮我们干了所以在这里就不能还像以前一样引入OpenFeign了那么怎么办呢为了延续之前的编程风格及服务通信代码的简易性这里我们需要自己定制一个类似于OpenFeign的框架可以基于OpenFeign的源码进行改造但是要去掉其中关于服务负载均衡、熔断限流等服务治理相关的逻辑让它变成一个只是简单进行Http服务调用的框架。目前市面上并没有这样一个官方的适配框架所以一些落地Service Mesh架构的公司为了兼容Spring Cloud微服务体系的迁移也是自己单独改造和封装的这里我从github上找了一个个人改造的代码并进行了适配修改测试是可以的其具备的能力说明如下1、支持在istio服务网格体系下完成服务间的快速调用体验和原先Spring Cloud Feign类似2、支持多环境配置例如本地环境微服务的调用地址可配置为本地其他环境默认为Kubernetes集群中的服务3、支持链路追踪默认透传如下Header可以自动支持jaeger、zipkin链路追踪等如下x-request-id, x-b3-traceid, x-b3-spanid, x-b3-sampled, x-b3-flags, x-b3-parentspanid,x-ot-span-context, x-datadog-trace-id, x-datadog-parent-id, x-datadog-sampled, end-user, user-agent最后的实际编程风格是这样的FakeClient(name micro-order)
RequestMapping(/order)
public interface OrderServiceClient {/*** 订单创建*/PostMapping(/create)ResponseResultCreateOrderBO create(RequestBody CreateOrderDTO createOrderDTO);
}这里是micro-order微服务给micro-api所提供的接口调用代码micro-api服务引入调用即可从编程风格上与之前Spring Cloud微服务的开发方式十分类似。只不过到这里为止你并没有能看到任何与服务注册发现相关的逻辑其次服务治理的核心逻辑都是由Istio及Sidecar代理完成的完成应用开发后只需要编写k8s部署文件将服务部署进安装了Istio环境的Kubernetes集群即可而将编写的Java服务部署到k8s集群的流程涉及Docker镜像打包-镜像仓库发布-k8s部署拉取镜像这一套CI/CD操作流程如果不明白可以看看本号之前的文章《Kubernetes微服务自动化发布系统》!接下来重点演示micro-api及micro-order的k8s发布文件看看它们有什么特别之处micro-order服务k8s发布文件(micro-order.yaml):apiVersion: v1
kind: Service
metadata:name: micro-orderlabels:app: micro-orderservice: micro-order
spec:type: ClusterIPports:- name: httpport: 80targetPort: 9091selector:app: micro-order---
apiVersion: apps/v1
kind: Deployment
metadata:name: micro-order-v1labels:app: micro-orderversion: v1
spec:replicas: 2selector:matchLabels:app: micro-orderversion: v1template:metadata:labels:app: micro-orderversion: v1spec:containers:- name: micro-orderimage: 10.211.55.2:8080/micro-service/micro-order:1.0-SNAPSHOTimagePullPolicy: Alwaystty: trueports:- name: httpprotocol: TCPcontainerPort: 19091如上所示这是micro-order服务的k8s部署文件就是正常定义了该应用的Service资源及Deployment编排资源为了后面演示服务的负载均衡调用这里我特地将该应用部署成了2个副本接下来继续看看调用方micro-api服务的k8s发布文件(micro-api.yaml)apiVersion: v1
kind: Service
metadata:name: micro-api
spec:type: ClusterIPports:- name: httpport: 19090targetPort: 9090selector:app: micro-api---
apiVersion: apps/v1
kind: Deployment
metadata:name: micro-api
spec:replicas: 1selector:matchLabels:app: micro-apitemplate:metadata:labels:app: micro-apispec:containers:- name: micro-apiimage: 10.211.55.2:8080/micro-service/micro-api:1.0-SNAPSHOTimagePullPolicy: Alwaystty: trueports:- name: httpprotocol: TCPcontainerPort: 19090与micro-order一样也只是定义了该应用的k8s正常发布资源到这里也并没有体现出micro-api是怎么调用micro-order服务的接下来我们通过这个文件将服务发布至k8s集群中注意是开启了Sidecar自动注入的默认命名空间部署成功后查看Pods信息具体如下# kubectl get pods
NAME READY STATUS RESTARTS AGE
micro-api-6455654996-57t4z 2/2 Running 4 28h
micro-order-v1-84ddc57444-dng2k 2/2 Running 3 23h
micro-order-v1-84ddc57444-zpmjl 2/2 Running 4 28h如上所示可以看到一个micro-api Pod两个micro-order Pod都已经正常运行起来了但不知你发现没有每个Pod中READY字段显示的都是2/2这意味着每个Pod中都启动了两个容器一个是微服务应用本身另外一个就是自动注入启动的Sidecar代理进程。为了更深理解这个逻辑我们可以通过命令查看下Pod的描述信息# kubectl describe pod micro-api-6455654996-57t4zName: micro-api-6455654996-57t4z
...IP: 10.32.0.10
IPs:IP: 10.32.0.10
Controlled By: ReplicaSet/micro-api-6455654996
Init Containers:istio-init:Container ID: docker://eb0298bc8456f5f1336dfe2e8baab6035fccce898955469353da445aceab15cbImage: docker.io/istio/proxyv2:1.8.4Image ID: docker-pullable://istio/proxyv2sha256:6a4ac67c1a74f95d3b307a77ad87e3abb4fcd64ddffe707f99a4458f39d9ce85....Containers:micro-api:Container ID: docker://ebb45c5fa826f78c354877fc0a4c07d6b2fae4c6304e15729268b1cc6a69abcaImage: 10.211.55.2:8080/micro-service/micro-api:1.0-SNAPSHOTImage ID: docker-pullable://10.211.55.2:8080/micro-service/micro-apisha256:f303016a604f30b99df738cbb61f89ffc166ba96d59785172c7b769c1c75a18d此处省略...istio-proxy:Container ID: docker://bba9dc648b9e1a058e9c14b0635e0872079ed3fe7d55e34ac90ae03c5e5f3a66Image: docker.io/istio/proxyv2:1.8.4Image ID: docker-pullable://istio/proxyv2sha256:6a4ac67c1a74f95d3b307a77ad87e3abb4fcd64ddffe707f99a4458f39d9ce85此处省略...可以看到在开启了Sidecar自动注入的命名空间中每启动一个PodIstio都会将Sidecar代理以初始化容器(Init Containers)的方式自动启动一个对应地istio-proxy代理进程(Envoy)到这里你应该真实感到到Sidecar到底是一个什么样的存在了吧03 部署Istio微服务网关前面的步骤中我们已经完成了微服务应用的开发并且也已经将其部署到了k8s集群Sidecar代理也正常启动了那么怎么访问呢一般来说如果要访问Kubernetes集群中的Service可以通过NodePort端口映射及Ingress的方式向k8s集群外暴露访问端口。但在Istio中采用了一种新的模型——Istio Gateway来代替Kubernetes中的Ingress资源类型。在Istio微服务体系中所有外部流量的访问都应该通过Gateway进来并由Gateway转发到对应的内部微服务而基于统一的控制面配置Istio也可以集中管理Gateway网关的流量访问规则实现对外部流量访问的整体管控在前面部署Istio时istio-ingressgateway入口流量网关已经作为Istio体系的一部分运行在k8s集群中了如下# kubectl get svc -n istio-system|grep istio-ingressgateway
istio-ingressgateway LoadBalancer 10.100.69.24 pending 15021:31158/TCP,80:32277/TCP,443:30508/TCP,31400:30905/TCP,15443:30595/TCP 46h接下来我们需要设置通过该网关访问micro-api微服务的逻辑编写网关部署文件micro-gateway.yamlapiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:name: micro-gateway
spec:selector:istio: ingressgatewayservers:- port:number: 80name: httpprotocol: HTTPhosts:- *
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: micro-gateway
spec:hosts:- *gateways:- micro-gatewayhttp:- match:- uri:exact: /api/order/createroute:- destination:host: micro-apiport:number: 19090如上所示该部署文件中定义了路由匹配规则凡事访问/api/order/create地址的请求都会被转发到micro-api服务的19090端口配置完上述网关路由转发规则后我们尝试通过访问istio-ingressgateway来到达访问微服务接口的效果具体链路是:外部调用-istio-ingressgateway-micro-api-micro-order。但是对于istio-ingressgateway的访问由于也是k8s内部pod所以暂时先配置一个NodePort端口映射具体可以通过以下命令进行操作export INGRESS_PORT$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath{.spec.ports[?(.namehttp2)].nodePort})
export SECURE_INGRESS_PORT$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath{.spec.ports[?(.namehttps)].nodePort})
export INGRESS_HOST127.0.0.1
export GATEWAY_URL$INGRESS_HOST:$INGRESS_PORT以上分别设置了istio-ingressgateway的http/https的NodePort访问端口设置完成后具体查看nodePort端口映射情况# kubectl get svc -n istio-system|grep istio-ingressgateway
istio-ingressgateway LoadBalancer 10.100.69.24 pending 15021:31158/TCP,80:32277/TCP,443:30508/TCP,31400:30905/TCP,15443:30595/TCP 46h可以看到通过http的32277以及https的30508端口可以访问istio-ingressgateway。具体访问url是:http://{k8s集群IP}:32277/接口url。具体访问效果如下从调用效果上可以看到基于Istio的Service Mesh微服务体系已经运行成功而从编程体验上看你似乎已经快感觉不出微服务的存在了反正稀里糊涂的服务就调通了服务发现怎么做到的负载均衡怎么做到的这些问题在不需要你关心的同时可能也引起了你的疑惑接下来我们通过调用日志简单感知下调用链路所经过的逻辑04 链路调用日志原理通过Postman调用返回结果后我们分别看下链路所经过的服务日志先看看istio-ingressgateway的容器日志具体如下# kubectl logs istio-ingressgateway-74ccb8977c-gnhbb -n istio-system...
2021-03-18T08:02:30.863243Z info xdsproxy Envoy ADS stream established
2021-03-18T08:02:30.865335Z info xdsproxy connecting to upstream XDS server: istiod.istio-system.svc:15012
[2021-03-18T08:14:00.224Z] POST /api/order/create HTTP/1.1 200 - - 66 75 7551 6144 10.32.0.1 PostmanRuntime/7.26.8 8e8bad1d-5dd9-954b-b218-15f8c9595a24 10.211.55.12:32277 10.32.0.10:9090 outbound|19090||micro-api.default.svc.cluster.local 10.32.0.8:57460 10.32.0.8:8080 10.32.0.1:33229 - -
[2021-03-18T08:14:32.465Z] POST /api/order/create HTTP/1.1 200 - - 66 75 3608 3599 10.32.0.1 PostmanRuntime/7.26.8 ccf56049-88e8-9170-a1f5-93affbf6e098 10.211.55.12:32277 10.32.0.10:9090 outbound|19090||micro-api.default.svc.cluster.local 10.32.0.8:57460 10.32.0.8:8080 10.32.0.1:33229 - -
[2021-03-18T08:16:37.242Z] POST /api/order/create HTTP/1.1 200 - - 66 75 68 67 10.32.0.1 PostmanRuntime/7.26.8 98ecbd52-91a0-97c6-9ce6-d8f6094560e0 10.211.55.12:32277 10.32.0.10:9090 outbound|19090||micro-api.default.svc.cluster.local 10.32.0.8:57460 10.32.0.8:8080 10.32.0.1:33229 - -如上所示从istio-ingressgateway的网关日志中可以看到/api/order/create接口的访问情况确实是被转发到了micro-api所在的pod ip符合前面配置的网关路由规则。接下来我们查看micro-api的istio-proxy代理的日志# kubectl logs micro-api-6455654996-57t4z istio-proxy
...
[2021-03-18T08:41:10.750Z] POST /order/create HTTP/1.1 200 - - 49 75 19 18 - PostmanRuntime/7.26.8 886390ea-e881-9c45-b859-1e0fc4733680 micro-order 10.32.0.7:9091 outbound|80||micro-order.default.svc.cluster.local 10.32.0.10:54552 10.99.132.246:80 10.32.0.10:39452 - default
[2021-03-18T08:41:10.695Z] POST /api/order/create HTTP/1.1 200 - - 66 75 104 103 10.32.0.1 PostmanRuntime/7.26.8 886390ea-e881-9c45-b859-1e0fc4733680 10.211.55.12:32277 127.0.0.1:9090 inbound|9090|| 127.0.0.1:52782 10.32.0.10:9090 10.32.0.1:0 outbound_.19090_._.micro-api.default.svc.cluster.local default
...
[2021-03-18T08:47:22.215Z] POST /order/create HTTP/1.1 200 - - 49 75 78 70 - PostmanRuntime/7.26.8 9bbd3a3c-86c4-943f-999a-bc9a1dc02c35 micro-order 10.32.0.9:9091 outbound|80||micro-order.default.svc.cluster.local 10.32.0.10:54326 10.99.132.246:80 10.32.0.10:44338 - default
[2021-03-18T08:47:22.173Z] POST /api/order/create HTTP/1.1 200 - - 66 75 134 129 10.32.0.1 PostmanRuntime/7.26.8 9bbd3a3c-86c4-943f-999a-bc9a1dc02c35 10.211.55.12:32277 127.0.0.1:9090 inbound|9090|| 127.0.0.1:57672 10.32.0.10:9090 10.32.0.1:0 outbound_.19090_._.micro-api.default.svc.cluster.local default这里我们访问了两次接口情况可以看到micro-api的Sidecar代理以负载均衡的方式分别调用了micro-order服务的两个不同实例(打下划线IP)而访问micro-order的istio-proxy代理日志# kubectl logs micro-order-v1-84ddc57444-dng2k istio-proxy
...
2021-03-18T08:33:06.146178Z info xdsproxy Envoy ADS stream established
2021-03-18T08:33:06.146458Z info xdsproxy connecting to upstream XDS server: istiod.istio-system.svc:15012
[2021-03-18T08:34:59.055Z] POST /order/create HTTP/1.1 200 - - 49 75 8621 6923 - PostmanRuntime/7.26.8 b1685670-9e54-9970-a915-5c5dd18debc8 micro-order 127.0.0.1:9091 inbound|9091|| 127.0.0.1:36420 10.32.0.7:9091 10.32.0.10:54552 outbound_.80_._.micro-order.default.svc.cluster.local default
[2021-03-18T08:41:10.751Z] POST /order/create HTTP/1.1 200 - - 49 75 17 16 - PostmanRuntime/7.26.8 886390ea-e881-9c45-b859-1e0fc4733680 micro-order 127.0.0.1:9091 inbound|9091|| 127.0.0.1:41398 10.32.0.7:9091 10.32.0.10:54552 outbound_.80_._.micro-order.default.svc.cluster.local default
....可以看到请求通过micro-order的istio-proxy代理被转到了具体的micro-order实例通过上面日志的分析虽然很细节的原理可能还是有疑问但至少可以得到一个结论那就是在Istio的Service Mesh微服务架构中服务的转发、路由逻辑的确都是由Sidecar代理来干的而且从日志中可以看到Envoy代理时刻都在保持着同控制面服务istiod的连接并随时通过xDS协议更新着服务治理规则后记本文从Service Mesh的大致原理出发以实际的开发案例演示了如何开发一套基于Service Mesh架构的微服务体系应该算是能够让大家入门Service Mesh了也多少弥补了一点目前网络上Service Mesh具体实践文章几近空白的情况但不得不说虽然Service Mesh微服务架构体系极大的简化了研发人员开发微服务应用的成本但另一方面Service Mesh在将微服务治理体系下沉为基础设施一部分的同时也增加了对Devops工程师的要求毕竟要玩好Service Mesh架构不仅需要开发技能还需要对Service Mesh的架构体系及其框架源码有深刻的理解。除此之外还需要对Kubernetes基础设施特别熟悉总之Service Mesh虽然先进但是在团队技能知识储备尚不具备的情况下贸然将这套体系引入生产环境也是有风险的所以这只是一个开始在后面的时间里我还会继续分享有关Service Mesh及Istio的实践及原理感兴趣的朋友可以持续关注下最后如果需要本文所演示的示例代码地址如下https://github.com/manongwudi/istio-micro-service-demo参考文档https://www.sohu.com/a/314752747_825425https://github.com/WenDev/spring-boot-istio-demohttps://github.com/ring1012/istio-fake更多精彩推荐
☞三个月前被 K8S 弃用Docker 火了获 2300 万美元融资☞一招上手这样设计扛住亿级流量活动系统☞Kubernetes 稳定性保障手册极简版
