02 | 从单体应用走向服务化
胡忠想
该思维导图由 AI 生成，仅供参考
专栏上一期，我给你讲述了什么是微服务，以及微服务架构的由来。简单回顾一下，微服务就是将庞杂臃肿的单体应用拆分成细粒度的服务，独立部署，并交给各个中小团队来负责开发、测试、上线和运维整个生命周期。
那么到底什么时候应该拆分单体应用？拆分单体应用有哪些标准可依呢？
为了解答这两个问题，今天我将通过具体案例来阐述，希望你能够学会单体应用拆分成微服务的正确姿势。
什么时候进行服务化拆分？
从我所经历过的多个项目来看，项目第一阶段的主要目标是快速开发和验证想法，证明产品思路是否可行。这个阶段功能设计一般不会太复杂，开发采取快速迭代的方式，架构也不适合过度设计。所以将所有功能打包部署在一起，集中地进行开发、测试和运维，对于项目起步阶段，是最高效也是最节省成本的方式。当可行性验证通过，功能进一步迭代，就可以加入越来越多的新特性。
比如做一个社交 App，初期为了快速上线，验证可行性，可以只开发首页信息流、评论等基本功能。产品上线后，经过一段时间的运营，用户开始逐步增多，可行性验证通过，下一阶段就需要进一步增加更多的新特性来吸引更多的目标用户，比如再给这个社交 App 添加个人主页显示、消息通知等功能。
一般情况下，这个时候就需要大规模地扩张开发人员，以支撑多个功能的开发。如果这个时候继续采用单体应用架构，多个功能模块混杂在一起开发、测试和部署的话，就会导致不同功能之间相互影响，一次打包部署需要所有的功能都测试 OK 才能上线。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
单体应用如何走向服务化？本文介绍了单体应用拆分成微服务的正确姿势。首先，作者提到了拆分单体应用的时机，指出当单体应用同时进行开发的人员超过10人时，就需要考虑进行服务化拆分。接着，文章介绍了服务化拆分的两种姿势，即纵向拆分和横向拆分，以及服务化拆分的前置条件，包括服务定义、发布和订阅、监控、治理以及故障定位等方面的问题。最后，文章总结了拆分微服务时需要考虑的粒度问题，并提出了按照每个开发人员负责不超过3个大的服务为标准的建议。整体而言，本文深入浅出地介绍了单体应用拆分成微服务的必要性、方法和前置条件，对于想要了解微服务架构的读者具有一定的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《从 0 开始学微服务》，新⼈⾸单¥59
《从 0 开始学微服务》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(86)
- 最新
- 精选
oddrock我现在对拆分的考量： 一是业务维度聚类，业务和数据关系密切的应该放在一起。 二是功能维度聚类，公共功能聚合为一个服务。 三是人员聚类，这是个实际中的考量，如果某几个业务就是这几个人比较熟，那么最好放在一起，未来开发部署都好办。 四是性能聚类，性能要求高的并发大的和性能要求低的并发小的，要分开为不同的服务，这样部署和运行都独立，好维护。 还请老师指教作者回复: 总结的很好，看得出来属于业务经验很丰富的。😁
2018-08-275194
技术修行者
关于服务拆分策略，我理解在实际工作中应该是横向和纵向相结合的方式: 1. 首先收集整理公用的模块，将其进行服务化处理，这是横向拆分。 2. 其次根据不同业务之间的耦合程度，将相对独立的服务拆分到不同的服务中，这属于纵向拆分。 最后的微服务列表中，既有被其他微服务使用的公共服务，也有彼此独立运行的业务服务。作者回复: 对，实际业务中这两种拆分方式一般是相互结合使用的，如果业务比较多分散，适合做纵向拆分。如果多个业务之间有公共模块耦合，适合把公共模块拆分出来，适合做横向拆分。
2018-08-26247
jogin看评论感觉好多人不需要微服务。 1.业务复杂度问题单体应用没能梳理清楚，微服务也搞不懂定。 2.人手太少，微服务只会增加系统复杂度，运维成本，大家不要看到把原先的函数调用改成接口调用，没真正了解服务拆分后带来的系统复杂度。 3.系统设计问题，代码写的乱，开发流程问题，不是微服务能解决的。作者回复: 对，微服务只能解决单体膨胀后的痛，但也会带来架构复杂性，要权衡利弊
2018-08-25428
明天更美好我们是单体应用，一共22个接口，但是有一个接口并发巨大，二期势必拆分微服务架构。我觉得按照功能进行垂直拆分比较合适，我们之前有17个开发人员，现在裁员就剩下4个。希望胡老师给个建议作者回复: 4个人搞微服务，有没有基础架构人员？没有就算了吧……
2018-08-25523- Geek_8d2caa开始是10多人的团队，对业务进行了拆分，上线后，人员陆续离职，现在是6个人背着将近30个微服务，开发一个功能点，基本上所有人都得上，就演变成天天开会还解决不了问题，效率奇低……所以，有没有微服务退回到单体的做法？
作者回复: 可以适当做服务合并
2018-08-28314 
常玉棋我觉得目前单体能搞定的话就不要为了拆分而拆分，因为拆分后涉及到的问题有可能会让现有人员手忙脚乱，最好等做好了技术和人员准备再拆分。作者回复: 是这样的
2018-08-2513
🤕 ～ 😮横向拆分:把一些不会和其他主业务有依赖的功能拆分出来，最典型的就是common。 纵向拆分:按照业务来拆分，比如用户访问一个商城，从访问到下单成功会调用很多服务，我们可以把用户登录做一个服务，商城首页以及商品信息做一个服务，购物车模块是一个服务，支付模块又是另一个服务，这样整个商城都是微服务架构，不管哪个单独的服务出现问题，都不会影响别的服务，方便于技术人员最快定位问题，解决问题。 准确来说，一个项目里边是横向和纵向都有的，并不冲突，微服务带给我们的好处有很多，但具体能不能使用微服务还要根据具体的项目和团队来决定。 (以上拆分仅供举例参考，具体拆分视项目而定)作者回复: 对，视具体项目而定
2018-08-26212
lovedebug微服务对运维和运维架构要求很高，没有运维就搞微服务就是给自己埋坑。作者回复: 是的
2018-08-2827
eason2017前期，可以稍微粗粒度一些。先进行纵向拆分，把基础功能（用户系统）独立部署以维护。其它业务功能关联不紧密的可以独立部署，可以看这些业务在公司发展方向的重要性 后面，可以看清哪些功能是其他业务系统一定要调用的，同时，自身系统内也有其他繁杂的功能，那么可以进行横向切分，把被频繁调用的服务抽象并独立部署。作者回复: 对
2018-08-257
少帅是否需要拆分要看目前公司项目的具体的情况，如果现有架构无法满足当前业务发展速度，比如构建一次要半天，上一次线经常搞通宵，牵一发而动全身，那么这个时候可以考虑一下微服务，拆微服务势必会提高运维、问题追踪、分布式事务等复杂度，所以微服务整个技术栈都要考虑进去作者回复: 嗯，搞不定微服务的技术栈就不要往这个坑里跳
2018-08-266
收起评论
