高并发系统设计40问
唐扬
美图公司技术专家
立即订阅
9202 人已学习
课程目录
已更新 38 讲 / 共 40 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要学习高并发系统设计?
免费
基础篇 (6讲)
01 | 高并发系统:它的通用设计方法是什么?
02 | 架构分层:我们为什么一定要这么做?
免费
03 | 系统设计目标(一):如何提升系统性能?
04 | 系统设计目标(二):系统怎样做到高可用?
05 | 系统设计目标(三):如何让系统易于扩展?
06 | 面试现场第一期:当问到组件实现原理时,面试官是在刁难你吗?
演进篇 · 数据库篇 (5讲)
07 | 池化技术:如何减少频繁创建数据库连接的性能损耗?
08 | 数据库优化方案(一):查询请求增加时,如何做主从分离?
09 | 数据库优化方案(二):写入数据量增加时,如何实现分库分表?
10 | 发号器:如何保证分库分表后ID的全局唯一性?
11 | NoSQL:在高并发场景下,数据库和NoSQL如何做到互补?
演进篇 · 缓存篇 (6讲)
12 | 缓存:数据库成为瓶颈后,动态数据的查询要如何加速?
13 | 缓存的使用姿势(一):如何选择缓存的读写策略?
14 | 缓存的使用姿势(二):缓存如何做到高可用?
15 | 缓存的使用姿势(三):缓存穿透了怎么办?
16 | CDN:静态资源如何加速?
加餐 | 数据的迁移应该如何做?
演进篇 · 消息队列篇 (6讲)
17 | 消息队列:秒杀时如何处理每秒上万次的下单请求?
18 | 消息投递:如何保证消息仅仅被消费一次?
19 | 消息队列:如何降低消息队列系统中消息的延迟?
20 | 面试现场第二期:当问到项目经历时,面试官究竟想要了解什么?
用户故事 | 从“心”出发,我还有无数个可能
期中测试 | 10道高并发系统设计题目自测
演进篇 · 分布式服务篇 (9讲)
21 | 系统架构:每秒1万次请求的系统要做服务化拆分吗?
22 | 微服务架构:微服务化后,系统架构要如何改造?
23 | RPC框架:10万QPS下如何实现毫秒级的服务调用?
24 | 注册中心:分布式系统如何寻址?
25 | 分布式Trace:横跨几十个分布式组件的慢请求要如何排查?
26 | 负载均衡:怎样提升系统的横向扩展能力?
27 | API网关:系统的门面要如何做呢?
28 | 多机房部署:跨地域的分布式系统如何做?
29 | Service Mesh:如何屏蔽服务化系统的服务治理细节?
演进篇 · 维护篇 (5讲)
30 | 给系统加上眼睛:服务端监控要怎么做?
31 | 应用性能管理:用户的使用体验应该如何监控?
32 | 压力测试:怎样设计全链路压力测试平台?
33 | 配置管理:成千上万的配置项要如何管理?
34 | 降级熔断:如何屏蔽非核心系统故障的影响?
高并发系统设计40问
登录|注册

22 | 微服务架构:微服务化后,系统架构要如何改造?

唐扬 2019-11-13
你好,我是唐扬。
上一节课,我带你了解了,单体架构向微服务化架构演进的原因,你应该了解到,当系统依赖资源的扩展性出现问题,或者是一体化架构带来的研发成本、部署成本变得难以接受时,我们会考虑对整体系统,做微服务化拆分。
微服务化之后,垂直电商系统的架构会将变成下面这样:
在这个架构中,我们将用户、订单和商品相关的逻辑,抽取成服务独立的部署,原本的 Web 工程和队列处理程序,将不再直接依赖缓存和数据库,而是通过调用服务接口,查询存储中的信息。
有了构思和期望之后,为了将服务化拆分尽快落地,你们决定抽调主力研发同学,共同制定拆分计划。但是细致讨论后发现,虽然对服务拆分有了大致的方向,可还是有很多疑问,比如:
服务拆分时要遵循哪些原则?
服务的边界如何确定?服务的粒度是怎样呢?
在服务化之后,会遇到哪些问题呢?我们又将如何来解决?
当然,你也许想知道,微服务拆分的具体操作过程和步骤是怎样的,但是这部分内容涉及的知识点比较多,不太可能在一次课程中,把全部内容涵盖到。而且《DDD 实战课》中,已经侧重讲解了微服务化拆分的具体过程,你可以借鉴。
上面这三点内容,会影响服务化拆分的效果,但在实际的项目中,经常被大部分人忽略,所以是我们本节课的重点内容。而我希望你能把本节课的内容和自身的业务结合起来体会,思考业务服务化拆分的方式和方法。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《高并发系统设计40问》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(20)

  • Stalary
    微服务化之后一些读库操作变成了远程调用,很多多次读的操作都要修改为批量读取来减少网络耗时,这里的改动还是很大的,甚至一些要求响应时间很高的,还需要做本地缓存/

    作者回复: 是的

    2019-11-13
    1
    5
  • 老师好,我们在做微服务项目的时候。碰到最难受的问题就是:比如一个流程要调用三四个服务,前两个调用成功了,第三个失败了。类似的这种情况,该怎么处理呢?

    作者回复: 这个只能保证最终一致性,比如如果有失败的,想办法把数据修复

    2019-11-15
    2
    4
  • 小喵喵
    微服务拆分的原则:
    原则一,做到单一服务内部功能的高内聚,和低耦合
    原则二,你需要关注服务拆分的粒度,先粗略拆分,再逐渐细化。
    原则三,拆分的过程,要尽量避免影响产品的日常功能迭代,也就是说,要一边做产品功能迭代,一边完成服务化拆分。
    原则四,服务接口的定义要具备可扩展性。
    2019-11-13
    4
  • 吃饭饭
    服务接口修改版本号问题;服务间的循环依赖问题;传输协议的选型很重要,因为牵扯到序列化问题;链路追踪能及时发现报错日志;点太多啦:)
    2019-11-13
    2
  • Hwan
    然后想问下老师,就是我们的用户服务也是单独分出来了,有的内容放在了缓存里面了,但是目前除了去调用用户服务的接口获得数据外,有的时候是直接在其他服务里面调用用户的redis里面的数据的,感觉这样比较快,比调用接口快,然后想问下,按照微服务的话,这种放在缓存供其他服务调用是合理的吗?是不是最好还是缓存也分开,然后每次都得调用接口,然后接口里面调用缓存会比较好啊,希望老师解答,谢谢老师

    作者回复: 这样不太好,服务依赖的资源最好不要和其他服务共享,否则一旦这个资源变更了,我们很可能会漏掉其他服务;再有就是如果其他服务对这个资源有不当的使用,那么也会影响到你的服务

    2019-11-13
    2
    1
  • 大鸡腿🍗
    反驳一点,用户相关的数据有时需要冗余到本服务,跨项目有时查点数据很蛋疼,或者说加点接口,用户服务要排期,如果是冗余到自己的服务,随便加接口。
    其次改接口成4个参数的时候,应该加个过期注解,保留旧的接口兼容旧的调用,让他们慢慢迁移,然后新增新的接口来实现新的逻辑。其次还有maven的快照版本跟正式版本来解决,虽然我没有去了解过,哈哈
    2019-12-08
  • Luciano李鑫
    感觉微服务的拆分像极了面向对象中的类的划分。
    2019-11-20
  • stg609
    想问下老师如何拆分数据库又不影响日常功能迭代的? 是该先拆工程还是先拆数据库呢?

    作者回复: 一般先拆数据库

    2019-11-20
  • chp
    公司现在的项目,用的应该是老师说的折中方法,拆分了很多子模块,但是模块与模块的依赖比较严重,像资源模块,作为基础模块,其他模块基本都要用到这模块的表,老师关于这个,针对这个依赖情况,您有什么好建议吗?如何做到高内聚低耦合
    2019-11-18
  • longslee
    打开。wow,这节课似乎学到不少。
    1. 从认证用户这个例子,联想到分层架构思想,即便有些很简单的逻辑,也不宜越级实现,否则后期维护的时候分散得到处都是。
    2. 服务接口的参数类型最好是封装类
    3. “康威定律”听起来很有道理
    4. 我们团队监控调用链使用的是 pinpoint
    5. 拆分工程jar包依赖我们也做,采用maven来互相引入,不过也容易出现改动后编译期就出问题,不如微服务运行时来的纯粹。
    2019-11-14
  • 红袖添香
    “团队按照业务边界划分”,这个是非常必要的,如果没有对应的人负责,拆分的“高内聚,低耦合”根本无从谈起
    2019-11-14
  • 高源
    老师阅读开源框架源码这块你们是怎么进行的,理清架构和分析架构开发思想,读开源的源代码我想要的是人家是怎么设计使用利用设计模式反射等开发出来的框架的,我理解学会了可以学习借鉴自己应用到实践中,但苦于看源码有些不懂的,该怎么进行呢

    作者回复: 我的做法一般是把源代码下载下来先把它运行起来,然后想一想它解决的是什么问题,再根据问题来调试代码

    2019-11-14
    1
  • Hwan
    刚进公司的时候就是使用的微服务,结合文章的内容,我觉得我们团队在遇到故障之后的问题追踪方面还可以加强下,
    2019-11-13
  • 夜空中最亮的星(华仔)
    我又回来啦,老师

    作者回复: 欢迎~

    2019-11-13
  • 陈 争
    我们一开始是按照页面功能进行拆分的,感觉拆的太细了,后来又按照业务合并了一些服务。
    服务如果拆的太多,一旦修改了接口,沟通成本还是很高的。
    2019-11-13
  • mickey
    微服务拆分以后最大的问题是故障的排查与定位问题。

    作者回复: 是的

    2019-11-13
  • 啊啊啊哦哦
    老师问你一些我对微服务的困惑。
    1:服务层是前面分层架构中讲到的service和manager层拆分出来独立部署成一个微服务吗
    2业务逻辑都是写在服务层吗。比如我下一个订单。web 层直接调用服务层的下单逻辑
    3。web层需要变动吗。 还是也要变成用户web层。订单web层。
    没真正接触过微服务看了网站那些有点乱
     

    作者回复: 1. 是的
    2. 是的,业务逻辑是在服务层
    3. web层需要把业务逻辑下沉到服务层,web层也可以区分成用户web和订单web

    2019-11-13
  • 白马度和
    拆分后必然要面临分布式事物
    2019-11-13
  • 健少
    微服务的“拆”,比较讲究,前期怎么拆,后期要如何拆,其实没有做过微服务是很难把握的。
    2019-11-13
  • 方木木
    考试能不能推荐一些微服务相关的书籍和资料
    2019-11-13
收起评论
20
返回
顶部