作者回复: k8s是开箱即用式的PaaS平台，Google基本上把微服务的基础能力（服务发现，容器资源调度，发布和监控等）都封装在这个平台里头。目前k8s在社区很火，我认为可以作为微服务平台的一站式解决方案。当然也可以走另外一条路，利用社区开源的组件，比如Spring Cloud自己组合拼装微服务平台。这两种方式各有利弊，前一种方式起步会快，但是随着业务发展难免需要深度定制，所以要有研发资源深入k8s的源码+深度定制的能力。后一种方式前期学习成本和门槛不低，需要有研发定制能力，但是后期会有更大的灵活性。简单讲，两条路都可以走通，但是如果要用好运维好的话，深度定制能力是必须的，千万别简单认为用一个开源产品可以解决所有问题，真正的复杂性在运维治理、流程和业务中。

作者回复: 聚合服务并非必须，视情况可以直接调基础服务，要不要聚合层，要看业务规模复杂度，前端的迭代频率，团队规模和构成。小团体业务不复杂未必要聚合层。大团队分工业务复杂多变，通常需要聚合层，避免变化扩散到基础服务。另外，聚合层一般是异步并行调后端然后聚合数据。

作者回复: 没有统一标准，简单讲看你的规模，原则是尽量单一职责，一种网关负责一种场景（无线GW，H5 GW，第三方联盟商GW，开放平台GW等等）。如果你的规模小人少，有些东西可以合起来，甚至只有一种网关（里头逻辑会复杂维护是问题）。规模大人多的话，尽量分分开吧，当然维护成本工作量也大。

作者回复: 你的思考正确，可参考Consul Template这样的组件，它可以监视Consul中服务变化，动态更新nginx模板。研发能力强也可以定制自研lua角本对接服务注册中心，另外kong也可参考，内核也是nginx，定制扩展能力更强。

作者回复: 有些公司做法基础服务基本上就是数据访问层(对领域模型的增删改查)，也有公司基础服务也是包含一定业务逻辑的，比如订单服务/支付服务。聚合服务主要聚合/裁剪/适配工作。 聚合：比如首页同时要展示分类和产品信息，那么首页聚合服务同时要调用category和product两个服务再聚合起来。 裁剪：针对手机屏幕，显示不了那么多数据，所以要裁剪掉一些payload。 适配：适配不同的端用户体验设备，PC/Pad/Mobile等。

作者回复: zk可以做服务发现，阿里的dubbo还有新浪微博的motan都支持zk做服务发现。zk是一个通用的分布式协调框架，自己做服务发现的话，需要在上面进一步封装，有一定门槛，不如eureka开箱即用简单。

作者回复: 服务调用/返回和注册中心/服务发现没有直接关系。 外部客户端->网关->聚合服务->基础服务，这个是微服务调用链。基础服务->聚合服务->网关->外部客户端，这个是微服务响应返回链路。 网关发现聚合服务，或者聚合服务发现基础服务，这些一般是后台异步进行，和客户端调用/返回没有直接关系。

作者回复: 无线网关主要负责无线原生Native和Hybrid等应用场景，这个是只是一种划分，具体每家公司的划分方式可能不太一样。

作者回复: k8s平台内置支持服务发现，所以不需要再单独引入服务注册发现中心。