一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第8天，点击查看活动详情。
在我刚加入公司时，负责维护一块非常重的服务，里面包含500个接口，并且有3个团队在维护，所有人都往里面提交代码，发版比较频繁还特别容易重复。
由于代码确实过于庞大，有时候在翻代码时，也会非常耗费时间，而且所有接口都在一个篮子里，很容易发生风险。
另一个痛点是，由于业务方太多，导致日志告警非常乱，我们无法准确知道到底哪个是我们业务的，哪个是别的业务的，为了节省注意力，只能去调高告警的阈值，但这会削弱我们对线上的把控能力。
为此在今年的时候，我们特地做了一波微服务拆分。在这里分享一些在做服务拆分方面的一些经验心得。
1. 明确拆分模块
首先要明确有哪些功能模块需要拆出来。这些需要拆出来的功能模块，往往是更新比较频繁，业务比较重要，同时功能相对独立。我们是一个叫做创作中心的服务，把里面的几个核心模块，包括数据中心、任务中心、创作服务、版权保护依次拆出来。
2. 明确服务依赖
微服务之间的界限一定要明晰，以数据中心的新服务为例，我们先要理清楚它所依赖的基础设施，比如MySQL、Redis、Tidb等等，拆分之后，尽量做到就服务不再依赖这些资源，为新服务独立提供自己的依赖服务。
以MySQL为例，如果新服务刚好有自己独立的MySQL，那迁移时比较好迁移，直接把这个MySQL剥离开。但是如果是共用的MySQL，如果要准备新的独立MySQL，还要涉及到数据迁移方案。如果纯粹是读请求的话，会比较方便。而如果涉及到写请求，则需结合业务的特点，评估下业务的影响，看怎样迁移能够降低对用户的影响，是否要进行双写等等。这些日后我再开专题讨论。
除了基础设施的依赖，也许还涉及到别的业务方的一些接口，这些接口调用，都不会影响到原服务。我个人建议是在迁移后，如果有必要的话，可以先对代码做一些重构，把需要迁移的代码相对收敛一些，可以减小一些迁移成本。
3. 明确对外服务
之前的服务也许有对外提供一些接口，服务迁移之后，也要相应的提供这些能力。
这些接口一般是两种方式，http或者grpc。
如果是http的话，迁移后一般可以保证接口的名字不变，需要切换提供该接口的服务，可以修改nginx的配置，让对应路由转发的新的服务上。当然，也可以提供新的接口，但这时候就需要调用方去进行切换了。
如果是grpc，因为服务提供方变了，会比较麻烦一点。一种方案就是调用方切换，另一种就是在原服务调用新服务，这会多一层调用，如果需要改的彻底的话，还是建议业务提供方直接切换新的路由。
4. 测试与验证
切换到新服务后，需要一些有效的测试验证手段，来保证服务是正确的。
一是可以做一些流量回放的工作，我们公司就提供了一种工具，可以在原应用上录制流量，并且在新应用上进行回放。
另一个就是回归验证，可以在预发环境进行验证，并且让测试同学帮忙回归一下，以免迁移后，会对原来的服务有影响。
