Python中国社区  »  Git

Git设计原理对业务系统设计与开发的启示

饿了么物流技术团队 • 2 月前 • 50 次点击  
阅读 84

Git设计原理对业务系统设计与开发的启示

作者简介

近铁Jeff Dean, 饿了么物流研发部搬砖工, 崇拜各种大牛, 由于Jeff Dean的作品深而广, 本文特意专注于小而美的Linus Torvalds 第二作品:Git, 希望从中汲取营养, 向大师致敬。

提示: 本文介绍Git核心优点和实现思路,重点引申出对业务系统设计与开发的启示; 由于篇幅有限,本文不详细介绍Git命令的具体执行细节,如果需要了解执行Git命令时,底层具体发生了什么, 请移步Git官方文档第十章 Git Internals

为什么关注Git?

Git作为一个前无古人,很可能后无来者的内容地址跟踪器 , 席卷各大公司,深受所有程序员喜爱(觉得Git难用的除外), 肯定有他的过人之处。

先搬出互联网技术关键词标配:

分布式、去中心化、可靠性、容错性、可用性、数据一致性、性能是一个功能, 而不是一个优化等。

Git都满足有木有! Linus用两周就实现自举的Git十几年后依然健壮如初。 假如我写一个接口或设计一个微服务或写一个小工具, 自带扩展技能,从来不挂,QPS暴增也无需推翻重构,外部依赖抖动时自动降级,数据量增大而没有拖垮性能, 能与Git有很多共同点,岂不很有成就感?

Git最初设计时要达到的目的

分布式:1)多人同一个分支不同地点不同时间并行开发;2)单人本地多分支并行开发。

性能: 速度要快。慢是Linus Torvalds本人无法接受的,因为linux内核每天有成百上千次提交。

安全与信任: 即可靠性, 我push上去的代码pull下来一定还是我的代码, 没有丢失或被恶意篡改过。

Git 数据建模

插播一条语录: Bad programmers worry about the code. Good programmers worry about data structures and their relationships. - by Linus Torvarlds. (一般的程序员只关心代码,而优秀的软件工程师更关心数据结构以及他们之间的关系。)

启示

Linus本人写C语言比较多,个人认为这里的data structures and their relationships 如果脱离C语言 的特定背景,可以泛指技术对场景或业务逻辑的抽象, 比如: 面向对象建模,领域驱动, 甚至更宏观的架构设计或微服务怎样划分。

根据个人经验,如果系统设计的好, 代码稍微写low一点,整个系统的表现也不会太差, 而且代码的坑比较容易填; 反之,再漂亮的代码也很难填上系统设计的坑, 只能面临重构。

Git 内部文件处理:

  1. 代码库里所有文件都是数据,以数据为中心,所有操作、存储和处理逻辑围绕数据展开。
  2. 跟踪整个项目整体状态,每次建立全局快照,而不是跟踪每个文件的变更。
  3. 针对git目录下的每个文件计算一个hash值, 文件内容作为value, hash值为文件key。
  4. 如果单个文件内容发生变化, 下次重新计算hash值。如果文件没有发生变更,当前快照指向历史hash。
  5. 整个代码库的变化历史和文件组成用树形结构表示。
  6. Git每次commit记录整个代码库的一次快照, 当前快照包含发生变化的文件和历史快照(子树)。
    图1 - Git数据建模
    Git数据建模

Git 执行效率与时间复杂度

对于Git内部结构可以简单的理解为: Git内部是一棵 , 每个节点都是一个指针(key), 这个指针(key)可能代表一个文件,或一次commit或一个分支起点或一次merge或一个tag, key对应的value就是内容, 如果key是代表一个文件, value就是文件内容; 如果key是代表一次commit, value是一颗子树, 包含此次commit对整个项目的snapshot。

平时很多git操作都可以近似理解为: 在树上执行遍历查找O(lg(n)),切换指针O(1),然后根据指针取文件内容O(1))。 这些操作速度都是很快的,只有在网络交互,文件压缩与解压和计算diff时,人肉可以感知到有时间等待。

启示

  1. 数据结构和算法原来是这么用的,基本功还是要扎实呀。
  2. LeetCode还是要常刷的。
  3. 建模很重要。越好的设计模型离被推翻重构的距离越远。 关于架构设计和规划的 做技术选型和概要设计,P7级别的就要做到, 1年以后当别人接手时就不需要考虑重构,如果是P8的就有信心做到2年以后,而P9的则是3年或更长时间。 Git已经经历了超过10年的考验了。

Git 空间压缩与访问效率平衡

对于Git,近期发生变化的数据属于热数据,Git假设这些数据会被频繁访问或使用到。其他数据为历史数据。 对于热数据, 即使发生微小变化,Git也会全量冗余存储,提高访问效率。 当热数据文件数量达到一定值时,会触发打包压缩逻辑, delta差异存储,节省空间。

启示

对于不同的存储介质,例如db, redis, mq, 选用不同的存储逻辑或策略,以达到访问效率与存储空间的平衡。

Git 安全性与容错性

Git对文件内容和项目整体snapshot都使用hash值表示,hash值与内容一一对应, 如果文件内容被篡改或硬盘损坏 导致数据丢失,hash值校验都会失败。 此时Git设计时已经假设:

  1. 硬盘是随时崩溃的,即存储是不可靠的
  2. 有人恶意引入Bug或偷偷修改代码

启示

在分布式环境下,设计系统或接口,能否保持容错性,自带降级,建议多向自己提出假设:

  1. 网络是不可靠的。 接口调用timeout和失败是必然存在的, 逻辑应该怎样处理?是否自带降级技能。
  2. DB是会抖动的,缓存也会失效,主从延迟一定存在的,此时代码逻辑能否兼容?如果fail fast, 是否有报警机制?
  3. 对外的接口,调用方的传参要考虑最坏的场景,是否有合理的入参校验/防重/幂等处理?

Merge 算法思想: 三路合并

先找出两个分支的公共祖先, 然后两个分支分别与公共祖先diff,指出有冲突的地方。 Git merge并没有试图智能的去解决冲突,只是指出冲突,然后将merge交给最合适最高效的人去解决: 即引起冲突的开发者。

启示

  1. 选用最合理的数据结构、索引结构或算法思路,不断优化系统处理速度。
  2. 划清边界,只做自己最擅长和应该做的事情, 尽量保证高内聚,低耦合 。 微服务环境下,在设计系统时,应该多考虑: 各个服务调用时,不同的异常谁负责处理; 接口超时谁负责补偿; 数据一致性交给谁来保证等。

Linus Torvalds眼中好的代码和好的软件工程师

好的软件工程师要有good taste, 坚持不懈的追求用正确的方式解决问题。

好的代码, 举个例子:移除链表中某个节点

一般的代码, 用if else 判断边界值:

void remove_list_entry(entry)
{
    prev = NULL;
    walk = head;

    // Walk the list
    while (walk != entry){
        prev = walk;
        walk = walk->next;
    }

    //Remove the entry by updating the
    //head or the previous entry

    if(!prev)
        head = entry->next;
    else
        prev->next = entry->next;
}
复制代码

好的代码, 换一种写法,使正常处理逻辑可以兼容边界值:

void remove_list_entry(entry)
{
    //The "indirect" pointer points to the
    // *address* of the thing we'll update

    indirect = &head;

    //Walk the list,looking for the thing that
    //points to the entry we want to remove

    while ((*indirect) != entry)
        indirect = &(*indirect)->next;

    // .. and just remove it
    *indirect = entry->next
}

复制代码

启示

平时编码中对边界值的处理是否优雅?

现在一个变量的传递会经过多种编程语言和中间件,中间过程一般有序列化和反序列化, 给空对象赋默认值等逻辑, 怎样保证实际结果与预想的完全一致? 边界值处理不好,一是代码不好维护,二是容易引入Bug。 日常碰到的边界值有: null, int默认值0等。

其他

  1. 从用户角度出发设计系统。Linus是Git的第一个也是最粘性的用户, 在写Git之前他就已经了解了当时的各个版本控制 软件的优缺点,他清楚Git需要实现哪些功能, 哪些功能无需实现。
  2. Git在命令行执行命令时,响应的提示信息及时且准确。
  3. 站在巨人肩膀上,向已有系统学习。Git最初的核心命令都是复用操作系统已有的功能,例如diff, 压缩,文件处理等。

启示

  1. 自己写的系统或功能,自己要从最终用户角度尝试使用或模拟使用。
  2. 对于api接口,研发负责自测; 写单元测试时,可以从调用方角度思考接口名称和参数设计是否合理,是否抛出异常, 返回信息中是否包含错误码和提示信息。
  3. [既要有造轮子的能力,又要有不重复造轮子的觉悟] (www.zhihu.com/question/31…)。 多向开源系统学习,多研究底层原理,大部分原理或设计思路都是相通的。

彩蛋

(如下为Linus Torvalds语录,仅供娱乐。 Linus Torvalds以喷人闻名,网络上很多人指责他人品不行, 很少有人评价他的技术水平,可能是没有能力评价吧。)

  1. "In fact, I am a very cynical and untrusting person. I think most of you are completely incompetent". In front of a large group of Google developers. 翻译:在一群谷歌软件工程师面前说: 各位不要误会, 我不是针对你, 我是说在座的各位写代码的水平完全都是垃圾。
  2. "Because nobody actually creates perfect code at first time around except me, but there's only one of me. " 翻译:实际上没人能一次就写出完美的代码,除了我。但是世界上只有一个我。ps: 这句话也是在一群谷歌软件工程师面前说的。

参考

  1. Linus Torvalds 2007年在谷歌分享Git
  2. Linus Torvalds TED 采访
  3. Git官方文档





阅读博客还不过瘾?

欢迎大家扫二维码通过添加群助手,加入交流群,讨论和博客有关的技术问题,还可以和博主有更多互动

博客转载、线下活动及合作等问题请邮件至 shadowfly_zyl@hotmail.com 进行沟通


今天看啥 - 高品质阅读平台
本文地址:http://www.jintiankansha.me/t/SFCr2Co62V
Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/27726
 
50 次点击  
分享到微博