微服务架构优势和不足
在一些电影中，“银弹”被认为是杀死狼人的武器，是杀死狼人的灵丹妙药，“银弹”常被比喻为解决复杂问题的良方和高招。
由于软件的复杂性本质，而使真正的“银弹”并不存在。同样的，架构设计是一门权衡、取舍的艺术，没有十全十美的架构，微服务架构为我们带来了如：可扩展性、灵活性等诸多优点。我们收获这些好处的同时，也一定会带来一些新的问题与不足。当我们完全理解了微服务的优势和不足，就可以应用它的时候扬长避短。
微服务的优势
微服务架构有很多重要的优势，我们来看以下几个
复杂问题简单化
微服务架构能有效解决系统复杂性的问题，将大型单体应用拆解为多组服务，虽然功能总量不变，但应用已被分解为可实现、可管理的模块和服务。
高内聚低耦合
微服务架构中，每个服务都可以有专注于此服务的团队独立开发，服务间定义了明确的 API 边界，责任划分清晰，同时每部设计和实现细节都被隔离开，相互之间没有强依赖。
独立自治
微服务架构中，各个服务可以独立发展自己的系统，选择合适的技术栈和研发模式，包括开发语言、工具以及中间件等技术，这有助于试验和引入更先进和创新的技术。
从一些边缘服务开始尝试、技术、工具、中间件、研发模式，孵化成熟以后再逐步范围推广，实现技术和研发能力的持续更新迭代，让研发组织保持长期的优势和活力，充分获得技术发展的红利。
持续交付
服务实例独立部署，也便于利用自动化测试和自动化部署来加速功能的迭代，配合 CI/CD 等基础设施，实现业务功能的持续交付，保障研发能够紧跟业务发展变化的节奏。
灵活扩展
每个服务都可独立扩展，即可以按照服务的实际负载进行局部的扩展伸缩，比如扩容某个服务的实例数量，或者按照服务要求的配置、容量等条件进行吊证资源使用。比如我们可以在计算优化实例上部署 CPI 密集型服务，在内存优化实例上部署内存数据型服务。一句话概括来说：微服务架构支持快速、频繁和可靠地交付大型、复杂的应用程序，它还使组织能够不断烟花发展其技术堆栈。
微服务的不足
微服务架构同样也会面临一些问题和不足，我们来看以下几个不足内容。
服务拆分
微服务强调服务大小，但实际上这并没有一个统一的标准，业务逻辑应该按照什么规划分为微服务，这本身就是一个经验工程。
虽然建立小型服务是微服务架构的所崇尚的，但是每个做架构服务的人都需要意识到微服务只是为了达到完成应用程序的一种手段，而不是目标。微服务的目标是充分了解应用程序，以促进应用程序的持续迭代和演进。
分布式复杂度
开发人员需要基于 RPC 或者消息实现调用和通信，任何一次远程调用都可能失败，如何保障服务之间的可靠交互。
数据一致性，非中心化的架构下，由于 CAP 原理的约束，强一致性的要求可能需要转向最终一致性方面考虑。
分布式场景下的资源竞争、主从选举、状态同步也是非常棘手的问题。
测试运维成本
对微服务进行继承测试、需要由相关服务的配合、部署对应的服务，很有可能是多个，甚至可能存在级联的关系。
微服务架构体系中的服务治理的能力往往需要一系列基础服务（比如注册中心、配置中心、APM 系统等等）提供支持，这无疑也是增加了运维的成本。
问题定位排查
微服务之间的拓扑关系十分复杂，一个请求可能跨越好几个服务，中间价，出现业务 bug 是线上问题时，排查或者定位非常困难，需要由完善的机制和方案。
对于上面的问题，任何一个微服务开发人员都不能绕过去的，因此大部分的微服务产品都针对每一个问题提供了相应的组件来解决它们。