当下市场瞬息万变，新技术不断涌现，而微服务持续火热。如果说2014年是微服务的元年，那么2015年和2016年则是微服务走下神坛的时刻，越来越多的开发者、架构师们探讨着如何落地，如何解决各种实际问题，而很多技术栈和工具也纷纷涌现。
构建微服务时，我们真的深深进入了分析分布式系统 - 一个已经研究了40年以上的技术主题，复杂的自适应系统理论已经深入人心有很长的时间。从技术的角度来看，我们需要解决的事情如下：
-
部署
-
交付
-
API
-
版本控制
-
合同
-
缩放/自动缩放
-
服务发现
-
负载均衡
-
路由/自适应路由
-
健康检查
-
配置
-
熔断器
-
bulk-heads
-
TTL / deadlining
-
延迟跟踪
-
服务因果跟踪
-
分布式日志
-
度量操作与收集
Netflix和一些互联网公司作为早期微服务的采用者在这些领域做了很多的投资、尝试和贡献（如开源工具和相关论文）。然“微服务不是免费的午餐”。企业也并不都是Netflix，微服务的复杂性以及带来的各种成本还是让很多企业望而却步，挡在了门外。
而如今，随着越来越多的企业和社区加入到这一行列，经过早期采用者的沉淀和后续加入者的共同创造，在微服务的多个已知问题领域出现了新的一波解决方案和技术栈，给其注入了新的希望。最近，Christian Posta发表了题为“令人兴奋的微服务技术栈2.0”的文章阐述了这一趋势。他指出，这些技术栈的出现可以帮助解决原来很多已有的或者在一些问题域中难易跨越的问题，甚至可以更优雅的解决。
Christian提到的第一个例子是Kubernetes。他指出：
Google和Red Hat都是第三次在构建一个有应用程序级原语的平台时使用Kubernetes，这个平台用来运行在容器上构建的原生云应用程序。过去Google或开源社区也曾有过不同的尝试，但Kubernetes大大简化了像服务发现、规模化、部署等任务。似乎社区里其他人也同意Kubernetes是GitHub上最热门的项目，现在已经有1000多个提交者，很是疯狂。如果Kubernetes出现在5年前，你不会看到这么多“微服务”框架来解决这些问题。
Christian提到的另一个例子是熔断。微服务架构是由多个独立的服务组成，如果任何一个服务出现故障，就会导致其它依赖的服务像多米诺骨牌一样出现连带故障，最终导致整个系统的瘫痪。这就使得在微服务这样的架构中，保障服务及服务之间的稳定性是非常重要的问题之一。而熔断机制则是解决这个问题的一个模式。
熔断机制是指在某个服务发生故障时，断路器的故障监控向调用放返回一个及时的错误响应，而不是长时间的等待。这样就不会使得线程因调用故障被长时间占用，从而避免了故障在整个系统中的蔓延。
