|
|
51CTO旗下网站
|
|
移步端
  • 脚下运维与面试领域有哪些新技术?

    今日我们的程序和服务越来越庞大,光是单元测试 TDD 等等的就已经很难保证质量,不过这些都是 baseline,故此今天聊点新的话题。

    笔者:黄东旭 来源:架构头条| 2020-01-21 21:48

    我以为面对测试的态势是区分一个寻常程序员和拔尖程序员的要害标准。

    今日我们的程序和服务越来越庞大,光是单元测试 TDD 等等的就已经很难保证质量,不过这些都是 baseline,故此今天聊点新的话题。

    说测试之前,咱们先问下团结,为什么要测试?当然是为了找 Bug。看上去这是句废话,但是仔细琢磨,如果我们能写出 Bug-free 的顺序不就好了吗?何必那么麻烦。不过 100% 的 bug-free 确认是不足的,这就是说我们有没有办法能够尽可能地提升我们先后的品质?

    举个比喻,我想到一个 Raft 的僵化算法,与其等实现后再测试,能不能在写代码前就掌握这个算法理论上有没有问题?主意其实是一些,那就是无证明技术,比起常用的是 TLA+。

    1. TLA+

    TLA+ 悄悄的思维很简单,TLA+ 会通过一套自己之 DSL(标志很接近数学语言)叙述程序的初始状态以及后续状态之间的更换关系,同时根据你的工作逻辑来定义在这些状态切换中的不变量,下一场 TLA+ 的 TLC model checker 对状态机的一切可达状态进行穷举,在穷举过程中不断检验不变量约束是否被破坏。

    举个简单的例证,分布式事务最简单的两阶段提交算法,对于 TLA+ Spec 来说,要求你定义好初始状态(例如事务要借鉴的 keys、有几个并发客户端等),下一场定义状态间跳转的借鉴( Begin / Write / Read / Commit 等),说到底定义不变量(例如任何处于 Committed 状态的 write ops 永恒是按照 commit timestamp 排序的,或者 Read 的借鉴一定不会读到脏数据之类的),写完以后放到 TLC Checker 其中运行,等待结果就好。

    但是,咱们活在一番不健全的时尚,即使你写出了圆满的关系,也很难保证你就是对的。着重, Simulator 并没有艺术模拟出无限多之 paticipants 和并发度, 普通也就是三五个;其次,聪慧的你可能也看出来了,普通 TLA+ 的放开文章也不会告诉你 Spec 的严重性是定义不变量,如果不变量定义不完备,或者定义出错,这就是说证明就是杯水车薪的。故此,我以为无验证的含义在于让工程师在写代码之前提高信心,在写证明的经过中也能更加剧对书法的了解,另外,如果在 TLC Checker 阴就跑出异常,那就更好了。

    脚下 PingCAP 有道是是国内唯一一个用到 TLA+ 证明关键算法,并且将关系的 Spec 开源出来的合作社,大家可以参考  pingcap/tla-plus  其一 Repo。

    2. Chaos Engineering

    如果完美的关系不存在,这就是说 Deterministic 的统考存在吗?我记得大概 2015 年在 PingCAP 建立前,我见到了一番 FoundationDB 关于他们的 Deterministic 高考的 发言。大概来说他们用自己之 IO 拍卖和多任务处理框架 Flow 名将代码逻辑和操作系统的点程以及 IO 借鉴解耦,并通过集群模拟器做到了全方位重现 Bug 出现时的风波顺序,同时可以在新石器中精确模拟各种异常,活生生很完美。但是考虑到现实的状况,咱们那时选择使用的编程语言主要是 Go,很难或者没有必要做类似 Flow 的作业 。故此我们挑选了副另一番方向解决这个题目,提升分布式环境下 Bug 的回信现率,能从容复现的 Bug 就能好解决,其一思路也是近年来几年很火的 Chaos Engineering。做 Chaos Engineering 的几个关键点:

    定义稳态,记录正常环境下的 workload 以及关心的要害指标。

    定义系统稳态后,咱们分为实验组和对待组进行试验,确认在良好的软件情况下,不顾操作实验组,说到底都会回归稳态。

    起来对底层的操作系统和网络进行破坏,再重复实验,考察实验组会不会回归稳态。

    道理大家都懂,但是实际做起来最大的题材在于如何将军全部流程自动化。原因在于:一是靠手动的频率很低;二是专业的 Chaos Engineering 强调的是在生养条件中操作,如何控制爆炸半径,这也是个比较重要的题材。

    先说第一个问题,PingCAP 在实行 Chaos Engineering 的早期,都是在物理机上通过脚本启停服务,整整实验都要求手动完成,耗资且非常低效,在电源利用上也十分不合理。其一题目我们认为正好是 K8s 异常擅长的,于是乎我们开发了一番基于 K8s 的,其间称为 Schrodinger 的无测试平台,名将 TiDB 集群的启停镜像化,此外将 TiDB 自己的 CI/CD,电气化测试用例的治本、Fault Injection 都统一了初步。其一项目还催生出一番好玩的专项 Chaos Operator:咱们通过 CRD 来叙 Chaos 的项目,下一场在不同之物理节点上启动一个 DaemonSets,其一 DaemonSets 就负责干扰 Pod,往对应的 Pod 其中注入一个 Sidecar,Sidecar 起咱进行注入错误(例如使用 Fuse 来模拟 IO 独特,修改 iptable 制造网络隔离等),破坏 Pod。不久前我们也有准备将 Chaos Operator 开源。

    其次个问题,其实在我瞅来,有 Chaos Engineering 仍然还是缺乏的,咱们在长时间的对测试和质量的研讨中发现提升测试质量的严重性是如何发现更多的统考 workload。在最初我们大量依赖了 MySQL 和相关社区的三合一测试,多少大概千万级别,其一决定让咱在高速迭代的同时保证质量,但是即使这样还是缺乏的,咱们也在主业学术界寻求答案. 例如引入并通过法定的 Jepsen Test ,再例如通过 SQLfuzz 机动生成合法 SQL 的话语加入到测试集中。

    总而言之,较之写作业逻辑,在分布式环境下写测试 + 写测试框架花费的生命力可能一点都不少,甚至可能多很多(如果就下代码量来说,TiDB 的统考相关的编码行数可能比内核代码行数多一个数量级),而且这是一番奇异值得研究和投资的园地。此外一个问题是如何通过测试发现性能回退。咱们的统考平台中每天运行着一个名为 benchbot 的机器人,那天的回归测试都会自动跑性能测试,相比之下每日的结果。也就是说我们的技术员就能迅速知道哪些变更导致了性能下降,以及得到一个长期性能变化趋势。

    3. eBPF

    说完测试,此外一个相关的命题是 profiling 和分布式 tracing。tracing 探望 Google 的 Dapper 和开源实现 OpenTracing 就大概能了解,故此,我第一聊聊 profiling。近些年这几年我关注的比较多之是 eBPF (extended BPF) 艺术。想象下,过去我们如果要付出一个 TCP filter,要么就自己写一个本驱动,要么就用 libpcap 等等的基于传统 BPF 的库,而传统 BPF 只是针对包过滤这个场面设计的虚拟机,很难定制和壮大。

    聊聊目前运维与测试领域有哪些新技术?

    聊聊目前运维与测试领域有哪些新技术?

    在这个背景下,eBPF 应运而生,eBPF 引入了 JIT 和寄存器,名将 BPF 的效应进一步壮大,这背后的含义是,咱们在基础中有一度安全的、高性能的、基于事件的、支持 JIT 的字节码的虚拟机!这其实极大地降落了进展内核能力的秘诀,咱们可以不用担心在驱动中写个非常把本搞崩,咱们也得以将给 llvm 用之 clang 直接编译成 eBPF 目标,镇区还有类似 bcc 这样的基于 Python 的适用工具集……

    过去其实大家是副系统状态监控、防火墙这个角度认识 eBPF 的。正确,性能监控以及防火墙确实是现阶段 eBPF 的王牌场景,但是我大胆地预测未来不止于此,就像最近 Brendan Gregg 在它的 blog 阴喊出的口号:BPF is a new type of software。可能在短短之前途,eBPF 镇区能诞生出更多好玩的东西,例如我们能不能用 eBPF 来做个超高性能的 web server?能不能做个 CDN 玉器?能不能用 BPF 来重定义操作系统的经过调度?我喜欢 eBPF 的另一番重要原因是,着重次内核应用开发者可以无视内核的项目和版本,只要内核能够运行 eBPF bytecode 就足以了,实际形成了一次编译,各国内核运行。故此有一种说法是 BPF is eating Linux,也不是没有道理 。

    PingCAP 也已经默默地在 BPF 镇区投入了很长时间,咱们也将团结做的组成部分 bcc 工具开源了,详情可以参考 pingcap/kdt  其一 repo。其中值得一提的是,咱们的 bcc 工具之一 drsnoop 把 Brendan Gregg 的新书收录了,也算是为灾区做出了某些微小的孝敬。

    地方聊的许多东西都是现实的技艺,艺术之出生离不开部署和运维,分布式系统之性状决定了保障的复杂度比单机系统大得多。在这个背景之下,我以为解法可能是:不可变基础设施。

    云和容器的推广让 infrastructure as code 的见解得以变成现实性,穿过讲述式的语言来创造可反复的调度体验,这样可选用的叙说其实很红火在开源社区共享,而且由于这些描述几乎是和现实的云的贯彻无关,对于跨云部署和混合数据中心部署之面貌很恰当。局部部署工具甚至诞生出团结之自然环境体系,例如 Terraform / Chef / Ansible。有一种说法戏称现在的运维工程师都是 yaml 语言工程师,其实很有道理的:人口总是会出错,且传统的基于 shell 剧本的运维部署受环境影响太大,shell 原始也不是一番奇异严谨的语言。叙述意图,让机器去干工作,才是能 scale 的正道。

    4. 笔者介绍

    黄东旭:分布式系统专家,架构师,开源软件作者。PingCAP 合并创始人兼 CTO,闻名开源项目 Codis / TiDB / TiKV 重点作者,曾就职于微软亚洲研究院,网易有道及豌豆荚。2015 年创业,建立 PingCAP,初来乍到下一代开源分布式必发娱乐登录的调研工作,擅长分布式存储系统设计与实现,高并发下端架构设计。

    【编纂推荐】

    1. 声明掌握核心技术,实则换皮Python?国产编程语言木兰引起社区热议
    2. GraphQL vs REST API 架构,哪个更胜一筹?
    3. 入职阿里5年,她如何破解“艺术债”?
    4. 写 Python 代码不可不知之函数式编程技术
    5. 为什么阿里P8、P9艺术大牛反复强调“布局化思维”?
    【义务编辑: 张燕妮 TEL:(010)68476606】

    点赞 0
  • 运维  架构  艺术
  • 分享:
    大家都在看
    猜你喜欢
  • 订阅专栏+更多

    Python使用场景实战手册

    Python使用场景实战手册

    Python使用场景实战手册
    共3章 | KaliArch

    19人口订阅学习

    一步到位玩儿透Ansible

    一步到位玩儿透Ansible

    Ansible
    共17章 | 骏马金龙1

    198人口订阅学习

    云架构师修炼手册

    云架构师修炼手册

    云架构师之必不可少技能
    共3章 | Allen在路上

    35人口订阅学习

    订阅51CTO邮刊

    点击这里查看样刊

    订阅51CTO邮刊

    51CTO劳务号

    51CTO官微

    <optgroup id="a70c64b0"></optgroup>

  •