朱赟的技术管理课
朱赟
计算机博士，前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
waltAirbnb是开发人员写测试用例，执行测试吗？上线前不回归测试吗？2017-12-27
mattlin喜欢这种平易近人的文章 👍2017-12-19
00最近浏览了后台架构，了解了下thrift、kafuka。看了安姐的分享，顿悟到thrift的无缝衔接。自己做的是桌面，了解系统的架构总觉是纸上谈兵。安姐的文章通俗易懂，因为有场景，即便是没从事过相关工作，也会理解相对深刻一些。
3ks2017-12-18
碰上这样的朋友团队构架对拆分也会很大影响2017-12-18
天之炽能不能着重讲讲招人2017-12-16
Edward朱老师，有开源的灰度发布工具和基于微服务的自动化测试工具推荐不2017-12-15
收起评论