如何抽取公共服务并成功迁移

博客地址

在单体到微服务架构的迁移过程当中，咱们常常会问一个问题：在什么状况下我须要从单体中剥离一部分出来将其做为一个微服务？答案有不少，其中有一个答案就是：我发现好多单体都有类似的功能，我以为能够把它抽出来作一个公共服务。

那么何为公共服务？公共服务就是那些专门为其余服务提供服务的服务，它的业务具备高度普适性和可复用性。好比用户服务、订单服务就是这样一类服务。

那咱们怎样才能达成这一目标呢？下面举个例子说明：

咱们发现单体A、B、C中的具备高度类似的功能F，通过初步研究发现能够抽取出一个公共服务P，因而立刻安排人员开发，而后上线、迁移。
一切彷佛会很顺利，可是等等，这里有太多风险和未经验证的东西。那咱们应该怎么作？

第一步：识别不兼容

咱们须要深刻到单体A、B、C的功能F的细节中去考察，虽然功能F在各个单体中的看起来差很少，可是细节是魔鬼。
毕竟这三个单体是独立演进的，若是深刻细节，就会发现AF、BF、CF总有一些不兼容的地方，具体表现形式能够是数据schema不一致、接口不一致，还有更糟糕的——部分业务逻辑不一致。

这些不兼容若是一开始不识别出来，那最有可能的结果是开发人员从单体A中抽取功能F开发公共服务P，结果公共服务P只能给单体A使用，单体B、C彻底没法使用。

第二步：设计并导入概念

识别出了不兼容，那么咱们就须要做出一套兼容单体A、B、C的功能F的设计，在设计过程当中咱们须要和单体A、B、C的产品经理、需求设计人员、开发人员作详尽的沟通。
作这些沟通最主要的目的就是将新的功能F的设计导入到相关人员的脑中，即所谓的概念导入。

概念导入是很是重要的一步，道理很简单，若是你们对同一件事情的认知是同样的，那么这件事情就好办了，不然在推行过程当中极可能出现不可预料的阻力。

第三步：开发类库

好了，我们设计也作了，思想也统一了，为何不直接开始开发服务P呢？这是由于虽然咱们在第二步已经统一了思想，可是在真正落地的时候极可能还会存在乎想不到的困难。
所以咱们要把这些困难在早期趟平，用的办法就是提供功能F的公共类库，将其替换掉原来单体A、B、C中的代码。

这一工做完成后我能可以获得的成果有：

1. 设计、概念层面造成了统一
2. 表、实体结构造成了统一
3. 接口造成了统一
4. 代码层面的复用

也就是说，咱们作到了表里一致，有了这个基础，开发公共服务P才有了真正坚实的基础。

第四步：微服务架构设计

公共类库的思路毕竟仍是单体应用的思路，只是作到了代码层面的复用。当你要作公共服务P的时候就须要额外考虑一些额外的设计，好比：

1. Client的认证模式。不认证、OAuth 2.0，若是用OAuth 2.0那么用哪一种Grant type？
2. 通讯协议。http、https、gRPC。
3. 接口协议。RESTful、SOAP。
4. 接口定义。Swagger、OpenAPI。
5. 加密方式。TLS、对称加密。
6. 是否涉及多租户，若是涉及，那么还须要设计多租户的业务、功能、数据schema。
7. 考虑服务注册、服务发现等等。
8. 弹性设计、容错设计、分布式事务等等。
9. 运维相关的日志采集、监控指标等等。

固然以上这些并非说要一次性所有作到，能够一开始只实现一部分，以后经过迭代不断地完善。

第五步：迁移

好了，咱们的公共服务P已经上线了，那么如何从公共类库迁移到公共服务P呢？

其实到这一步就很简单了，在制做公共类库的时候咱们应该定义了良好的接口，而且提供了一套基于单体架构的实现。
如今咱们只需提供一套基于公共服务的实现而后替换上去就能够了。举个例子，公共类库有一个接口叫作UserRepository，它有一个实现是查询本地数据库的，咱们只需提供另外一个实现是查询RESTful接口的就能够了。

固然，这个查询RESTful接口的实现最好也由公共服务P的开发团队提供，这样能够避免单体A、B、C开发团队的重复劳动。

第六步：没有第六步

到此为止大功告成。