从 0 开始学微服务
胡忠想
微博技术专家
63927 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 43 讲
开篇词 (1讲)
结束语 (1讲)
从 0 开始学微服务
15
15
1.0x
00:00/00:00
登录|注册

02 | 从单体应用走向服务化

专栏上一期,我给你讲述了什么是微服务,以及微服务架构的由来。简单回顾一下,微服务就是将庞杂臃肿的单体应用拆分成细粒度的服务,独立部署,并交给各个中小团队来负责开发、测试、上线和运维整个生命周期。
那么到底什么时候应该拆分单体应用?拆分单体应用有哪些标准可依呢?
为了解答这两个问题,今天我将通过具体案例来阐述,希望你能够学会单体应用拆分成微服务的正确姿势

什么时候进行服务化拆分?

从我所经历过的多个项目来看,项目第一阶段的主要目标是快速开发和验证想法,证明产品思路是否可行。这个阶段功能设计一般不会太复杂,开发采取快速迭代的方式,架构也不适合过度设计。所以将所有功能打包部署在一起,集中地进行开发、测试和运维,对于项目起步阶段,是最高效也是最节省成本的方式。当可行性验证通过,功能进一步迭代,就可以加入越来越多的新特性。
比如做一个社交 App,初期为了快速上线,验证可行性,可以只开发首页信息流、评论等基本功能。产品上线后,经过一段时间的运营,用户开始逐步增多,可行性验证通过,下一阶段就需要进一步增加更多的新特性来吸引更多的目标用户,比如再给这个社交 App 添加个人主页显示、消息通知等功能。
一般情况下,这个时候就需要大规模地扩张开发人员,以支撑多个功能的开发。如果这个时候继续采用单体应用架构,多个功能模块混杂在一起开发、测试和部署的话,就会导致不同功能之间相互影响,一次打包部署需要所有的功能都测试 OK 才能上线。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学微服务》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(85)

  • 最新
  • 精选
  • oddrock
    我现在对拆分的考量: 一是业务维度聚类,业务和数据关系密切的应该放在一起。 二是功能维度聚类,公共功能聚合为一个服务。 三是人员聚类,这是个实际中的考量,如果某几个业务就是这几个人比较熟,那么最好放在一起,未来开发部署都好办。 四是性能聚类,性能要求高的并发大的和性能要求低的并发小的,要分开为不同的服务,这样部署和运行都独立,好维护。 还请老师指教

    作者回复: 总结的很好,看得出来属于业务经验很丰富的。😁

    5
    193
  • 技术修行者
    关于服务拆分策略,我理解在实际工作中应该是横向和纵向相结合的方式: 1. 首先收集整理公用的模块,将其进行服务化处理,这是横向拆分。 2. 其次根据不同业务之间的耦合程度,将相对独立的服务拆分到不同的服务中,这属于纵向拆分。 最后的微服务列表中,既有被其他微服务使用的公共服务,也有彼此独立运行的业务服务。

    作者回复: 对,实际业务中这两种拆分方式一般是相互结合使用的,如果业务比较多分散,适合做纵向拆分。如果多个业务之间有公共模块耦合,适合把公共模块拆分出来,适合做横向拆分。

    2
    47
  • jogin
    看评论感觉好多人不需要微服务。 1.业务复杂度问题单体应用没能梳理清楚,微服务也搞不懂定。 2.人手太少,微服务只会增加系统复杂度,运维成本,大家不要看到把原先的函数调用改成接口调用,没真正了解服务拆分后带来的系统复杂度。 3.系统设计问题,代码写的乱,开发流程问题,不是微服务能解决的。

    作者回复: 对,微服务只能解决单体膨胀后的痛,但也会带来架构复杂性,要权衡利弊

    4
    28
  • 明天更美好
    我们是单体应用,一共22个接口,但是有一个接口并发巨大,二期势必拆分微服务架构。我觉得按照功能进行垂直拆分比较合适,我们之前有17个开发人员,现在裁员就剩下4个。希望胡老师给个建议

    作者回复: 4个人搞微服务,有没有基础架构人员?没有就算了吧……

    5
    23
  • Geek_8d2caa
    开始是10多人的团队,对业务进行了拆分,上线后,人员陆续离职,现在是6个人背着将近30个微服务,开发一个功能点,基本上所有人都得上,就演变成天天开会还解决不了问题,效率奇低……所以,有没有微服务退回到单体的做法?

    作者回复: 可以适当做服务合并

    3
    14
  • 常玉棋
    我觉得目前单体能搞定的话就不要为了拆分而拆分,因为拆分后涉及到的问题有可能会让现有人员手忙脚乱,最好等做好了技术和人员准备再拆分。

    作者回复: 是这样的

    13
  • 🤕 ~ 😮
    横向拆分:把一些不会和其他主业务有依赖的功能拆分出来,最典型的就是common。 纵向拆分:按照业务来拆分,比如用户访问一个商城,从访问到下单成功会调用很多服务,我们可以把用户登录做一个服务,商城首页以及商品信息做一个服务,购物车模块是一个服务,支付模块又是另一个服务,这样整个商城都是微服务架构,不管哪个单独的服务出现问题,都不会影响别的服务,方便于技术人员最快定位问题,解决问题。 准确来说,一个项目里边是横向和纵向都有的,并不冲突,微服务带给我们的好处有很多,但具体能不能使用微服务还要根据具体的项目和团队来决定。 (以上拆分仅供举例参考,具体拆分视项目而定)

    作者回复: 对,视具体项目而定

    2
    12
  • lovedebug
    微服务对运维和运维架构要求很高,没有运维就搞微服务就是给自己埋坑。

    作者回复: 是的

    2
    7
  • eason2017
    前期,可以稍微粗粒度一些。先进行纵向拆分,把基础功能(用户系统)独立部署以维护。其它业务功能关联不紧密的可以独立部署,可以看这些业务在公司发展方向的重要性 后面,可以看清哪些功能是其他业务系统一定要调用的,同时,自身系统内也有其他繁杂的功能,那么可以进行横向切分,把被频繁调用的服务抽象并独立部署。

    作者回复: 对

    7
  • 少帅
    是否需要拆分要看目前公司项目的具体的情况,如果现有架构无法满足当前业务发展速度,比如构建一次要半天,上一次线经常搞通宵,牵一发而动全身,那么这个时候可以考虑一下微服务,拆微服务势必会提高运维、问题追踪、分布式事务等复杂度,所以微服务整个技术栈都要考虑进去

    作者回复: 嗯,搞不定微服务的技术栈就不要往这个坑里跳

    6
收起评论
显示
设置
留言
85
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部