深度分析:Istio替代Spring Cloud的合理性

一、现有微服务架构

微服务本质上是分布式架构、分布式应用、分布式计算。

分布式计算可以带来的好处有:性能、可靠性、弹性、可扩展性、可用性、稳健性。

而从应用开发者角度看,使用微服务架构必须考虑:断路、服务发现、

客户端负载平衡等组件。也就是说,开发人员需要在应用逻辑中考虑太多的PaaS基础设计相关的内容,所以他们很烦。。。:

现有主流的微服务架构是这样的:

也就是说,通过各种组件拼凑而成,当然,通过现有的模式,搭建实验环境,做Demo展示是完全没问题的,例如此前我做的实验,通过Spring Cloud搭建一个电商:

但老实说,代码比较复杂:

而且这还只是一个实验,如果真的大规模上生产,我相信现有Spring Cloud的复杂度还是非常高的。所以有的客户,只使用了Spring Cloud的某几个组件,而非整套上,这其实是比较明智的。

而架构复杂的原因是:现有微服务模式,需要应用开发人员过多地考虑PaaS基础架构!

二、新一代微服务架构

Istio是新一代微服务架构,这个观点我在去年的文章中已经介绍过了。今天我们看一下这种架构的优势。这个架构的核心观点,就是提供一种:尽量减少开发人员处理其应用程序分布式特性的要求的微服务架构。

如果说目前的微服务架构,只针整个PaaS的第七层,因此开发人员非常累,需要考虑的点很多。而Istio,面向的是PaaS的4-6层。这样,开发人员只需要关注大麦本身即可。

Istio的架构图如下:

Istio分为数据平面和控制平面。

Istio的管理平面有三个核心组件:

Pilot:负责流量管理发现

Mixer负责:访问控制、策略管理、信息收集

Auth:负责认证

Istio的数据平面创建了一个跨平台的服务网格来解决常见的微服务架构问题,如其中包括很多:通信,负载平衡,流量路由,指标,配额,身份验证,速率限制,断路器,超时,自动重试,等等。Istio的数据平面采取sidecars的方式,也就是在一个pod的主容器旁边,增加一个istio的proxy。

我看看一下,在istio模式下,容器的通讯方式。例如Service和ServiceB。ServiceA和ServiceB分别属于两个pod。

我们再看得细一些:

我们查看一个调用istio的应用:

这个pod有两个容器,一个是主应用bookinfo-productpage,一个是istio/proxy。

我们看一下我们如何可以利用Pilot规则控制应用,策略一共有三个:

DestinationPolicy:

●Client-side load-balancing, circuit-breaking

这个策略主要负责应用之间的负载均衡、熔断。

我们看一个设置策略的例子:里面设置了http最大请求连接数等。超出阈值,会触发熔断。

EgressRule

●Enable whitelist access to external (HTTP/S) services

●External access is off by default in Istio

这个策略控制应用访问外部网络,设置白名单的策略。默认是不能访问外部网络的。

RouteRule

●Timeouts, retries, fault injection, http rewriting and redirection

这策略主要设置应用之间通信的路由策略,属于Ingress策略。

我们看一个使用例子,在应用的yaml文件中定义Ingress resource策略:

三、实验验证Istio

使用OCP3.7的环境。先创建项目:

oc new-project istio-system

增加SA权限:

oc adm policy add-scc-to-user anyuid -z istio-ingress-service-account -n istio-system oc adm policy add-scc-to-user anyuid -z istio-grafana-service-account -n istio-system oc adm policy add-scc-to-user anyuid -z istio-prometheus-service-account -n istio-system

oc adm policy add-scc-to-user privileged -z default -n bookinfo

下载istio的包:

curl -L https://git.io/getLatestIstio | sh -

cd istio-0.5.0

export PATH=$PWD/bin:$PATH

安装istio:

kubectl apply -f install/kubernetes/istio.yaml

查看部署的相关istio组件:

截至到目前,istio相关的内容就配好了:

接下来,部署一个应用调用istio,应用的名称叫bookinfo,就是定票信息网站。

这个应用也是一套微服务,有产品描述、评论、评级、详细信息。

不是应用使用一个yaml:samples/bookinfo/kube/bookinfo.yaml,我们看一下这个yaml的主要内容:

我们看一下文件中对详细信息服务的定义:

查看评级服务的定义:

评论服务:

查看产品定义:

yaml文件的最后部分,是调用istio ingress策略的描述:

所以,在istio模式下,对于开发人员而言,不用再过多考虑PaaS基础架构层面的东西。

通过yaml文件部署微服务:

oc adm policy add-scc-to-user privileged -z default -n bookinfo

配置route:

oc expose svcproductpage --name=productpage --path=/productpage--hostname=productpage-bookinfo.example.com

oc expose svc productpage --name=productpage-login --path=/login--hostname=productpage-bookinfo.example.com

接下来,设置ingress路径:

oc get routes productpage -o jsonpath='{.spec.host}'

把Gateway的URL设置成productpage-istio-system.apps.example.com

通过浏览器访问应用:

访问normal user,可以看到用户是json,显示的信息是莎士比亚的作品“错误喜剧”的票据信息,包括预定信息、话剧评论等。

接下来,我们展示如何在线更换路由策略。我们更换的路由策略,实际上就是微服务之间相互调用的策略。

在这个实验中,有多个routes相关的yaml文件。

在没有路由的情况下,页面展示如下(将已有路由删除),里面没有评论相关内容,因为微服务之前的路由被删除了:

创建并使用V1版本的路由:

浏览器访问页面如下(已经出现了评论,但没有出现rating):

创建V3版本的路由:然后将路由在线替换到V3:

重新访问页面(已经可以看到rating的信息):

同样,我们可以设置在多个版本路由之间的访问比率:

然后我们访问页面,在线点击页面刷新:

刷新一次:

再刷新一次(页面回来了):

也就是说,我们可以通过简单的替换路由的方式,改变微服务之间的调用关系。

在Istio中,我们可以部署prometheus、Metrics、Tracing,这些都是istio的addson:

oc apply -f prometheus.yaml

oc expose svc prometheus

oc apply -n istio-system -fhttps://raw.githubusercontent.com/jaegertracing/jaeger-kubernetes/master/all-in-one/jaeger-all-in-one-template.yml

oc expose -nistio-system deployment jaeger-deployment --name=jaeger --port=16686

oc expose svc jaeger

然后可以看到丰富的页面:

原文发布于微信公众号 - 大魏分享(david-share)

原文发表时间:2018-02-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT技术精选文摘

CDN日志实时分析

CDN(Content Delivery Network),内容分发网络)是互联网网站、应用上极其重要的基础设施,通过CDN,终端用户可直接从边缘节点访问各种图...

4084
来自专栏大史住在大前端

一统江湖的大前端(3) DOClever——你的postman有点low

有了Mock服务器和Excel的文档说明后,相信大家的沟通效率会比以前提升很多,但仍然被沟通占据着绝大部分开发时间,常常遇到的情况会有:

1505
来自专栏EAWorld

DevOps平台中的自动化部署框架设计

本文目录: 一、背景 二、我们的需求是什么? 三、概念澄清 四、概念模型 五、总体设计 六、关键点设计 七、总结 一、背景 说到自动化部署,大家肯定都会想到一些...

5064
来自专栏Java技术分享

RBAC新解:基于资源的权限管理(Resource-Based Access Control)

本文讨论以角色概念进行的权限管理策略及主要以基于角色的机制进行权限管理是远远不够的。同时我将讨论一种我认为更好的权限管理方式。 什么是角色 当说到程序的权限管理...

6647
来自专栏搜云库

分布式和集群区别?什么是云计算平台?分布式的应用场景?

分布式是指将一个业务拆分不同的子业务,分布在不同的机器上执行,集群是指多台服务器集中在一起,实现同一业务,可以视为一台计算机,一个云计算平台,就是通过一套软件系...

2555
来自专栏开发与安全

建议程序员都读一读的31篇论文系列笔记(1~2)

序:前几日网上偶然看到”程序员必读论文系列“,顺便搜了一下,发现有多个版本共31篇,不过看起来都不错,故准备花时间都读一下,可以拓宽下视野。来源论文题目主要参考...

2360
来自专栏张戈的专栏

解决Linux修改密码报PAM authentication failed错误

最近接到一个运维开发任务,需要开发一个帐号管理系统,对手头三千多台 Linux 服务器的 root 帐号进行批量系统的管理,实现定期修改 root 为随机密码并...

4899
来自专栏即时通讯技术

腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面

我们常常会听说,某个互联网应用的服务器端系统多么牛逼,比如QQ、微信、淘宝。那么,一个大型互联网应用的服务器端系统,到底牛逼在什么地方?为什么海量的用户访问,会...

1782
来自专栏纯洁的微笑

不懂高性能的负载均衡设计?没关系,架构师带你飞

在软件系统的架构设计中,对集群的负载均衡设计是作为高性能系统优化环节中必不可少的方案。负载均衡本质上是用于将用户流量进行均衡减压的,因此在互联网的大流量项目中,...

862
来自专栏CSDN技术头条

Autodesk基于Mesos的通用事件系统架构

【编者按】本文由Autodesk Cloud软件架构师Olivier Paugam撰写,解释了如何集合Mesos、Kafka、RabbitMQ、Akka、Spl...

2115

扫码关注云+社区