高并发系统设计 40 问
唐扬
美图公司技术专家
49013 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
高并发系统设计 40 问
15
15
1.0x
00:00/00:00
登录|注册

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

一课一思
课程小结
问题和解决思路
原则
微服务架构

该思维导图由 AI 生成,仅供参考

你好,我是唐扬。
上一节课,我带你了解了单体架构向微服务化架构演进的原因,你应该了解到当系统依赖资源的扩展性出现问题,或者是一体化架构带来的研发成本、部署成本变得难以接受时,我们会考虑对整体系统做微服务化拆分。
微服务化之后垂直电商系统的架构将会变成下面这样:
在这个架构中,我们将用户、订单和商品相关的逻辑抽取成服务独立的部署,原本的 Web 工程和队列处理程序将不再直接依赖缓存和数据库,而是通过调用服务接口查询存储中的信息。
有了构思和期望之后,为了将服务化拆分尽快落地,你们决定抽调主力研发同学共同制定拆分计划。但是仔细讨论后你们发现,虽然对服务拆分有了大致的方向可还是有很多疑问,比如:
服务拆分时要遵循哪些原则?
服务的边界如何确定?服务的粒度是怎样的?
在服务化之后会遇到哪些问题呢?我们又将如何来解决?
当然,你也许想知道微服务拆分的具体操作过程和步骤是怎样的,但是这部分内容涉及的知识点比较多,不太可能在一次课程中把全部内容涵盖到。而且《DDD 实战课》中已经侧重讲解了微服务化拆分的具体过程,你可以借鉴。
而上面这三点内容会影响服务化拆分的效果,但在实际的项目中经常被大部分人忽略,所以是我们本节课的重点内容。我希望你能把本节课的内容和自身的业务结合起来体会,思考业务服务化拆分的方式和方法。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了微服务架构的原则和方法,以及在微服务化后可能出现的问题和解决思路。在拆分微服务之前,需要遵循几个原则,包括保持单一服务内部功能的高内聚和低耦合,关注服务拆分的粒度,避免影响产品的日常功能迭代,以及定义具备可扩展性的服务接口。文章强调了拆分过程中的注意事项和拆分顺序上的建议。此外,还介绍了微服务化后可能引入的复杂度,包括服务接口的跨进程网络调用、多个服务之间的依赖关系、以及请求的调用链路上涉及多个服务时的问题。为了解决这些问题,需要引入服务调用框架、服务注册中心、服务治理体系、分布式追踪工具和服务端监控报表。文章还提到了“康威定律”和微服务化的团队组织结构,以及微服务化的目标和团队规模的建议。最后,鼓励读者分享在微服务拆分后遇到的问题和解决经验。整体而言,本文为读者提供了微服务架构的原则、方法和可能出现的问题及解决思路,为业务服务化拆分提供了指导和思路。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《高并发系统设计 40 问》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(37)

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

    作者回复: 是的

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

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

    2019-11-15
    5
    21
  • Hwan
    然后想问下老师,就是我们的用户服务也是单独分出来了,有的内容放在了缓存里面了,但是目前除了去调用用户服务的接口获得数据外,有的时候是直接在其他服务里面调用用户的redis里面的数据的,感觉这样比较快,比调用接口快,然后想问下,按照微服务的话,这种放在缓存供其他服务调用是合理的吗?是不是最好还是缓存也分开,然后每次都得调用接口,然后接口里面调用缓存会比较好啊,希望老师解答,谢谢老师

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

    2019-11-13
    4
    9
  • 吕超
    两个披萨就够我一个人吃。老外一个个人高马大的,胃口咋那么小。

    作者回复: 这个有时间要问问老贝了:)

    2020-01-05
    6
    6
  • mickey
    微服务拆分以后最大的问题是故障的排查与定位问题。

    作者回复: 是的

    2019-11-13
    5
  • 微服务化基础设施不全会很痛苦,尤其是出现服务问题时,怎么拆最关键的?具体需要看公司大环境,以及组内业务情况,不过设计原则基本是老师所说的吧!目标是提高人效节省成本,使公司业务更好的开展赚更多的钱😍

    作者回复: 能不碰就不碰吧 尤其是业务前景不明的情况下,就别添乱了

    2020-04-25
    2
  • 芳菲菲兮满堂
    这个微服务的编译依赖其他的微服务的 版本管理很是难受

    作者回复: 是的

    2020-03-18
    3
    1
  • 空知
    老师,问下文中说的 用户服务 和 内容服务 那里,对于内容服务内容的获取鉴权的过程,每次请求都先去用户服务那边判断是否有权限,有权限再走内容服务 没权限直接返回,而 内容服务只是获取内容 不做任何鉴权 这样做可以吗?

    作者回复: 我觉得是可以的

    2020-01-15
    1
  • 木木
    我们的微服务,缺少运维啊。都是一个人当两三个人用,开发测试运维都做了。导致各种基建没做好,也没有运维,就是定定位问题就太痛苦了

    作者回复: 那是痛苦啊

    2020-04-14
    2
  • 芳菲菲兮满堂
     老师 编译依赖有什么实践吗 这些东西破坏了我持续交付体系 发布版本补丁时候要把之前依赖的版本都找回来 目前是通过nexus管理 但是后期想容器化的时候 这块是个拦路虎 没想到要怎么解决这个问题 老师可否提供个思路?

    作者回复: 没太懂……依赖不是maven来管理的?

    2020-03-20
收起评论
显示
设置
留言
37
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部