微服务架构提供了许多显著的优势，但也带来了挑战。挑战中最主要是扩展性。因为有效扩展微服务应用需要一种与单一扩展完全不同的方法，在这种方法中，通常只依赖负载平衡和应用的副本。

这是一个重要的话题，因为虽然微服务的可扩展性看起来很简单，但实际上很难掌握。虽然，抽象的有意义的微服务扩展的基本规则和原则，在现实中并不总是适用，如在每小时处理数百万次请求的真实环境；但是考虑到最初的挑战，从抽象的角度讨论团队在扩展微服务体系结构时应考虑问题，也未尝不可。

挑战1：处理微服务的复杂性

复杂性很难定义，但总体概念与许多组件和部件在时间范围内相互作用而成为系统。复杂系统是许多人的研究对象，微服务架构是复杂系统的经典案例。它不仅意味着技术的转变，而且意味着组件连接的方式，它们沟通的方式以及人们如何协作以保持运行。

处理复杂环境（如面向微服务的解决方案）的一项有用技术是将其视为网络。网络分析为你提供工具，指标和方法来了解架构中的结构属性和关键节点（微服务，组件和代理）。以及如何保护它们免于意外故障以实现弹性或稳定性。此外，Kubernetes，Swarm和Mesos等工具将帮助你将基础架构整合到一起，以开发和部署完整的解决方案。

挑战2：微服务架构中服务发现

作为通过应用接口（API）协同工作的小型自包含已定义任务的单元，微服务可能会在架构中大量产生，从几十到几百甚至更高的数量级。添加更多微服务意味着为你的解决方案增加更多复杂性，并且你必须确保新的微服务可以与现有的微服务一起扩展。凶猛的微服务可以使你的整个解决方案失效！

微服务发现和注册工具（如Netflix的Eureka）允许对可用服务进行分散管理（如域名服务器）。Eureka是一个服务注册中心，用于“灵活的中间层负载平衡和故障转移”，可以让服务自动注册并发现其他服务。它还提供了分布负载到这些服务实例的机制。

挑战3：微服务的监控问题

日志记录是每个软件解决方案的重要组成部分，但在微服务架构中，跟踪环境中所有组件的问题很快就会变成一场噩梦。要满足微服务监控挑战，需要诸如将请求映射到微服务拓扑的功能，或收集来自其他服务的信息的集中端点的工具。能够在动态环境中建立正常活动的基线，了解监视范围内的服务之间的依赖关系，并将基础架构（如主机服务器）的一层内的事件与其他层（如应用服务）关联起来。

挑战4：微服务的通信

通信是微服务领域的一大挑战。创建明确的操作约定和定义责任是架构师和开发人员的两个常见任务。这两个项目的完成都必须使用一种语言来说明每种服务的功能。在许多情况下，还包括上下文元素或对其他微服务的依赖关系。

当你的解决方案扩展到数百个微服务时，清晰地了解每个服务的特性和要求对于生存至关重要。Swagger和API Blueprint是两个可用于澄清微服务应该如何工作的工具示例。

挑战5：构建微服务专业知识

一个不断积累的学习团队建立可用于未来的知识。为此，自动化和可重复性是管理微服务的成熟过程的两个主要特征。为了学习过去的经验，像Zookeeper这样的工具可以派上用场，用于存储操作涉及的工具配置。