微服务架构核心 20 讲
杨波
拍拍贷框架研发部总监,资深架构师,微服务技术专家
48687 人已学习
新⼈⾸单¥29
微服务架构核心 20 讲
登录|注册
留言
50
收藏
沉浸
阅读
分享
手机端
回顶部
当前播放: 01 | 什么是微服务架构?
00:00 / 00:00
高清
  • 高清
1.0x
  • 2.0x
  • 1.5x
  • 1.25x
  • 1.0x
  • 0.75x
  • 0.5x
网页全屏
全屏
00:00
付费课程,可试看
01 | 什么是微服务架构?
02 | 架构师如何权衡微服务的利弊?
03 | 康威法则和微服务给架构师怎样的启示?
04 | 企业应该在什么时候开始考虑引入微服务?
05 | 什么样的组织架构更适合微服务?
06 | 如何理解阿里巴巴提出的微服务中台战略?
07 | 如何给出一个清晰简洁的服务分层方式?
08 | 微服务总体技术架构体系是怎样设计的?
09 | 微服务最经典的三种服务发现机制
10 | 微服务 API 服务网关(一)原理
11 | 微服务 API 服务网关(二)开源网关 Zuul
12 | 跟 Netflix 学习微服务路由发现体系
13 | 集中式配置中心的作用和原理是什么?
14 | 微服务通讯方式 RPC vs REST
15 | 微服务框架需要考虑哪些治理环节?
16 | 微服务监控系统分层和监控架构
17 | 微服务的调用链监控该如何选型?
18 | 微服务的容错限流是如何工作的?
19 | Docker 容器部署技术 & 持续交付流水线
20 | 容器集群调度和基于容器的发布体系&结课测试
本节摘要

登录 后留言

全部留言(50)

  • 最新
  • 精选
LMD
置顶
关于《微服务架构核心20讲》课程讲义(PDF 文件),学员可复制下面链接到浏览器下载获取。 http://t.cn/RQs9iTw
2018-01-26
84
null
1. 独立部署给服务带来的好处 提高应用的可扩展性,按需分配资源。同时保证了各服务间的环境隔离,使局部故障的影响最小化;也保证了应用最大资源化和方便管理。 2. 独立数据源带来的挑战 拆分前的下单流程,扣减库存,扣减积分,锁定优惠券,保存订单等操作同属一个事务;拆分后属于不同的服务,需要额外流程保证数据一致性。

作者回复: 理解很到位,应该是有经验的👍

2018-08-25
12
Mine
老师可以解释一下微服务和SOA的差异吗?找了很多回答看都觉得不是很清晰

作者回复: 微服务和SOA没有本质区别,微服务也是一种面向服务的架构风格,只是粒度更细,融入了近年一线互联网服务化实践经验。

2018-03-21
11
小丑魚去哪了
听着微服务和我们公司服务化没啥区别啊 像阿里应该早就采用服务化框架,在支撑业务了吧。为啥14年才提出呢

作者回复: 是的,没有这个概念前很多公司已经是微服务,比如亿贝,阿里,亚马逊等。Netflix经过大规模微服务实战,开源其主要微服务组件,14年左右马丁.福勒写了关于微服务博文,这些事件推动了微服务兴起。

2018-04-25
7
trylove
大中台,小前台。它的最终目标是赋能业务的不断创新!

作者回复: yes

2018-03-31
7
阅过留痕 什么是微服务架构? 微服务架构,拆开就是微+服务+架构 微——表示小,首先,是服务的粒度小,然后是开发团队小,再者就是通信轻量化。 服务——本质就是一个接口的方法,用于处理信息,早就有之,本质不变。 架构——系统的主题结构,类似人体骨架的意思,系统中有类似MVC架构、分层架构、主从架构等分类。 新技术三连击 微服务解决了什么问题? 微服务是怎么解决这些问题的? 微服务引入了那些新问题? 没有微服务系统会是怎样的,痛点在哪里? 新技术的出现基本是为了解决原有技术解决不了的问题的,这个希望老师也讲一下?

作者回复: 单块架构的最大问题,是系统紧密耦合,但是业务发展到一定阶段,必然产生多团队协同开发,于是单块耦合系统和多团队之间就会产生矛盾~多个团队在单块上开发部署,需要很多协同开销,常常还会产生摩擦和打架,严重影响交付效率。 于是,把单体拆解成微服务,各个团队可以自治开发/测试/部署各自负责的微服务,相互不干扰(或者干扰很小),这样可以大大提升交付效率。 在如今的互联网时代,企业快速迭代和交付的效能就是竞争力,单体架构太慢太不灵活,难以规模化。微服务架构最终目标是业务的快速迭代和规模化发展。

2020-02-23
4
Geek_25cbd8
大神讲的挺好,想系统化丰富一下知识体系 有没有k8s云平台系列的讲座?

作者回复: 计划2019开设docker/k8s相关视频课程,敬请关注

2018-09-22
4
meijing0114
独立部署的好处是解耦,把服务部署对机器或者对其他服务的依赖解除掉。这样扩容和缩容就可以更容易自动化并且业务无感知。同时可以把不同服务拆分到不同团队,对团队的技术栈限制也没那么严格。 bounded text主要带来的问题就是数据同步,用户服务提供用户信息,粉丝服务提供粉丝列表,是否要落地一份在粉丝服务?如果落了,粉丝服务的逻辑更干净,服务的使用者也不需要再次额外的调用,但问题就在于 数据的一个实时性是否有那么高的要求。

作者回复: 理解大致正确👍

2018-05-06
4
老师,关于微服务后的质量保障体系有没有什么建议呢?

作者回复: 这是另外一个质量保证QA主题,微服务可以独立测试,传统测试方法体系仍然适用,另外微服务集成测试较复杂,须多套环境,对基础设施要求高,还需要工程规范和流程管理配合。还有微服务強调生产服务监控实时反馈。

2018-04-21
4
小鱼
根据老师的讲解我是否可以理解成不同的构件可以拆分为不同的微服务,并进行相互独立的演化发展。只是有个问题没想明白,假设产品和订单两个构件拆成了两个独立的服务,但是订单中又会包含产品信息,订单服务中如何去提现产品信息的?请老师答疑解惑,谢谢

作者回复: 如果明确订单和产品拆成两个服务,那么订单服务可通过调用产品服务方式获取产品数据信息。对于上层服务如需要的话,也可以去调订单和产品服务后再聚合。

2018-11-11
3
收起评论