记一次微服务拆分的经历

微服务是这几年兴起的一个概念，它的含义是说把一个单体应用拆分成一个个各自独立的服务，然后编排调用这些服务来对外提供服务，有些技术人员可能觉得是新技术就要采用，也不管是否适用于自己就进行微服务化，但是有一点是可以明确的，微服务不是银弹，也不是所有的情况都适用微服务，简而言之如果微服务化带来的收益已经超过了付出那就是值得的。

笔者最近参加了一个公司的项目，项目是一个社区电商的项目，项目初期为了快速上线，整个项目只有一个单体PHP应用，但是随着单量越来越多，需求越来越多，开发人员越来越多，单体应用已经成为了发展瓶颈了。所有的开发人员都在一个项目里开发，经常会发生代码冲突；代码职责不清晰不明确，有时候根本就不知道自己的修改是否会影响到其他的地方；随着代码量越来越大，每次上线的时间也越来越长，而且每次上线所有的部门都要有人留守，因为根本就不知道是否会发生问题。所以，微服务拆分势在必行。

既然确定了方向，那就剩行动了。首先，怎么拆分，这是第一个要回答的问题，而且我个人觉得这个也是最重要的问题，基础不牢地动山摇，要想回答这个问题，必须首先梳理现有的业务流程及代码实现，此外还要和产品们讨论业务未来的发展方向，因为你要留下未来发展的余地。在拆分过后要和团队成员进行充分讨论，对于一些拆分后在技术层面实现很复杂的东西可以在产品层面优化，就是确定这是否是一个必须的功能，是否可以用类似的功能来实现，因为有的功能可能在技术这里昏天黑地搞了很久但也许在产品那里这是一个可有可无的东西，因此前期的沟通真的很重要。

然后接下来就是代码层面的东西了，这地方有一个要注意的点就是尽可能减少对用户体验的影响，就是不能影响整个业务主流程，因此，我们首先在model层进行替换，把现有的一些裸写SQL或者orm的操作替换成对微服务RPC的调用，并且这个地方也并不是直接就替换了，那样风险太大了，我们引入了一个灰度工具，可以对调用条件判断，当命中条件的时候走RPC，不命中的时候走本地调用，并且这个灰度是一个逐步放量的过程，此外还会对某些调用同时执行两步，并把执行的结果记录下来进行比较，当然这个只是针对读操作而言。然后PHP应用还是我们所有流量的入口，从PHP应用进来以后进行分流，这样也最小限度影响第三方。

如果只是在代码层面进行拆分，但是资源和耦合在一起，那拆分实际上是没有多少意义的，因此对于使用的资源也要拆分，数据库，Redis，都要拆分，只有这些都拆分了那才算得上是独立的服务，因为笔者遇到过某个请求突然增多导致数据库扛不住，然后导致其他的请求都被阻塞了，因为数据库连接被打满导致其他的查询无法执行。

总而言之，拆分就是一个梳理，慢慢剥离的过程，一步一步来，有错误也可以及时停止或者回滚。