劝君放弃微服务

近年来，微服务架构在各种项目中逐渐流行起来，同时也催生了众多服务和框架用以管理和监控微服务。但对大多数应用来说，是否真的需要采用微服务架构，却是一个值得考虑的问题。

微服务相比传统单体应用的好处包括：

• 解耦：服务间独立，仅通过远程接口交互，迫使原本数据耦合的模块分割，从而提升系统的可修改性。
• 性能：每个微服务拥有独立的数据库，可以根据需要选择数据库，分散了数据库的访问压力，有利于性能提升。

然而，微服务也有其缺点：

• 事务问题：微服务的跨服务、跨数据库特性使得事务一致性从ACID变为BASE，增加了业务编写的复杂性。
• 错误处理：接口必须设计为幂等，增加了业务编写时的心智负担。

在考虑是否采用微服务时，应评估单数据库情况下系统是否能满足性能要求。如果不能，微服务可能是必要的；如果可以，可能没有必要使用微服务。

对于微服务带来的模块解耦好处，可以通过共享库的方式实现。例如，在Java中可以将业务和数据库访问封装成库，通过Maven引入这些库。这样，系统在运行上分为若干小的单体应用，逻辑上通过共享库实现高内聚、低耦合的业务逻辑。这种架构适用于大多数应用，如下图：

每个共享库访问特定数据库表且不与其他库的表重叠，满足里氏替换原则，实现了业务的高内聚、低耦合。由于聚合在单个应用中，便于在ServiceFacade层通过AOP实现事务控制，利用关系型数据库的ACID特性。