微服务的优缺点_java架构师指南：微服务架构都有哪些优缺点

什么是微服务

微服务是由一组小型服务构建的应用程序。服务在不同的进程中运行。服务通过轻量级的通信机制进行交互，并且可以通过自动部署独立部署服务。正是因为服务在微服务体系结构中是彼此独立的，所以可以根据不同的语言开发不同的服务，或者可以根据业务需求使用不同类型的数据库。

java架构师问答社区(ask.lubanjava.com)

优点

1、服务解耦

将原有的巨大的单体应用拆分为多个独立的微服务，使每个服务更加专注于自己的业务，并满足高内聚和低耦合的设计原则。例如，电子商务服务的差异分为用户服务，帐户服务，商品服务，购物车服务，订单服务等。

2、独立的开发环境

将应用拆分为独立的微服务，服务之间彼此隔离，通过轻量级的通讯机制(比如：dubbo)进行交互，使得开发时无需关注具体的开发环境，只需要协商好通讯机制即可。

3、独立的部署环境

微服务拥有独立的开发环境，因此需要根据各自的开发环境规划部署环境，对于访问量大的服务可以增加服务的部署数量，访问量小的服务适当的减少部署数量。

4、更高的扩展性

基于服务的独立性，服务之间的耦合性降低，无论从功能上，还是架构上，我们都可以进行更为灵活的扩展，而不影响其他服务。

缺点

1、通讯机制的不标准问题

微服务之间相互独立，但是服务间的交互需要依赖规范的通讯机制，没有规范的通讯机制作为桥梁，服务间交互将变得非常复杂。保证规范的通讯机制，是微服务的前提。

2、事务一致性问题

整体应用程序通过数据库事务来确保一致性，并且在拆分成微服务后，将形成分布式处理业务，这又将导致分布式事务一致性问题。分布式系统的事务一致性本身就是一个技术问题，目前还没有一种简单而完善的解决方案可以处理所有情况。分布式系统的困难之一是“网络通信的不可靠性”。有些问题只能通过“确认机制”，“重试机制”，“补偿机制”等方面解决。考虑可用性，性能和实现复杂性的所有方面时，更好的选择是“异步确保最终一致性”，但是特定的实现方法存在一些差异。

3、服务间的依赖变得复杂

需要根据业务的重要性进行系统梳理，定义出关键业务和非关键业务；梳理服务调用的主要路径，明确强弱依赖、限流、降级规则等。服务治理就是基于以上规则进行的，否则无法进行系统运维或管理。比如非关键业务被关键业务所依赖，会导致非关键业务变成关键业务，服务链中就会出现“木桶效应”，即整个服务质量由最差的那个服务所决定。

数据库也需要做相应的隔离：避免非关键业务把数据库拖死，进而导致全站不可用。不允许直接读取对方的数据库进行系统交互，只允许通过服务接口进行系统交互。这也是微服务的要求：拆分服务和相应数据库。

应避免服务间的循环调用，如果产生循环引用，需要通过架构层面解决循环问题，避免因循环引用导致的系统崩溃问题。同时要对接口进行降级、限流控制，以应对系统的高并发。

4、微服务运维变得复杂

微服务的架构一般会包含基础层、中间件层、应用层、接入层、安全层，同时需要有相应的团队负责各层的运维。各层之间有比较明确的职责，共同支撑着整个系统的运行。一旦某个环节出现问题，整个系统就会像“多米诺骨牌”一样倒下。因此需要统一的运维平台，实时监控服务调用链路，及时发现和定位问题。而建立统一的运维平台的成本和难度是相当之大的，目前也只有几家互联网大公司拥有这种能力。

5、系统监控变得复杂

对系统的监控依赖于系统的调用链路，链路中包含：http请求、服务间调用、消息队列、数据库、nosql、线程间调用等，如何将监控整个链路将变得非常困难，可能需要修改各中间件的请求数据包。

6、系统测试变得复杂

由于服务的依赖变得复杂，在进行系统测试时，要考虑服务间强弱依赖、降级、限流等问题。在进行压测时要考虑依赖的服务的性能。在制造测试场景时应充分考虑各服务的数据量，避免出现测试误差。更多知识可在java架构师问答社区(ask.lubanjava.com)中查看。