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