最近几年以来，微服务开始大行其道。各种项目都开始采用微服务架构。在此基础上，又诞生了多种服务、框架用来治理、监控微服务。问题是，对于大多数应用，你真的需要微服务吗？
微服务相对于传统的单体应用，有以下几个方面的好处：
- 解耦。微服务由于各个服务之间完全独立，仅仅通过远程接口进行访问。这迫使原来单体应用中习惯于通过数据耦合在一起的模块，被分割得相当彻底。这对于原来一些设计复杂、耦合性高的应用，突然间有了灵丹妙药解耦复杂。利用得当，可以产生高聚合、低耦合的服务，从而提升系统的可修改性。
- 性能。在单体应用下，一般情况下都是一个应用共用一个数据库（分库从逻辑上还是一个数据库），这就限制了数据库大规模扩展。当各个业务数据越来越多，压力越来越大，你只能通过拓展数据库性能来缓解压力。而在微服务的架构下，每个微服务就有自己一套数据库，可以根据自己服务的需要选择数据库。对单个数据库来说，由于把访问可以拆为多个数据库的访问，压力也远比单体应用下小。
在带来好处的同时，微服务也带来了若干缺点，有些缺点甚至要付出相当的代价。
- 事务问题。由于微服务跨服务、跨数据库访问，原来的ACID一致性被迫变为BASE一致性。即使是BASE一致性，也需要有精巧的手段来处理跨业务的服务。比如确保数据的最终一致性，在数据中间状态时给用户的体验等，这个事务处理一定程度上让业务编写变得更加复杂。我们就曾经自己开发了一套用于不同服务之间事务的调度服务，虽然如此，也没有基于RBMS的Transaction用起来那么方便。
- 错误处理。由于存在错误重试问题，比如网络延时等导致的。因此各个接口必须设计成幂等的，这对原来的业务编写是个冲击，你在编写业务的时候，还要时刻考虑接口被重复调用的问题，对程序员来说增加了心智压力。
对大多数应用来说，是否采用微服务，我觉得要问自己一个问题：在单数据库的情况下，系统是否不能满足性能要求？如果回答是，那么你可能不得不用微服务；如果回答是否，我认为是没有必要使用微服务的。
对于微服务带来的使各个模块解耦的好处，完全可以通过共享库的方式来实现。比如在Java中，可以按照类似微服务的思路，将一个业务对应的一组业务、数据库访问封装成一个库，对外的API通过Maven引入库。这样系统通过多个API服务把系统划分为若干业务独立的应用，各个应用之间通过共享库的方式共用业务逻辑。从程序运行上，系统被分为若干小的单体应用，各个应用通过一个数据库访问实现业务。但从逻辑上，由于业务都通过共享库实现，业务库做到了高内聚、低耦合。这样的架构对于绝大多数应用来说，应该是足够了，如下图：
每个共享库都访问特定的数据库表，不通过任何方式访问其他共享库的表。各个共享库访问的数据库表相互没有重叠，因此各个共享库完全满足里氏替换原则。同时，每个共享库完成特定部分业务，对业务来说高内聚、低耦合。由于共享库是聚合在单个应用里面的，因此很容易在ServiceFacade层通过AOP等方式实现事务的控制，充分利用关系型数据库ACID特性。