2018-10-26学了这么久的课程，受益匪浅，出来说几句。老师的这门课程极大的提升和丰富了我的技术视野，涉及微服务架构设计的诸多领域和具体问题，课程都有着非常系统性的讲解，由表及里由浅至深，有理论有实践。尤其值得称道的是，老师的课程并不是主要教授你组件如何配置如何使用，我认为老师这套课程最大的亮点在于，课程是从微服务架构的一个具体领域问题出发，先提出问题，然后再谈解决思路和主流的解决方案，由此再引出基于解决方案设计的具体组件的讲解，并在最后还会对其进行横向类似产品的比较，这样系统性的层层递进式的课程安排和讲解，使得整套课程的学习过程非常的顺畅，理解的更加透彻，能真正的做到，知其然且知其所以然。诚然，学完整套课程，并不会让我马上就精通这些组件的使用，精通微服务架构的设计，这套课程只是把我领进门，告诉我方向，并告诉我为什么要走这个方向，往这个方向走你能得到什么，但这些对于一线的架构师工程师而言，真的已经足够有价值了。感谢老师的辛苦付出和无私分享。真心的希望老师后续还有更多的课程产品推出，有更多一线架构设计经验的分享：）作者回复: 很感激你的收获总结，很多感受和我设计课程思路吻合，说明你真心认真学习了这门课程。对年轻工程师、架构师成长拓展视野有帮助，是我制作这门课程初衷。领会分布式架构背后的需求原理是道，具体组件实现是术，道是根本，术是落地实践，道术结合可以说是本课的一个设计亮点。感谢你的心得总结🌹🌹🌹
5
2019-04-06波波老师，我们公司目前采用的还是传统的dns+nginx的服务发现方式。但是随着服务的增多，人员流动等原因。许多服务提供方很难梳理到底被多少服务所消费，曾经出现过服务提供方升级功能，某个消费方不知情导致生产事故的情况。只要是基于rest的调用方式，即使是使用了eureka注册中心直连的方式，应该也会出现这种问题吧？请教下老师，这种情况有什么好的解决办法么？作者回复: 这个是普遍存在的问题，我之前呆过的公司比如亿贝，携程/拍拍贷等都存在，而且没有一劳永逸的解决办法。这个不全是技术问题，更多需要服务研发流程和治理层面的关注，比如服务变更和版本管理，需要制定一些服务升级的最佳实践（尽量保证向下兼容），测试流程要规范充分，上线前要经过灰度测试等等，可以减少不兼容变更造成影响。但是这里头也有一个平衡，过多的治理流程会阻碍效率。所以，业务在不停迭代，变更再所难免，这个问题不可能完全避免，对这个问题保持适度容忍(侧面反应业务迭代快)，同时制定恰当的流程保障业务平稳即可。
2019-03-22老师:
1、三种模型都用到代理了吧,那不是都要多一跳吗?
2、集中式运维简单 --->需要一定运维能力 这里指的是专门的运维团队为管理 proxy机子嘛？作者回复: 你好，问题1：从抽象层次看，三种模式都是采用了代理，只不过对于嵌入式代理，代码和主应用代码住在一起(同一进程)，所以性能损耗最小，严格不算多一跳；对于主机独立进程代理，代码进程和主应用进程住在同一个主机/操作系统中，所以性能损耗也不大，严格也不算多一跳；对于集中式代理，代码部署在独立机器上，所以确实有多一跳性能损耗。问题2：理解正确，集中式代理一般由运维团队集中管理，比如集中nginx集群一般由运维管，所以需要一定运维能力。