微服务重构心得

现在都在做微服务，看起来就是做服务拆分比较简单，但是实际上真正重构起来又遇到许许多多的问题。

微服务重构常见问题

1.领域驱动模型的困扰

比如听到很多理论比如领域驱动，那么到底需要不需要学习或者使用领域驱动呢？

2.系统的复杂性

重构的时候发现系统之间调用非常复杂，很难完整的剥离。

3.重构的顺序

数据库要不要重构，先重构后台还是前台还是一起重构。

我做了几个微服务重构，有过不少经验的总结。

1.领域划分

通用划分模式，比如商品，购物车，订单，活动，奖券，用户等等。

做一定的内聚，这并不难，不用特别的纠结自己划分的对不对，难的还是领域直接的耦合怎么尽可能的解耦干净。

先需要数据库边界的划分。

2.领域解耦

错综复杂的调用关系

分层，从顶到底，不允许底层调上层。

底层需要的数据尽量上层提供，这一点有点像IOC思想，非常巧妙的解决很多问题。

底层继续调接口：性能问题，循环调用，需要别的部门增加工作量等。

3.代码翻译与义译

基本是直接翻译，但是需要做一定的去重，原先代码因为是单体工程，所以会不断的查库，分层之后，需要的数据都已经上层给你提供，那么没必要做太多的if  else这需要消除。

例如：某方法  原先是 需要根据商品id区分是自己从购物车取商列还是用id取商品信息。

合并之后就一个新参数pids。

没必要区分是继续自己从购物车取商列还是用id取商品信息，直接面对list<product>就可以了。

4.重构的先后顺序

数据库不要重构，重构数据库意味着你的读写所有接口都要迁移到新平台，不是不可以而是很难。

先尝试对读接口收口，再收口写接口，待到所有接口收口完可以切库。

《未完，随想随机》