- 标清
- 2.0x
- 1.5x
- 1.25x
- 1.0x
- 0.5x
微服务架构核心20讲
精选留言(17)
LMD 置顶2018-01-26关于《微服务架构核心20讲》课程讲义（PDF 文件），学员可复制下面链接到浏览器下载获取。 http://t.cn/RQs9iTw 4
2018-11-13从逻辑划分的角度，微服务可以划分成基础服务和聚合服务。
基础服务是核心的领域服务。如订单服务、商品服务。
聚合服务有时候也叫裁剪服务或边界服务。位于外层的边界服务，从基础服务过去数据，有的时候只需要将这些数据的子集传递给前断，因此得名“裁剪“；有的时候需要从多个基础服务获取数据，并将这些数据按照一定的格式重新组装后响应给前段，因此得名“聚合”。
边界服务的存在，使得每一个基础服务可以围绕业务领域，被设计地更加高内聚。也使得基础服务仅需暴露出合适粒度的通用接口。这两点都使得位于底层的基础服务更加稳定。展开 3
2018-02-03zuul性能OK的，关键看怎么用，如果网关上加重逻辑性能肯定下降，另外有很多参数要调，还有网关无状态，性能不够可加机器水平扩。golang里头开源网关也不少，traefik和tyk等都不错 3
2019-01-04波波老师，这节的架构图好像没有提到Zuul层；
Zuul网关层和聚合/边界访问，是垂直依赖关系？ 还是两者融合在一个代码工程里面呢？作者回复: 图示为了简化，突出和业务相关的聚合和基础服务层，没有提网关层zuul。zuul一般只处理和业务无关的跨横切面(cross-cutting)逻辑，建议BFF单独一层，关注分离和职责单一原则，当然特殊情况(业务和团队规模很小)zuul上也可以承担BFF职责。
2
2018-01-28有个问题请教，对于apigateway的性能有讲究么，比如zuul单机能达到多少，我们用golang做项目，正在参考gateway这个框架golang写的，作者说笔记本上做到3万的QPS不知道关于网关的性能有啥标准没？作者回复: 都可以，统一webapi简单，一套框架搞定。内部用RPC也OK，但对外要多用一套框架转成REST/HTTP。
2- 2018-01-25不一定，有些公司是层次间调用采用rpc，比如用dubbo，也有用rest api，比如用spring，也有混用的，视情况没有严格规范。建议标准化服务框架和调用模式。 2
2018-09-27能否请杨老师举个场景事例，来讲解一下聚合层跟基础服务层的划分。作者回复: 对于一个电商网站，基础服务有商品，分类，购物车，用户等。对于无线app，可以有专门的无线聚合服务，对基础服务进行聚合裁剪，再暴露给无线app，方便无线app使用。对h5app，或第三方接入，也可有专门的聚合服务。
1
2018-06-15现在公司基本上也是分为API层和SOA服务层。API主要为app、web站点提供逻辑组合服务，间或有一些缓存来提高自己的处理性能，语言为PHP和Java两种。SOA服务层主要是基础的服务，如用户、作家、阅读等等。两者之间使用二进制协议进行沟通。作者回复: 恩，标准的聚合层＋基础服务层
1- 2018-01-23层之间用rpc彼此调用么，还是全部用webapi统一？ 1
- 2019-01-04web bff是使用zuul可以吗？最佳实践是pc 移动 第三方部署独立的zuul还是共用一个project代码？
作者回复: zuul一般只处理和业务无关的跨横切面(cross-cutting)逻辑，建议BFF单独一层，当然特殊情况(业务和团队规模很小)zuul上也可以承担BFF职责。PC/mobile/3rd party zuul是共享还是独立，也是看业务和团队规模，小的时候可以共用，大的时候如果团队间有摩擦影响效率了，就要分开，这个就是微服务的分而治之的思想。
2018-11-23聚合服务起承上启下的作用吗作者回复: 可以这样认为，更多是适配器，适配不同体验设备
2018-11-06业务前台、中台、技术中台是不是也可以看做是一种服务分层？业务前台对应聚合层，其他对应基础服务作者回复: 可以是一种逻辑分层方式
2018-05-18请问杨老师，对于领域核心服务。
比如订单基础服务。我这边设计成2层应用。一个订单领域服务，一个订单核心服务。核心服务只是对db和redis的数据原子操作。领域服务是对各种核心服务的业务封装。比如下订单的操作，由聚合服务组装，订单领域，库存领域，用户领域等等。每层领域都至少分为2层，不能横向调用，不能跨db操作。这样的设计会不会过度?
如果这样设计了，tcc事务操作是在聚合服务做，还是领域服务做?
领域服务应该是不能互相调用是吗?只能向下调用自己的核心服务。
微服务体系设计成聚合，领悟，核心这样如何?展开作者回复: 你好，我是在参考Netflix微服务架构的基础上，推荐了一个简化的两层分层模型，下层是基础服务（也称原子服务，领域服务或者公共服务），上层是聚合服务（也称适配服务，BFF），聚合服务可以认为是下层的基础服务和外部的端用户体验（无线，桌面，H5，第三方开放平台等）之间的一个适配层，主要是用来适配端用户体验的，让体验和基础服务不强耦合，可以相互独立变化。这个模型比较简单易于理解，但是不是一个严格的规范，每家公司具体的分层和叫法可能都不太一样，大家不必拘泥纠结。基础服务层中如果有聚合服务也是有场景OK的，有些情况下可能没有聚合服务层，基础服务直接对外暴露，也是有场景OK的，大家要根据具体业务场景、团队和业务规模灵活应用。如果你使用TCC做分布式事务，一般是在基础服务层做，当有也可能有场景需要在聚合层做，也需要灵活应变。一般上层调用下层服务OK，同一层服务间相互调用OK，但是避免下层调用上层。
2018-05-16聚合服务是不是有用nodejs开发的？记得之前看过哪家架构似乎有用到nodejs来对接前端和后端，从而给前端提供更好的api调用。作者回复: 完全可以，很多公司用nodejs开发聚合服务。聚合服务一般由前端开发，前端熟js，用node正合适
- 2018-05-02我心中的理想分层是微服务层，聚合层(负责聚合微服务)，bff层。这样微服务间禁止互相调用避免了层级过深的问题。但是bff这层谁去做？后端做，相当于前端提需求，增加了后端工作量，前端做，他们无法统一语言。最后被迫在前端内部做，他们很不满。
那么为什么我这里聚合层不适合做bff，是因为违背了他的初衷，聚合不是一个服务聚合所有微服务接口。所有业务在一个那就相当于网关，负载压力太大。既然分开了肯定因为有各自的业务属性。
归根结底还是bff层无法统一的问题。展开作者回复: BFF我理解就是聚合层，就是前端应用和后端微服务的一个适配器层，适配不同用户体验的。BFF可以有很多（桌面浏览器应用BFF，无线应用BFF，H5应用BFF，第三方接入BFF），看资源和需求，一般前端团队按需开发
2018-04-03杨老师您好我想请教一下，微服务的基础服务主要是轻量级无状态的，以便于scaleout同时为不同的前台服务提供调用。我想这样的话不适合放入大量的业务逻辑在api里。在您的视频中主要是2层，因此是否需要抽象出业务逻辑层，当然也许需要考虑逻辑层是否是多个服务共通的，或者是让bff来担任这个角色。我想知道一下您的思路和最佳实践，为什么？作者回复: 我的两层分层方式比较简单，下层统称基础服务(也有称公共服务，业务领域服务），上层聚合服务（适配服务，或BFF），下层一般有复杂业务逻辑，上层较简单聚合逻辑
2018-02-20杨老师好，有两个问题：
1、第一讲里提到微服务的架构规范或者原则有一点叫松散耦合，跟这一讲的基础和聚合服务有没有冲突
聚合服务完全需要依赖基础服务才可以对外提供完整服务，这个是否属于强依赖，基础服务的功能上线 测试发布对聚合服务都会有影响
2、有多个微服务应用，但是数据库都是同一个，这是好的设计么，比如对于保险业务，整个投保的过程包括投保单录入、核保规则校验、投保确认、支付、签单几个过程，这几个过程都需要依赖投保单数据，这种是按功能结构划分成多个微服务呢，还是作为一整个服务合适展开作者回复: 1，松散耦合主要是指各个服务之间可以独立开发部署，相互尽量不强依赖，前端聚合服务和后台服务只是一种逻辑划分，这种划分使架构上更清晰易于识别。松散耦合并不是说完全没有依赖，前端服务一般是会依赖于后台服务的，这种依赖如果是有限受控的，则架构上是合理的。后台服务变更，如何做到对前台服务无或者很小影响，这是对架构、服务治理和研发流程管理等众多方面的考验。2，视情况定，多个微服务后面用同一个数据库也是可以的。如果量涨到一定阶段，单体数据库成为瓶颈（性能和团队开发效率瓶颈），则逐步拆分数据库，很多公司都是这么过来的。服务具体怎么拆分，没有统一标准，视业务量和团队规模，也和架构师的领域拆分能力有关。