标签 Golang 下的文章

TB一周萃选[第4期]

本文是首发于个人微信公众号的文章“TB一周萃选[第4期]”的归档。

img{512x368}

孩子,我要求你读书用功,不是因为我要你跟别人比成绩,而是因为,我希望你将来会拥有选择的权利,选择有意义、有时间的工作,而不是被迫谋生。当你的工作在你心中有意义,你就有成就感。当你的工作给你时间,不剥夺你的生活,你就有尊严。成就感和尊严,给你快乐。——龙应台 《亲爱的安德烈》

这两天中原大地的一场大雪正式宣告了深冬的到来。小寒节气已过,我们即将经历“三九天”的严寒。不过在这种寒冷的天气下,有一群人却不以为然,他们仍然绽放着天真无邪的笑脸,那就是低年级的孩子们,因为寒假来了

寒假意味着孩子们的阶段性“解脱”,因为中国孩子的学习是很辛苦的,而且这种“辛苦程度”丝毫没有减弱的趋势。就在刚才开车回家的路上还碰到一辆高中放学的校车,此时的时间已经指向了晚上20:30。这勾起了我高中时代的回忆,只不过那时我没有校车坐,而是自己骑车披星戴月地上下学。现在的我作为一名家长或多或少还是了解一些小学教育的实际情况的。就拿我家闺女来说吧,(市重点)小学二年级学生,平时还好些,一到期末复习阶段(一般提前一个月课程就学完了),几乎每天都在“刷题”,有时一天能刷五六张“大卷纸”。多么美好的校园童年时光,就在这“题海”中消耗了!

不得不承认,近三十年来,中国教育在硬件设施、教育普及程度是大幅提升了,但教育理念和方式方法依旧落后,甚至原地踏步。我的一种赶脚:中国现在不缺顶尖科学家、不缺顶尖工程师,不缺顶尖的工匠,唯独缺少的是顶尖的、能够影响社会、能够影响领导层决策的教育大家。

寒假即将开始,希望像我闺女一样的众多小朋友们能在这个寒假中开开心心地做一些自己想做的事情。

img{512x368}

一、一周文章精粹

1. C语言当选2017 TIBOE年度编程语言

时间飞逝!大脑中还满满是去年Go语言当选TIBOE年度编程语言的情景。在刚刚公布的2017年TIBOE年度编程语言中,老当益壮的C语言战胜了新秀Kotlin当选年度语言。C语言的当选,一方面反映了其他主流编程语言在2016年的表现不是很给力,另外一方面也说明了快速发展的制造行业、智能机器行业中,C语言的应用十分广泛。

img{512x368}

2. The Why of Go

Travis CI的Infrastructure工程师Carmen Andoh 从编程语言发展演化的角度讲述了Go的诞生的来龙去脉、Go的典型特性(并发、GC等)的设计考量及与其他主流语言的对比,137页的slides,内容很丰富。

原文链接:“The Why of Go”

3. Go 1.10解读

这是Gopher Academy BlogAdvent 2017系列的倒数第二篇文章,由gopherconeu和LondonGophers的联合发起人Florin Pățan(dlsniper)撰文对即将发布的Go 1.10的变化做了详尽说明,有些类似Go 1.10 release notes,但又有不同。

原文链接:“Go 1.10″

4. 使用istio治理微服务入门

做了一年多微服务开发,感受到了微服务的好,也困惑于微服务治理之痛。Service Mesh概念的出现,尤其是istio项目的发布让我眼前一亮。迎着2018年第一缕阳光,我亲自动手验证了如何使用istio治理微服务,虽说还不成熟,但未来可期。

原文链接:“使用istio治理微服务入门”

img{512x368}

5. 2018,关于区块链的18个预测

2017年,比特币价格像坐上了火箭,年底冲破20000美元大关。这让比特币背后的技术-区块链再次成为人们关注的焦点。国外专业人士提出了关于区块链在2018的18个预测,建议大家不妨看看,不要失去下一个风口哦!

原文链接:“18 Blockchain Predictions for 2018”

img{512x368}

6. Kubernetes入门教程

这是由一位Google Cloud Platform的员工编写的Kubernetes入门教程!

原文链接:“Kubernetes 101: Pods, Nodes, Containers, and Clusters”

img{512x368}

二、一周资料分享

1. Conduit官方文档中文版

在istio项目发布之后,service mesh概念的提出者、Buoyant公司的William Morgan在Kubecon 2017 austin大会上宣布发布Conduit项目。Conduit是Buoyant公司继linkerd之后的第二代专门面向Kubernetes的超轻量Service Mesh开源项目,它的控制平台由Go实现,数据平面则由Rust实现。这也是buoyant公司在service mesh针对istio项目的反制措施。servicemesh中文社区对conduit文档做了翻译。

资料分享链接:“Conduit官方文档中文版”

三、一周工具推荐

1. Android上运行linux环境的神器:Termux

Termux是一个Android terminal emulator,可以像那些terminal工具一样,提供基本的shell操作命令;除此之外它还可以提供一套模拟的Linux环境,你可以在无需root、无需root、无需root的情况下,像在PC linux环境下一样进行各种Linux操作,包括使用apt工具进行安装包管理、定制shell、访问网络、编写源码、编译和运行程序,甚至将手机作为反向代理、负载均衡服务器或是Web服务器,又或是做一些羞羞的hack行为等。

工具链接:Termux

img{512x368}

四、一周图书推荐

1. 21本关于开源的必读书单

2017岁尾,Linux Foundation上发表了一篇博客,给出了一份开源项目开发者、爱好者、企业开源程序负责人必读的书单。这些书涵盖开源项目开发、组织、工具使用、开源项目使用、社区维护、商业模式等诸多领域。

书单链接:“The Essential Open Source Reading List: 21 Must-Read Books”


我的联系方式:

微博:http://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

使用istio治理微服务入门

近两年微服务架构流行,主流互联网厂商内部都已经微服务化,初创企业虽然技术积淀不行,但也通过各种开源工具拥抱微服务。再加上容器技术赋能,Kubernetes又添了一把火,微服务架构已然成为当前软件架构设计的首选。

但微服务化易弄,服务治理难搞!

一、微服务的“痛点”

微服务化没有统一标准,多数是进行业务领域垂直切分,业务按一定的粒度划分职责,并形成清晰、职责单一的服务接口,这样每一块规划为一个微服务。微服务之间的通信方案相对成熟,开源领域选择较多的有RPC或RESTful API方案,比如:gRPCapache thrift等。这些方案多偏重于数据如何打包、传输与解包,对服务治理的内容涉及甚少。

微服务治理是头疼的事,也是微服务架构中的痛点治理这个词有多元含义,很难下达一个精确定义,这里可以像小学二年级学生那样列出治理的诸多近义词:管理、控制、规则、掌控、监督、支配、规定、统治等。对于微服务而言,治理体现在以下诸多方面:

  • 服务注册与发现
  • 身份验证与授权
  • 服务的伸缩控制
  • 反向代理与负载均衡
  • 路由控制
  • 流量切换
  • 日志管理
  • 性能度量、监控与调优
  • 分布式跟踪
  • 过载保护
  • 服务降级
  • 服务部署与版本升级策略支持
  • 错误处理
  • … …

从微服务治理角度来说,微服务其实是一个“大系统”,要想将这个大系统全部落地,绝非易事,尤其是之前尚没有一种特别优雅的技术方案。多数方案(比如:dubbogo-kit等。)都或多或少地对应用逻辑有一定的侵入性,让业务开发人员不能只focus到业务本身,还要关心那些“治理”逻辑。并且市面上内置了微服务治理逻辑的框架较少,且很多编程语言相关。这种情况下,大厂多选择自研或基于某个框架改造,小厂一般只能“东拼西凑”一些“半成品”凑合着使用,就这样微服务也走过了若干年。

二、Service Mesh横空出世,istio带来“福音”

我不知道在没有TCP/IP协议的年代,主机和主机之间的应用通信时是否需要应用关心底层通信协议实现逻辑。但是和TCP/IP诞生的思想类似,在微服务使用多年后,人们发现需要独立地抽象出一层逻辑网络,专门用于“微服务通信与治理策略的落地”,让应用只关心业务,把服务治理的事情全部交由“这一层”去处理。

img{512x368}
图:传统微服务之间的微服务治理逻辑的位置

img{512x368}
图:微服务治理逻辑被独立出来之后的位置

由“Service Govern Logic”这一层组成的逻辑网络被定义为service mesh,每个微服务都包含一个service mesh的端点。

“Service Mesh”概念还非常年轻,这个词在国内被翻译为“服务网格”或“服务啮合层”,我们这里就用Service Mesh这个英文词。这里摘录一下ServiceMesh中文社区上的一篇名为“年度盘点2017之Service Mesh:群雄逐鹿烽烟起”的文章中对Service Mesh概念的回顾:

  • 在 2016 年年初,“Service Mesh”还只是 Buoyant 公司的内部词汇,而之后,它开始逐步走向社区:
  • 2016 年 9 月 29 日在 SF Microservices 上,“Service Mesh”这个词汇第一次在公开场合被使用。这标志着“Service Mesh”这个词,从 Buoyant 公司走向社区。
  • 2016 年 10 月,Alex Leong 开始在 Buoyant 公司的官方 Blog 中连载系列文章“A Service Mesh for Kubernetes”。随着“The Services must Mesh”口号的喊出,Buoyant 和 Linkerd 开始 Service Mesh 概念的布道。
  • 2017 年 4 月 25 日,William Morgan 发布博文“What’s a service mesh? And why do I need one?”。正式给 Service Mesh 做了一个权威定义。

而Service Mesh真正引起大家关注要源于istio项目的开源发布。为什么呢?个人觉得还是因为“爹好”!istio项目由Google、IBM共同合作创建,lyft公司贡献了envoy项目将作为istio service mesh的data panel。Google、IBM的影响力让Service Mesh概念迅速传播,同时也让大家认识到了istio项目在service mesh领域的重要性,于是纷纷选择积极支持并将自己的产品或项目与istio项目集成。

istio项目是service mesh概念的最新实现,旨在所有主流集群管理平台上提供service mesh层,初期以实现Kubernetes上的服务治理层为目标。它由控制平面和数据平面组成(是不是感觉和SDN的设计理念相似啊)。控制平面由Go语言实现,包括pilot、mixer、auth三个组件;数据平面功能暂由envoy在pod中以sidecar的部署形式提供。下面是官方的架构图:

img{512x368}
图:istio架构图(来自官网)

sidecar中envoy代理了pod中真正业务container的所有进出流量,并对这些流量按照控制平面设定的“治理逻辑”进行处理。而这一切对pod中的业务应用是透明的,开发人员可以专心于业务逻辑,而无需再关心微服务治理的逻辑。istio代表的service mesh的设计理念被认为是下一代“微服务统一框架”,甚至有人认为是微服务框架演化的终点。

istio于2017 年 5 月 24 日发布了0.1 release 版本,截至目前为止istio的版本更新到v0.4.0,演进速度相当快,不过目前依然不要用于生产环境,至少要等到1.0版本发布吧。但对于istio的早期接纳者而言,现在正是深入研究istio的好时机。在本篇的接下来内容中,我们将带领大家感性的认识一下istio,入个门儿。

三、istio安装

istio目前支持最好的就是kubernetes了,因此我们的实验环境就定在kubernetes上。至于版本,istio当前最新版本为0.4.0,这个版本据说要k8s 1.7.4及以上版本用起来才不会发生小毛病:)。我的k8s集群是v1.7.6版本的,恰好满足条件。下面是安装过程:(Node上的os是ubuntu 16.04)

# wget -c https://github.com/istio/istio/releases/download/0.4.0/istio-0.4.0-linux.tar.gz

解压后,进入istio-0.4.0目录,

# ls -F
bin/  install/  istio.VERSION  LICENSE  README.md  samples/

# cat istio.VERSION
# DO NOT EDIT THIS FILE MANUALLY instead use
# install/updateVersion.sh (see install/README.md)
export CA_HUB="docker.io/istio"
export CA_TAG="0.4.0"
export MIXER_HUB="docker.io/istio"
export MIXER_TAG="0.4.0"
export PILOT_HUB="docker.io/istio"
export PILOT_TAG="0.4.0"
export ISTIOCTL_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/istioctl"
export PROXY_TAG="0.4.0"
export ISTIO_NAMESPACE="istio-system"
export AUTH_DEBIAN_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/deb"
export PILOT_DEBIAN_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/deb"
export PROXY_DEBIAN_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/deb"
export FORTIO_HUB="docker.io/istio"
export FORTIO_TAG="0.4.2"

# cd install/kubernetes

我们先不用auth功能,因此使用istio.yaml这个文件进行istio组件安装:

# kubectl apply -f istio.yaml
namespace "istio-system" created
clusterrole "istio-pilot-istio-system" created
clusterrole "istio-initializer-istio-system" created
clusterrole "istio-mixer-istio-system" created
clusterrole "istio-ca-istio-system" created
clusterrole "istio-sidecar-istio-system" created
clusterrolebinding "istio-pilot-admin-role-binding-istio-system" created
clusterrolebinding "istio-initializer-admin-role-binding-istio-system" created
clusterrolebinding "istio-ca-role-binding-istio-system" created
clusterrolebinding "istio-ingress-admin-role-binding-istio-system" created
clusterrolebinding "istio-sidecar-role-binding-istio-system" created
clusterrolebinding "istio-mixer-admin-role-binding-istio-system" created
configmap "istio-mixer" created
service "istio-mixer" created
serviceaccount "istio-mixer-service-account" created
deployment "istio-mixer" created
customresourcedefinition "rules.config.istio.io" created
customresourcedefinition "attributemanifests.config.istio.io" created
... ...
customresourcedefinition "reportnothings.config.istio.io" created
attributemanifest "istioproxy" created
attributemanifest "kubernetes" created
stdio "handler" created
logentry "accesslog" created
rule "stdio" created
metric "requestcount" created
metric "requestduration" created
metric "requestsize" created
metric "responsesize" created
metric "tcpbytesent" created
metric "tcpbytereceived" created
prometheus "handler" created
rule "promhttp" created
rule "promtcp" created
kubernetesenv "handler" created
rule "kubeattrgenrulerule" created
kubernetes "attributes" created
configmap "istio" created
customresourcedefinition "destinationpolicies.config.istio.io" created
customresourcedefinition "egressrules.config.istio.io" created
customresourcedefinition "routerules.config.istio.io" created
service "istio-pilot" created
serviceaccount "istio-pilot-service-account" created
deployment "istio-pilot" created
service "istio-ingress" created
serviceaccount "istio-ingress-service-account" created
deployment "istio-ingress" created
serviceaccount "istio-ca-service-account" created
deployment "istio-ca" created

注:我还曾在k8s v1.7.3上安装过istio 0.3.0版本,但在创建组件时会报下面错误(这个错误可能会导致后续addon安装后工作不正常):

unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric

安装后,我们在istio-system这个namespace下会看到如下pod和service在运行(由于istio的各个组件的image size都不小,因此pod状态变为running需要一丢丢时间,耐心等待):

# kubectl get pods -n istio-system
NAME                             READY     STATUS    RESTARTS   AGE
istio-ca-1363003450-jskp5        1/1       Running   0          3d
istio-ingress-1005666339-c7776   1/1       Running   4          3d
istio-mixer-465004155-twhxq      3/3       Running   24         3d
istio-pilot-1861292947-6v37w     2/2       Running   18         3d

# kubectl get svc -n istio-system
NAME            CLUSTER-IP       EXTERNAL-IP   PORT(S)                                                   AGE
istio-ingress   10.98.10.87      <pending>     80:31759/TCP,443:25804/TCP                         4d
istio-mixer     10.109.244.155   <none>        9091/TCP,15004/TCP,9093/TCP,9094/TCP,9102/TCP,9125/UDP,42422/TCP   4d
istio-pilot     10.105.80.55     <none>        15003/TCP,443/TCP                                              4d

istio安装成功!

四、服务治理策略验证

接下来我们来用几个例子验证一下istio在服务治理方面的能力!(istio自带一些完整的例子,比如bookinfo,用于验证服务治理的能力,但这里先不打算用这些例子)

1、验证环境和拓扑

我们先来看一下验证环境的示意图:
img{512x368}

我们看到在service mesh中部署了两个service: server_a和service_b,前者调用后者完成某项业务,后者则调用外部服务完成业务逻辑。

  • service_a: 模拟pay服务,在收到client请求后,进行pay处理,并将处理结果通过service_b提供的msg notify服务下发给user。该服务的endpoint为/pay;
  • service_b: 模拟notify服务,在收到service_a请求后,将message转发给external service,完成notify逻辑。该服务的endpoint为/notify;
  • external service: 位于service mesh之外。
  • client:我们使用curl模拟。

img{512x368}

我们先来部署service_a和service_b的v0.1版本:

以service_a的部署为例, service_a的deployment文件如下:

//svca-v0.1.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: svca
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: svca
        version: v0.1
    spec:
      containers:
      - name: svca
        image: docker.io/bigwhite/istio-demo-svca:v0.1
        imagePullPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: svca
  labels:
    app: svca
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
  selector:
    app: svca

注意,我们部署service_a时不能直接使用kubectl apply -f svca-v0.1.yaml,而是要apply经过istioctl(需将istio安装目录下的bin放入PATH)处理过的yaml,以注入sidecar容器。当然也可以配置为自动为每个k8s启动的pod注入sidecar,但我们这里没有使用自动注入。我们执行下面命令:

# kubectl apply -f <(istioctl kube-inject -f svca-v0.1.yaml)
deployment "svca" created
service "svca" created

# kubectl get pods
NAME                               READY     STATUS    RESTARTS   AGE
svca-1997590752-tpwjf              2/2       Running   0          2m

同样的方法,我们来创建svcb:v0.1:

# kubectl apply -f <(istioctl kube-inject -f svcb-v0.1.yaml)
deployment "svcb" created
service "svcb" created

我们看到istio向每个pod中插入一个sidecar container,这个就是前面说的envoy,只不过container名字为istio-proxy。

接下来,我们把那个external service启动起来:

# nohup ./msgd > 1.log & 2>&1
[1] 9423

实验环境ok了。下面我们来验证一下业务是否是通的。

2、egress rule

按照之前我们的设定,我们使用curl去访问service_a服务的/pay端点,我们查看一下svca服务的ip和端口:

# kubectl get svc
NAME               CLUSTER-IP       EXTERNAL-IP   PORT(S)
svca               10.105.38.238    <none>        80/TCP                                         9h
svcb               10.105.119.194   <none>        80/TCP                                         9h

我们访问一下svca服务,svca的服务地址可以通过kubectl get svc查到:

# curl {svca_ip}/pay

查看svca和svcb的日志:

//service_a的日志:

service_a:v0.1 is serving the request...
service_a:v0.1 pays ok
&{500 Internal Server Error 500 HTTP/1.1 1 1 map[X-Content-Type-Options:[nosniff] Date:[Tue, 02 Jan 2018 15:41:50 GMT] Content-Length:[66] Content-Type:[text/plain; charset=utf-8]] 0xc420058d40 66 [] false false map[] 0xc4200eaf00 <nil>}
service_a:v0.1 notify customer ok

// service_b的日志:
&{GET /notify?msg=service_a:v0.1-pays-ok HTTP/1.1 1 1 map[User-Agent:[Go-http-client/1.1] Accept-Encoding:[gzip]] {} <nil> 0 [] false svcb map[] map[] <nil> map[] 127.0.0.1:58778 /notify?msg=service_a:v0.1-pays-ok <nil> <nil> <nil> 0xc4200fa3c0}
service_b:v0.1 is serving the request...
service_b:v0.1 send msg error: Get http://10.100.35.27:9997/send?msg=service_a:v0.1-pays-ok: EOF

我们看到service_a和service_b都返回了错误日志(注意:go http get方法对于non-2xx response不会返回错误,我们只是看到了response中的500状态码才意识到错误的存在)。其中源头在service_b,原因是其连不上那个external service!那么为什么连不上external service呢?这是由于缺省情况下,启用了Istio的服务是无法访问外部URL的,这是因为Pod中的iptables把所有外发传输都转向到了Sidecar代理,而这一代理只处理集群内的访问目标。因此位于service mesh内的服务svcb无法访问外部的服务(msgd),我们需要显式的添加egressrule规则:

我们创建一个允许svcb访问外部特定服务的EgressRule:

//rules/enable-svcb-engress-rule.yaml

apiVersion: config.istio.io/v1alpha2
kind: EgressRule
metadata:
  name: enable-svcb-engress-rule
spec:
  destination:
    service: 10.100.35.27
  ports:
    - port: 9997
      protocol: http

使规则生效:

# istioctl create -f enable-svcb-engress-rule.yaml
Created config egress-rule/default/enable-svcb-engress-rule at revision 30031258

这时你再尝试curl svca,我们可以看到msgd的日志中出现了下面的内容:

2018/01/02 23:58:16 &{GET /send?msg=service_a:v0.1-pays-ok HTTP/1.1 1 1 map[X-Ot-Span-Context:[2157e7ffb8105330;2157e7ffb8105330;0000000000000000] Content-Length:[0] User-Agent:[Go-http-client/1.1] X-Forwarded-Proto:[http] X-Request-Id:[13c3af6e-2f52-993d-905f-aa6aa4b57e2d] X-Envoy-Decorator-Operation:[default-route] X-B3-Spanid:[2157e7ffb8105330] X-B3-Sampled:[1] Accept-Encoding:[gzip] X-B3-Traceid:[2157e7ffb8105330] X-Istio-Attributes:[Ch8KCXNvdXJjZS5pcBISMhAAAAAAAAAAAAAA//8KLgAMCjoKCnNvdXJjZS51aWQSLBIqa3ViZXJuZXRlczovL3N2Y2ItMjAwODk3Mzc2OS1ncTBsaC5kZWZhdWx0]] {} <nil> 0 [] false 10.100.35.27:9997 map[] map[] <nil> map[] 10.100.35.28:38188 /send?msg=service_a:v0.1-pays-ok <nil> <nil> <nil> 0xc4200584c0}
2018/01/02 23:58:16 Msgd is serving the request...
2018/01/02 23:58:16 Msgd recv msg ok, msg= service_a:v0.1-pays-ok

说明Svcb到外部服务的通信被打通了!

3、迁移流量到新版本svcb:v0.2

我们经常有这样的需求,当svcb运行一段时间后,svcb添加了新feature,版本要升级到v0.2了,这时我们会部署svcb:v0.2,并将流量逐步切到v0.2上。

我们先来部署一下svcb:v0.2:

// svcb-v0.2.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: svcb-v0.2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: svcb
        version: v0.2
    spec:
      containers:
      - name: svcb
        image: docker.io/bigwhite/istio-demo-svcb:v0.2
        imagePullPolicy: Always

我们可以看到,服务名不变,但版本的label变成了v0.2,我们来执行这次部署:

# kubectl apply -f <(istioctl kube-inject -f svcb-v0.2.yaml)
deployment "svcb-v0.2" created

# kubectl get pods
NAME                               READY     STATUS    RESTARTS   AGE
svca-1997590752-pq9zg              2/2       Running   0          9h
svcb-2008973769-gq0lh              2/2       Running   0          9h
svcb-v0.2-3233505404-0g55w         2/2       Running   0          1m

svcb服务下又增加了一个endpoint:

# kubectl describe svc/svcb

.... ...
Selector:        app=svcb
Type:            ClusterIP
IP:            10.105.119.194
Port:            <unset>    80/TCP
Endpoints:        10.40.0.28:8080,10.46.0.12:8080
... ...

此时,如果按照k8s的调度方式,v0.1和v0.2版本的两个svcb pod应该1:1均衡地承载流量。为了方便查看流量分布,我们将每个版本的svcb的pod副本数量都扩展为2个(replicas: 2),这样service mesh中一共会有4个 svcb endpoints。

通过curl访问svca注入流量后,我们发现流量都集中在一个svcb:v0.2的pod上,并且长时间没有变化。我们通过下面的route rule规则来尝试将流量在svcb:v0.1和svcb:v0.2之间1:1均衡:

// route-rules-svcb-v0.2-50.yaml
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: route-rules-svcb
spec:
  destination:
    name: svcb
  precedence: 1
  route:
  - labels:
      version: v0.1
    weight: 50
  - labels:
      version: v0.2
    weight: 50

# istioctl create -f route-rules-svcb-v0.2-50.yaml
Created config route-rule/default/route-rules-svcb at revision 30080638

按照istio文档中的说法,这个规则的生效需要一些时间。之后我们注入流量,发现流量切换到svcb:v0.1的一个pod上去了,并且很长一段时间不曾变化,未均衡到svcb:v0.2上去。

我们更新一下route rule,将流量全部切到svcb:v0.2上去:

//route-rules-svcb-v0.2-100.yaml
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: route-rules-svcb
spec:
  destination:
    name: svcb
  precedence: 1
  route:
  - labels:
      version: v0.2
    weight: 100

# istioctl replace -f route-rules-svcb-v0.2-100.yaml
Updated config route-rule/default/route-rules-svcb to revision 30082944

我们用istio的replace命令更新了规则:route-rules-svcb。更新后,再次注入流量,这回流量重新集中在svcb:v0.2的一个pod上了,再过一段时间另外一个svcb:v0.2的pod上才有了一些流量。但svcb:v0.1上不再有流量,这个切换是成功的。

在k8s的service的负载均衡中,k8s就利用了iptables的概率转发(random –probability 0.5),因此这种流量均衡并非是精确的,只有在长时间大量流量经过后,才能看到流量的分布与设定的权重是相似的,可能istio也是如此,这里仅是入门,就不深入挖掘了。

当然istio在路由规则设施方面的“能耐”远不止上面例子中所展示的那样,如果要悉数列出,那本文的长度可是要爆掉了。有兴趣的朋友可以去翻看官方文档

五、插件安装

istio的强大微服务治理能力还体现在其集成了grafanaprometheus、servicegraph、zipkin等addons,应用程序无需做任何改动,就可以具有数据收集、度量与可视化的监控能力、服务的分布式跟踪能力等。我们可以在istio的安装包中找到这些addons的安装文件,我们来逐一试试。

1、prometheus & grafana

我们先来安装一下prometheus 和 grafana插件(位于istio-0.4.0/install/kubernetes/addon下面):

# kubectl apply -f prometheus.yaml
configmap "prometheus" created
service "prometheus" created
deployment "prometheus" created

# kubectl apply -f grafana.yaml
service "grafana" created
deployment "grafana" created

# kubectl get pods -n istio-system
NAME                             READY     STATUS    RESTARTS   AGE
grafana-3617079618-zpglx         1/1       Running   0          5m
prometheus-168775884-ppfxr       1/1       Running   0          5m
... ...

# kubectl get svc -n istio-system
NAME            CLUSTER-IP       EXTERNAL-IP   PORT(S)            AGE
grafana         10.105.21.25     <none>        3000/TCP                     16m
prometheus      10.103.160.37    <none>        9090/TCP                16m
... ...

浏览器中输入prometheus的服务地址http://10.103.160.37:9090,访问prometheus:

img{512x368}

点击菜单项:status -> targets,查看各个target的状态是否正常:

img{512x368}

如果像上图所示那样,各个target都是up状态,那就说明istio运行时ok的。否则请参考istio troubleshooting中的内容对istio逐一进行排查,尤其是istio-mesh这个Target在istio-0.3.0+kubernetes 1.7.3的环境中就是Down的状态。

浏览器输入grafana的服务地址:http://10.105.21.25:3000/,打开grafana面板:

img{512x368}

切换到Istio Dashboard,并向istio service mesh注入流量,我们会看到仪表盘变化如下:

img{512x368}

img{512x368}

2、servicegraph

servicegraph插件是用来查看服务调用关系的,我们来创建一下该组件:

# kubectl apply -f servicegraph.yaml
deployment "servicegraph" created
service "servicegraph" created

# kubectl get svc -n istio-system
NAME            CLUSTER-IP       EXTERNAL-IP   PORT(S)                 AGE
servicegraph    10.108.245.21    <none>        8088/TCP                     52s
... ...

创建成功后,向service mesh网络注入流量,然后访问servicegraph:http://{servicegraph_ip}:8088/dotviz,在我的环境里,我看到的图示如下:

img{512x368}

调用关系似乎有些乱,难道是我在程序使用的调用方法不够标准?:(

3、zipkin

istio集成了zipkin,利用zipkin我们可以做分布式服务调用的追踪。之前自己曾经搭建过基于jaegeropentracing的分布式调用服务,十分繁琐。并且要想使用tracing,对应用代码的侵入必不可少。

我们安装一下zipkin addon:

# kubectl apply -f zipkin.yaml
deployment "zipkin" created
service "zipkin" created

# kubectl get svc -n istio-system
NAME            CLUSTER-IP       EXTERNAL-IP   PORT(S)                  AGE
zipkin          10.105.7.219     <none>        9411/TCP                             1h

我们访问以下zikpin的UI,通过浏览器打开http://{zipkin_service_ip}:9411。

img{512x368}

接下来,我们向service mesh注入一些流量,然后再zipkin首页的“服务名”下拉框中选择”svcb”,查找跟踪情况:

img{512x368}

我们看到:在没有对svca, svcb做任何修改的情况下,我们依然可以在zipkin中找到svcb相关的调用。点击其中一个trace,可以查看细节:

img{512x368}

当然如果你想做内容更为丰富的、更为强大的跟踪,可能需要在应用代码中做些配合,具体可以参见:istio的分布式跟踪

六、小结

istio项目诞生不到一年,目前离成熟还远。快速积极开发可能会导致istio的接口和实现机制都会发生很大的变化,因此本文不能保证内容将适用于后续所有istio的发布版本

本文涉及到的源码在这里可以下载到,demo service的镜像可以在我的docker hub上pull


微博:@tonybai_cn
微信公众号:iamtonybai
github.com: https://github.com/bigwhite

微信赞赏:
img{512x368}

TB一周萃选[第3期]

本文是首发于个人微信公众号的文章“TB一周萃选[第3期]”的归档。

img{512x368}

 《岁旦》

   宋伯仁 宋代诗人

  居间无贺客,早起只如常。桃版随人换,梅花隔岁香。
  春风回笑语,云气卜丰穰。柏酒何劳劝,心平寿自长。

本期萃选是2017年的最后一期,也是迎接2018新年“承前启后”的一期。

对于现代中国人来说,公历新年又称为“元旦”。但稍有些历史常识的朋友都会知道:此“元旦”与中国古时的那个“元旦”有所不同。古代中国人把农历大年初一称为元旦,传说古时“元旦”在距今4000多年前“尧舜禹”的时候就已经有了。1911年辛亥革命成功后,当时孙中山领导的国民政府把农历的大年初一称春节,把公历1月1日称元旦,这就是现在元旦的由来。现代中国的元旦,在世界更广的范围内被更多称为“新年”,是全世界人们的一个共同的节日。在这样的一个节日里,人们家庭团聚,亲友重逢,倾诉过往,憧憬新年,祈求平安。

节日,似乎是群居生物的一种典型的行为表现形式,动物有之(可能是以我们无法理解的形式),人类也在进化的几十万年(又或更长的时间)内设定了大大小小的各种节日。这是作为群居动物的人类的一个重要需求,是进化数十万年后依然保留的最古老的基因所表现出的行为倾向。人类通过“节日”来“蓄力”,以迎接新的挑战!不同的是,古代人类挑战的是凶恶的生存环境,现代人类抗争的是现代生活无形的“生活压力”。

不过,人类从来没有屈服于困难!近期火热的电影《芳华》向我们直观生动地阐释了这一点,让我们更加明白生活的真谛,珍惜与家人、爱人、朋友在一起的时光,享受现在的生活,乐观的面对人生。

img{512x368}

一、一周文章精粹

1. Go初学者的类型系统入门

对于Go初学者而言,尤其是对那些从OO语言转到Go的开发者,在他们大脑中根深蒂固的OO type hierachy不见了,这让他们似乎一下子失去了着力点或抓手。原Go core team成员JBD撰文阐述了Go类型系统的特点,诸如:流程优先、嵌入不是继承、多态、没有构造函数、没有范型等。

原文链接:《The Go type system for newcomers》

2. Go反射详解

Go语言提供了反射(reflect)特性,在标准库中很多常见功能都是用反射实现的,比如:encoding/json、fmt包的Println系列等。但日常编程中,直接使用reflect包的场合并不多。reflect为Go程序员提供了一种在运行时 “陷入” 的机制,使得Go程序具备了直接操作runtime中类型元数据的能力以及在运行时凭空“制造”变量的能力,因此reflect操作是比较“危险”的。

Sidhartha Mani的“Go反射详解”分为两个part,part1主要讲解type与kind的区别、基于reflect包的type和value进行Go原生类型变量的构造和值的析出;part2则是针对复合类型,比如数组、map、struct等类型变量的构造和值的析出进行讲解,思路十分清晰。

原文链接:

《Go Reflection: Creating Objects from Types — Part I (Primitive Types)》
《Go Reflection: Creating Objects from Types — Part II (Composite Types)》

3. 现代网络负载均衡和代理指南

lyft的envoy工程师撰文对高可用分布式网络中的负载均衡和反向代理做了详尽的科普性讲解,内容包含:lb与proxy的区别、L4 lb、L7 lb、lb特性分析、lb的拓扑类型、当前L4-lb技术、L7-lb技术现状的情况、全局lb和集中控制平面等。强烈推荐阅读!

原文链接:《Introduction to modern network load balancing and proxying》

img{512x368}

4. Go编译器内幕

这是由国内一位就职于ARM公司的开发者在Go dev group上发的topic,这位开发者将自己学习和整理了Go compiler的原理(主要针对ARM平台)放在了一篇slide中,并在Go core team的反馈下,对他的slide进行了修正和优化。这份资料对于想深入了解Go compiler的朋友可能是大有裨益的。

原文链接:“Golang Compiler Internals for arm64″

5. 年度盘点2017之Service Mesh:群雄逐鹿烽烟起

在Kubecon&CloudNativeCon 2017上大放异彩后,Service Mesh在国内已经渐入火热阶段。Service Mesh的著名Advocator:数人云的架构师敖小剑年终前发了此文,对service mesh的发展历史、来龙去脉、各方开源项目和厂商势力分析以及未来发展做了回顾和展望。如果你还不知道什么是service mesh,那借此文赶紧上车吧:)

原文链接:“年度盘点2017之Service Mesh:群雄逐鹿烽烟起”

二、一周资料分享

1. Microservice’ing like a unicorn with kubernetes, envoy, and istio

随着传播渠道多元化和传播速度的加快,新技术“火”的速度也变得以前所未有。以Service Mesh概念为例(参考了 “年度盘点2017之Service Mesh:群雄逐鹿烽烟起”):

  • 2016 年 9 月 29 日在 SF Microservices 上,“Service Mesh”这个词汇第一次在公开场合被使用。这标志着“Service Mesh”这个词,从 Buoyant 公司走向社区。
  • 2017 年 4 月 25 日,William Morgan 发布博文“What’s a service mesh? And why do I need one?”。正式给 Service Mesh 做了一个权威定义。
  • 2017 年 5 月 24 日,Istio 0.1 release 版本发布,Google 和 IBM 高调宣讲,社区反响热烈,很多公司在这时就纷纷站队表示支持 Istio。

istio的正式发布,成为了service mesh的一个重要里程碑事件。谁能否认istio不是另一个Google内部技术的开源版本呢,就好比当年Kubernetes的开源。微服务框架走向统一的service mesh似乎成了大势所趋的趋势。无论国内外,对service mesh的研究、开发和试验,甚至是商用都在如火如荼地进行当中。

Redhat架构师Christian Posta近日在自己的博客上放出一份正在构建中的资料:Microservice’ing like a unicorn with kubernetes, envoy, and istio,对envoy和istio的原理与使用进行案例式的详尽说明,同时配有对应的示例源码。对于希望学习service mesh技术的朋友们,这是一份不可多得的资料。

资料分享链接:Microservice’ing like a unicorn with kubernetes, envoy, and istio

img{512x368}

三、一周工具推荐

1. mdp

今天给大家推荐一个比较有Geek赶脚的present工具:mdp

mdp是一款文稿演示工具,与go present工具有些类似,都是以一种类markdown格式的文档作为输入。不同之处,后者是将演示文稿渲染到浏览器中,而mdp工具则是将文稿渲染到terminal中,效果参见下面图示:

img{512x368}

mdp支持标准markdown语法,同时也支持通过一些扩展语法实现的特定渲染效果。mdp同时支持一些快捷键控制命令,比如:h,j,k,l组合的翻页控制等。在Mac上可使用brew工具来install mdp,在其他平台可以通过下载源码并自行编译的方式安装。

工具链接:mdp

四、一周图书推荐

笔者认为人类正在构建支撑未来20-30年支撑人类社会发展的IT技术“有机生命体”,包括:

  • 能量系统(类比于细胞化学反应,提供计算能量) – IT基础设施(云计算、vm、k8s、container)、Cloud Native技术框架:microservice 、service mesh(服务治理网络) 、serverless等。
  • 神经通道 – 基础高速互联网、移动网络、区块链(信用网络)
  • 大脑 – 人工智能、数据与智能算法
  • 肢体与感知 – 机器人、智能交通工具(比如:无人汽车等)、智能硬件、Iot等。

其中区块链技术作为未来社会信用网络的重要基础,IT技术人员都应该认真学习。本期我就推荐一本有关区块链技术的开源书:yesky的《区块链开发指南》。这是一本关于区块链技术的较为系统的开源书。该书探索了区块链概念的来龙去脉,剥茧抽丝,剖析关键技术原理、典型应用场景、分布式系统核心问题,同时讲解了区块链技术的三大典型应用:比特币、以太坊Hyperledger超级账本以及相关应用的开发入门。

开源书链接:《区块链开发指南》
商业纸板图书链接:《区块链原理、设计与应用》


我的联系方式:

微博:http://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:


如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多