大萧条时期的野蛮生长——微服务拆分

一起养成写作习惯！这是我参与「掘金日新计划·4月更文挑战」的第11天，点击查看活动详情。

微服务这个词我大概是从2016年开始就听说了，时至今日我依然无法认同它算是一种所谓的架构方法。可能主要是给行内人的交流提供了谈资，然后在老板面前要了更多的hc。本质上说，微服务只是将原来大的服务拆小，这在这个概念出来之前早就有了，而且是和公司的组织架构强关联。

早期的微服务

但一个创业公司的规模开始逐步扩张时，原来单体部署的大应用可能还在持续的工作，但组织架构需要拆分的更细，部门的职能也需要做一些划分，然后这部分人会从原来的系统中“挖”走一部分功能的代码独立部署，然后与原来的大服务之间通过RPC调用相关联。这种服务拆分从互联网诞生就存在至今。这也是我对微服务最难以认同的点，这不就是改头换面吗？

真的需要拆吗

随着业务的发展，确实需要拆，而且即使没有部门的变更也会需要。但这件事没有统一的标准，可能当有些事让你的团队效率下降了很多，大家都很难受时，你就需要拆了。做架构的迭代，要么更稳定，要么更高效，如果只是徒增工作量，就没有意义了。可能部分年轻的开发者已经没有经历过那种部署一个服务，整个部门都很慌的时候了。因为所有的代码都揉在一起，任何一行变更都可能导致其他的未知问题，这就必须要拆了。

拆分原则

什么高内聚，低耦合都是人尽皆知的事，大家都想这样，那不如一个包拆成一个服务？1个服务拆成100个微服务，我也确实见过这样的极端例子，我只能说：搬起石头砸自己的脚。废话不多说，我总结一下我认为的拆分原则：

1. 能不拆分就不拆分，当没有关联变更导致效率降低时，就不用拆分
2. 先拆功能性业务：短信服务，缓存服务，支付服务等等。偏功能性和底层性，依赖少
3. 深入到业务拆分，优先拆依赖链条最底层的服务，比如订单服务依赖账户服务，账户服务依赖用户服务，那可以先从用户服务开始拆，自底向上进行拆分。