微服务拆分真的要谨慎

微服务的优点

在讨论弊端之前，我们先简要回顾一下微服务的优点： （摘录至某知识博客）

1. 灵活性：每个微服务可以独立部署和更新，不影响其他服务。
2. 可扩展性：可以根据需要单独扩展某个微服务，而不是整个系统。
3. 技术多样性：不同的微服务可以使用不同的技术栈，选择最适合的工具来解决特定问题。
4. 故障隔离：一个微服务的故障不会直接影响其他服务，提高系统的整体稳定性。

微服务上面说的优点确实不假，一种技术或者加一个新的架构必然是有一定道理，但是不建议随便一个服务都来微服务，就我在工作中发现很多利用微服务不当的地方，最明显的就是滥用微服务，随便一个鸟模块1天的工作量的功能都搞个微服务出来。这里拆分过多，导致管理麻烦，运维复杂，资源占用 ，随便一个微服务不得开个256M的内存给一个Java应用，如果是RPc远程调用的话，本来3-4个微服务可以rua在一个服务中的过度拆分，某些业务又有一定关联在调用的时候线程池会被打满的，如果是比较稳定的不如直接搞个SDK集成。其次是调用链路太长，没有专业的运维且不是一个团队负责一个微服务的其中一个链路出问题那是灾难性的问题。最好的问题我是遇到最多的，不了解业务就开始分服务，最常见的就是按模块来分的微服务，没有真正理解业务场景。举个简单的例子，假如有两个接口，A-METHON，B-METHON。B-METHON的调用前提是A-METHON调用完毕后返回正确的参数经过一系列处理 才能去调用B-METHON达到一个完整的调用。A和B的接口流量大概是98:2，也就是说大部分请求都在A-METHON，拿Tomcat举例的话 web容器都是基于线程池+队列的形式，即使我设置了线程数和队列大小但问题依旧，一是队列过小容易忽略了B-METHON请求给，队列过长上游超时无效请求。从功能模块上这两个接口按模块划分就是在一个微服务上是没问题，但是要考虑到真实的场景，A-METHON，B-METHON应该是独立不干扰的，服务应该隔离。如果是基于一个服务的要改造容器的部分，也就是不同的接口放在A-METHON，B-METHON不同的队列中处理，这个工作量不小，不是一般的开发者能搞定的，需要更多的学习成本在这里，如果不是应该进行拆分成一个新的服务。

总之这个微服务拆分是非常考验架构师的对业务真正的理解，要在初期就能预判处理，等业务上线了发现问题再去调整费时费力。