LMD 置顶2018-01-26关于《微服务架构核心20讲》课程讲义（PDF 文件），学员可复制下面链接到浏览器下载获取。 http://t.cn/RQs9iTw 8
2018-01-21请教杨老师一个问题：第三种方式主机LB，如果是采用容器的部署方式，那么这个LB是部署在容器内被独享呢，还是部署在容器的宿主机中被多个容器中的微服务共享呢？ 6
2018-01-25容器部署的话，建议每个容器部署一个独立进程LB（或者说Service Mesh Proxy），这样隔离性更好，容器内的LB挂了，只影响那个容器，主机上其它容器不受影响。如果容器共享主机上的独立进程LB的话，则如果主机上的LB挂了，则整个主机上的容器全部受影响。 5
2018-11-13电商系统用户下单时，需要根据商品价格来计算订单总价。所以，订单服务需要调用商品服务。由于两个服务部署在不同的机器上，所以订单服务需要知道去哪里找到商品服务，即商品服务的IP和端口号是什么。
所谓的服务发现，就是如何让订单服务知道商品服务的具体位置。
方案一：
为商品服务配置二级域名。订单服务访问约定好的域名来访问商品服务。域名会被DNS服务解析到一级域名对应的服务器上，该服务器是一个负载均衡服务器，会根据二级域名来将来自订单服务的请求转发到某一台部署了商品服务的服务器上。
方案二：
商品服务将自己注册到注册表中，并与注册表保持心跳通信，表明自己还活着。订单服务去注册表中拉取商品服务的地址信息，然后订单服务选择某一台部署商品服务的服务器，直接向商品服务发起请求。
方案三：
商品服务将自己注册到注册表中，并与注册表保持心跳通信，表明自己还活着。订单服务这一端定义了一个指向商品服务的代理层。这个代理层从注册表拉取商品服务的地址信息，并实现了负载均衡算法。订单服务直接在进程内访问该代理层暴露的商品接口。
Service Mesh更像第三个方案模型。看了Service Mesh的介绍，牛逼。展开 4
2018-01-20service mesh采用的第三种，类似sidecar的概念。之前对lb一直都是模糊概念，杨老师总结很到位，学习了。 3
2018-11-15老师，能讲一个复杂系统进行微服务改造的具体例子么作者回复: 后面有想法，可参考下github.com/Staffjoy上面的源源，这个创业公司项目最后业务没做成，但是把源码都贡献社区了，V1版是近似单体，V2版是微服务，可供研究学习。
2- 2018-05-03请教一下为什么二有多语言问题，而三就没有呢，不明白！
作者回复: 二是根据应用的语言需要开发针对该语言的客户端负责路由，应用语言越多，开发客户端就多。三是主机上部署一个独立LB进程专门负责路由，该主机上的应用（不管什么语言）就不需要专门开发客户端了
2 
2018-11-08醍醐灌顶，做了大半年的微服务，总是跟着公司架构人员做，有所理解但迷迷糊糊，看了杨老师的这套视频，终于豁然开朗作者回复: 谢谢支持🌹加油💪
1
2018-05-24老师好，请问为什么第二种方式需要为每种语言开发一个版本呢？此话怎讲？为什么这样作者回复: 第二种是客户端软负载，负载均衡和路由逻辑是做在客户端的库里头的，不同的语言需要不同的客户端实现，比如Netflix的Eureka+Ribbon，Ribbon就是客户端，目前只支持Java，如果其它语言也要接入，则需要定制实现类似Ribbon的负载均衡和路由逻辑。
1- 2019-07-04杨老师，对于业务中台来说，是微服务来实现的。是这样理解吗？
作者回复: 从技术角度看，可以简单理解为中台大部分都是微服务实现。因为中台不仅是一个技术问题，同时还设计组织架构，甚至业务，所以它的内涵更广。
2019-05-26请教一下，微服务有主备模式吗？作者回复: 你好，一般有状态的服务如果要做高可用，那么主备模式是一种方案，例如DB或者Cache等。但是微服务一般建议无状态部署，这样可以水平扩展，不需要主备。
2019-04-29老师，我们最近使用的是etcd作为服务注册容器，微服务网关订阅服务变化作者回复: ectd是一种轻量级的服务注册发现产品，类似的除了eureka，还有zookeeper或者consul等。
2018-12-12杨老师你好，注册中心的选择有zookeeper和eureka，zookeeper是CP设计，eureka是AP设计，在项目的开发中，两者该如何选择？或者说是不是混搭使用？- 2018-12-12杨老师您好，我认为第二种服务发现的模式就是dubbo的这种架构，这种模式适用于web层作为消费者，service层作为生产者，zookeeper作为注册中心，内部的服务调用的场景。当我们需要将服务发布到外部，给普通用户调用时，这个时候，用户访问的是web层提供的服务，而web层还是需要用nginx这样的软件来做负载均衡，这个理解是否正确？
2018-06-29听到最后的主机独立LB，就想说service mesh了。通过service mesh的方式，是可以避免为不同语言开发的客户端来提供服务远程调用的适配的。我自己使用过：nginx进行服务发现、腾讯的L5进行服务发现（本地agent，定期同步，但各语言成本确实非常高）、TARS微服务框架的主控调用服务发现（调用远程名字服务+客户端本地缓存）、TSEER负载均衡器（同样本地agent，但是以udp方式通信，无需额外适配）。作者回复: 👍你很有经验，用过很多开源微服务组件，理解很深
2018-05-26老师您好，采用第三种lb将请求路由出去，请求响应回来是直接到消费者吗？还是还需要经过lb，再回到消费者？作者回复: 第三种主机独立进程lb相当于在主机上布了一个代理proxy，请求和响应都要穿透的。
- 2018-05-24为什么第二种方式需要为每种语言开发一个版本呢？此话怎讲？为什么这样
作者回复: 第二种是客户端软负载，负载均衡和路由逻辑是做在客户端的库里头的，不同的语言需要不同的客户端实现，比如Netflix的Eureka+Ribbon，Ribbon就是客户端，目前只支持Java，如果其它语言也要接入，则需要定制实现类似Ribbon的负载均衡和路由逻辑。
2018-05-10内容非常赞。作者回复: 谢支持🌹
- 2018-05-10老师您好。服务消费方具体指的是什么？是个客户端还是一个业务模块。还是什么？能否具体指一下吗？还有第一种是不是没有服务注册表就无法进行服务的自动发现？谢谢
作者回复: 提供方一般是提供服务的服务器端，消费方就是调用其它服务的应用程序，有时一个应用既是服务提供方，也是服务消费方（既提供服务同时也调用其它服务）。第一种一般不支持自注册和自发现，一般由运维静态配置，当然也可以扩展支持自注册自发现，作为思考题，你自己调研思考一下
- 2018-05-10service mesh proxy除了LB是否还有其它功能，能否推荐一下具体产品，后面是否会对其具体介绍，目前有什么学习材料。谢谢。
作者回复: envoy+istio目前比较热，搜一下，资料其网站上有不少，可以学习，但目前service mesh大规模生产级应用还不多，产品大都不成熟，建议先学习调研为主