我第一次搞微服务——在祖传项目上摸石头过河

我当时第一次搞微服务的事情。

由于迁移微服务不是一蹴而就的事情，但是我又急需一些微服务的部署简单、开发快速的优点。所以，当时不得已，想了个折中的办法。

我把一些急需实现的业务需求分析了下，发现这些需求大体可以分为以下两类:

1. 有些需求本身是一套独立的边缘业务

2. 有些需求是集中在核心业务的边缘上

我后来想想，觉得这是理所应当的。业务和我们技术一样，如果动了核心业务的逻辑，万一出现了问题，他们是要背大责任的。但是他们又要体现自己的价值，那最保险的就是在核心业务的边边角角动些手脚。

知道了这些，那就好办了。

对于第一类独立的业务需求，我直接就设计出一套独立服务，让它和已有的老系统通过网络远程互联。这样的话，新搭建的服务很小，维护也简单。以前的老系统也成为新服务的服务。这样，一部分需求，就可以快速迭代了。

对于第二类需求，原有系统核心边缘的需求，我是这样做的。

• 首先，我争取了领导的支持，优先对经常被提需求的业务模块做了剥离。这样，就剩下了一些不经常变动的业务模块还在老系统。其实这些时候，系统也没那么大了，也能满足业务偶然提出的业务变动需求了。

• 然后，我会在后续的时间里，慢慢的抽空把剩下的业务模块没事儿就剥离一些出来。但是，优先级很低。

• 这样，慢慢的抽丝剥茧，最后，我发现，核心业务我们都没有动，一套微服务体系就已经搭建出来了。

有人可能会比较好奇，你这样剥离，同时存在老系统和新系统。那外面的用户使用会不会受影响呢？

其实，这里还有个小技巧。就是我在拆微服务之前，先搭建了一个代理。这个代理就是专门路由外面用户请求的。每次上线服务的时候，都会对这套代理进行一次微调整。这样搞下来，用户是感知不到背后新老系统并存的状态的。

但是，说到这里，我也要说一下，这个方法真的是比较粗暴的，是实在没办法才选择这种方法。

后来，我再搞微服务的时候，吸取了很多教训。总的方向还是需要优先划分出清晰的业务模块，然后再根据业务模块的划分搞出微服务来。