微服务化过程中遇到的问题和思考

我目前遇到的问题：

1.微服务拆分多个，团队在行政上不能拆分，大家还都是一个团队，但是维护的服务却多达几十个，新人学习和认识成本高昂。

2.微服务拆分多个，运维工具没有跟上，自动化能力不足，此时会造成每次上线都要发很多的服务上线，耗时耗力，造成此问题的原因有一个是产品经理每个迭代要做的需求都是跨多个领域的也就是跨了多个服务，所以才发这么多的服务。

3.微服务拆分多个，只是进行了进程隔离，并没有进行代码的合理重构和划分，相同的代码源文件出现在多个服务进程中，改一处发几十个服务，下面一条也是这个原因。

4.微服务拆分多个，害怕单点故障所以，每个都相对独立，没有过多调用其他服务。

 

思考和结论：

微服务为了解决什么问题？

系统更容易维护、线上更加的稳定、迭代更加的快速

那么上面哪些问题造成了与我们要解决的问题相悖呢？

强硬的按领域拆分服务是不正确的，因为会增加很多的服务，造成难以维护的局面。

相较于进程的拆分，代码清晰的重构更能提升系统的稳定性和可维护性。

什么时候应该拆分进程？当某功能的运行熵与其所在服务运行熵完全不是一个量级，极有可能引起其他业务问题的情况，才应该拆分成一个独立的进程。

不属于自己业务领域的代码如果也不属于本服务，一定要进行远程调用