下载APP
登录
关闭
讲堂
算法训练营
Python 进阶训练营
企业服务
极客商城
客户端下载
兑换中心
渠道合作
推荐作者
当前播放: 08 | 微服务总体技术架构体系是怎样设计的?
00:00 / 00:00
标清
  • 标清
1.0x
  • 2.0x
  • 1.5x
  • 1.25x
  • 1.0x
  • 0.5x
网页全屏
全屏
00:00
付费课程,可试看

微服务架构核心20讲

共20讲 · 20课时·约160分钟
13958
免费
01 | 什么是微服务架构?
免费
02 | 架构师如何权衡微服务的利...
免费
03 | 康威法则和微服务给架构师...
04 | 企业应该在什么时候开始考...
05 | 什么样的组织架构更适合微...
06 | 如何理解阿里巴巴提出的微...
07 | 如何给出一个清晰简洁的服...
08 | 微服务总体技术架构体系是...
09 | 微服务最经典的三种服务发...
10 | 微服务 API 服务网关(...
11 | 微服务 API 服务网关(...
12 | 跟 Netflix 学习微服务...
13 | 集中式配置中心的作用和原...
14 | 微服务通讯方式 RPC vs...
15 | 微服务框架需要考虑哪些治...
16 | 微服务监控系统分层和监控...
17 | 微服务的调用链监控该如何...
18 | 微服务的容错限流是如何工...
19 | Docker 容器部署技术 &...
20 | 容器集群调度和基于容器的...
本节摘要

精选留言(15)

  • LMD 置顶
    2018-01-26
    关于《微服务架构核心20讲》课程讲义(PDF 文件),学员可复制下面链接到浏览器下载获取。 http://t.cn/RQs9iTw
    11
  • 2018-03-18
    业务初期要快速迭代产品验证市场接受度,所以前期应以业务驱动,提高开发效率为主,单体应用在这个时期是适合的。如果一开始应用微服务会为整个技术解决方案带来更高的复杂性,拖慢了产品的开发效率

    作者回复: 单块优先,解决业务问题优先

    4
  • 2018-03-16
    假设我需要重新设计系统共用模组架构,其中如IAM,audit日志,缓存,批处理作业,repoting,异常处理,数据访问适合使用微服务来规划吗?
    还是根据单块先行的概念,先设计单块共用模组?谢谢。

    作者回复: 可以设计开发成微服务,这样职责更单一结构更清晰,多人并行开发效率高。但要不要这样做还需综合考虑,微服务也引入复杂性,需基础设施支撑,投入大。主要考量因素是业务和团队规模,系统耦合度是否影响到多团队并行开发效率。如果业务不复杂人也少,单块能搞定最好,没必要为了微服务而微服务。

    2
  • 2018-03-16
    假设我需要重新设计系统共用模组架构,其中如IAM,audit日志,缓存,批处理作业,repoting,异常处理,数据访问适合使用微服务来规划吗?
    还是根据单块先行的概念,先设计单块共用模组?谢谢。

    作者回复: 要看你的业务复杂性和团队规模,规模越大服务会分得越细,否则会有效率问题。如果规模小,建议做好基本的模块化就好了。

    2
  • 2018-08-28
    请教您一个问题,聚合服务层通常作用是聚合和裁剪,那么如果业务只是一个简单的功能,是否可以不调用聚合服务层而直接调用基础服务层,换句话说就是如果基础服务层基本已经提供了某个业务需求,还需要调用聚合服务层吗,如果需要,那不是需要在聚合服务层又写一遍同样的功能,然后转发给基础服务层,这样的场景如果比较多,会有很多冗余,而且会增加一次网络开销。如果老师看到这个问题,请解答我的疑惑,多谢!
    1
  • 2018-08-13
    基础层得各个微服务之间会互相调用吗?还是都不互相理解,都走聚合服务?

    作者回复: 原则:上层可调下层,同层也可相互调用,但禁止下层调用上层

    1
  • 老师的白板写的很好

    作者回复: 谢谢夸赞!

  • 2019-07-30
    网关层,如内部GW、H5GW、无线GW、开放平台GW,套用到SpringCloud的话,是要为其一一单独设置zuul服务么

    作者回复: 具体看你企业的规模,小规模1~2套网关就可以了,中大规模一般分场景部署多套网关 。例如携程网(ctrip)规模较大,2015年我在携程工作的时候,它们大致有6~7套面向不同场景的网关(配置也会有差别),目前应该远不止这么多套了。

  • 2019-05-11
    老师,为什么网关层需要区分内部gw,h5网关,无线网关等? 网关不是应该重点关注跨横切面的功能而不应该涉及具体业务么?

    作者回复: 随着企业业务和团队规模的扩展,会出现需要多套网关部署的场景,例如针对无线应用的无线网关,针对H5应用的H5网关,针对第三方开放平台的开放API网关,针对合作联盟商的联盟商API网关,当然如果企业内部部门和服务多了,也会出现内部API网关。

    这些网关的职能大体类似,但是针对的业务场景不同,一些具体的功能和配置会有不同,有时还需要不同团队进行管理运维,这是分网关部署的一个主要原因,是一种按业务场景分开治理的策略。

    当然,如果企业业务和团队规模小,则可能一套网关就可以搞定,规模大了业务场景复杂了自然会分治。

  • 2019-03-03
    老师请教一个问题,我们当前的微服务中,由于数据库只有一个,用的是mybatis,然后专门做了一个微服务来进行接数据操作,里面大部分都是对单表的操作,其他服务需要调用这个数据库服务,用的是feign来调用。这个时候其他服务同时对多张表进行增删改,就没有事务去控制,这种情况怎么处理?除了用三方中间件处理,本身这种设计是否有问题?能否有其他的方案替代?

    作者回复: 你好,这种做法我没有直接实践过,但我觉得可行,没有看到有明显的问题。事务控制你需要在这个数据服务中封装掉,最好有独立团队集中开发和维护这个数据服务,这样可以根据使用方的不同需求进行封装,集中进行事务处理,也集中进行治理。你需要做好监控,同时考虑扩展性,等量起来了可以考虑sharding,例如根据不同的领域进行拆分和隔离部署,后面按需扩容。

  • 2019-02-19
    老师,您说的资源治理举了什么个栗子,没听清。

    作者回复: 资源治理例如配额治理,一个微服务应用使用多少核CPU,内存多少,多少个容器或虚拟机,一个部门或者团队允许使用多少物理资源等,这些需要治理(规划管理和监控),不治理会被滥用。

  • 2019-01-04
    波波老师,架构图里的业务层的聚合层可以挪到网关层zuul里实现吗? 就是两个在一个zuul工程里面。

    作者回复: zuul一般只处理和业务无关的跨横切面(cross-cutting)逻辑,建议BFF单独一层,关注分离和职责单一原则,当然特殊情况(业务和团队规模很小)zuul上也可以承担BFF职责。

  • 2018-11-13
    相比于单体应用,实施微服务需要更大的技术队伍和更多的硬件资源。初创团队资金有限,没有必要。
  • 2018-10-12
    没学过架构的我。越来越听不懂了

    作者回复: 需要一些后端研发和架构经验积累,加油💪

  • 2018-08-28
    不好意思,我已经在后面的章节评论里看到了答案,之前没有仔细看评论,所以老师您可以忽略我的问题了