微服务架构概述架构模式( 二 ) _微服

而在微服务架构中，如果仅在一百个微服务中的一个中需要改变，则仅构建和部署改变的微服务，没有必要部署一切。我们甚至可以在短时间内多次部署。
3.3应用复杂性
过去，随着应用规模的增长（功能、功能等），团队也会相应扩张，应用很快就就会变得复杂和交织在一起。随着不同的团队不断修改代码，维护模块化结构慢慢变得越来越困难，并慢慢导致像意大利面一样交织的代码。这不仅会影响代码质量，还会影响整个组织。
在基于微服务的应用中，每个团队都在单独的微服务上工作，代码会有序很多。
3.4没有明确的所有权
在一体化应用中，看起来独立的团队实际上并不是独立的。它们同时在相同的代码库上工作，严重依赖于彼此。
在基于微服务的应用中，独立团队处理单独的微服务。一个团队将拥有一个完整的微服务。工作的明确所有权明确控制服务的一切，包括开发、部署和监控。
3.5故障级联
如果没有正确设计，一体化应用的一部分失败可能会级联并导致整个系统崩溃。
在基于微服务的架构的情况下，我们可以使用断路器来避免这种故障。
3.6Dev和Ops之间的墙
开发团队通常会进行开发、测试，一旦部署，就会将维护和支持的所有权交给运维团队，应用此时与开发团队无关了，而运维团队需要努力在生产环境中支持一体化架构应用。
在基于微服务的应用中，团队的组织理解为“构建它、运行它”，开发团队继续在生产中拥有该应用。
3.7陷入某种技术/语言
使用一体化架构，意味着被某种已实现的技术/语言锁定。如果需要更改技术/语言，则必须重写整个应用程序。
使用微服务，每个服务可以根据需求和业务使用不同的技术或语言实现。任何改变服务技术/语言的决定都只需要重写该特定服务，因为所有微服务都是相互独立的。
3.8支持微服务的正确工具/技术的可用性
几年前，我们还没有适当的工具和技术来支持微服务。但自从Docker容器和云基础设施（特别是PaaS）向大众提供服务以来，微服务正在大规模采用，因为它们提供了我们所需的“自由”，而无需进行传统的配置程序。
四、认识微服务小结4.1 微服务架构优点

【微服务架构概述架构模式】

微服务架构概述 架构模式( 二 )

猜你喜欢

微服务架构概述架构模式( 二 )