为什么要做微服务拆分

最近在对广告归因系统进行重构，重构的原因有两个：

1. 我们团队的技术栈是go，但由于历史原因，广告归因系统是使用Java开发的。为了统一技术栈，决定使用go重构。
2. 目前归因系统是单体架构，随着流量越来越大、功能越来越复杂，单体架构的问题逐渐开始暴露，因此决定进行微服务拆分。

下面就来讨论下，为什么要对单体架构进行微服务拆分。首先要声明下，本篇文章不是教科书式的文章，不会从理论角度分析，也不会全方位的讨论为什么要微服务拆分。 本篇文章更多的是从实践角度出发：我们在单体架构下遇到了什么问题，使得我们决定进行微服务拆分，拆分完成后，我们得到了什么好处。

单体架构下遇到了什么问题

没有故障隔离

所有接口都在一个服务中对外提供，是无法做到故障隔离的。当其中的一个接口有问题，其他接口也会跟着受到影响。

系统上线繁琐

任何一个改动，不论是复杂还是简单，都需要把整个服务重新上线，上线后要确认服务提供的所有接口是否都正常，即使仅仅是一个很小的改动。

定时任务不合理

服务是分布式的，有多台实例。一些的定时任务，比如定时清理Redis数据，只需要一台实例即可。并且在在线服务中，添加这种离线的定时任务，明显也是不合理的。

如何进行微服务拆分

1. 按照功能拆分：比如接收归因平台回传的接口，即使有多个，也把这多个都归到同一个服务之中。
2. 按照流量拆分：同样的功能，但流量相差特别大的，要拆分成不同的服务。比如接收点击接口，affiliate流量和自有流量的比例是20:1，并且affiliate流量的抖动特别大， 为了避免affiliate流量影响到自有流量，要把这俩接口拆到不同的服务中。
3. 所有内部使用的增删改查类接口，都拆分到同一个服务中。
4. 将所有定时任务，都拆分到同一个服务中。

微服务拆分后问题解决了吗

进程级别的故障隔离

接口拆成不同的服务，在不同的进程之中，即使有问题，也只会影响自身，其他接口都能正常提供功能。

系统上线简单

系统上线时只需要对本次需求开发影响到的服务上线即可，上线更加轻量级，上线后也只需要关注上线服务对应的接口即可。

定时任务更加合理

所有的定时任务都放在一个服务中，并且这个服务只有一个实例，任务中不再需要分布式锁了。