林大虫子的专栏

本人所在的产品线是公司统一的构建管理平台，该平台采用了微服务的构造，跟微服务自身的通病一样，服务数量多了之后，存在这样一些问题： 接口超时或者调用失败后，无法知道具体是那个下游接口超时 接口响应慢后，怎么去了解是那个服务的那个方法调用耗时较长 对前端暴露的接口，响应时间对用户的体验比较敏感，怎么监控到系统中存在的慢接口，进而优化 微服务发展到今天，业界对这类问题已经有很多通用的解决方案，最早的比较Google公司发表的Dapper应该算得上是始祖了吧。 我们也不想重复造轮子，比较了一些方案，综合对埋点语

微服务这几年应该是我听过最多的，很多公司的架构现在都在往这个方面迁移，包括很多的互联网公司，以及其它行业的软件公司。至于原因吗，很多人都出自己的理解，从业务需求上讲，可以scale-out，满足业务增长的需求，另外从软件开发者的角度，服务化的架构确实是降低了各个软件模块的偶合，更方便软件的开发，部署，测试。但这里为什么把微服务跟负载均衡服务器联系在一起呢？首先看一下当软件的架构从传统的单体应用切换到