why:
一体化架构的问题
难以扩展
一体化架构应用只能通过在负载均衡器后面放置整个应用程序的多个实例来进行水平扩展。如果应用中的特定服务需要扩展，则没有简单的选项。我们需要完整地扩展应用程序，这显然会造成不必要的资源浪费。
相比之下，基于微服务的应用程序允许我们根据需要独立扩展单个服务。如果需要缩放服务B，则可以有10个实例，同时保持其他实例，并可以根据需要随时更改。
交付时间长
一体化架构在单个应用的任何部分/层中进行的任何更改都需要构建和部署整个应用程序。个人开发人员还需要下载整个应用程序代码来修复和测试，而不仅仅是受影响的模块，这就影响到了持续部署的效率。
而在微服务架构中，如果仅在一百个微服务中的一个中需要改变，则仅构建和部署改变的微服务，没有必要部署一切。我们甚至可以在短时间内多次部署。
应用复杂性
过去，随着应用规模的增长（功能、功能等），团队也会相应扩张，应用很快就就会变得复杂和交织在一起。随着不同的团队不断修改代码，维护模块化结构慢慢变得越来越困难，并慢慢导致像意大利面一样交织的代码。这不仅会影响代码质量，还会影响整个组织。
在基于微服务的应用中，每个团队都在单独的微服务上工作，代码会有序很多。
故障级联
如果没有正确设计，一体化应用的一部分失败可能会级联并导致整个系统崩溃。
在基于微服务的架构的情况下，我们可以使用断路器来避免这种故障。
陷入某种技术/语言
使用一体化架构，意味着被某种已实现的技术/语言锁定。如果需要更改技术/语言，则必须重写整个应用程序。
使用微服务，每个服务可以根据需求和业务以不同的技术或语言实现。任何改变服务技术/语言的决定都只需要重写该特定服务，因为所有微服务都是相互独立的。
小结
简单来说，使用微服务架构会获得以下好处：
独立开发部署服务
速度和敏捷性
更高的代码质量
获得围绕业务功能创建/组织的代
最低0.47元/天 解锁文章
144
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
