当我们将应用程序弹性能力的实现分散到应用程序本身时，显然减轻了对大规模服务架构的担忧，但同时也引入了一些新的挑战。譬如，如果我们希望在架构中引入新服务，它将受限于其他人和其他团队的实施决策。假设在架构中要使用Netf lixOSS Hystrix，则必须使用Java或某些基于JVM的技术。通常，熔断和负载均衡是一致的，因此需要使用这两个弹性库。若要使用Netf lix功能区进行负载均衡，可能还需要使用Eureka的服务注册库。
当引入新语言或框架来实现服务时还会引发另一个潜在问题。譬如，你可能会发现NodeJS更适合实现面向用户的API，但已有架构的其余部分都是基于Java语言并利用了Netf lix OSS库。你可以选择一组不同的库来实现弹性模式，对于希望引入的每种语言，需要搜索、认证和引入新的开发堆栈。这些库中的每一个库都将具有不同的实现，在某些情况下，你可能无法为每个框架语言组合找到类似的替代方案，最终得到结果的是总体使用效果不一致性。
如图1-2所示，这些代码库中包括了服务发现、熔断、限流等功能，版本不同往往会带来冲突问题，而且版本一旦变更，整个应用也要随之全部变更，即使你的应用逻辑并没有任何变化。复杂系统中的微服务实现往往会使用不同的编程语言、不同的框架，这些实现方案往往存在差异大、缺少共性的问题。
图1-2 特定应用程序库的缺点