下载APP
登录
关闭
讲堂
算法训练营
Python 进阶训练营
企业服务
极客商城
客户端下载
兑换中心
渠道合作
推荐作者
当前播放: 05 | 什么样的组织架构更适合微服务?
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 | 容器集群调度和基于容器的...
本节摘要

精选留言(32)

  • LMD 置顶
    2018-01-26
    关于《微服务架构核心20讲》课程讲义(PDF 文件),学员可复制下面链接到浏览器下载获取。 http://t.cn/RQs9iTw
    6
  • 2018-03-12
    这个视频播放器实在太烂,怎么设计的

    作者回复: 会反馈极客时间,谢谢提醒🌹

    26
  • 2018-01-17
    架构是演化出来的,开始要保证simple原则,尽可能简单
    12
  • 2018-11-13
    微服务架构本质上是一种组织架构的重组。
    这里说的重组,应该是指从按照职能(技术技能)来组织团队转变为按照产品(特性)来组织团队的过程。
    职能团队将关注点主要放在技术上,团队成员掌握了同一个技术知识。
    跨职能的特性团队将关注点放在业务和产品上,团队成员掌握了同一个产品特性的知识。
    由于,团队间的沟通成本远大于团队内的沟通成本。因此,要将沟通频率更高的问题和沟通价值更高的问题放到团队内部。
    由于业务是不断变化的。所以,相比于技术问题,业务问题是沟通频率更高的问题。
    由于对于大部分企业来说,真正产生价值的是公司的主营业务,而非公司积累的技术专利。所以,相比于技术问题,业务问题是沟通价值更高的问题。
    因此,以业务关注点来划分特性团队,相比于以技术关注来划分职能团队,会让整个企业内部的沟通效率更高,让企业更具市场竞争力。
    展开
    10
  • 2018-01-21
    微服务的团队更加专注于某类业务,迭代服务的开发。而传统的开发团队所有业务都接触,难以专注
    8
  • 2018-02-22
    我个人认为团队成员,自己决策者的能力来决定微服务,任何的结果都是人来触发的,水平比较低差的,代码最后的结果只能是重写重构

    作者回复: 恩,团队人才水平对组织和微服务架构有重大影响

    4
  • 2018-01-28
    分情况,有的场景下:架构是设计出来的;而有的时候是需要不断演进而来的
    4
  • 2018-01-18
    把原先按照职能来划分的组织打散,重新按照契合微服务的开发方式来组织。比如,原先甲属于研发团队,后来微服务来了,其中有个用户微服务,安排甲来做微服务,那甲就属于用户微服务团队了。
    3
  • 2018-06-03
    好架构是随着业务发展、问题暴露,不断演化来的,不可能一开始就设计出好架构出来

    作者回复: 正确👍

    2
  • 2018-05-19
    传统软件企业要交付软件给多个客户(十几个到几十个),项目周期又普遍较长(半年到两年不等),这个时候怎么规划团队呢?

    作者回复: 微服务较适合平台型互联网公司,传统软件企业可能还是围绕合同项目组织团队,个人在这块经验不多。

    1
  • 2018-04-15
    都是跨职能的微服务团队的话,应该还需要一个横向的架构在各个微服务之上的组织吗?要不然谁能看到全局呢

    作者回复: 可以有,比如某些公司有虚拟架构团队,但不能太重轻量即可

    1
  • 2018-04-11
    架构是设计出来的,再逐步跟随业务演化,演化的过程其实还是在不停的设计。

    作者回复: 在设计中演化,在演化中设计

    1
  • 2018-01-21
    讲解的非常好,前期的业务验证不一定能得到认可,成本很高,适当的权衡利弊
    1
  • 2019-11-03
    平台+服务支撑业务
  • 2019-08-20
    波波老师,为以后过度到微服务的目标,在一开始采用单体模式开发的时候,需要考虑功能模块的划分设计不?以方便以后微服务的实现,即不用重新实现模块

    作者回复: 模块化是软件设计最佳实践,可以保障软件低耦合,易于重用,今后能灵活扩展,单体和模块化并不矛盾,所以即使采用单块模式,也要提前考虑模块化设计。另外,作为架构师,系统架构设计需要有一定的提前量,其中包括模块化设计。

  • 2019-08-02
    有什么样的组织架构就有什么样的系统架构反应

    作者回复: 对,这是康威法则(conway's law)

  • 2019-03-09
    精彩!

    作者回复: 谢谢支持!

  • 2019-03-01
    目前我们部门团队是异地两地协同开发,在沟通协调测试上面缺乏一些经验,在此模式下采用微服务开发,老师有何意见和个人看法?

    作者回复: 你是,微服务即使一种技术手段,也是一种组织治理方式,通过分而治之方式,达到组织团队和业务开发规模化和快速迭代的目标。异地团队协同开发,采用微服务架构,可以考虑采用契约优先(contract first)开发模式,例如grpc或spring/swagger支持契约驱动开发,开发前,两边团队定义好服务契约, 根据契约开展开发和测试,可以提升一致性和研发效率;当然团队之间良好的沟通和协作也非常重要。

  • 架构设计三原则 :合适原则 、简单原则 、演化原则。

    作者回复: 总结得不错!

  • 2018-11-22
    从架构中来到微服务中去