从单体系统到微服务

极客时间《朱赟的技术管理课》学习笔记 12

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

2018

我个人的经验中并没有遇到过系统需要拆分的情况，感觉有点可惜，白忙活了这么多年。如果将来真的如愿成为了自由职业者，那么估计需要进行系统拆分的情况也不会太多。

接触到的系统，应该都还是处于复杂性比较低的情况（人为造成的复杂度不计算在内）；但是系统拆分的思想，还是应该有的。

比较喜欢持续集成和持续交付的愿景，但是目前自己还做不到单元测试代码的完全覆盖，在这种情况下，似乎系统拆分无从谈起。

现在比较流行微服务的做法，不过似乎在目前的单位并不适用。

2021

不光是创业公司，估计一般的公司或者项目都是从一大坨代码开始的。如果侥幸能够生存下去，运气好的话，会发展到需要做系统拆分的时候；运气不好，会在不需要的时候，遇到一个热衷于微服务的架构师。

在我的印象里，国内的公司很多都没有测试覆盖，那么拆分起系统来，真的只能听天由命了。这大概也是大部分项目，都是另起炉灶，而不是在原有系统上拆分改造的原因。

如果有完整的测试流程，哪怕是手工测试，那么拆分的时候，至少也会有一张保护网。

测试、接口、报错、日志、超时、代码……打怪升级

如果有机会，还是希望有机会旁观或者操盘一次系统拆分，但愿不要至于太过难看，以至于删库跑路。

在网络上没有找到系统拆分对应的英文单词，更多的是从 monolithic 到 microservices，但是有多少单体架构真的需要拆分到微服务的粒度呢？特别是一些用户数和并发数都不是特别高的企业内部系统。