朱赟的技术管理课
朱赟
计算机博士,前Airbnb技术经理
立即订阅
11176 人已学习
课程目录
已完结 39 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 | 从工程师到管理者,我的思考与实践
免费
01 | 职场分身术:从给答案到做引导
02 | Bug引发事故,该不该追究责任?
03 | 每个工程师都应该了解的:A/B测试
04 | 如何帮助团队成员成长
05 | 当我们给别人提意见时,要注意些什么?
06 | 每个工程师都应该了解的:聊聊幂等
07 | 当别人给我们提意见时,该如何应对?
08 | 说说硅谷公司中的一对一沟通
09 | 每个工程师都应该了解的:大数据时代的算法
10 | 项目延期了,作为负责人该怎么办?
11 | 管理和被管理:期望值差异
12 | 每个工程师都应该了解的:数据库知识
13 | 管理者在进行工作分配时,会考虑哪些问题?
14 | 硅谷人到底忙不忙?
15 | 每个工程师都应该了解的:系统拆分
16 | 技术人如何建立个人影响力?
17 | 管理者不用亲力亲为:关键是什么?
18 | 每个工程师都应该了解的:API 的设计和实现
19 | 硅谷面试:那些你应该知道的事儿
20 | 项目管理中的三个技巧
21 | 每个工程师都应该了解的:中美在支付技术和大环境下的差异
22 | 不要做微观的管理者
23 | 如何处理工作中的人际关系?
24 | 编程语言漫谈
25 | 兼容并包的领导方式
26 | 如何做自己的职场规划?
27 | 小议Java语言
28 | 如何激发团队人员的责任心
29 | 说说硅谷互联网公司的开发流程
30 | 编程马拉松
31 | 工程师、产品经理、数据工程师是如何一起工作的?
32 | 硅谷人如何做 Code Review
33 | 技术人的犯错成本
34 | 如何从错误中成长?
35 | 理解并建立自己的工作弹性
36 | 如何对更多的工作说“不”
尾声:成长不是顿悟,而是练习
新书 |《跃迁:从技术到管理的硅谷路径》
朱赟的技术管理课
登录|注册

15 | 每个工程师都应该了解的:系统拆分

朱赟 2017-12-15
四年前,我加入了风头正劲的 Square 公司。两年前,我又加入了涨势甚猛的 Airbnb 公司。在我加入的时候,这两个公司都有上百名的工程师,网站和主要产品的核心功能也已齐备。
两家创业公司从 0 到 1 的创业过程我并没有亲身经历,但是两次都恰好经历了公司从 1 到 N 的扩张过程和业务拆分的过程。
今天我就和你聊聊,公司从 1 到 N 发展过程中的系统拆分问题。

创业初期的代码现状

在 Square 刚刚起步的时侯,整个产品都是基于 Ruby on Rails 构建的,所有的产品和功能代码几乎都在一个代码库里。
等到我进入 Square 的时候,有一些服务已经从 Ruby 代码中分离出来了,形成了单独的 Java 或者 Ruby 服务,然而大部分功能还是在一大块 Ruby 代码里。
当时,几乎所有的工程师每天都在这一份基准代码(Code Base)里写程序。虽然有严格的代码审核过程和规范的开发流程,但是,不同功能的代码模块会产生交叉影响,不同工程师改动的模块会有重合或牵连,所以,系统还是会时不时出现问题。
那时候, Square 的做法是:在周五对本周所有的代码进行代码审查(Code Review),通过审查之后,把修改合并到主分支,然后再发布到生产环境。
这种做法虽然可以避免产生人为错误,但是非常不灵活,比如,每周只有周五有一次机会将改进的代码部署到线上。
可以想象一下,一百多名工程师,就算只有三分之一的人在这个代码池子里改代码,一周累积下来,已经有不少的改动了。
于是,当时 Square 有个系统管理员组(Sysops),专门负责每周五的部署。我也是工作近半年的时侯,因为表现不错才被荣幸地 “选拔” 进了这个 “特别行动小组”,承担部署的重任。
那么说,每次的部署是一幅什么样的场景呢?
部署开始的时候,一正一副两位工程师正襟危坐,多个显示器同时打开,进行各种指标监控。
工程师先将在测试环境中测试无误的代码部署到若干生产机器上,进行灰度发布,这就意味着有一部分用户的访问量会调用新代码。如果监控没有发现异常的话,再进行全量发布,这周修改的代码就会被部署到几百台机器上。
一旦出现异常,监控系统就开始各种红色告警,工程师们会立刻扔下手中的可乐或者咖啡,进入备战状态,停止系统,进行数据回滚、排查问题、修复,从头开始把流程再来一遍,直到代码安全地部署到线上并能够正常运行为止。
随后的两年,我们进行了细致的业务拆分,等到我离开 Square 的时候,大部分可以独立出来的服务都已经拆分出来,很多系统可以分别部署和上线,也就再没有了那种激动人心的周五上线日。
Airbnb 的情况也差不多,我刚加入的时候,代码状态甚至更原始一些。不同的是,Airbnb 没有一周只能部署一次代码的规矩,所有的工程师只要准备好了就可以做部署上线。
这样做的优点是可以快速迭代,每次部署的代码改动也很小,缺点是几乎任何时候都有人在部署代码。时时的部署也就意味着,红色告警随时可能在身边响起。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《朱赟的技术管理课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(18)

  • 刘剑
    技术管理课,讲这个稍微有点过于基础哦(包括前面的数据库片)。建议多讲讲团队、激励、培训、招聘、绩效等方面呀。
    2017-12-15
    19
  • 刘剑
    对于业务拆分的原则之一是:服务边界内的业务能力职责单一化,不是完成同一业务能力的模型不放在同一个上下文中。

    至于拆分的手段,我们用的是

    1.绞杀模式,就是在遗留系统外围,将新功能用新的方式构建为新的服务。随着时间的推移,新的服务逐渐“绞杀”完老的系统。对于那些老旧庞大难以更改的遗留系统,推荐采用绞杀者模式。

    2.修缮者模式就像修房子和修路一样,将老旧待修缮的部分进行隔离,用新的方式对其进行单独修复。修复的同时,需保证与其他部分仍能协同功能。App版本兼容上也多用此模式

    我们业务拆分的原则是:“旧的不变,新的创建,一步切换,旧的再见”
    2017-12-19
    15
  • whhbbq
    开发环境的成熟度、调试难度、日志查看、接口超时、异常处理,安姐列出的都是干货,都是系统拆分随之而来绕不过去的痛点。去年经历了公司系统的微服务化和一些模块的重构,看完文章后特别有感触。特别是修改代码后,有时本地需要起好多服务才能调试,一直是个痛点。公司只有一套公共使用的环境,上面部署的都是最新的主干代码。安姐提到google和facebook的开发环境比较成熟,他们是如何做到开箱即用呢?能否针对这些痛点,写写解决的方案?谢谢!
    2018-01-09
    1
    5
  • 系统拆分是任何到发展到中后期公司必须经历的过程,前期因为商业模式试错抢占市场等会快速上线快速迭代,前期公司也没多少牛人,各方面都是业务优先,在不知道自己能活多久前提下,谈什么服务化技术优化都是扯淡。随时公司发展一般2-3年还没死,随着业务量越来越大,系统增加新功能、系统维护成本越来越高,系统变得越来越不稳定,DB一直挑战极限,这个阶段重构服务化是必须介入了,拆分和服务化的具体问题文中大体都介绍了,至于什么原则来进行服务化,如何去确定服务边界,如果确定上下文大小,哪些功能该放在一个服务中,这些需要好好看看DDD-领域模型设计。什么阶段做什么样的事,遇到事了不怕事,事后会发现这些不过如此。
    2018-03-24
    3
  • 顾金鑫
    灰度发布的时候,新旧的数据库 schema 不一样,怎么数据迁移咧?新老系统同时存在,也就意味着会对库有两种写法…这可如何是好
    2017-12-15
    3
  • zhengfc
    拆起来容易,合起来成为一体就有挑战了
    2017-12-15
    3
  • 产品助理
    不要为了拆分而拆分,视业务实际痛点,人员实际水平综合考虑
    2017-12-15
    2
  • 张伟波
    系统拆分最佳时机是否是软件设计时,如果系统已经上线,因为没有拆分带来了大量的弊端,比如迭代发版总出各种各样的连带问题,是不是要考虑下架构的问题了?
    2017-12-15
    1
  • 柠檬树
    比较感兴趣的是airbnb是如何做技术创新的,因为经常看见你们各种技术大会都有露面,然后经常开源各种架构。不过你们的app确实做的好棒,不像国内的某程等眼花缭乱
    2019-11-15
  • 好像每次都是提出问题,然后没有答案?应该举个实际遇到过的场景让我们参考,比如多大并发,什么业务,到达什么指标需要执行什么样的操作等等,希望作者能把实际经验分享一下
    2018-11-16
  • GeekAmI
    这篇文章写的非常好,从望京一路看到西二旗。解答了很多困惑。
    2018-01-04
  • Dylan
    公司刚成立,我们现在的代码库就是一个大的代码库,工程师人少,每个客户端,后台,前段也就一两个工程师,所以目前每次部署变更正式环境还是可控的,而且业务逻辑也还没复杂到说要进行拆分的时候~看了作者的观点后,还是要准备着以后可能面临的这些拆分问题~
    2017-12-30
  • walt
    Airbnb是开发人员写测试用例,执行测试吗?上线前不回归测试吗?
    2017-12-27
  • mattlin
    喜欢这种平易近人的文章 👍
    2017-12-19
  • 00
    最近浏览了后台架构,了解了下thrift、kafuka。看了安姐的分享,顿悟到thrift的无缝衔接。自己做的是桌面,了解系统的架构总觉是纸上谈兵。安姐的文章通俗易懂,因为有场景,即便是没从事过相关工作,也会理解相对深刻一些。
    3ks
    2017-12-18
  • 碰上这样的朋友
    团队构架对拆分也会很大影响
    2017-12-18
  • 天之炽
    能不能着重讲讲招人
    2017-12-16
  • Edward
    朱老师,有开源的灰度发布工具和基于微服务的自动化测试工具推荐不
    2017-12-15
收起评论
18
返回
顶部