认识达内从这里开始

随着互联网的不断发展，越来越多的程序员都在学习微服务架构开发等互联网技术，而本文我们就通过案例分析来简单了解一下，微服务架构优势与劣势分析。

一、微服务的优势

微服务架构有很多重要的优势，我们来主要看以下几个：

复杂问题简单化

先就是，复杂问题简单化。微服务架构能有效解决系统复杂性的问题，将大型单体应用拆解为一组服务，虽然功能总量不变，但应用已被分解为可实现、可管理的模块或服务。

高内聚低耦合

微服务架构中，每个服务都可以由专注于此服务的团队独立开发。服务间定义了明确的API边界，责任划分清晰，同时内部设计和实现细节都被隔离开，相互之间没有强依赖。

独立自治

各服务可以各自独立的发展自己的系统，选择合适的技术栈和研发模式，包括开发语言、工具以及中间件等技术，这也有助于试验和引入更先进和创新的技术。

从一些边缘服务开始尝试，技术、工具、中间件、研发模式，孵化成熟以后，再逐步大范围推广，实现技术和研发能力的持续更新换代，让研发组织保持长期的优势和活力，充分获得技术发展的红利。

持续交付

服务实例独立部署，也便于利用自动化测试和自动化部署来加速功能的迭代，配合CI/CD等基础设施，实现业务功能的持续交付，保障研发能够紧跟业务发展变化的节奏。

灵活扩展

每个服务都可独立扩展。既可以按照服务的实际负载进行局部的扩展伸缩，比如扩容某个服务的实例数;或者按照服务要求的配置、容量等条件进行调整资源使用，比如我们可以在计算优化实例上部署CPU密集型服务，在内存优化实例上部署内存数据型服务。

一句话概括来说，微服务架构支持快速、频繁和可靠地交付大型、复杂的应用程序。它还使组织能够不断演化发展其技术堆栈。

二、微服务的不足

微服务架构同样也会面临一些问题和不足，我们来主要看以下几个：

服务拆分

微服务强调了服务大小，但实际上这并没有一个统一的标准。业务逻辑应该按照什么规则划分为微服务，这本身就是一个经验工程。

虽然建立小型服务是微服务架构崇尚的，但要记住，微服务是达到目的的手段，而不是目标。微服务的目标是充分分解应用程序，以促应用的持续迭代和演进。

分布式复杂度

开发人员需要基于RPC或者消息实现调用和通信，任何一次远程调用都有可能失败，如何保障服务之间的可靠交互。

数据一致性，非中心化的架构下，由于CAP原理的约束，强一致性的要求可能需要转向终一致性方面考虑。

分布式场景下的资源竞争、主从选举、状态同步也是非常棘手的问题。

测试运维成本

对微服务进行集成测试，需要有相关服务的配合，部署对应的服务，很有可能是多个，甚至有可能存在级联的关系。

微服务架构体系中服务治理的能力往往需要一系列基础服务(比如注册中心、配置中心、APM系统等等)提供支持，这无疑也是增加了运维的成本。

问题定位排查

微服务之间的拓扑关系十分复杂，一个请求可能跨越好几个服务、中间件，出现业务bug或是线上问题时，排查或定位会很困难，需要有完善的机制和方案。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。