从0开始学微服务
胡忠想
微博技术专家
立即订阅
16163 人已学习
课程目录
已完结 42 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 微服务,从放弃到入门
免费
模块一 入门微服务 (10讲)
01 | 到底什么是微服务?
02 | 从单体应用走向服务化
03 | 初探微服务架构
04 | 如何发布和引用服务?
05 | 如何注册和发现服务?
06 | 如何实现RPC远程服务调用?
07 | 如何监控微服务调用?
08 | 如何追踪微服务调用?
09 | 微服务治理的手段有哪些?
10 | Dubbo框架里的微服务组件
模块二 落地微服务 (14讲)
11 | 服务发布和引用的实践
12 | 如何将注册中心落地?
13 | 开源服务注册中心如何选型?
14 | 开源RPC框架如何选型?
15 | 如何搭建一个可靠的监控系统?
16 | 如何搭建一套适合你的服务追踪系统?
17 | 如何识别服务节点是否存活?
18 | 如何使用负载均衡算法?
19 | 如何使用服务路由?
20 | 服务端出现故障时该如何应对?
21 | 服务调用失败时有哪些处理手段?
22 | 如何管理服务配置?
23 | 如何搭建微服务治理平台?
24 | 微服务架构该如何落地?
模块三 进阶微服务 (8讲)
25 | 微服务为什么要容器化?
26 | 微服务容器化运维:镜像仓库和资源调度
27 | 微服务容器化运维:容器调度和服务编排
28 | 微服务容器化运维:微博容器运维平台DCP
29 | 微服务如何实现DevOps?
30 | 如何做好微服务容量规划?
31 | 微服务多机房部署实践
32 | 微服务混合云部署实践
模块四 展望微服务 (4讲)
33 | 下一代微服务架构Service Mesh
34 | Istio:Service Mesh的代表产品
35 | 微博Service Mesh实践之路(上)
36 | 微博Service Mesh实践之路(下)
阿忠伯的特别放送 (4讲)
阿忠伯的特别放送 | 答疑解惑01
阿忠伯的特别放送 | 答疑解惑02
微博技术解密(上) | 微博信息流是如何实现的?
微博技术解密(下)| 微博存储的那些事儿
结束语 (1讲)
结束语 | 微服务,从入门到精通
从0开始学微服务
登录|注册

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

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

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

从我所经历过的多个项目来看,项目第一阶段的主要目标是快速开发和验证想法,证明产品思路是否可行。这个阶段功能设计一般不会太复杂,开发采取快速迭代的方式,架构也不适合过度设计。所以将所有功能打包部署在一起,集中地进行开发、测试和运维,对于项目起步阶段,是最高效也是最节省成本的方式。当可行性验证通过,功能进一步迭代,就可以加入越来越多的新特性。
比如做一个社交 App,初期为了快速上线,验证可行性,可以只开发首页信息流、评论等基本功能。产品上线后,经过一段时间的运营,用户开始逐步增多,可行性验证通过,下一阶段就需要进一步增加更多的新特性来吸引更多的目标用户,比如再给这个社交 App 添加个人主页显示、消息通知等功能。
一般情况下,这个时候就需要大规模地扩张开发人员,以支撑多个功能的开发。如果这个时候继续采用单体应用架构,多个功能模块混杂在一起开发、测试和部署的话,就会导致不同功能之间相互影响,一次打包部署需要所有的功能都测试 OK 才能上线。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学微服务》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(75)

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

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

    2018-08-27
    115
  • 唐伯虎点蚊香
    纵向拆分和横向拆分感觉还是不太理解
    2018-08-25
    62
  • 日拱一卒
    关于服务拆分策略,我理解在实际工作中应该是横向和纵向相结合的方式:
    1. 首先收集整理公用的模块,将其进行服务化处理,这是横向拆分。
    2. 其次根据不同业务之间的耦合程度,将相对独立的服务拆分到不同的服务中,这属于纵向拆分。

    最后的微服务列表中,既有被其他微服务使用的公共服务,也有彼此独立运行的业务服务。

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

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

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

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

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

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

    作者回复: 是这样的

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

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

    2018-08-26
    8
  • 科大大👏🏻
    当公司技术人员不足时就没必要考虑微服务了,好好做好单体架构,但是做的同时也要考虑未来有可能过渡到微服务,所以如果明确了以后会变成微服务的话单体架构有没有什么设计标准呢?
    2018-08-25
    7
  • 实际项目通常是横向和纵向拆分相结合,公共的服务单独拆分出来,然后上层业务按功能模块拆分
    2018-08-28
    6
  • Geek_8d2caa
    开始是10多人的团队,对业务进行了拆分,上线后,人员陆续离职,现在是6个人背着将近30个微服务,开发一个功能点,基本上所有人都得上,就演变成天天开会还解决不了问题,效率奇低……所以,有没有微服务退回到单体的做法?

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

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

    作者回复: 是的

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

    作者回复: 对

    2018-08-25
    4
  • softtwilight
    横向拆分我的理解是就像aop,把共用但又跟其他部分不太相关的抽离出来,而纵向拆分是把高没聚的拆分出来
    2018-08-25
    4
  • 少帅
    是否需要拆分要看目前公司项目的具体的情况,如果现有架构无法满足当前业务发展速度,比如构建一次要半天,上一次线经常搞通宵,牵一发而动全身,那么这个时候可以考虑一下微服务,拆微服务势必会提高运维、问题追踪、分布式事务等复杂度,所以微服务整个技术栈都要考虑进去

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

    2018-08-26
    3
  • 🇨🇳光🇨🇳
    目前根据业务 拆分出来了两个 独立服务 接口走rpc 调用 还在测试环境验证中!
    2018-08-25
    3
  • jogin
    没有推行微服务之前,单体应用的业务逻辑拆分,整体系统设计做得好,会给后期服务化改造铺平道路。
    2018-08-25
    3
  • yankerzhu
    纵向拆分类似于接口,横向拆分类似于抽象类
    2018-09-02
    2
  • 🐢先生
    我们不要为了微服务而做微服务,做了服务拆分,我们会投入更大。个人觉得,做了服务拆分后,带来的最大的挑战应该是分布式事务,这个原因也导致了我们微服务的难落地。另外的话,大部分的初创公司不适合,需要结合公司自身的人员储备和业务情况等来综合考虑。

    作者回复: 是的

    2018-08-27
    2
  • jogin
    什么时候推行微服务,不同技术栈有区别,之前最多的一次4,50个php技术维护一个单体应用,整个系统结构,业务模块之间划分比较清晰,不同小组负责不同模块,开发上采用多版本并行开发,每个版本7,8个技术。这时候整个团队开发效率上没有太大问题,架构组把控非常好。
    2018-08-25
    2
收起评论
75
返回
顶部