LMD 置顶2018-01-26关于《微服务架构核心20讲》课程讲义（PDF 文件），学员可复制下面链接到浏览器下载获取。 http://t.cn/RQs9iTw 5
2018-05-18杨老师，现在kubernate讨论的比较多，我的理解他主要起到paas和支撑服务的角色，请问用它搭建微服务架构是否合适，对于运维和开发的要求和工作量是否高？作者回复: k8s是开箱即用式的PaaS平台，Google基本上把微服务的基础能力（服务发现，容器资源调度，发布和监控等）都封装在这个平台里头。目前k8s在社区很火，我认为可以作为微服务平台的一站式解决方案。当然也可以走另外一条路，利用社区开源的组件，比如Spring Cloud自己组合拼装微服务平台。这两种方式各有利弊，前一种方式起步会快，但是随着业务发展难免需要深度定制，所以要有研发资源深入k8s的源码+深度定制的能力。后一种方式前期学习成本和门槛不低，需要有研发定制能力，但是后期会有更大的灵活性。简单讲，两条路都可以走通，但是如果要用好运维好的话，深度定制能力是必须的，千万别简单认为用一个开源产品可以解决所有问题，真正的复杂性在运维治理、流程和业务中。
4
2018-03-30请问杨老师，聚合服务是必须的吗？如客户端使用异步调用多个请求服务，这样不是更快些吗？如果通过聚合服务调用，然后聚合服务再分别调用基础服务，这样是不是反而更慢些呢？
还有是否只有需要合并数据的时候才通过聚合服务，否者直接可以调用基础服务？谢谢作者回复: 聚合服务并非必须，视情况可以直接调基础服务，要不要聚合层，要看业务规模复杂度，前端的迭代频率，团队规模和构成。小团体业务不复杂未必要聚合层。大团队分工业务复杂多变，通常需要聚合层，避免变化扩散到基础服务。另外，聚合层一般是异步并行调后端然后聚合数据。
3- 2018-02-19各种用途的gw什么时候应该独立部署，什么情况应该合并部署？
作者回复: 没有统一标准，简单讲看你的规模，原则是尽量单一职责，一种网关负责一种场景（无线GW，H5 GW，第三方联盟商GW，开放平台GW等等）。如果你的规模小人少，有些东西可以合起来，甚至只有一种网关（里头逻辑会复杂维护是问题）。规模大人多的话，尽量分分开吧，当然维护成本工作量也大。
2 
2018-07-10对老师说的服务注册组件console了解不多。如果用nginx做网关层的话，势必会遇到通过nginx模块或者lua脚本与服务注册中心进行通信的问题。一个明显的痛点就是如何把upstream中写死的ip列表，替换成后端的服务名称进行动态路由。并且能够感知后端服务的机器扩缩容。可能需要通过定期探测+定期获取缓存+失效移除的方式。作者回复: 你的思考正确，可参考Consul Template这样的组件，它可以监视Consul中服务变化，动态更新nginx模板。研发能力强也可以定制自研lua角本对接服务注册中心，另外kong也可参考，内核也是nginx，定制扩展能力更强。
1
2018-06-04波波老师，您好。听了你的课程受益匪浅。有个问题请教一下，目前有些架构师在服务发现的选型上使用了zookeeper，但个人觉得这个框架貌似不合适做微服务的服务发现。您对这个有什么建议么？作者回复: zk可以做服务发现，阿里的dubbo还有新浪微博的motan都支持zk做服务发现。zk是一个通用的分布式协调框架，自己做服务发现的话，需要在上面进一步封装，有一定门槛，不如eureka开箱即用简单。
1
2019-10-13杨老师，外部服务直接通过网关调用内部聚合服务的时候是不是都会先通过网关去注册中心里的路由表中查询到具体的聚合服务，然后聚合服务再去调用基础服务，然后基础服务在注册网关中发现聚合服务，进行返回？
2019-08-18想问下无线GW主要是负责哪些场景呢？作者回复: 无线网关主要负责无线原生Native和Hybrid等应用场景，这个是只是一种划分，具体每家公司的划分方式可能不太一样。
2018-11-15网关和注册中心是微服务体系的两个核心概念。
上游服务向注册中心注册服务，下游服务到注册中心发现服务。网关是最下游的服务，负责将外部请求转发到微服务体系内的边界服务。
注册中心在负责了所有服务的注册和发现的同时，也肩负起了微服务体系的监控和服务治理的职责。
2018-06-07从长远维护角度，大型互联网企业里怎么选择网关？例如：kong，zuul或其它。目前团队Java为主作者回复: 推荐zuul，基于java门槛低点；kong基于nginx/openresty，性能更好，但门槛更高，团队要有人能hold住nginx+lua