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

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

故障如何定位
服务如何治理
服务如何监控
服务如何发布和订阅
服务如何定义
从公共且独立功能维度拆分
按照业务关联程度决定
线上服务稳定性挑战
多个功能模块混杂开发、测试和部署
证明产品思路是否可行
快速开发和验证想法
思考题
拆分微服务的建议标准
功能拆分的粒度
必须解决的问题
业务系统引入新技术带来的问题
横向拆分
纵向拆分
问题出现标志
大规模扩张开发人员
需要增加新特性
项目第一阶段的目标
总结
服务化拆分的前置条件
服务化拆分的两种姿势
什么时候进行服务化拆分?
单体应用如何走向服务化?

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

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

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

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

单体应用如何走向服务化?本文介绍了单体应用拆分成微服务的正确姿势。首先,作者提到了拆分单体应用的时机,指出当单体应用同时进行开发的人员超过10人时,就需要考虑进行服务化拆分。接着,文章介绍了服务化拆分的两种姿势,即纵向拆分和横向拆分,以及服务化拆分的前置条件,包括服务定义、发布和订阅、监控、治理以及故障定位等方面的问题。最后,文章总结了拆分微服务时需要考虑的粒度问题,并提出了按照每个开发人员负责不超过3个大的服务为标准的建议。整体而言,本文深入浅出地介绍了单体应用拆分成微服务的必要性、方法和前置条件,对于想要了解微服务架构的读者具有一定的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学微服务》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(86)

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

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

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

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

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

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

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

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

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

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

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

    作者回复: 是这样的

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

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

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

    作者回复: 是的

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

    作者回复: 对

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

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

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