作者回复: 图示为了简化，突出和业务相关的聚合和基础服务层，没有提网关层zuul。zuul一般只处理和业务无关的跨横切面(cross-cutting)逻辑，建议BFF单独一层，关注分离和职责单一原则，当然特殊情况(业务和团队规模很小)zuul上也可以承担BFF职责。

作者回复: 你好，我是在参考Netflix微服务架构的基础上，推荐了一个简化的两层分层模型，下层是基础服务（也称原子服务，领域服务或者公共服务），上层是聚合服务（也称适配服务，BFF），聚合服务可以认为是下层的基础服务和外部的端用户体验（无线，桌面，H5，第三方开放平台等）之间的一个适配层，主要是用来适配端用户体验的，让体验和基础服务不强耦合，可以相互独立变化。这个模型比较简单易于理解，但是不是一个严格的规范，每家公司具体的分层和叫法可能都不太一样，大家不必拘泥纠结。基础服务层中如果有聚合服务也是有场景OK的，有些情况下可能没有聚合服务层，基础服务直接对外暴露，也是有场景OK的，大家要根据具体业务场景、团队和业务规模灵活应用。如果你使用TCC做分布式事务，一般是在基础服务层做，当有也可能有场景需要在聚合层做，也需要灵活应变。一般上层调用下层服务OK，同一层服务间相互调用OK，但是避免下层调用上层。

作者回复: 都可以，统一webapi简单，一套框架搞定。内部用RPC也OK，但对外要多用一套框架转成REST/HTTP。

作者回复: 可以这样认为，更多是适配器，适配不同体验设备

作者回复: 对于一个电商网站，基础服务有商品，分类，购物车，用户等。对于无线app，可以有专门的无线聚合服务，对基础服务进行聚合裁剪，再暴露给无线app，方便无线app使用。对h5app，或第三方接入，也可有专门的聚合服务。

作者回复: 恩，标准的聚合层＋基础服务层

作者回复: 你们的划分方式类似技术支持服务+业务服务，也是一种常见划分方式。

作者回复: zuul一般只处理和业务无关的跨横切面(cross-cutting)逻辑，建议BFF单独一层，当然特殊情况(业务和团队规模很小)zuul上也可以承担BFF职责。PC/mobile/3rd party zuul是共享还是独立，也是看业务和团队规模，小的时候可以共用，大的时候如果团队间有摩擦影响效率了，就要分开，这个就是微服务的分而治之的思想。

作者回复: 可以是一种逻辑分层方式