微服务的优缺点

微服务架构有如下好处：

1：使大型的复杂应用程序可以持续交付和持续部署

持续交付和持续部署是DevOps的一部分，DevOps是一套快速、频繁、可靠的软件交付实践。高效的DevOps组织通常将软件部署到生产环境时面临更少的问题和故障。DevOps工具有Docker、Kubernets、Jenkins、Git等。

2：每个服务相对较小并容易维护

微服务架构相比单体应用要小的多，开发者理解服务中的逻辑代码更容易。代码库小，打包，启动服务速度也快。

3：服务可以独立部署

每个服务都可以独立于其他服务进行部署

4：服务可以独立扩展

服务可以独立扩展，不论是采用X轴扩展的实例克隆，还是Z轴的流量分区方式。此外每个服务都可以部署到适合它们需求的硬件之上

5：微服务架构可以实现团队的自治

可以根据服务来把开发团队拆分。每个团队都有自己负责的微服务，而不用关心不属于他们负责的服务。

6：更容易实验和采纳新的技术

最后，微服务可以消除对某个技术栈的长期依赖。因为服务更小，使用更换的编程语言和技术来重写一项服务变得有可能，这也意味着，对一项新技术尝试失败后，可以直接丢弃这部分工作而不至于给整个应用带来失败的风险。

7：更好的容错性

微服务架构也可以实现更换的故障隔离。例如，某个服务引发的致命错误，不会影响其他服务。其他服务仍然正常运行。

微服务架构的主要弊端和问题如下

1：服务拆分和定义是一项挑战

采用微服务架构首当其冲的问题，就是根本没有一个具体的、良好定义的算法可以完成服务的拆分工作。与软件开发一样，服务的拆分和定义更像一门艺术。更糟糕的是，如果对系统的服务拆分出现了偏差，很有可能会构建出一个分布式的单体应用；一个包含了一大堆互相之间紧耦合的服务，却又必须部署在一起的所谓分布式系统。这将会把单体架构和微服务架构两者的弊端集于一身。

2：分布式系统带来的各种复杂性、使开发、测试和部署变得更困难

使用微服务架构的另一个问题是开发人员必须处理创建分布式系统的额外复杂性。服务必须是进程间通信。这比简单的方法调用要复杂的多。

3：当部署跨越多个服务的功能时需要谨慎地协调更多的开发团队

使用微服务架构的另外一项挑战在于当部署跨越多个服务的功能时需要谨慎地协调更多开发团队。必须制定一个发布计划，把服务按照依赖关系进行排序。这跟单体架构下部署多个组件的方式截然不同。

4：开发者需要思考到底应该在应用的什么阶段使用微服务架构

使用微服务架构的另一个问题是决定在应用程序生命周期的哪个阶段开始使用这种架构。

5：跨服务数据的问题

在单体应用中，所有的数据都在一个数据库中，而在微服务架构中，每个服务都有自己的数据库，想要获取，操作其他服务的数据，只能通过该服务提供API进行调用，这样就带来一个问题，进程通信的问题，如果涉及到事务，那么还需要使用Saga来管理事务，增加了开发的难度

总结：

1：单体架构模式将应用程序构建为单个可部署单元

2：微服务架构模式系统分解为一组可独立部署的服务，每个服务都有自己的数据库

3：单体架构是简单应用的不错选择，微服务架构通常是大型复杂应用的更好的选择

4：微服务架构是小型自治团队能够并行工作，从而加快开发速度

5：微服务架构不是银弹：它存在包括复杂性在内的诸多弊端

6：我们需要的不仅仅是通过微服务架构来加速软件交付。成功的软件开发还需要DevOps和小而自治的团队
————————————————
版权声明：本文为CSDN博主「虚无的技术」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zhanglu0302/article/details/96460926