02丨从单体应用走向服务化1.pdfVIP

加微信：642945106发送“赠送”领取赠送精品课程  发数字“2”获取众筹列表 下载APP  02 | 从单体应用走向服务化 2018-08-25 胡忠想 从0开始学微服务 进入课程  讲述：胡忠想  时长 07:55 大小 3.64M 专栏上一期，我给你讲述了什么是微服务，以及微服务架构的由来。简单回顾一下，微服务 就是将庞杂臃肿的单体应用拆分成细粒度的服务，独立部署，并交给各个中小团队来负责开 发、测试、上线和运维整个生命周期。 那么到底什么时候应该拆分单体应用？拆分单体应用有哪些标准可依呢？ 为了解答这两个问题，今天我将通过具体案例来阐述，希望你能够学会单体应用拆分成微服 务的正确姿势。 什么时候进行服务化拆分？ 从我所经历过的多个项目来看，项目第一阶段的主要目标是快速开发和验证想法，证明 思路是否可行。这个阶段功能设计一般 太复杂，开发采取快速迭代的方式，架构也不适 合过度设计。所以将所有功能打包部署在一起，集中地进行开发、测试和运维，对于项目起 步阶段，是最高效也是最节省成本的方式。当可行性验证通过，功能进一步迭代，就可以加 入越来越多的新特性。 比如做一个社交 App，初期为了快速上线，验证可行性，可以只开发首页信息流、评论等 基本功能。 上线后，经过一段时间的运营，用户开始逐步增多，可行性验证通过，下一 阶段就需要进一步增加 的新特性来吸引 的目标用户，比如再给这个社交 App 添加 个人主页显示、消息通知等功能。 一般情况下，这个时候就需要大规模地扩张开发 ，以支撑多个功能的开发。如果这个时 候继续采用单体应用架构，多个功能模块混杂在一起开发、测试和部署的话，就会导致不同 功能之间相互影响，一次打包部署需要所有的功能都测试 OK 才能上线。 不仅如此，多个功能模块混部在一起，对线上服务的稳定性也是个巨大的 。比如 A 开 发的一个功能由于代码编写考虑不够全面，上线后产生了内存泄漏，运行一段时间后进程异 常 ，那么部署在这个服务池中的所有功能都不可 。一个经典的案例就是，曾经有一 个 App，因为短时间内某个 量巨大，超过了服务器的承载能力，造成了 这个 无法 。不幸的是，这个 和 的服务部署在一起，也波及了 ，几乎全站 。 根据 实际项目经验，一旦单体应用同时进行开发的 超过 10 人，就会遇到上面的问 题，这个时候就该考虑进行服务化拆分了。 服务化拆分的两种 那么服务化拆分具体该如何实施呢？一个最有效的 就是将不同的功能模块服务化， 部署和运维。以前面提到的社交 App 为例，你可以认为首页信息流是一个服务，评论是一 个服务，消息通知是一个服务，个人主页也是一个服务。 这种服务化拆分方式是纵向拆分 ，是从业务维度进行拆分。标准是按照业务的关联程度来决 定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较 的业务适合单独拆分 为一个微服务。 还有一种服务化拆分方式是横向拆分 ，是从公共且 功能维度拆分。标准是按照是否有公 共的被多个其他服务调用，且依赖的 不与其他业务耦合。 继续以前面提到的社交 App 举例，无论是首页信息流、评论、消息箱还是个人主页，都需 要显示用户的昵称。假如用户的昵称功能有 需求的变更，你需要上线几乎所有的服务， 这个成本就有点高了。显而易见，如果我把用户的昵称功能单独部署成一个