朱赟的技术管理课
朱赟
计算机博士,前 Airbnb 技术经理
48935 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 39 讲
时长 13:23
时长 13:31
朱赟的技术管理课
15
15
1.0x
00:00/00:00
登录|注册

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

拆分计划的谨慎性
开发人员经验
业务量和复杂度
超时设置
日志的完整性
报错的处理
接口相关的改动
测试复杂性
代码自由与标准化
超时设置
异常处理和日志
接口相关的改动需要协调
服务拆分后的测试复杂性
集成测试
微服务的效率
复杂度与效率的关系
代码审查和部署
代码库结构
如何去判断系统是不是到了必须进行拆分和服务化的临界点
业务拆分时的注意事项
业务拆分并不像看起来那么简单
为什么系统需要进行业务拆分
创业初期的代码现状
系统拆分
参考文章

该思维导图由 AI 生成,仅供参考

四年前,我加入了风头正劲的 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/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

在这篇文章中,作者分享了创业公司从1到N发展过程中的系统拆分问题。文章首先介绍了创业初期代码的现状,指出单一代码库的不足之处,并介绍了业务拆分的必要性。随后,作者详细讨论了业务拆分的复杂性,以及在拆分过程中需要注意的事项。文章通过举例说明了业务拆分的挑战和解决方案,强调了系统拆分后的痛点。作者还提到了测试复杂性、接口相关改动的协调、报错处理、日志完整性以及超时设置等问题。最后,作者分享了如何判断系统是否需要进行拆分和服务化的临界点。整篇文章以实际经历为基础,深入浅出地介绍了系统拆分的技术特点,对于工程师了解系统拆分问题具有一定的参考价值。文章内容丰富,涵盖了系统拆分的各个方面,对于面临类似问题的读者具有很强的指导意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《朱赟的技术管理课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(21)

  • 最新
  • 精选
  • 刘剑
    技术管理课,讲这个稍微有点过于基础哦(包括前面的数据库片)。建议多讲讲团队、激励、培训、招聘、绩效等方面呀。
    2017-12-15
    1
    34
  • 刘剑
    对于业务拆分的原则之一是:服务边界内的业务能力职责单一化,不是完成同一业务能力的模型不放在同一个上下文中。 至于拆分的手段,我们用的是 1.绞杀模式,就是在遗留系统外围,将新功能用新的方式构建为新的服务。随着时间的推移,新的服务逐渐“绞杀”完老的系统。对于那些老旧庞大难以更改的遗留系统,推荐采用绞杀者模式。 2.修缮者模式就像修房子和修路一样,将老旧待修缮的部分进行隔离,用新的方式对其进行单独修复。修复的同时,需保证与其他部分仍能协同功能。App版本兼容上也多用此模式 我们业务拆分的原则是:“旧的不变,新的创建,一步切换,旧的再见”
    2017-12-19
    28
  • 系统拆分是任何到发展到中后期公司必须经历的过程,前期因为商业模式试错抢占市场等会快速上线快速迭代,前期公司也没多少牛人,各方面都是业务优先,在不知道自己能活多久前提下,谈什么服务化技术优化都是扯淡。随时公司发展一般2-3年还没死,随着业务量越来越大,系统增加新功能、系统维护成本越来越高,系统变得越来越不稳定,DB一直挑战极限,这个阶段重构服务化是必须介入了,拆分和服务化的具体问题文中大体都介绍了,至于什么原则来进行服务化,如何去确定服务边界,如果确定上下文大小,哪些功能该放在一个服务中,这些需要好好看看DDD-领域模型设计。什么阶段做什么样的事,遇到事了不怕事,事后会发现这些不过如此。
    2018-03-24
    6
  • whhbbq
    开发环境的成熟度、调试难度、日志查看、接口超时、异常处理,安姐列出的都是干货,都是系统拆分随之而来绕不过去的痛点。去年经历了公司系统的微服务化和一些模块的重构,看完文章后特别有感触。特别是修改代码后,有时本地需要起好多服务才能调试,一直是个痛点。公司只有一套公共使用的环境,上面部署的都是最新的主干代码。安姐提到google和facebook的开发环境比较成熟,他们是如何做到开箱即用呢?能否针对这些痛点,写写解决的方案?谢谢!
    2018-01-09
    1
    5
  • 顾金鑫
    灰度发布的时候,新旧的数据库 schema 不一样,怎么数据迁移咧?新老系统同时存在,也就意味着会对库有两种写法…这可如何是好
    2017-12-15
    3
  • zhengfc
    拆起来容易,合起来成为一体就有挑战了
    2017-12-15
    3
  • 张伟波
    系统拆分最佳时机是否是软件设计时,如果系统已经上线,因为没有拆分带来了大量的弊端,比如迭代发版总出各种各样的连带问题,是不是要考虑下架构的问题了?
    2017-12-15
    1
    2
  • 产品助理
    不要为了拆分而拆分,视业务实际痛点,人员实际水平综合考虑
    2017-12-15
    2
  • GeekAmI
    这篇文章写的非常好,从望京一路看到西二旗。解答了很多困惑。
    2018-01-04
    1
  • 留白
    客户端拆库也是一样,开发层面的通信、调用是个问题,考虑输入输出的模拟测试更是个大问题
    2021-10-11
收起评论
显示
设置
留言
21
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部