当下市场瞬息万变，新技术不断涌现，而微服务持续火热。如果说2014年是微服务的元年，那么2015年和2016年则是微服务走下神坛的时刻，越来越多的开发者、架构师们探讨着如何落地，如何解决各种实际问题，而很多技术栈和工具也纷纷涌现。
Netflix和一些互联网公司作为早期微服务的采用者在这些领域做了很多的投资、尝试和贡献（如开源工具和相关论文）。然“微服务不是免费的午餐”。企业也并不都是Netflix，微服务的复杂性以及带来的各种成本还是让很多企业望而却步，挡在了门外。
而如今，随着越来越多的企业和社区加入到这一行列，经过早期采用者的沉淀和后续加入者的共同创造，在微服务的多个已知问题领域出现了新的一波解决方案和技术栈，给其注入了新的希望。最近，Christian Posta发表了题为“令人兴奋的微服务技术栈2.0”的文章阐述了这一趋势。他指出，这些技术栈的出现可以帮助解决原来很多已有的或者在一些问题域中难易跨越的问题，甚至可以更优雅的解决。
Christian提到的第一个例子是Kubernetes。他指出：
Google和Red Hat都是第三次在构建一个有应用程序级原语的平台时使用Kubernetes，这个平台用来运行在容器上构建的原生云应用程序。过去Google或开源社区也曾有过不同的尝试，但Kubernetes大大简化了像服务发现、规模化、部署等任务。似乎社区里其他人也同意Kubernetes是GitHub上最热门的项目，现在已经有1000多个提交者，很是疯狂。如果Kubernetes出现在5年前，你不会看到这么多“微服务”框架来解决这些问题。
Christian提到的另一个例子是熔断。微服务架构是由多个独立的服务组成，如果任何一个服务出现故障，就会导致其它依赖的服务像多米诺骨牌一样出现连带故障，最终导致整个系统的瘫痪。这就使得在微服务这样的架构中，保障服务及服务之间的稳定性是非常重要的问题之一。而熔断器模式则是解决这个问题的一个模式。
熔断器模式指，在某个服务发生故障时，熔断器的故障监控向调用放返回一个及时的错误响应，而不是长时间的等待。这样就不会使得线程因调用故障被长时间占用，从而避免了故障在整个系统中的蔓延。
在熔断器技术的发展中，Christian谈到：
“现在任何人都可以写一个熔断器（和许多有）。 Netflix甚至发布了他们的熔断器（Hystrix库）。应用程序可以使用hystrix库来实现相关功能。然而其对于熔断、服务发现、跟踪，指标以及其它系列问题的缺点时，它强依赖于开发人员获取正确的类库，并真正的将这些事情作对。这是非常困难的。我们需要一种新的方式来解决这个问题。”
Christian认为“我们真正想要的并不是更多的类库或框架让我们的应用程序变得更复杂，而是希望每个开发人员可以正确的在项目之间使用或应用它们，甚至更重要的是与编程语言无关。维护类库不同的实现会让人抓狂。”他指出在该领域也出现了一些“更优雅的”方式，如IMHO和来自Lyft的Envoy project。
IMHO将这些问题放在客户端代理，这个代理部署为应用程序的“跨斗”。而Envoy是一个非常小的C++客户端代理，用于处理诸如熔断、批量堆栈、服务发现、度量收集、跟踪等问题。这意味着单个Envoy代理将与每个应用程序（1-1）一起部署。应用程序可以利用此功能，而无须考虑编程语言的约束。该应用程序基本上通过“localhost”与其他服务通信，Envoy完成服务的所有代理工作。它知道如何找到后端服务，完成自适应路由、重试、跟踪、调节等任务。开发人员可以保持整洁的应用程序代码，并免费获得所有的这些便利。
Christian谈到的最后一个例子是构建微服务的方式。他认为：
用REST构建微服务是绝对的事实。搭建一个服务，使用REST端点提供服务，并将其用在服务之间的所有交互和集成。而REST也存在一些在规模化上已知的问题，如追踪服务的破坏性变更，理解服务之间的类型安全，以及与二进制RPC风格的服务（至少HTTP 1.x）相比带来的过大开销等。今天它正在演进为一些更优雅的方式，如非阻塞通信框架（即RxJava、Vert.x）、异步通信模式等，甚至像RPC（如gRPC）也变得更加的优雅。
最后，笔者认为技术并不依赖于特定的技术栈或工具，然如果没有有效的技术栈和工具，好的想法也可能夭折。就如Christian所说，微服务领域不断的发展，这些新的技术栈和解决思路可以让一些已知的问题得到解决，并优雅的得到解决，他为之兴奋，也值得我们关注。随着越来越多的企业、社区、个人参与其中，微服务必将在更多的领域落地生根，开花结果。
本文转自d1net（转载）