开篇​

人生最大的遗憾，是一个人无法同时拥有青春和对青春的感受。

“种完麦子我就往南走”，这是近两年感悟较深的一句话，一位来自于“麦子阿姨”的故事。我们常常说来一次说走就走的旅行，但实际上大多数人都无法做到。生活中总有各种各样的牵绊，让我们无法轻易地放下手中的一切，去追寻内心的渴望。

流年​

2024-2025 是来北京的第6、7个年头，也是本科毕业的第5、6年，应该说是北漂已经7年了，离高中毕业已经整整10年了。时间过得飞快，转眼间又过去了两年。对于时间的流逝之快，这两年感觉尤为明显，快到有时候需要用笔签字写日期的那一刻都会写错年份~

工作​

在25年年初，迎来了职业生涯的再次跳槽。经过深思熟虑，我决定开始新的挑战与机遇。在前司工作了接近三年半的时间，这段经历让我积累和思考了不少关于技术路线与职场等方面的经验与认知。

如何判断一个工作是否适合你，或者说什么是你期望的好工作？我认为，能赚钱、干得开心、能学到东西，同时满足这三点的工作，就是好工作。曾经与一位实习生同事交流时也提到这点，他非常认同。当然了，在现在的就业市场环境下，找到一份同时满足这三点的工作并不容易，很多时候需要靠运气以及在其中做出不断地权衡取舍。

另外重要的一方面，能够在工作中不断接收新的挑战与任务，学以致用，通过自己的努力去完成它们，是个人职业成长、技术提升、心态成熟的关键。

这几年，随着AI技术的迅猛发展，尤其是大模型的兴起，整个技术领域都发生了翻天覆地的变化。国内外都诞生了不少和AI相关的新兴公司和岗位。作为一名技术人员，保持对新技术的敏感度和学习能力显得尤为重要。对个人职业方向而言，AI Infra、AIOps等相关领域无疑是未来发展的重要方向。在未来的工作中，希望能够更多地靠拢这些前沿技术领域，提升自己的竞争力和适应能力。

生活​

出游​

生活上，这两年系统地完成了我们小俩口的一些旅游与出行计划，这两年去了新加坡、泰国、张家口、大同、青岛、苏州、上海、宁夏、内蒙热阿-达达线等地，完成了两次境外旅游（这也是头一次出国旅游）以及多次北京周边的自驾游。旅行的意义不仅在于看风景，更在于体验不同的风土人情，感受这个世界的多样性和美好。

运动​

这两年公路自行车骑行的频率有所下降，但依然保持着在天气合适的情况下坚持骑行的习惯。骑行不仅锻炼了身体，也让我在忙碌的工作之余找到了一种放松的方式。通过骑行，我感受到了风的速度和自由的感觉，这种感觉是无法用言语表达的。

在2024年9月底，和朋友一起完成了北京-天津的单日往返骑行，总骑行里程实际约220公里。这是自行车骑行以来的最长距离挑战，虽然过程艰辛，但最终的成就感让我难以忘怀，也算是对自己的一次挑战和突破，完成了人生中的一个小目标，不留遗憾。

从24年年中开始，我养成了跑步与健身的习惯。25年入冬以来，骑行次数减少，更多地进行了室内的跑步锻炼，这也是我找到的一种能调整自我状态的不错方式。

其他​

这两年身边的同学陆陆续续都结束北漂离开了北京，这是感受最为深切的，不知道自己会在北京待多久，但目前来看，还是希望能多待几年，毕竟这里有更多的机会和资源。

送别了离开北京的同学朋友，也迎来了新朋友，结识了Mia、老王哥、小有财等新朋友，感恩生活中遇到的每一个人。

新的一年我们一起解锁了第一次 Live House 方式的跨年，和年轻的小鲜肉们一起摇摆到凌晨，感受到了不一样的跨年氛围。

最后​

回首过去的两年，感恩生活中的点点滴滴，感恩遇到的每一个充满善意与温暖的人，感恩自己依然保持着对生活的热爱与追求。

你想成为怎样的人，过怎样的生活，只要你不后悔就行。并不是所有人都能在早上七点钟起床的，也别拿一碗饭来衡量一个人胃口的大小。有的人喜欢狼吞虎咽，有的人喜欢细嚼慢咽，允许别人做别人，也允许自己做自己，一岁有一岁的味道，一站有一站的风景，跟着自己的心走就好。不是所有选择都必须要做出正确选项的，只要你想，你可以选择你喜欢的选项，沿途的花会一直开，以后的路也是，祝你也祝我。

30岁后见，老己~

早上通勤路上，看到有文章提到耗子叔，便立马想起2年前耗子叔离世时自己拟下的本文标题，却迟迟未动笔。 落笔之日，适逢耗子叔离世二周年。

与技术人的精神远游​

最早接触左耳朵耗子，是在大学时间折腾 Linux 时，误打误撞访问到耗子叔的博客 CoolShell，当时便被耗子叔的技术才华所吸引，于是便一直关注。

大学毕业参加工作，圈子与认知都在不断发生变化，譬如技术圈子的人彼时应该都用过或听过极客时间，而极客时间当时最为出名的便是耗子叔的专栏——《左耳听风》。

后来得知在此之前，耗子叔已有过相关著作《程序员的练级攻略》。

再后来与耗子叔有交集，是学习浅谈 Prometheus 的数据存储时，参考到耗子叔的创业公司 MegaEase 的B站Up主视频。

芝兰生于空谷，不以无人而不芳。这是耗子叔的座右铭，也是他一生的写照。

耗子叔的博客文章从 2004年开始，到 2023年结束，整整 19年，作为一个技术人，能坚持如此长时间输出高质量内容，实属不易。反观自己，又能坚持到何时？

2023年惊闻耗子叔离世，当时便觉得惋惜，一个技术圈的传奇人物就这样离世了。在当今技术圈，像他这样既深耕技术又贴近现实的引路人，已然难觅踪影。这个时代从不缺乏励志故事和成功典范，但真正能体察普通工程师的困境，并指明切实可行路径的导师却寥寥无几。那些站在聚光灯下的成功人士，往往难以理解普通从业者面临的真实挑战，他们或许不曾体会过缺乏资源和支持的处境。

互联网时代信息泛滥，但经得起时间沉淀的内容屈指可数。耗子叔的诸多洞见，纵使岁月流转，依然能为后来者提供清晰的指引和持续的动力。他的文字如同技术人的精神坐标，无论何时重读，都能让人重新找到前行的方向。我想，技术人的生命价值或许在于：我们写的每一行代码，解决的每一个问题，分享的每一篇心得，都可能成为他人前进路上的垫脚石。就像耗子叔留给我们的精神遗产——那些深入浅出的技术解析，那些发人深省的职业思考，那些历经岁月仍熠熠生辉的真知灼见。

附上一个代码仓库Remembering-Haoel，记录了一些与耗子叔认识、打过交道的人和事。

生如夏花​

耗子叔的离世，加上之前的疫情、以及这几年身边逝去的亲人，促使我不断思考生命的意义。当我们离开时，希望留下怎样的精神遗产？

这种思考并非为了迎合他人眼光，而是帮助我们厘清内心真正珍视的价值。

生命像一场无法回放的直播，没有彩排，没有重来。我们总以为来日方长，却忘了世事无常。那些计划中的旅行，那些想说却未说出口的话，那些被"等有空再说"推迟的相聚，都可能在某一个平凡的午后，永远失去实现的机会。

在日复一日的忙碌中，我们常常忘记生命最本真的模样。清晨的露珠，午后的蝉鸣，傍晚的晚霞，这些最平凡的自然馈赠，往往被我们视而不见。直到某天，当我们突然失去感受这些美好的能力时，才惊觉生命中最珍贵的，从来都不是那些我们拼命追逐的东西。

当我们终将离开时，带不走的不是名利与成就，而是那些曾经温暖过他人的时刻，那些让世界变得更美好的微小改变。“生如夏花之绚烂，死如秋叶之静美”。生命的意义不在于长度，而在于我们是否真正活出了自己的色彩。

背景​

某线上应用部署在ack集群内，用于根据用户定义的http请求项配置，周期性检查http接口的请求响应状态，接口地址为内网或公网，当接口地址为公网时，频繁出现请求超时的报警错误。经过排查发现，在公网请求发生超时的时刻，集群vpc NAT带宽达到上限200Mbps，也就是25MB/s

分析：由于集群占用vpc，vpc内所有ip（node和pod的ip）都属于vpc内各子网地址，这些地址出公网的请求共用vpc绑定的公网NAT，在某时刻子网ip请求公网使用的EIP是随机的，无法控制，会产生和其他ip同时请求公网使用同一个EIP的情况，由此发生了带宽内拥挤，超限的情况，因此上述超时报警其实是客户端带宽不够产生的误报

解决方案​

为了避免发生上述情况，解决办法是避免这些特定的pod请求公网时和其他ip发生公网带宽的争抢，走独立的公网出口，有以下两种方案：

• 方案一

将这些pod调度到特定的子网node，node的ip和pod的ip会使用特定的子网，这个特定的子网由于在特定的vSwitch虚拟交换机下，因此可以为这个子网单独指定路由条目，也就是将请求公网地址的请求的下一跳路由到特定的公网NAT，特定的公网NAT使用特定的EIP且不和其他子网共用

• 方案二

ack集群的网络使用的是阿里云Terway，在此前提下，阿里云提供了为Terway网络中的Pod挂载独立的公网EIP的解决方案，具体可以查看文档说明，简单来说就是阿里云提供了集群内的控制器，实现了通过k8s原生的声明式配置，调用EIP产品相关api动态为pod绑定EIP的功能

方案选取和实现​

方案一，改动较大，需要将pod调度到特定的node上，且需要人工维护路由条目，维护性较差； 方案二，更为直接，在安装控制器插件后，通过给pod添加特定注解实现目的，主要分为两种方式：

• 一种是根据声明式配置动态随机购买EIP

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example
  labels:
    app: example
spec:
  replicas: 1
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
      annotations:
        k8s.aliyun.com/pod-with-eip: "true"  # 自动创建并绑定EIP
        k8s.aliyun.com/eip-bandwidth: "200"  # EIP峰值带宽
        k8s.aliyun.com/eip-internet-charge-type: "PayByTraffic" # EIP的计量方式
        k8s.aliyun.com/eip-instance-charge-type: "PostPaid"  # EIP的计费方式
        k8s.aliyun.com/eip-name: "app-eip"  # EIP名称
        k8s.aliyun.com/eip-description: "app-eip"  # EIP描述

• 一种是先购买EIP，pod注解中声明EIP的id

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example
  labels:
    app: example
spec:
  replicas: 1
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
      annotations:
        k8s.aliyun.com/pod-eip-instanceid: eip-2zeXXXXXx  # EIP ID

配置RAM策略并安装插件​

按照文档操作，配置挂载EIP所需的RAM权限 安装插件ack-extend-network-controller，安装时启用插件pod eip的能力，一键安装即可

购买EIP​

由于业务目前只有1个pod，为了后续排查方便，选择通过先购买EIP再根据EIP id绑定的方式 购买EIP，按量付费，带宽上限为200Mbps

为pod添加注解​

在deployment的yaml中为pod添加注解，根据EIP id绑定这个EIP即可

spec:
  template:
    metadata:
      annotations:
        k8s.aliyun.com/pod-eip-instanceid: eip-xxx

绑定后效果

• 集群cr

控制器会自动创建一个和pod名称相同的PodEIP的cr，从这个cr的status中可以看到和上面购买的EIP相关的信息

~ kubectl get pods -o wide|grep app
app-79dcf755fb-ks2ld                                       1/1     Running             0                47h     10.245.36.4      ack-010245035222packets-spot       <none>           1/1
~ kubectl get podeips app-79dcf755fb-ks2ld -o yaml
apiVersion: alibabacloud.com/v1beta1
kind: PodEIP
metadata:
  creationTimestamp: "2024-04-01T07:55:46Z"
  finalizers:
  - podeip-controller.alibabacloud.com/finalizer
  generation: 1
  name: app-79dcf755fb-ks2ld
  namespace: dev
  resourceVersion: "2389078403"
  uid: 292773d3-80b4-4c88-b0ef-17f011a1530e
spec:
  allocationID: eip-xxxxx
  allocationType:
    releaseStrategy: Follow
    type: Static
status:
  eipAddress: 101.xxx.xxx.5
  internetChargeType: PayByTraffic
  isp: BGP
  name: app独享
  networkInterfaceID: eni-2zexxxxxxxqvrrpxxx
  podLastSeen: "2024-04-01T07:39:39Z"
  privateIPAddress: 10.xxx.36.4
  resourceGroupID: rg-xxxxx5afyhf3xky
  status: InUse

• EIP绑定情况，与从集群查看cr得到的状态一致

其他说明​

以上实现了pod绑定特定EIP的功能，在此条件下，pod请求公网时会固定为此eip出公网，为了保障配置的稳定，经过测试，上面提到此业务pod只有一个副本，且通过deployment管理，属于无状态应用，只做上面为pod添加注解的方式会有以下问题

如何控制当pod状态变为ready后才绑定EIP？​

控制器会在Pod IP分配后，为Pod配置EIP地址，Pod Ready状态可能早于EIP绑定成功时间。解决办法是为pod添加就绪前的检测

• 一种方式是为Pod配置Readiness gates

kind: Pod
...
spec:
  readinessGates:
  - conditionType: "k8s.aliyun.com/eip"
...
status:
  conditions:
  - lastProbeTime: "2022-12-12T03:45:48Z"
    lastTransitionTime: "2022-12-12T03:45:48Z"
    reason: Associate eip succeed
    status: "True"type: k8s.aliyun.com/eip
...

• 一种方式是为Pod配置init container，在init container中检查EIP是否已经分配成功

apiVersion: v1
kind: Pod
metadata:
  name: example
  annotations:
    k8s.aliyun.com/pod-with-eip: "true"
spec:
  containers:
  - name: example
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init
    image: busybox:1.28
    command: ['timeout', '-t' ,'60', 'sh','-c', "until grep -E '^k8s.aliyun.com\\/allocated-eipAddress=\\S?[0-9]+\\S?' /etc/podinfo/annotations; do echo waiting for annotations; sleep 2; done"]
    volumeMounts:
      - name: podinfo
        mountPath: /etc/podinfo
  volumes:
    - name: podinfo
      downwardAPI:
        items:
          - path: "labels"
            fieldRef:
              fieldPath: metadata.labels
          - path: "annotations"
            fieldRef:
              fieldPath: metadata.annotations

如何控制pod更新时，EIP始终只绑定了一个pod？​

pod如果发生了滚动更新，且pod在配置有探针的情况下，可以保障始终只有一个pod接收流量，但是无法保证EIP的正常绑定，因为发布过程中有两个pod同时绑定了这个EIP，新pod启动后，老的pod下线调用了解绑EIP的动作，EIP绑定是需要调用接口到vpc去绑定，只有绑定了这个EIP pod的后续探针才会ready。在新pod滚动更新的过程中，会重新绑定EIP，但是旧pod的回收，又会卸载绑定这个EIP

这里EIP当做了创建pod所需的基础资源，实际上EIP并不是pod运行所必须的，解决办法：

• A. 修改控制器实现支持在pod滚动更新结束后才将新的pod ip与EIP绑定（下述C可以避免此问题）

• B. 将pod的滚动更新模式修改为销毁重建Recreate，这样会损失一定流量

• C. 控制器支持有状态应用的pod在一定时间内发生更新后仍然使用之前的EIP，因此把pod由deployment改为statefulset，并声明pod在更新过程中仍然使用之前的EIP即可（固定EIP可以保证Pod重建后依然使用之前的EIP地址。该策略可与自动分配EIP能力结合，用于有状态应用的固定EIP）

      annotations:
        k8s.aliyun.com/pod-with-eip: "true"
        k8s.aliyun.com/pod-eip-release-strategy: "10m"

结合现状，业务pod如果支持多副本模式，可以切换到statefulset并创建2个副本，有状态应用的滚动更新本身就是副本销毁和重新创建，在多副本的情况下不会有流量丢失。目前只有一个（暂不支持多副本模式），且可以接受在升级的过程中丢失一定的流量，在不改变原有的无状态应用属性的情况下，选择的解决办法为B

最终配置如下:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  strategy:
    type: Recreate
  template:
    metadata:
      annotations:
        k8s.aliyun.com/pod-eip-instanceid: eip-XXXXXXXlus72fax
    spec:
      readinessGates:
      - conditionType: "k8s.aliyun.com/eip"

pod绑定EIP后pod本身监听的端口是否也就通过EIP暴露？​

pod由于没有通过NAT请求公网，是EIP和Pod IP（ecs 弹性辅助网卡）直接绑定，因此默认情况下，通过pod ip（vpc内网）:端口可以直接访问到pod暴露的接口，通过eip（公网）:端口也可以访问到，但是由于EIP绑定的是ecs的弹性辅助网卡，因此和ecs共用了一个安全组，ecs是集群node，只开放了集群子网间互通，因此这个问题已经规避

开篇​

“许多人迷迷糊糊，光阴虚度，尽管眼见已二三十岁，却仍旧活在生活之下，即便多活几十年，也不过是一种窘困，愁苦，凡庸的延伸，着实冤枉”

“复以何因缘，得大坚固力，人世间的一切都不牢靠、不坚固，寿命，也是不坚固的，顶多活一百年来年就要走了。家庭、父母、子女、夫妇相聚都不坚固，终归要分散的。佛经上经常有一句话：积聚必消散。聚拢的因缘完了，统统要分散。发了财，钞票来了，终归有不发财的一天，钱也有消散的一天。权力拿到手，总会有失掉的一天。房子建筑起来也总会有毁坏的一天。世界上有没有一个东西是坚固不破的”

上述是近期看到的一些文字，不再年轻的我，深有感触

时光如箭，岁月如梭，时间与命运的齿轮依然保持着不停转动。转眼间，两年的时光已在指尖溜走。若说时间是艺术家，那么它绘制的线条既粗犷又细腻，每一笔都描绘着成长与变迁

回首​

2022-2023 是来北京的第4、5个年头，也是本科毕业的第3、4年。过去的两年，个人成长与所遇之事，对我而言充满了不平凡

还记得22年的年底，疫情在正当严重时突然放开，在此之前人们好像都已习惯了没有固定频率的核酸，习惯了健康宝与行程码。忽然间这股弦就松开了，生活也立马回到了19年疫情前的样子，伴随着的是令人“阳了”的痛苦以及生命的逝去

这两年完成的最大一件事情，就是人生角色的转变——我结婚了。两年里，从22年春节双方父母见面，到23年春节的订婚，再到23年国庆的婚礼，感恩父母，感恩爱人，成就了我们的小家

两年里拥有了几本新的证书，算是对自己这两年变化的一个证明

工作​

从上一篇年终总结[2021 总结与公众号文章回顾]的时间点，就到现在的公司任职，如今也已经两年过去了

两年中经历与推动了不少从零开始的工作内容，自身能力、经验等各方面也得到了一些历练与长进，具体内容这里就不过多展开了

生活​

生活上认真听取了另一半的建议，不再像之前刚毕业时的宅，调整一个相对较好的自我状态。关于状态的自我剖析与调整有兴趣的朋友可以找找之前的文章。现在看来，这是一个打工人必会经历的心路历程

在保持健康饮食的同时，更爱在休息时间和另一半走出出租屋，打卡各店美食（实际上是薅🐑毛）

在22年初有了一台代步车，于是这两年每逢假期基本都会回家看看或是出去走走，享受在路上的感觉，享受出发与抵达。不到两年的时间里，总里程已经达到了约2.7w公里，期望来年伴随着四个车轮行至更多好去处

学习​

得益于在公司的环境和产出，这两年个人技能在前后端、架构，以及底层等方面都有了更为深入的认知与提升

计算机技术范围广泛且发展迅速，能够学以致用，解决实际问题，发挥与创造一些新的事物，这是技术从业者最大的价值体现，与此同时得到了正向反馈，才会更加精进

这些道理亦在为人处世上发挥关键作用

爱好​

公路车骑行的习惯依然保留，每年平均保持在约5000km的记录

在23年初购入了一台DJI Mini 3 Pro，解锁了新的爱好，拍摄了一些对于入门选手还算可以的作品

感兴趣的朋友可以加微信围观朋友圈，一起交流、约骑

博客与公众号​

博客是在大学期间开始折腾，微信公众号是在21年初开通同步发文

有些遗憾的是这两年由于工作生物钟、个人事务、拖沓等种种原因，导致博客与公众号都停更了很久

当初写文的出发点更多一方面是为了不断提升自我，从输出倒逼输入，记录一些自己在技术领域的路线，究其根本，还是自己没有平衡好一天的时间，有些产出早已拟好标题与关键内容，就是迟迟没有动笔，在这里做出自我检讨

希望新的一年还是能继续捡起写文章的好习惯

另外一方面也会更多分享个人生活，或许多年后还能有人寻着互联网的记忆找到这里

不过这两年里，关注的公众号中，之前有很多产出的一些号主，几乎很少有在坚持写文的了。我想这不仅和自身有关，印象中之前公众号是一块很纯净的地方，现如今微信公众号的浏览页面中已经沦为广告、推广、标题党、新闻八卦无脑推文的地方

我曾经每天愿意花大量时间挨篇仔细品读公众号的文章，现在也只是从少量收藏了名字的号中挑选阅读，看是否有好文诞生

以至于我花了一定时间尝试关闭/不接受任何公众号区域推送未关注的号内容，无奈在微信“个性化广告管理”菜单中说明：“智能推荐你可能感兴趣的广告内容，你可以开启或关闭服务，或管理广告兴趣标签，但广告总数不会因此变化”

简单理解，就是你可以设置关闭，然并luan，对此我只能说，tx会玩，罢了

最后​

我将朋友圈签名修改为“做有趣的人，做有意思的事”，这是在毕业后对于人生的思考

希望大家在现今纷繁复杂的社会环境中，远离“海燕综合征”，活出自我与真实

同时，对各位老粉丝与朋友的支持表示真心感谢

新的一年继续保持，挑战更多，人生在于折腾！

最后，附上上述总结相关的一些视频，供日后回忆与大家品鉴

Gradle介绍​

Gradle是一种自动化构建语言，是一种DSL。目前是Android的默认构建工具，是一个编程框架

Gradle是一个基于Apache Ant和Apache Maven概念的项目自动化构建开源工具。它使用一种基于Groovy的特定领域语言(DSL)来声明项目设置，也增加了基于Kotlin语言的kotlin-based DSL，抛弃了基于XML的各种繁琐配置

特点：

• 支持局部构建和增量构建
• 对多工程的构建支持很出色，工程依赖是gradle的第一公民
• 是第一个构建集成工具，与ant、maven、ivy有良好的相容相关性
• gradle的整体设计是以作为一种语言为导向的，而非成为一个严格死板的框架
• 支持多方式依赖管理：包括从maven远程仓库、nexus私服、ivy仓库以及本地文件系统的jars或者dirs
• 轻松迁移：gradle适用于任何结构的工程，你可以在同一个开发平台平行构建原工程和gradle工程。通常要求写相关测试，以保证开发的插件的相似性，这种迁移可以减少破坏性，尽可能的可靠。这也是重构的最佳实践

Gradle配置分析​

根目录配置​

在代码编译时最先找到这个文件

apply from: 'allconfig.gradle'
include: 'app'  // 包含的工程模块
if ( buildType==1 ){
    include ':mylibrary2'
} else if ( buildType==2 ){
    include ':mylibrary'
}
//在这里写一个脚本，让编译速度更快
rootProject.name = 'gradledemo'  // 工程名

build文件

// 根目录的构建脚本
buildscript {
    // 指定了仓库
    repositories {
        maven {  // 加速地址要放在最上面，从上往下找
            url 'http://maven.aliyun.com/nexus/content/groups/public/'
        }
        google()
        jcenter()
    }
    dependencies {  // 配置插件
        // gradle 插件版本
        classpath "com.android.tools.build:gradle:4.0.1"
    }
}

allprojects {
    // 项目本身需要的依赖，配置所有的Module公共依赖
    repositories {
        maven {
            url 'http://maven.aliyun.com/nexus/content/groups/public/'
        }
        google()
        jcenter()
    }
}

// 任务
task Clean(type: Delete) {
    delete rootProject.buildDir // 清理每次编译生成的文件
}

应用目录配置​

build文件

// 配置当前Module的属性
// 如果声明的是com.android.library  表示是一个依赖库
// 如果声明的是com.android.plugin   表示是一个插件
// 如果声明的是com.android.application   表示是一个app
apply plugin: 'com.android.application'
// 类似引入包一样，引入外部的gradle配置文件
apply from: 'config.gradle'

android {
    compileSdkVersion 30
    buildToolsVersion "30.0.2"

    defaultConfig {
        applicationId "com.mn.gradledemo"
        minSdkVersion 16
        targetSdkVersion 30
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "androidx.test.runner.AndridJunitRunner"
    }

    dependencies {
        implementation fileTree(dir: "libs", include: ["*.jar"])
        implementation 'androidx.appcompat:appcompat:1.2.0'
        implementation 'androidx.constraintlayout:constraintlayout:2.0.4'
        testImplementation 'junit:junit:4.12'
        androidtestInstrumentation 'androidx.test.ext:junit:1.1.2'
        androidtestInstrumentation 'androidx.test.espresso:espresso-core:3.3.0'
    }
}

// 只要声明了一个任务，不用调用就会执行
task stringText{
    // 使用def声明关键字
    def str1 = "shuanyinhao";
    def str2 = 'danyinhan';
    println("${str1}---${str2}")
}

配置文件

// ext就表示额外的属性声明
ext{
    server = "prod"
    dataSource = "0"
}

Gradle基础语法​

常规语法​

// list
task list{
    def list=[1,2,3,4,5,6]
    def weekList = ['one','two','three']
    println(list[0])
    println(weekList[0])
    for(int i in 1..10){
        println i
    }
    // 这里的it就表示每一个元素, it是一个关键字，表示它自己
    weekList.each {
        println it
    }
}

// map
task map{
    def map:['name':'jack','age':19]
    println map['name']
    map.each {
        println "key:${it.key},value:${it.value}"
    }
    println(methodA(2,3)) // 5
}

// 在gradle语法当中，定义一个方法
// 如果在没有return的情况下，函数默认会返回最后一行非空的值
def methodA(int a,int b){
    a+b
}

// 怎样定义一个对象
task javaBeanTask{
    Student student = new Student()
    student.name = "Lily"
    student.age = 19
    println student.name + "---${student.age}"
    println student.getName() + "---${student.getAge()}"
}

class Student{
    String name
    int age

    String getName(){
        return name
    }

    void setName(String name){
        this.name = name
    }

    int getAge(){
        return age
    }

    void setAge(int age){
        this.age = age
    }
}

闭包和it关键字​

Groovy中的闭包是一个开放，匿名的代码块，可以接受参数，返回值并赋值给变量

闭包，是一个代码块，或可以理解成一个匿名函数，在外部方法调用时，可以将其作为方法的实参传递给方法的形参，并在方法内部回调此匿名函数，且回调此匿名函数时可以传递实参给到匿名函数的内部去接收，并执行此匿名函数

同时，此代码块或匿名函数也可以赋值给一个变量，使其具有自执行的能力，且最后一行的执行语句作为匿名函数的返回

// 闭包，自定义闭包
def mEach(closure){
    for(int i in 1..5){
        closure(i)
    }
}

def mEachWithParams(closure){
    def map = ['name':'groovy','age':10]
    map.each{
        closure(it.key,it.value)
    }
}

// 调用闭包
task closureTask{
    // 回调一个参数的时候，it就是指这个参数，就能用it，多个就不行了
    mEach({
        println it
        // a->println a
    })
    mEachWithParams{
        m,n—>println "${m} is ${n}"
    }
}

环境区分​

主要目的是不需要修改代码就能区分测试环境和生产环境

例如有这样的代码目录（不同环境的配置文件）

app/src/main/filters/debug/config.properties
app/src/main/filters/release/config.properties

通过读取文件流实现按不同环境区分

// 配置当前Module的属性
// 如果声明的是com.android.library  表示是一个依赖库
// 如果声明的是com.android.plugin   表示是一个插件
// 如果声明的是com.android.application   表示是一个app
apply plugin: 'com.android.application'
// 类似引入包一样，引入外部的gradle配置文件
apply from: 'config.gradle'

android {
...

    // 构建类型
    buildTypes{
        // 测试环境
        debug{
            // 参数: 声明的类型、名字、属性值
            buildConfigField 'String','SERVER2',getServer2('debug')
        }
        release{
            buildConfigField 'String','SERVER2',getServer2('release')
        }
    }
}

// 读取文件流,str代表debug还是release
def getServer2(String str){
    def SERVER2
    Properties properties = new Properties();
    // 相对路径
    def proFile = file("src/main/filters/"+str+"/config.properties")
    if(proFile.canRead()){
        properties.load(new FileInputStream(proFile))
        if(properties!=null){
            SERVER2 = properties['SERVER2']
        }
    }
    return SERVER2
}

多渠道打包​

多渠道打包常用于安卓app，例如统计不同渠道的数据（投放到多个应用市场）

核心逻辑​

主要核心实现如下

apply plugin: 'com.android.application'
apply from: 'config.gradle'

android {
    compileSdkVersion 30
    buildToolsVersion "30.0.2"

    defaultConfig {
        applicationId "com.mn.gradledemo"
        minSdkVersion 16
        targetSdkVersion 30
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "androidx.test.runner.AndridJunitRunner"
        // 多渠道打包
        flavorDimensions "versionCode"
    }
...

    // 构建类型
    buildTypes{
        // 测试环境
        debug{
            // 参数: 声明的类型、名字、属性值
            buildConfigField 'String','SERVER2',getServer2('debug')
            android.applicationVariants.all{
                variant ->
                    variant.outputs.all{
                        def fileName = "${getCurrentTime()}_V{defaultConfig.versionName}_debug.apk"
                        outputFileName = fileName
                    }
            }
        }
        release{
            buildConfigField 'String','SERVER2',getServer2('release')
        }
    }

    // 多渠道打包
    productFlavors{
        xiaomi{
            buildConfigField 'String','PLATE_FORM',"\"xiaomi\""
            manifestPlaceholders = [UMENG_CHANNEL_VALUE: "xiaomi"]
        }
        yinyongbao{
            buildConfigField 'String','PLATE_FORM',"\"yingyongbao\""
            manifestPlaceholders = [UMENG_CHANNEL_VALUE: "yingyongbao"]
        }
    }
}

static def getCurrentTime(){
    return new Date().format("yyyy-MM-dd",timeZone.getTimeZone("UTC"))
}

一键化配置多渠道打包​

    // 一键化多渠道打包
    productFlavors{
        xiaomi{}
        yingyongbao{}
    }
    productFlavors.all{
        flavor ->
            flavor.manifestPlaceholders = [UMENG_CHANNEL_VALUE: name]
            buildConfigField 'String','PLATE_FORM',"\"${name}\""
    }

gradle打包加速​

和maven打包一样，gradle会在编译时的用户家目录，例如/root/.gradle目录下生成一个缓存目录，除此之外，在应用的目录下也会生成一个build目录，这个目录下也有相应的build cache

可以在全局配置gradle，使其拉取插件时走国内的源

配置文件为/root/.gradle/init.gradle，内容如下

allprojects {
    repositories {
        mavenLocal()
		maven { name "Aliyun" ; url "https://maven.aliyun.com/repository/public" }
		maven { name "Bstek" ; url "http://nexus.bsdn.org/content/groups/public/" }
    }

	buildscript {
		repositories {
			maven { name "Aliyun" ; url 'https://maven.aliyun.com/repository/public' }
			maven { name "Bstek" ; url 'http://nexus.bsdn.org/content/groups/public/' }
			maven { name "M2" ; url 'https://plugins.gradle.org/m2/' }
		}
	}
}

背景​

使用阿里云ack托管版运行k8s集群，有时需要对团队内成员授权集群非管理员的权限，以及某些服务需要调用k8s相关api做特定操作，例如在指定的某namespace下创建某控制器（例如deployment）的权限

由于在ack托管版环境下，集群的master节点由阿里云托管，对租户不可见，因此除了基于k8s的RBAC权限外，还需要授予阿里云的授权体系，即RAM

授权体系概述​

k8s授权体系​

先来回忆一下k8s的RBAC（Role-Based Access Control）基于角色的访问控制授权体系

这是一种很常见并通用的授权体系，在k8s中，RBAC使用rbac.authorization.k8s.io API Group 来实现授权决策

Kubernetes从1.6版本开始支持RBAC，集群管理员可以对用户或服务账号的角色进行更精确的资源访问控制。允许管理员通过Kubernetes API动态配置策略，在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色

如上图所示，左边对于Pod资源的get、list操作（称为请求动词）类似于常见的CRUD，对k8s的相关资源操作都是以REST API形式发起，每一类请求动词对应http请求如下表

k8s中的资源和API Group关联，不同的资源属于不同的API Group，例如Pod属于Core API Group，Deployements属于apps API Group

资源操作的集合叫做Rule，RBAC中的角色，在k8s中分为Role和ClusterRole，其区别就是前者是命名空间级别下，后者不限命名空间（集群范围内生效）

上图最右边即用户，k8s中的用户可以分为三类：User、Group、Service Account，User即传统意义上的用户，这个用户一般由外部服务管理；Group用来关联多个账户；而Service Account（服务帐号）就是通过Kubernetes API来管理的一些用户帐号，适用于集群内部运行的应用程序。所有的用户称作一个Subject

有了角色和用户，就需要两者之间的绑定关系，由于角色有Role和ClusterRole两类，因此绑定关系也分为RoleBinding和ClusterRoleBinding，即把声明的Subject和想要绑定的Role进行绑定（给某个用户绑定上某些操作的权限），二者作用范围和角色类似

阿里云RAM遇上RBAC​

如文章封面图所示，ACK的授权体系包含对基础资源层的RAM授权和对ACK集群层的RBAC授权两部分

• RAM授权对应ACK集群的运维操作，需要获取ACK产品及其所依赖阿里云云产品的OpenAPI操作权限，主要包括以下操作：
  • 集群：创建、查看、升级、删除
  • 节点池：创建、修改、扩缩容
  • 授权管理
  • 集群监控、日志、事件
• RBAC授权对应的是运行于ACK集群中Kubernetes应用的运维操作，需要获取ACK集群及其命名空间的操作权限，主要包括对以下Kubernetes对象的增删改查操作：
  • 工作负载：Deployment、StatefulSet、DaemonSet、Job、CronJob、Pod、ReplicaSet、HPA等
  • 网络：Service、Ingress、NetworkPolicy等
  • 存储：PV、PVC、StorageClass等
  • Namespace、ConfigMap 、Secrets等

因此当RAM用户或RAM角色需要进行集群运维和应用运维时，需要依次对其进行RAM授权和RBAC授权

对于RAM这里不再深入，因为阿里云RAM关联了很多很多不同的云产品统一进行授权，因此很复杂，也不做过多研究

授权过程​

上面对阿里云RAM和k8s的RBAC两个体系做了简要介绍和回顾，接下来根据一个实际场景简要介绍授权的整个过程以及需要注意的踩坑点

需求如下：

研发或集群外服务需要操作某集群，例如dev（开发）ack集群，具有dev命名空间的创建、删除deployment、service、ingress这三类资源的权限

若服务在集群内，那么就可以通过ServiceAccount方式，假设服务在集群外，目的是要生成一个给kubectl使用的config文件

创建RAM用户并授权​

由于用户最终只能通过控制台才能获取config文件，因此需要创建一个可以登录控制台，并对ack具有只读权限的用户

然后对用户进行授权，记录下用户的密码

ACK集群中创建ClusterRole​

在集群中创建相关授权通常是通过编写对应的yaml资源清单

这里推荐一个图形化的工具Permission manager，是一个简单便捷的RBAC管理界面工具，支持通过web界面创建用户，分配Namespace权限，并可以生成kubeconfig文件，项目地址https://github.com/sighupio/permission-manager

前面需求提到是指定命名空间下的权限，但这里是创建ClusterRole而不是Role，这个问题后面解释

ClusterRole的内容如下

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: project-rbac-role
rules:
  - apiGroups: ["extensions", "apps"]
    resources: ["deployments"]
    verbs: ["create", "delete"]
  - apiGroups: [""]
    resources: ["service"]
    verbs: ["create", "delete"]
  - apiGroups: ["networking.k8s.io"]
    resources: ["ingress"]
    verbs: ["create", "delete"]

使用kubectl进行创建

➜  rbac git:(master) ✗ kubectl apply -f clusterrole.yaml

控制台授权绑定​

在ack的控制台对ram用户授权，点击到某个集群——>安全管理——>授权，选择上面创建的ram子账号，点击“管理权限”，选择集群（这里虽然已经进入到了特定集群，但依然可以选择其他集群，或许是ack产品设计上有点不合理），选择对应要授权的命名空间，访问权限选择“自定义”，然后下拉就能找到上面创建的名为project-rbac-role的ClusterRole

上面提到了创建ClusterRole而不是Role，原因就在这里，因为这里下拉只能读取到集群中存在的ClusterRole，选择完成后点击下一步，授权成功

那么，既然已经使用了ClusterRole，又选定了命名空间，因此相当于还是基于Role的权限？

没错，实际上这里的操作是对应的在ack集群中创建了一个Rolebinding绑定集群的ClusterRole，正常来说应该是Rolebinding绑定集群的Role，ClusterRolebinding绑定集群的ClusterRole，这里相当于交叉绑定了，但实际上这个ClusterRole的权限范围缩小了

可以通过如下方式查看集群中的Rolebinding，名称大致为“ram用户的uid-命名空间-clusterrole的名称-rolebinding”，关联的subjects用户正是ram用户的uid

➜  rbac git:(master) ✗ kubectl get rolebinding -n dev|grep 29xxxxxxxxxxx1
29xxxxxxxxxxx1-dev-project-rbac-role-rolebinding   ClusterRole/project-rbac-role    41m
➜  rbac git:(master) ✗ kubectl -n dev get rolebinding 29xxxxxxxxxxx1-dev-project-rbac-role-rolebinding -o yaml|kubectl neat
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: 29xxxxxxxxxxx1-dev-project-rbac-role-rolebinding
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: project-rbac-role
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: "29xxxxxxxxxxx1"

到这里授权就完成了

获取连接集群的config​

用上面创建的readonly这个ram用户登录到ack的每个集群控制台，获取这个ram用户的集群连接信息即config内容，保存成文件即可

小结​

使用ack托管版对集群授权需要关联ram用户和集群RBAC的ClusterRole，无需在集群中手动创建其他资源，整个过程中有一定的小坑和个人感觉设计不太合理的地方仅供参考~

See you ~

参考资料​

https://kubernetes.io/zh/docs/reference/access-authn-authz/authorization/

https://help.aliyun.com/document_detail/119596.html

为什么还要写这类看似枯燥的文章？我始终认为，学习和实践应用一门新技术之前，应该做好多方调研，全局认知，当前有什么痛点能解决而不是有哪些功能能拿来用等等，到最后不至于仅仅是用了起来而已

服务治理的三种形态​

服务治理的发展经过了以下三种形态的演进

• 应用程序中包含治理逻辑（代码自行实现，复用性很低）
• 治理逻辑独立的代码（sdk方式，提高复用性，但避免不了的是要应用一起打包部署）
• 治理逻辑独立的进程（sidecar模式，对应用无感知，解耦合）

服务网格的特点​

• 基础设施：服务网格是一种处理服务间通信的基础设施层
• 云原生：服务网格尤其适用于在云原生场景下帮助应用程序在复杂的服务拓扑间可靠地传递请求
• 网络代理：在实际使用中，服务网格一般是通过一组轻量级网络代理来执行治理逻辑的
• 对应用透明：轻量网络代理与应用程序部署在一起，但应用感知不到代理的存在，还是使用原来的方式工作

网格带来的损耗​

传统环境下，服务A到服务B可以直接通过网络（ip或服务名）直连

用了网格后，从A服务到B服务的一个访问必须要经过A服务的Sidecar拦截Outbound流量执行治理动作；再经过B服务的Sidecar拦截Inbound流量，执行治理动作。 这就引入两个问题：

• 增加了两处延迟和可能的故障点
• 多出来的这两跳对于访问性能、整体可靠性及整个系统的复杂度都带来了新的挑战

通过保证转发代理的轻量和高性能降低时延影响，尤其是考虑到后端实际使用的应用程序一般比代理更重，叠加代理并不会明显影响应用的访问性能；另外，对于这些高性能的代理，只要消耗足够的资源总能达到期望的性能， 特别是云原生场景下服务的弹性特点使得服务实例的弹性扩展变得非常方便，通过扩展实例数量总是能得到期望的访问性能

因此最终需要决策的是： 是否愿意花费额外的少量资源在这些基础设施上来换取开发、运维的灵活性、业务的非侵入性和扩展性等便利？

为什么服务网格选择Istio​

• 控制面设计

Istio作为一种全新的设计，在功能、形态、架构和扩展性上提供了远超服务网格的能力范围。它基于xDS协议提供了一套标准的控制面规范，向数据面传递服务信息和治理规则。Istio的早期版本使用Envoy V1版本的API，即Restful方式，其新版本使用Envoy V2版本的API，即gRPC协议。标准的控制面API解耦了控制面和数据面的绑定。Nginx的nginMesh、F5 Networks的Aspen Mesh等多种数据面代理支持Istio的控制面，甚至有些老牌微服务SDK也开始往Istio上集成

• 数据面设计

Istio的标准数据面Envoy是由Lyft内部于2016年开发的，比Linkerd更早。2016年9月，Envoy开源并发布了1.0.0版本；2017年9月，Envoy加入CNCF，成为第2个Service Mesh项目；2018年11月，Envoy从CNCF毕业，这标志着其趋于成熟。从开发语言上看，Envoy是使用C++开发的，其性能和资源占用比用Rust开发的Linkerd Proxy要更好，更能满足服务网格中对透明代理的轻量高性能要求；从能力上看，Envoy提供L3/L4过滤器、HTTP L7过滤器，支持HTTP/2、HTTP L7路由及gRPC、MongoDB、DynamoDB等协议，有服务发现、健康检查、高级LB、前端代理等能力，具有极好的 可观察性、动态配置功能；从架构实现上看，Envoy是一个可高度定制化的程序，通过Filter机制提供了 高度扩展性，还支持热重启，其代码基于模块化编码，易于测试。除了在Istio中应用，Envoy在其他Service Mesh框架中也被广泛应用，渐渐成为Service Mesh的数据平面标准

• 大厂加持

Istio由谷歌和IBM共同推出，从应用场景的分析规划到本身的定位，从自身架构的设计到与周边生态的结合，都有着比较严密的论证。Istio项目在发起时已经确认了将云原生生态系统中的容器作为核心打包和运行时，将Kubernetes作为管理容器的编排系统，需要一个系统管理在容器 平台上运行的服务之间的交互，包括控制访问、安全、运行数据收集等，而Istio正是为此而生的；另外，Istio成为架构的默认部分，就像容器和Kubernetes已经成为云原生架构的默认部分一样

另外一点，很多的公有云厂商在提供kubernetes容器服务时也内置了Istio功能或者二次开发（包装）了Istio，例如阿里云的asm

Istio与kubernetes​

Istio和Kubernetes从设计理念、使用体验、系统架构甚至代码风格等小细节来看，关系都非常紧密。更细粒度的proxy提供更多更细粒度的能力

Istio最大化地利用了Kubernetes这个基础设施，与之叠加在一起形成了一个更强大的用于进行服务运行和治理的基础设施，并提供了更透明的用户体验。

• 数据面

数据面Sidecar运行在Kubernetes的Pod里，作为一个Proxy和业务容器部署在一起。在服务网格的定义中要求应用程序在运行的时候感知不到Sidecar的存在。而基于Kubernetes的一个Pod多个容器的优秀设计使得部署运维对用户透明，用户甚至感知不到部署Sidecar的过程。用户还是用原有的方式创建负载，通过Istio的自动注入服务，可以自动给指定的负载注入Proxy。如果在另一种环境下部署和使用Proxy，则不会有这样的便利

• 统一服务发现

Istio的服务发现机制非常完美地基于Kubernetes的域名访问机制构建而成，省去了再搭一个类似Eureka的注册中心的麻烦，更避免了在Kubernetes上运行时服务发现数据不一致的问题

尽管Istio强调自己的可扩展性的重要性在于适配各种不同的平台，也可以对接其他服务发现机制，但在实际场景下，通过深入分析Istio几个版本的代码和设计，便可以发现其重要的能力都是基于Kubernetes进行构建的

• 基于Kubernetes CRD描述规则

Istio的所有路由规则和控制策略都是通过Kubernetes CRD实现的，因此各种规则策略对应的数据也被存储在kube-apiserver中，不需要另外一个单独的APIServer和后端的配置管理。所以，可以说Istio的APIServer就是Kubernetes的APIServer，数据也自然地被存在了对应Kubernetes的etcd中

Istio非常巧妙地应用了Kubernetes这个好基座，基于Kubernetes的已有能力来构建自身功能。Kubernetes里已经有的，绝不再自己搞一套，避免了数据不一致和用户使用体验的问题

Istio不仅数据面Envoy跑在Kubernetes的Pod里，其控制面也运行在Kubernetes集群中，其控制面组件本身存在的形式也是Kubernetes Deployment和Service，基于Kubernetes扩展和构建

最后，看看微服务、容器、Kubernetes、Istio四者的关系

微服务和Istio的选择侧重​

微服务是架构风格、方法论，Istio是一套完整的实践

但是，回到我在本文开头提到的一点观念，Istio是用来解决问题的，并不是微服务理论的一种落地，在实际项目中拿着微服务的细节列表来硬套Istio的功能，比如要求Istio治理的服务必须实现微服务的服务注册的一些细节，就明显不太适当

Istio的侵入性​

从单个应用来看，Sidecar与应用进程的解耦带来的应用完全无侵入、开发语言无关等特点解除了开发语言的约束，从而极大降低了应用开发者的开发成本。这种方式也经常被称为一种应用的基础设施层，类比TCP/IP网络协议栈，应用程序像使用TCP/IP一样使用这个通用代理：TCP/IP负责将字节码可靠地在网络节点间传递，Sidecar则负责将请求可靠地在服务间进行传递。TCP/IP面向的是底层的数据流，Sidecar则可以支持多种高级协议（HTTP、gRPC、HTTPS等），以及对服务运行时进行高级控制，使服务变得可监控、可管理

从全局来看，在多个服务间有复杂的互相访问时才有服务治理的需求。即我们关注的是这些Sidecar组成的网格，对网格内的服务间访问进行管理，应用还是按照本来的方式进行互相访问，每个应用程序的Inbound流量和Outbound流量都要经过Sidecar代理，并在Sidecar上执行治理动作

Sidecar是网格动作的执行体，全局的管理规则和网格内的元数据维护通过一个统一的控制面实现，只有数据面的Sidecar和控制面有联系，应用感知不到Sidecar，更不会和控制面有任何联系，用户的业务和控制面彻底解耦

Istio用在哪​

Istio是一个服务治理平台，治理的是服务间的访问，只要有访问就可以治理，不在乎这个服务是不是 所谓的微服务，也不要求跑在其上的代码是微服务化的。单体应用即使不满足微服务的若干哲学，用Istio治理也是完全可以的

Istio做了什么​

以前后端分离的服务为例 前端 服务的代码中通过域名访问 后端 服务，在两个服务中都不用包含任何服务访问管理的逻辑。Istio在其中都做了什么（可以做些什么）

• 自动通过服务发现获取服务实例列表，并根据负载均衡策略选择一个服务实例
• 对服务双方启用双向认证和通道加密
• 如果某个服务实例连续访问出错，则可以将该实例隔离一段时间，以提高访问质量
• 设置最大连接数、最大请求数、访问超时等对服务进行保护
• 限流
• 对请求进行重试
• 修改请求中的内容
• 将一定特征的服务重定向
• 灰度发布
• 自动记录服务访问信息
• 记录调用链，进行分布式追踪
• 根据访问数据形成完整的应用访问拓扑
• ……

所有这些功能，都不需要用户修改代码，用户只需在Istio的控制面配置即可，并且动态生效

对业务代码完全没有侵入性

用什么姿势接入 Istio​

虽然Istio能解决那么多的问题，但是引入Istio并不是没有代价的。最大的问题是Istio的复杂性，强大的功能也意味着Istio的概念和组件非常多，要想理解和掌握Istio，并成功在生产环境中部署需要非常详细的规划。一般情况下，集群管理团队需要对kubernetes非常熟悉，了解常用的使用模式，然后采用逐步演进的方式把Istio的功能分批掌控下来

• 第一步，自然是在测试环境搭建一套Istio的集群，理解所有的核心概念和组件。了解Istio提供的接口和资源，知道它们的用处，思考如何应用到自己的场景中，然后是熟悉Istio的源代码，跟进社区的issues，了解目前还存在的issues和bug，思考如何规避或者修复。这一步是基础，需要积累到Istio安装部署、核心概念、功能和缺陷相关的知识，为后面做好准备

• 第二步，可以考虑接入Istio的观察性功能，包括logging、tracing、metrics数据。应用部署到集群中，选择性地（一般是流量比较小，影响范围不大的应用）为一些应用开启Istio自动注入功能，接管应用的流量，并安装prometheus和zipkin等监控组件，收集系统所有的监控数据。这一步可以试探性地了解 Istio对应用的性能影响，同时建立服务的性能测试基准，发现服务的性能瓶颈，帮助快速定位应用可能出现的问题。此时，这些功能可以是对应用开发者透明的，只需要集群管理员感知，这样可以减少可能带来的风险

• 第三步，为应用配置timeout超时参数、自动重试、熔断和降级等功能，增加服务的容错性。这样可以避免某些应用错误进行这些配置导致问题的出现，这一步完成后需要通知所有的应用开发者删除掉在应用代码中对应的处理逻辑。这一步需要开发者和集群管理员同时参与

• 第四步，和ingress、helm、应用上架等相关组件和流程对接，使用Istio接管应用的升级发布流程。让开发者可以配置应用灰度发布升级的策略，支持应用的蓝绿发布、金丝雀发布以及AB测试

• 第五步，接入安全功能。配置应用的TLS互信，添加RBAC授权，设置应用的流量限制，提升整个集群的安全性。因为安全的问题配置比较繁琐，而且优先级一般会比功能性相关的特性要低，所以这里放在了最后

当然这个步骤只是一个参考，需要根据自己的情况、人力、时间和节奏来调整，找到适合的方案

Istio不是银弹​

Istio的架构在数据中心和集群管理中非常常见，每个agent分布在各个节点上（可以是服务器、虚拟机、pod、容器）负责接收指令并执行，以及汇报信息；控制中心负责汇聚整个集群的信息，并提供API让用户对集群进行管理。kubernetes也是类似的架构，SDN（Software Defined Network）也是如此。相信以后会有更多类似架构的出现，这是因为数据中心要管理的节点越来越多，我们需要把任务执行分布到各节点（agent负责的功能），同时也需要对整个集群进行管理和控制（control plane的功能），完全去中心化的架构是无法满足后面这个要求的

Istio的出现为负责的微服务架构减轻了很多的负担，开发者不用关心服务调用的超时、重试、rate limit的实现，服务之间的安全、授权也自动得到了保证；集群管理员也能够很方便地发布应用（AB 测试和灰度发布），并且能清楚看到整个集群的运行情况

但是这并不表明有了Istio就可以高枕无忧了，Istio只是把原来分散在应用内部的复杂性统一抽象出来放到了统一的地方，并没有让原来的复杂消失不见。因此我们需要维护Istio整个集群，而Istio的架构比较复杂，尤其是它一般还需要架在kubernetes之上，这两个系统都比较复杂，而且它们的稳定性和性能会影响到整个集群。因此再采用Isito之前，必须做好清楚的规划，权衡它带来的好处是否远大于额外维护它的花费，需要有相关的人才对整个网络、kubernetes和Istio都比较了解才行

云原生​

云原生的定义：

• 2010年，WSO2技术总监PaulFremantle 首次提出Cloud Native，他一直想用一个词表达一个架构，这种架构能够描述应用程序和中间件能够在云环境中有良好的运行状态。云原生有以下特性 分布式、弹性、多租户，子服务，按需计量和计费，增量部署和测试

• 2013年，Netflix云架构师，Adrian Cockcroft介绍了Netflix在AWS上基于Cloud Native的成功应用，Netflix在AWS上有上万个实例

• 2015年，来自Pivotal的Matt Stine，他的电子书《迁移到云原生应用架构》，他认为单体架构在向云原生架构的演进过程中，需要流程、文化、技术共同变革，该书把Cloud Native描述为一组最佳实践，具体包含如下内容：十二因子，微服务，敏捷基础设施，基于API的协作，反脆弱性

• 2017年，Matt Stine在接受媒体采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器

2015年云原生计算基金会（CNCF）成立，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务。

• CNCF于2018年通过了对云原生重新定义的提案，V1.0的定义如下：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更

云原生的英文原文叫Cloud Native，从英文的角度来理解，Native表示与生俱来，就是亲生的，把Cloud 和Native放到一起又该如何理解？详细的解释是：应用原生被设计为在云上以最佳方式运行，充分发挥云的优势，享受云的特点

云原生这个词看起来比较新鲜，其实从开发人员的角度来理解是很简单的，就是应用在开发的时候就考虑到云上提供的各种服务，充分利用云的动态调度、自恢复、通过API访问服务等基本特性，以及敏捷高效的特性。传统的应用开发方式都是闷头开发，不管应用跑在哪个基础设施环境中，也不用考虑基础设施提供的各种能力，让应用能正常运行就好

上面都是从广义上来理解云原生，有点空洞，对应到具体的方法论就是大家耳熟能详的三板斧

• 容器化

• 微服务

• DevOps

微服务架构​

微服务或微服务架构是一种架构风格，它将一个应用程序构建为服务的集合。松散耦合的微服务集合提供了与单个单体应用相同的功能，但有额外的优势。微服务可以独立于其他服务进行开发和部署。它们是围绕业务能力组织的，由较小的团队拥有。它们在部署/开发中更小、更独立，可以更好地维护和测试

开发人员经常将云原生应用程序分解为多个执行特定动作的服务。例如，可能有一个只处理客户的服务和另一个处理订单或付款的服务。所有这些服务都通过网络相互沟通。如果一个新的付款需要被处理，请求会被发送到付款服务。如果客户数据需要更新，请求会被发送到客户服务等等

这种类型的架构被称为微服务架构。这种架构有几个好处。可以有多个较小的团队从事个别服务。这些团队可以灵活地选择他们的技术栈和语言，并且通常有独立部署和发布服务的自主权。这种机制得以运作得益于其背后通信网络。随着服务数量的增加，它们之间的网络通信也在增加。服务和团队的数量使得监控和管理通信逻辑变得相当复杂。由于我们也知道网络是不可靠的，它们会失败，所有这些的结合使得微服务的管理和监控相当复杂

Kubernetes​

Kubernetes是现代基于容器的DevOps和微服务以及容器携手并进的黄金标准，其设计之初就是按照云原生的理念设计的

Kubernetes是一款用于管理容器化工作负载和服务的可移植、可扩展的开源平台，拥有庞大、快速发展的生态系统，它面向基础设施，将计算、网络、存储等资源进行紧密整合，为容器提供最佳运行环 境，并面向应用提供封装好的、易用的工作负载与服务编排接口，以及运维所需的资源规格、弹性、运行参数、调度等配置管理接口，是新一代的云原生基础设施平台。 从平台架构而言，Kubernetes的设计围绕平台化理念，强调插件化设计与易扩展性，这是它与其他同类系统的最大区别之一，保障了对各种不同客户应用场景的普遍适应性。另外，Kubernetes与其他容器编排系统的显著区别是Kubernetes并不把无状态化、微服务化等条件作为在其上可运行的工作负载的约束

随着互联网的发展，后端服务和容器编排技术的日益成熟，微服务成为了后端服务的首选，Kubernetes也已成为目前容器编排的事实标准

服务网格​

服务网格被定义为一个专门的基础设施层，用于管理服务与服务之间的通信，使其可管理、可见、可控制。在某些版本的定义中，可能还会听到服务网格如何使服务间的通信安全和可靠。用一个更直接的句子来描述服务网格：服务网格是关于服务之间的通信

但是，服务网格是如何帮助通信的呢？让我们思考一下通信逻辑和它通常所在的地方。在大多数情况下，开发人员将这种逻辑作为服务的一部分来构建。通信逻辑是处理入站或出站请求的任何代码，重试逻辑，超时，甚至可能是流量路由。因此，无论何时服务A调用服务B，请求都要经过这个通信代码逻辑，这个逻辑决定如何处理这个请求

如果我们采用微服务的方法，最终可能会有大量的服务。我们如何处理所有这些服务的通信逻辑呢？我们可以创建一个包含这种逻辑的共享库，并在多个地方重用它。假设我们对所有的服务都使用相同的堆栈或编程语言，共享库的方法可能会很有效。如果我们不这样做，我们将不得不重新实现这个库，这会带来巨大的工作量而且效率低下。你也可能使用自己本身不拥有代码库的服务。在这种情况下，我们无法控制通信逻辑或监控

另外一个问题是配置。除了配置你的应用程序外，我们还必须维护通信逻辑配置。如果我们需要同时调整或更新多个服务，我们将不得不为每个服务单独进行调整

服务网格所做的是，它将这种通信逻辑、重试、超时等从单个服务中分离出来，并将其移到一个单独的基础设施层。在服务网格的情况下，基础设施层是一个网络代理的阵列。这些网络代理的集合（每个服务实例旁边都有一个）处理你的服务之间的所有通信逻辑。我们称这些代理为sidecar，因为它们与每个服务并存

我们让Customer服务直接与Payment服务通信，现在我们有一个Customer服务旁边的代理与Payment服务旁边的代理通信。服务网格控制平面以这样一种方式配置代理，即它们透明地拦截所有入站和出站请求。这些代理的集合（基础设施层）形成了一个网络网格，称为服务网格

将通信逻辑从业务和应用逻辑中分离出来，可以使开发人员专注于业务逻辑，而服务网格运维人员则专注于服务网格配置

因此，用到服务网格sidecar模式后，应用的拓扑可能是这样

服务网格为我们提供了一种一致的方式来连接、保护和观察微服务。网格内的代理捕获了网格内所有通信的请求和指标。每一次失败、每一次成功的调用、重试或超时都可以被捕获、可视化，并发出警报。此外，可以根据请求属性做出决定。例如，我们可以检查入站（或出站）请求并编写规则，将所有具有特定头值的请求路由到不同的服务版本

Istio​

Istio是服务网格技术云原生Cloud Native时代的产物，是云原生应用的新型架构模式，而云原生又是云计算产业发展的新制高点

2016年，Google决定开发一个对微服务进行管理的开源项目，它与Google内部使用的平台有很大的相似性，该项目被命名为Istio,Istio在希腊语中的意思是“启航”。就在Google启动Istio项目的几乎同一时间，IBM也发布了一个名为Amalgam8的开源项目，这是一个基于Nginx代理技术，为微服务提供基于内容路由方案的项目。随后，Google和IBM意识到这两个项目在使用场景与产品愿景上存在很大一部分交集，于是答应成为合作伙伴，IBM放弃Amalgam8的开发，与Google共同基于Lyft公司开源的envoy项目打造Istio这款产品

Istio是一个与Kubernetes紧密结合的适用于云原生场景的Service Mesh形态的用于服务治理的开放平台

Istio与Kubernetes的关系如下

Istio的出现将服务网格的概念发扬光大，它创新性地将服务网格从逻辑上划分为“数据面板”和“控制面板

• 随着分布式应用一起部署的sidecar成为数据平面，它能够拦截网络请求并控制服务之间的通信

• 而集中式的管理模块成为控制平面，它提供服务发现、流量管理、遥测数据收集以及证书轮换等功能

在整个网络里面，所有的流量都在sidecar代理的控制当中，所有的sidecar代理都在控制面板控制当中，因此，可以通过控制面板控制整个服务网格，这是Istio带来的最大革新

Istio提供一种简单的方式来为已部署的服务建立网络，该网络具有负载均衡、服务间认证、监控等功能，只需要对服务的代码进行一点或不需要做任何改动，让服务支持Istio，只需要在环境中部署一个特殊的sidecar代理，使用Istio控制平面功能配置和管理代理，拦截微服务之间的所有网络通信

• HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡

• 通过丰富的路由规则、重试、故障转移和故障注入，可以对流量行为进行细粒度控制

• 可插入的策略层和配置 API，支持访问控制、速率限制和配额

• 对出入集群入口和出口中所有流量的自动度量指标、日志记录和追踪

• 通过强大的基于身份的验证和授权，在集群中实现安全的服务间通信

本文就写（参考）到这里，后面围绕Istio做更多学习、实践的分享

参考

• https://istio.io/latest/zh/docs/concepts/what-is-istio/
• https://www.infoq.cn/article/fA42rfjV*dYGAvRANFqE
• https://mp.weixin.qq.com/s/csY8T02Ck8bnE3vVcZxVjQ

年度总结​

时间一转眼就到了2021年最后一天，以2021最后一个工作周的周五结束，是的2021年就这样过去了

2021年是来北京的第3个年头，也是本科毕业的第2年

在这一年年末，完成了北漂两件（大）事：换工作、换房

工作​

如封面图，现在的工作地点在五道口

有时候我会觉得我是一个念旧的人，对于人生旅途上的人和事总会有那些美好让你难以释怀

因此换工作对我来说是一件艰难的事情

但转而一想，从初中开始，我们所处的环境、我们身边的人每过3年、4年就会换一拨

所以工作其实也是一样罢了，只要我们时常想起的时候总是充满美好就可以了

换工作对于职业发展、技术路线、公司发展等多方面也进行了多方取舍，最终选择了现在的公司

学习​

这一年也在Todo中定下了不少学习计划，具体这里就不列出了

部分计划的成果以博客/公众号文章的形式进行了输出，公众号原创的确是一件不容易的事情，上半年坚持周更三篇，下半年就只能周更两篇了，明年再接再厉

当然，在计划充分饱满的前提下，应该没有人能说把年初计划完美的完成了

计划赶不上变化，人生总会有遗憾 ~

生活​

从实习来到北京，就一直住在被冠以“老破小”称号的六七十年代筒子楼

搬家或许对于多数人来说都是一件很艰难的事情

为了减少通勤时间，改善改善居住环境

终于在最近一个周末狠下了心，连续完成了看房、搬家

下面就是以后经常战斗的小窝啦 ~

骑行​

这一年由于在前司找到了完美的停车位，感谢领导让我的小小爱好得以坚持

由于工作以及个人时间安排经常和俱乐部时间冲突，所以这一年去俱乐部一起参加活动的时间也就少了

更多骑行的时间还是在通勤以及和朋友休闲骑

希望新的一年到来后能继续并有所突破

公众号文章回顾​

这一年开始在写博客的同时发表到了公众号，除去转载的部分好文，剩下的原创文章和学习笔记按照领域分类，或按时间先后、阅读量排序整理如下，方便大家继续点击直达

云原生、Kubernetes、容器相关​

k8s生产实践之获取客户端真实IP

基于ack k8s集群调度的方案设计

Dockerfile语法概要

k8s环境下处理容器时间问题的多种姿势

SkyWalking链路追踪系统-部署篇

SkyWalking链路追踪系统-接入篇

SkyWalking链路追踪系统-告警篇

浅谈Prometheus的数据存储

使用kube-prometheus部署k8s监控(最新版)

基于k8s集群部署Nexus与旧数据的迁移

基于Dockerfile构建容器镜像的最佳实践

两大grafana实用插件快速监控kubernetes

Helm Chart语法概要

k8s内网和办公网络的打通实践

基于k8s手动部署rabbitmq集群

任务执行龟速，原因竟然是......

在k8s中解决pod资源的正确识别

k8s之Ingress自动化https

k8s Ingress nginx错误页面的深度定制

基于k8s Ingress Nginx+OAuth2+Gitlab无代码侵入实现自定义服务的外部验证

使用flannel+canal实现k8s的NetworkPolicy

kubernetes存储之GlusterFS

ack集群Terway网络场景下的vSwitch扩容

DevOps、Jenkins相关​

DevOps建设之基于钉钉OA审批流的自动化上线

Jenkins API+Pipeline深度实践之input的自动化

JenkinsPipeline语法概要

Jenkins连接k8s的多种姿势

Jenkins workflowLibs库的使(妙)用

Jenkins ShareLibrary实践之自定义通知器

使用Jenkins Operator在k8s中部署Jenkins

利用Github Action实现Github到Gitee的持续同步

Azure DevOps的使用入门

Python​

Celery在Django中的简单应用

drf的接口文档生成与管理

浅谈Python鸭子类型

drf分页器的使用

基于Python实现原生的登录验证码

Python分析Nginx日志

Django分页器的用法

Django自定义实现分页器

vue+drf+第三方滑动验证码的接入实现

数据分析之Numpy入门

剖析和解决Python中网络粘包的正确姿势

drf序列化器之反序列化的数据验证

Django之URL反向解析

Golang​

浅谈GoPath和Go Modules包管理

Golang格式化输出

Golang数据类型之数组

Golang数据类型之切片

浅谈float浮点型的底层存储与运算

Golang数据类型之Map

Golang函数参数的值传递和引用传递

Golang结构体类型的深浅拷贝

Golang数据类型之指针

Golang单元测试

Golang基准测试

Golang数据类型之结构体-上篇

Golang数据类型之结构体-下篇

Golang文件操作-上篇

Golang文件操作-下篇

Golang开发命令行工具之flag包的使用

Golang接口类型-上篇

Golang接口类型-下篇

Golang反射-上篇

Golang反射-下篇

Golang与散列算法

Golang与对称加密

Golang与非对称加密

数据库相关​

MySQL工具Atlas的安装使用

MySQL多实例的部署

MySQL MHA部署与测试-上篇

MySQL MHA部署与测试-下篇

MySQL备份工具之Xtrabackup

MySQL基于Binlog的数据恢复实战

数据库中间件Mycat的安装使用

Centos7静默安装Oracle11g

Git相关​

使用git-svn无损迁移SVN至GitLab

Git目录为什么这么大

利用Git钩子实现代码发布

Linux相关​

Squid代理及常见的代理上网

非LVM的xfs文件系统扩容

DNS or hosts ？

Tomcat调优整理

利用GoAccess分析web服务日志

LVS负载均衡之DR模式

LVS负载均衡之NAT模式

Nginx 目录浏览基础与进阶

其他杂文​

我的生产力工具推荐-终端01篇

我的生产力工具推荐-IDE插件篇

Mac + VMware Fusion + Windows11尝鲜

Mac下iTerm2配置lrzsz功能

写在 2021 快要结束的夏天

年度总结就到这里

感谢身边时长陪伴与关心的人，感谢这一年来遇到的人和事，感谢所有公众号读者

新的一年继续保持初心，向大家分享更好的内容，一起进步

非对称加密介绍​

非对称加密和对称加密不同，主要区别如下

• 使用公钥加密，使用私钥解密

• 公钥和私钥不同

• 公钥可以公布给所有人

• 私钥只有自己保存

• 相比于对称加密，运算速度非常慢

加密过程：明文+公钥——>密文 解密过程：密文+私钥——>明文

非对称加密算法常用于数据加密和身份认证, 常见的非对称加密算法如下

• RSA: 由RSA公司发明，是一个支持变长密钥的公共密钥算法，需要加密的文件块的长度也是可变的

• DSA(Digital Signature Algorithm): 数字签名算法，是一种标准的DSS(数字签名标准)

• ECC(Elliptic Curves Cryptography): 椭圆曲线密码编码学

• ECDSA(Elliptic Curve Digital Signature Algorithm): 基于椭圆曲线的DSA签名算法

DSA​

DSA是基于整数有限域离散对数难题的，其安全性与RSA相比差不多。DSA的一个重要特点是两个素数公开，这样，当使用别人的p和q时，即使不知道私钥，你也能确认它们是否是随机产生的，还是作了手脚。RSA算法却做不到，但是其缺点就是只能用于数字签名，不能用于加密

RSA​

在1976年，由于对称加密算法已经不能满足需要，Diffie和Hellman发表了一篇叫《密码学新动向》的文章，介绍了公匙加密的概念，由Rivet、Shamir、Adelman提出了RSA算法 RSA是目前最有影响力的公钥加密算法，它能够抵抗到目前为止已知的绝大多数密码攻击，已被ISO推荐为公钥数据加密标准

命名：Ron Rivest、Adi Shamir、Leonard Adleman

• 密钥越长，越难破解，目前768位的密钥还无法破解（至少没人公开宣布），因此可以认为1024位的RSA密钥基本安全，2048位的密钥极其安全
• RSA的算法原理主要用到了数论

RSA的加密过程​

1、随机选择两个不相等的质数p和q，p=61，q=53

2、计算p和q的乘积，n=3233

3、计算n的欧拉函数∅(n) = (p-1)(q-1)，∅(n)=3120

4、随机选择一个整数e，使得1 < e < ∅(n)，且e与∅(n)互质，e=17

5、计算e对于∅(n)的模反元素d，即求解e*d + ∅(n)*y =1，d=2753，y=-15

6、将n和e封装成公钥，n和d封装成私钥，公钥=(3233, 17)，私钥=(3233, 2753)

调用示例​

RSA使用示例代码

package main
import (
	"crypto/rand"
	"crypto/rsa"
	"crypto/sha1"
	"crypto/x509"
	"encoding/pem"
	"fmt"
)
// 使用对方的公钥的数据, 只有对方的私钥才能解开
func encrypt(plain string, publicKey string) (cipherByte []byte, err error) {
	msg := []byte(plain)
	// 解码公钥
	pubBlock, _ := pem.Decode([]byte(publicKey))
	// 读取公钥
	pubKeyValue, err := x509.ParsePKIXPublicKey(pubBlock.Bytes)
	if err != nil {
		panic(err)
	}
	pub := pubKeyValue.(*rsa.PublicKey)
	// 加密数据方法: 不用使用EncryptPKCS1v15方法加密,源码里面推荐使用EncryptOAEP, 因此这里使用安全的方法加密
	encryptOAEP, err := rsa.EncryptOAEP(sha1.New(), rand.Reader, pub, msg, nil)
	if err != nil {
		panic(err)
	}
	cipherByte = encryptOAEP
	return
}
// 使用私钥解密公钥加密的数据
func decrypt(cipherByte []byte, privateKey string) (plainText string, err error) {
	// 解析出私钥
	priBlock, _ := pem.Decode([]byte(privateKey))
	priKey, err := x509.ParsePKCS1PrivateKey(priBlock.Bytes)
	if err != nil {
		panic(err)
	}
	// 解密RSA-OAEP方式加密后的内容
	decryptOAEP, err := rsa.DecryptOAEP(sha1.New(), rand.Reader, priKey, cipherByte, nil)
	if err != nil {
		panic(err)
	}
	plainText = string(decryptOAEP)
	return
}
func test() {
	msg := "Content bo be encrypted!"
	// 获取公钥, 生产环境往往是文件中读取, 这里为了测试方便, 直接生成了.
	publicKeyData := `-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZsfv1qscqYdy4vY+P4e3cAtmv
ppXQcRvrF1cB4drkv0haU24Y7m5qYtT52Kr539RdbKKdLAM6s20lWy7+5C0Dgacd
wYWd/7PeCELyEipZJL07Vro7Ate8Bfjya+wltGK9+XNUIHiumUKULW4KDx21+1NL
AUeJ6PeW+DAkmJWF6QIDAQAB
-----END PUBLIC KEY-----
`
	// 获取私钥
	privateKeyData := `-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDZsfv1qscqYdy4vY+P4e3cAtmvppXQcRvrF1cB4drkv0haU24Y
7m5qYtT52Kr539RdbKKdLAM6s20lWy7+5C0DgacdwYWd/7PeCELyEipZJL07Vro7
Ate8Bfjya+wltGK9+XNUIHiumUKULW4KDx21+1NLAUeJ6PeW+DAkmJWF6QIDAQAB
AoGBAJlNxenTQj6OfCl9FMR2jlMJjtMrtQT9InQEE7m3m7bLHeC+MCJOhmNVBjaM
ZpthDORdxIZ6oCuOf6Z2+Dl35lntGFh5J7S34UP2BWzF1IyyQfySCNexGNHKT1G1
XKQtHmtc2gWWthEg+S6ciIyw2IGrrP2Rke81vYHExPrexf0hAkEA9Izb0MiYsMCB
/jemLJB0Lb3Y/B8xjGjQFFBQT7bmwBVjvZWZVpnMnXi9sWGdgUpxsCuAIROXjZ40
IRZ2C9EouwJBAOPjPvV8Sgw4vaseOqlJvSq/C/pIFx6RVznDGlc8bRg7SgTPpjHG
4G+M3mVgpCX1a/EU1mB+fhiJ2LAZ/pTtY6sCQGaW9NwIWu3DRIVGCSMm0mYh/3X9
DAcwLSJoctiODQ1Fq9rreDE5QfpJnaJdJfsIJNtX1F+L3YceeBXtW0Ynz2MCQBI8
9KP274Is5FkWkUFNKnuKUK4WKOuEXEO+LpR+vIhs7k6WQ8nGDd4/mujoJBr5mkrw
DPwqA3N5TMNDQVGv8gMCQQCaKGJgWYgvo3/milFfImbp+m7/Y3vCptarldXrYQWO
AQjxwc71ZGBFDITYvdgJM1MTqc8xQek1FXn1vfpy2c6O
-----END RSA PRIVATE KEY-----
`
	cipherData, err := encrypt(msg, publicKeyData)
	if err != nil {
		panic(err)
	}
	fmt.Printf("encrypt message: %x\n", cipherData)
	plainData, err := decrypt(cipherData, privateKeyData)
	if err != nil {
		panic(err)
	}
	fmt.Printf("decrypt message:%s\n", plainData)
}
func main() {
	test()
}

ECC​

ECC又称椭圆曲线加密

ECC（Elliptic Curve Cryptography）椭圆曲线加密算法，相比RSA，ECC可以使用更短的密钥，来实现与RSA相当或更高的安全

定义了椭圆曲线上的加法和二倍运算

椭圆曲线依赖的数学难题是：k为正整数，p是椭圆曲线上的点（称为基点），k*p=Q，已知Q和P，很难计算出k

ECC是建立在基于椭圆曲线的离散对数的难度, 大概过程如下：

给定椭圆曲线上的一个点P，一个整数k，求解Q=kP很容易；给定一个点P、Q，知道Q=kP，求整数k确是一个难题。ECDH即建立在此数学难题之上

今天只有短的RSA钥匙才可能被强力方式解破。到2008年为止，世界上还没有任何可靠的攻击RSA算法的方式。只要其钥匙的长度足够长，用RSA加密的信息实际上是不能被解破的。但在分布式计算和量子计算机理论日趋成熟的今天，RSA加密安全性受到了挑战

随着分解大整数方法的进步及完善、计算机速度的提高以及计算机网络的发展，为了保障数据的安全，RSA的密钥需要不断增加，但是，密钥长度的增加导致了其加解密的速度大为降低，硬件实现也变得越来越难以忍受，这对使用RSA的应用带来了很重的负担，因此需要一种新的算法来代替RSA

1985年N.Koblitz和Miller提出将椭圆曲线用于密码算法，根据是有限域上的椭圆曲线上的点群中的离散对数问题ECDLP。ECDLP是比因子分解问题更难的问题，它是指数级的难度

椭圆曲线算法因参数不同有多种类型, 这个网站列出了现阶段那些ECC是相对安全的:椭圆曲线算法安全列表, 而curve25519便是其中的佼佼者

Curve25519/Ed25519/X25519是著名密码学家Daniel J. Bernstein在2006年独立设计的椭圆曲线加密/签名/密钥交换算法, 和现有的任何椭圆曲线算法都完全独立 特点是：

• 完全开放设计: 算法各参数的选择直截了当，非常明确，没有任何可疑之处，相比之下目前广泛使用的椭圆曲线是NIST系列标准，方程的系数是使用来历不明的随机种子 c49d3608 86e70493 6a6678e1 139d26b7 819f7e90 生成的，非常可疑，疑似后门；
• 高安全性： 一个椭圆曲线加密算法就算在数学上是安全的，在实用上也并不一定安全，有很大的概率通过缓存、时间、恶意输入摧毁安全性，而25519系列椭圆曲线经过特别设计，尽可能的将出错的概率降到了最低，可以说是实践上最安全的加密算法。例如，任何一个32位随机数都是一个合法的X25519公钥，因此通过恶意数值攻击是不可能的，算法在设计的时候刻意避免的某些分支操作，这样在编程的时候可以不使用if ，减少了不同if分支代码执行时间不同的时序攻击概率，相反， NIST系列椭圆曲线算法在实际应用中出错的可能性非常大，而且对于某些理论攻击的免疫能力不高， Bernstein 对市面上所有的加密算法使用12个标准进行了考察， 25519是几乎唯一满足这些标准的；
• 速度快: 25519系列曲线是目前最快的椭圆曲线加密算法，性能远远超过NIST系列，而且具有比P-256更高的安全性；
• 作者功底深厚: Daniel J. Bernstein是世界著名的密码学家，他在大学曾经开设过一门 UNIX 系统安全的课程给学生，结果一学期下来，发现了 UNIX 程序中的 91 个安全漏洞；他早年在美国依然禁止出口加密算法时，曾因为把自己设计的加密算法发布到网上遭到了美国政府的起诉，他本人抗争六年，最后美国政府撤销所有指控，目前另一个非常火的高性能安全流密码 ChaCha20 也是出自 Bernstein 之手；
• 下一代的标准: 25519系列曲线自2006年发表以来，除了学术界无人问津， 2013 年爱德华·斯诺登曝光棱镜计划后，该算法突然大火，大量软件，如OpenSSH都迅速增加了对25519系列的支持，如今25519已经是大势所趋，可疑的NIST曲线迟早要退出椭圆曲线的历史舞台，目前， RFC增加了SSL/TLS对X25519密钥交换协议的支持，OpenSSL 1.1也加入支持，是摆脱老大哥的第一步，下一步是将 Ed25519做为可选的TLS证书签名算法，彻底摆脱NIST

ECC与RSA的比较​

ECC和RSA相比，在许多方面都有对绝对的优势，主要体现在以下方面：

• 抗攻击性强。相同的密钥长度，其抗攻击性要强很多倍
• 计算量小，处理速度快。ECC总的速度比RSA、DSA要快得多
• 存储空间占用小。ECC的密钥尺寸和系统参数与RSA、DSA相比要小得多，意味着它所占的存贮空间要小得多。这对于加密算法在IC卡上的应用具有特别重要的意义
• 带宽要求低。当对长消息进行加解密时，三类密码系统有相同的带宽要求，但应用于短消息时ECC带宽要求却低得多。带宽要求低使ECC在无线网络领域具有广泛的应用前景

ECC的这些特点使它必将取代RSA，成为通用的公钥加密算法。比如SET协议的制定者已把它作为下一代SET协议中缺省的公钥密码算法

ECDSA​

因为在数字签名的安全性高, 基于ECC的DSA更高, 所以非常适合数字签名使用场景, 在SSH TLS有广泛使用, ECC把离散对数安全性高很少，所以ECC在安全领域会成为下一个标准

在golang的ssh库中就是使用这个算法来签名的：A使用自己的私钥签名一段数据，然后将公钥发放出去。用户拿到公钥后，验证数据的签名,如果通过则证明数据来源是A，从而达到身份认证的作用

package main

import (
	"crypto/ecdsa"
	"crypto/elliptic"
	"crypto/md5"
	"crypto/rand"
	"fmt"
	"hash"
	"io"
	"math/big"
)
// SignData 用于保存签名的数据
type SignData struct {
	r         *big.Int
	s         *big.Int
	signhash  *[]byte
	signature *[]byte
}
// 使用私钥签名一段数据
func sign(message string, privateKey *ecdsa.PrivateKey) (signData *SignData, err error) {
	// 签名数据
	var h hash.Hash
	h = md5.New()
	r := big.NewInt(0)
	s := big.NewInt(0)
	io.WriteString(h, message)
	signhash := h.Sum(nil)
	r, s, serr := ecdsa.Sign(rand.Reader, privateKey, signhash)
	if serr != nil {
		return nil, serr
	}
	signature := r.Bytes()
	signature = append(signature, s.Bytes()...)
	signData = &SignData{
		r:         r,
		s:         s,
		signhash:  &signhash,
		signature: &signature,
	}
	return
}
// 校验数字签名
func verifySign(signData *SignData, publicKey *ecdsa.PublicKey) (status bool) {
	status = ecdsa.Verify(publicKey, *signData.signhash, signData.r, signData.s)
	return
}
func test() {
	//使用椭圆曲线的P256算法,现在一共也就实现了4种,我们使用折中一种,具体见http://golang.org/pkg/crypto/elliptic/#P256
	pubkeyCurve := elliptic.P256()
	privateKey := new(ecdsa.PrivateKey)
	// 生成秘钥对
	privateKey, err := ecdsa.GenerateKey(pubkeyCurve, rand.Reader)
	if err != nil {
		panic(err)
	}
	var publicKey ecdsa.PublicKey
	publicKey = privateKey.PublicKey
	// 签名
	signData, err := sign("This is a message to be signed and verified by ECDSA!", privateKey)
	if err != nil {
		panic(err)
	}
	fmt.Printf("The signhash: %x\nThe signature: %x\n", *signData.signhash, *signData.signature)
	// 验证
	status := verifySign(signData, &publicKey)
	fmt.Printf("The verify result is: %v\n", status)
}
func main() {
	test()
}

See you ~

Terway网络介绍​

Terway是阿里云开源的基于专有网络VPC的容器网络接口CNI（Container Network Interface）插件，支持基于Kubernetes标准的网络策略来定义容器间的访问策略。可以通过使用Terway网络插件实现Kubernetes集群内部的网络互通

Terway网络插件将原生的弹性网卡分配给Pod实现Pod网络，支持基于Kubernetes标准的网络策略（Network Policy）来定义容器间的访问策略，并兼容Calico的网络策略

在Terway网络插件中，每个Pod都拥有自己网络栈和IP地址。同一台ECS内的Pod之间通信，直接通过机器内部的转发，跨ECS的Pod通信，报文通过VPC的弹性网卡直接转发。由于不需要使用VxLAN等的隧道技术封装报文，因此Terway模式网络具有较高的通信性能

一句话总结，Terway最大的特点就是借助于云上ECS服务器的特性，将pod与node的网络进行了拉平，同时使用VPC下vSwitch中的ip

问题现象​

由于使用了Terway网络模式，随着node机器和pod数量的增多，每分配一个ip出去都需要消耗掉vpc下vsw的可用ip。如果某短时间业务快速增长，导致pod大量消耗可用ip，这个时候就有可能因前期规划不充足导致vSwitch的可用ip不足

这个时候新创建的pod状态为ContainerCreating，describe查看pod提示error allocate ip...，这个时候查看Pod所在节点的Terway的日志，会有下面内容

Message: The specified VSwitch "vsw-xxxxx" has not enough IpAddress.

提示没有足够的ip，这个时候基本都是由于交换机的ip不够用，登录到交换机的控制台可以查看到这个节点所在的交换机的可用ip数，如果很少甚至为0，就表示需要扩容了

扩容操作​

新增交换机并配置NAT​

在专有网络管理控制台对应的VPC创建新的vSwitch，该vSwitch必须与IP资源不足的vSwitch在同一个区域。这是因为Terway分配给pod ip时的策略是，分配node所在可用区中的vSwitch对应的ip，因此，扩容就需要扩容同一可用区的交换机

在初始化集群新建交换机以及扩容交换机的时候都应该考虑，因Pod密度越来越大，为了满足Pod对IP地址日益增长的需求，建议创建给Pod使用的vSwitch的网络位小于等于19，即每个网段中至少包含8192个可用IP地址

vSwitch创建完成后，需要对这个vSwitch配置NAT策略，以便访问外部网络

配置集群的Terway​

配置集群的Terway，添加上面创建的vSwitch到Terway的ConfigMap配置中

kubectl -n kube-system edit cm eni-config

配置样例参考Terway配置参考，部分内容说明如下

apiVersion: v1
kind: ConfigMap
metadata:
  name: eni-config
  namespace: kube-system
data:
  10-terway.conf: |-
    {
      "cniVersion": "0.3.0",
      "name": "terway",
      "type": "terway"
    }
  disable_network_policy: "true"
  eni_conf: |-
    {
      "version": "1",  # 版本
      "max_pool_size": 80,  # 资源池最大水位
      "min_pool_size": 20,  # 资源池最小水位
      "credential_path": "/var/addon/token-config",
      "vswitches": {"cn-shanghai-f":["vsw-AAA", "vsw-BBB"]},  # 关联的虚拟交换机(ENI多IP模式)，添加vsw-BBB到VSwitches部分，其中vsw-AAA是已经存在的且IP资源不足的VSwitch
      "eni_tags": {"ack.aliyun.com":"xxxxxxxxx"},
      "service_cidr": "172.16.0.0/16",  # 服务CIDR
      "security_group": "sg-xxxxxxx", # 安全组ID
      "vswitch_selection_policy": "ordered"
    }

上面配置参数中，资源池水位的配置值。Terway使用底层虚拟化底层的网络资源打通容器网络，网络资源的创建和释放需要一系列的API调用，如果在Pod创建销毁时频繁调用API会导致Pod配置时间较长。 Terway通过池化的方式对资源进行缓存，当小于资源的池的最小水位时自动补充资源，在大于资源池最大水位时开始释放资源，这样保障了高效的资源利用和分配的效率

相当于预先分配了ip，具体设置可以考虑到所在机器节点规格支持的最大eni辅助网卡个数以及最大pod数灵活设置

重启terway​

重启所有Terway的pod以便快速刷新缓存生效

# kubectl -n kube-system delete pod -l app=terway-eniip
# kubectl -n kube-system get pod | grep terway

重启后检查异常的pod是否正常获取了ip即可

当排查某个pod的ip分配相关问题时，也可以通过进入到所在节点的terway pod中，执行命令行，查看当前已分配的ip情况，以及已经从vSwitch分配得来后，暂时空闲的ip情况

# terway-cli mapping
Status | Pod Name                                               | Res ID                           | Factory Res ID
Normal | node-problem-detector-l5h52                            | 00:16:10:48:3e:37.10.244.18.167 | 00:16:10:48:3e:37.10.244.18.167
...
Idle   |                                                        | 00:16:10:48:3e:37.10.244.18.132 | 00:16:10:48:3e:37.10.244.18.132
Idle   |                                                        | 00:16:10:48:3e:37.10.244.18.18  | 00:16:10:48:3e:37.10.244.18.18
Idle   |                                                        | 00:16:10:48:3e:37.10.244.18.54  | 00:16:10:48:3e:37.10.244.18.54

See you ~

对称加密介绍​

对称加密算法用来对敏感数据等信息进行加密，常用的算法包括：

• DES(Data Encryption Standard)：数据加密标准，速度较快，适用于加密大量数据的场合
• 3DES(Triple DES)：是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高
• AES(Advanced Encryption Standard)：高级加密标准，是下一代的加密算法标准，速度快，安全级别高
• CBC 分组加密的四种模式之一ECB、CBC、CFB、OFB

对称加密又分为分组加密和序列密码

• 分组密码，也叫块加密block cyphers，一次加密明文中的一个块。是将明文按一定的位长分组，明文组经过加密运算得到密文组，密文组经过解密运算（加密运算的逆运算），还原成明文组

• 序列密码，也叫流加密stream cyphers，一次加密明文中的一个位。是指利用少量的密钥（制乱元素）通过某种复杂的运算（密码算法）产生大量的伪随机位流，用于对明文位流的加密

对称加密的特点

• 加密过程每一步都是可逆的

• 加密和解密用的是同一组密钥

DES​

概述​

DES（Data Encryption Standard）数据加密标准，是目前最为流行的加密算法之一 DES是一种使用密钥加密的块算法，1977年被美国联邦政府的国家标准局确定为联邦资料处理标准FIPS，并授权在非密级政府通信中使用，随后该算法在国际上广泛流传开来

AES与3DES的比较

破解历史

历史上有三次对DES有影响的攻击实验。1997年，利用当时各国 7万台计算机，历时96天破解了DES的密钥。1998年，电子边境基金会（EFF）用25万美元制造的专用计算机，用56小时破解了DES的密钥。1999年，EFF用22小时15分完成了破解工作

主要思路​

对原始数据（明文）进行分组，每组64位bit，最后一组不足64位时按一定规则填充，每一组上单独施加DES算法

DES子密钥生成​

• 第一步

初始密钥64位，实际有效位56位，每隔7位有一个校验位 根据初始密钥生成16个48位的字密钥

密钥置换（打散），64——>56

例如，第57位放在第1个位置，第49位放在第2个位置，将顺序打乱并去除了校验位

• 第二步

左旋右旋，再次置换56——>48

DES加密过程​

明文——>初始置换——>L0(32位)、R0(32位)

S盒替换的逻辑 输入48位，输出32位，各分为8组，输入每组6位，输出每组4位 分别在每组上施加S盒替换，一共8个S盒

合并 L16(32位)、R16(32位)——>合并——>最终置换——>密文（64位）

使用示例​

/DesEncrypt DES加密
//密钥必须是64位，所以key必须是长度为8的byte数组
func DesEncrypt(text string, key []byte) (string, error) {
	if len(key) != 8 {
		return "", fmt.Errorf("DES加密算法要求key必须是64位bit")
	}
	block, err := des.NewCipher(key) //用des创建一个加密器cipher
	if err != nil {
		return "", err
	}
	src := []byte(text)
	blockSize := block.BlockSize()           //分组的大小，blockSize=8
	src = common.ZeroPadding(src, blockSize) //填充成64位整倍数

	out := make([]byte, len(src)) //密文和明文的长度一致
	dst := out
	for len(src) > 0 {
		//分组加密
		block.Encrypt(dst, src[:blockSize]) //对src进行加密，加密结果放到dst里
		//移到下一组
		src = src[blockSize:]
		dst = dst[blockSize:]
	}
	return hex.EncodeToString(out), nil
}

//DesDecrypt DES解密
//密钥必须是64位，所以key必须是长度为8的byte数组
func DesDecrypt(text string, key []byte) (string, error) {
	src, err := hex.DecodeString(text) //转成[]byte
	if err != nil {
		return "", err
	}
	block, err := des.NewCipher(key)
	if err != nil {
		return "", err
	}

	blockSize := block.BlockSize()
	out := make([]byte, len(src))
	dst := out
	for len(src) > 0 {
		//分组解密
		block.Decrypt(dst, src[:blockSize])
		src = src[blockSize:]
		dst = dst[blockSize:]
	}
	out = common.ZeroUnPadding(out) //反填充
	return string(out), nil
}

分组模式​

• CBC（Cipher Block Chaining）密文分组链接模式，将当前明文分组与前一个密文分组进行异或运算，然后再进行加密
• 其他分组模式还有ECB、CTR、CFR、OFB

分组模式使用示例

func DesEncryptCBC(text string, key []byte) (string, error) {
	src := []byte(text)
	block, err := des.NewCipher(key) //用des创建一个加密器cipher
	if err != nil {
		return "", err
	}
	blockSize := block.BlockSize()           //分组的大小，blockSize=8
	src = common.ZeroPadding(src, blockSize) //填充

	out := make([]byte, len(src))                   //密文和明文的长度一致
	encrypter := cipher.NewCBCEncrypter(block, key) //CBC分组模式加密
	encrypter.CryptBlocks(out, src)
	return hex.EncodeToString(out), nil
}

func DesDecryptCBC(text string, key []byte) (string, error) {
	src, err := hex.DecodeString(text) //转成[]byte
	if err != nil {
		return "", err
	}
	block, err := des.NewCipher(key)
	if err != nil {
		return "", err
	}

	out := make([]byte, len(src))                   //密文和明文的长度一致
	encrypter := cipher.NewCBCDecrypter(block, key) //CBC分组模式解密
	encrypter.CryptBlocks(out, src)
	out = common.ZeroUnPadding(out) //反填充
	return string(out), nil
}

AES​

AES（Advanced Encryption Standard）高级加密标准，旨在取代DES

2000年10月，NIST(美国国家标准和技术协会)宣布通过从15种侯选算法中选出的一项新的密匙加密标准。Rijndael被选中成为将来的AES。 Rijndael是在1999年下半年，由研究员Joan Daemen和Vincent Rijmen创建的。AES正日益成为加密各种形式的电子数据的实际标准 并于2002年5月26日制定了新的高级加密标准AES规范

算法原理

AES算法基于排列和置换运算。排列是对数据重新进行安排，置换是将一个数据单元替换为另一个。AES使用几种不同的方法来执行排列和置换运算。 AES是一个迭代的、对称密钥分组的密码，它可以使用128、192和256位密钥，并且用128位（16字节）分组加密和解密数据。与公共密钥密码使用密钥对不同，对称密钥密码使用相同的密钥加密和解密数据。通过分组密码返回的加密数据的位数与输入数据相同。迭代加密使用一个循环结构，在该循环中重复置换和替换输入数据

综上看来AES安全度最高, 基本现状就是AES已经替代DES成为新一代对称加密的标准

AES使用示例

package main
import (
	"crypto/aes"
	"crypto/cipher"
	"fmt"
)
var commonIV = []byte{0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}
func encrypt(plainText string, keyText string) (cipherByte []byte, err error) {
	// 转换成字节数据, 方便加密
	plainByte := []byte(plainText)
	keyByte := []byte(keyText)
	// 创建加密算法aes
	c, err := aes.NewCipher(keyByte)
	if err != nil {
		return nil, err
	}
	//加密字符串
	cfb := cipher.NewCFBEncrypter(c, commonIV)
	cipherByte = make([]byte, len(plainByte))
	cfb.XORKeyStream(cipherByte, plainByte)
	return
}
func decrypt(cipherByte []byte, keyText string) (plainText string, err error) {
	// 转换成字节数据, 方便加密
	keyByte := []byte(keyText)
	// 创建加密算法aes
	c, err := aes.NewCipher(keyByte)
	if err != nil {
		return "", err
	}
	// 解密字符串
	cfbdec := cipher.NewCFBDecrypter(c, commonIV)
	plainByte := make([]byte, len(cipherByte))
	cfbdec.XORKeyStream(plainByte, cipherByte)
	plainText = string(plainByte)
	return
}
func main() {
	plain := "The text need to be encrypt."
	// AES 规定有3种长度的key: 16, 24, 32分别对应AES-128, AES-192, or AES-256
	key := "abcdefgehjhijkmlkjjwwoew"
	// 加密
	cipherByte, err := encrypt(plain, key)
	if err != nil {
		fmt.Println(err)
	}
	fmt.Printf("%s ==> %x\n", plain, cipherByte)
	// 解密
	plainText, err := decrypt(cipherByte, key)
	if err != nil {
		fmt.Println(err)
	}
	fmt.Printf("%x ==> %s\n", cipherByte, plainText)
}