服务的循环依赖，有时候是公司组织结构和管理不合理导致的，比如几个相对独立的部门，A部门要搞一个新需求，依赖B部门提供的服务，B部门又依赖C部门的服务，而C又依赖A部门的服务。如果没有能站在上帝视角俯视全局的明白人指路（通常是公司最熟悉技术及业务的资深人士或xx委员会），部门之间沟通又不顺畅的情况下，服务依赖环就这么产生了，甚至还可以顺利上线，为将来又添新坑

zipkin好像对代码侵入性有点大

腾讯的tars也带有versionset，配合序列化协议实现兼容和升级也是非常便利。

关于分布式调用监控，为什么您推荐zipkin？skywalking和pinpoint您有什么评价吗？目前项目正在考虑分布式调用监控的问题，谢谢

皓哥，能推荐一两本相关书籍么

关于分布式调用监控，为什么您推荐zipkin？skywalking和pinpoint您有什么评价吗？目前项目正在考虑分布式调用监控的问题，谢谢
2018-01-01

有个疑问是zipkin应该对代码侵入相对pinpoint来讲有些大，这个是怎么更好的解决的？尤其是已有的系统。

服务关键程度，服务依赖梳理，服务发现，服务治理，服务监控，服务扩缩容。这些道理，在我们生活中也是很朴素适用的。
找到生活工作的关键目标，确定关键的事情，厘清事物先后顺序，采取措施执行，并持续监控状态，刷新调整，最终向目标迈进。
而在开发的世界里，通过构建这样一套服务的管理系统，我们就可以对外提供一个稳定可靠的服务。在遇到服务故障，服务更新，回退以及突发事件时候可以及时感知并采取措施。
要做到这一点还是感谢开源的力量，有一整套思路来指引我们采取措施，也有一系列工具可以提供我们采用。docker和k8s，目前在云开发中已经是新的开发基础，这里面也有很多坑，前人在总结和优化，开发者只要能把工具用好都已经可以实现自我的提升了。

如果系统架构中有服务依赖环，那么表明你的架构设计是错误的。循环依赖有很多的副作用，最大的问题是这是一种极强的耦合，会导致服务部署相当复杂和难解

这个能举例说明下么？而不是结论

从服务关键程度、服务依赖关系、整个架构的版本管理，服务和资源的调度，服务的故障恢复和动态扩容，全面阐述了分布式系统架构五大关键技术之——服务资源调度。

真知灼见和学富五车的感觉，皓哥的内力真的是深厚

我们工作中使用kubernetes进行服务部署，镜像带上版本信息，服务升级只需要更新镜像，对POD点进行灰度发布。使用容器化，kubernetes集群管理大大提高工作效率

请教。state和status的区别是什么?

zipkin，长见识了

服务直接不能循环依赖

前面都看懂 但是最后的服务编排没明白…

老师可否讲下，负载均衡,比如一个主机通过负载均衡器到达服务器A，在已建立路由表的情况下，那台主机到负载均衡器的所有包都是路由给服务器A吗

请教一下，ESB为什么是Choreography，之前SOA服务之间调用不应该是通过ESC路由，消息协议转换么，我怎么感觉更应该像Orchestration的一个指挥者啊，文中的意思是API Gateway来取代ESC么，他们两个的功能不一样啊？而且gateway和服务内部之间调用没有关系吧

这个操作的过程一定是比较“慢”的。一方面，需要对其它操作排它；什么意思？