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

01 | 到底什么是微服务?

微服务架构提高了应用交付的效率
每个拆分出来的服务各自独立打包部署,并交由小团队进行开发和运维
微服务架构是将复杂臃肿的单体应用进行细粒度的服务化拆分
微服务化给服务的发布和部署,以及服务的保障带来了诸多好处
服务治理能力要求高
服务独立维护
服务独立部署
服务拆分粒度更细
服务化解决单体应用膨胀、团队开发耦合度高、协作效率低下的问题
把传统的单机应用中通过JAR包依赖产生的本地方法调用,改造成通过RPC接口产生的远程方法调用
线上发布变慢
系统高可用性差
团队协作开发成本高
部署效率低下
随着业务规模的扩大,团队开发人员的增加,单体应用架构出现问题
单体应用架构的优点
LAMP和MVC两大流派
作者总结了一套微服务落地经验,希望帮助中小规模团队了解微服务的本质和对业务的价值
缺乏适合中小团队的架构实践落地的指引
一些技术团队盲目引入微服务,缺乏技术掌控能力,影响业务稳定性
国内中小规模的技术团队对微服务的概念不甚了解
微服务的热度在进入2017年后突然爆发
总结
什么是微服务?
什么是服务化?
单体应用
到底什么是微服务?

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

从谷歌的搜索指数来看,微服务的热度在进入 2017 年后突然爆发,国内各大会议和论坛的相关讨论也如雨后春笋般层出不穷,各大一线互联网公司也纷纷将这一技术引入并在实际业务中落地。
然而据我所知,国内不少中小规模的技术团队对微服务的概念都不甚了解,对该不该引入微服务也不置可否。还有一些技术团队,没有考虑实际业务场景,只是为了追求技术热点,盲目引入微服务,但又缺乏相应的技术掌控能力,最后影响了业务的稳定性。
对于该不该引入微服务,以及微服务体系需要哪些技术,目前并没有适合中小团队的架构实践落地的指引。因此我结合自己在微博多年的业务实践,总结出了一套微服务落地经验,从基础理论到架构实践,再结合业界最新趋势分析,希望能帮助中小规模团队了解微服务的本质以及对业务的价值,从而做出正确的判断。
我们先来看看维基百科是如何定义微服务的。微服务的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出,他们定义了微服务是由单一应用程序构成的小服务,拥有自己的进程与轻量化处理,服务依业务功能设计,以全自动的方式部署,与其他服务使用 HTTP API 通讯。同时,服务会使用最小规模的集中管理 (例如 Docker)技术,服务可以用不同的编程语言与数据库等。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

微服务架构:解决单体应用痛点的技术趋势 微服务架构是近年备受关注的技术趋势,通过对单体应用、服务化和微服务的对比分析,生动地阐释了微服务的发展历程和技术特点。文章首先指出了单体应用的局限性,包括部署效率低下、团队协作开发成本高、系统高可用性差等问题,引出了服务化的思想。随后,以微博系统为例,阐述了服务化对解决单体应用问题的重要性。文章详细解释了微服务相对于服务化的不同之处,包括服务拆分粒度更细、独立部署和维护、以及对服务治理能力的要求。最后,总结了微服务架构的优势,强调了其对应用交付效率的提升和在各大互联网公司中的普遍应用。 总的来说,本文通俗易懂,适合技术人员和对微服务感兴趣的读者阅读。通过深入探讨微服务的概念和发展历程,为读者提供了深入了解微服务的概览。对于中小规模团队了解微服务的本质和对业务的价值,以及做出正确判断具有一定的指导意义。微服务架构能有效解决单体应用过度膨胀所带来的问题,提升应用交付效率,因此对于业务开发中遇到的问题具有一定的解决能力。 如果你在业务开发中也遇到过因单体应用过度膨胀所带来的问题,欢迎在留言区与我们一起讨论,分享你的思考和经验。

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

全部留言(108)

  • 最新
  • 精选
  • Colin
    服务化最难的是在数据库层,因为数据库中很多数据都是相互关联的,比如用户用户跟订单,订单和商品等等这些数据之间都是有关联的,服务拆分之后会面临以下问题:1当需要读取关联数据时,如果采用表连接的方式查询数据会出现跨数据库查询的可能,2如果是通过RPC的方式多次调用(比如要查订单,就需要查询商品及订单详细信息),也会出现多次调用导致的频繁多次的数据库连接,而如果使用缓存,也会面临数据库与缓存之间的数据同步问题,特别是数据库与缓存服务器都存在集群的情况下,会更难处理,这也是在做微服务之前必须要考虑的问题。

    作者回复: 是的,服务化拆分最好不要涉及跨数据库表交互

    2018-08-23
    5
    204
  • 少帅
    看到留言里面好多正在经历从单体到微服务的拆分过程,拆分微服务先要把业务梳理清楚,做到心中有数,梳理清楚了那么业务的边界自然清晰了,自然而然对应拆分哪些服务也出来了,拆分的过程中一定是绞杀式的,新的需求自然放到拆分的微服务,老的逻辑按照优先级和重要程度一个点一个点的从单体迁移微服务,服务化上线之后,渐渐取代老的单体,等全部拆分完毕,线上稳定之后,自然就可以下掉老的单体应用

    作者回复: 实践出真知👍

    2018-08-23
    2
    76
  • Neo_PJ
    现在的系统代码量50w,单体应用,但是拆分成微服务太麻烦了,领导不敢动,系统是金融管理基金托管计算的,太多复杂场景耦合,10几年的代码,好几个团队的代码堆积,俗话就是 又臭又硬的系统,只能不断维护,不敢重新搭建新的框架,不敢拆,拆不得,拆了谁负责,谁敢保证拆后所有功能按照原有一样逻辑呢? 唉,老员工都是吐槽,继续码代码,分支也多,团队也多,部署一次1小时,每次有代码提交就催着部署,意味着系统动不动挂一小时,部署相当麻烦,文件对比,打包等等 这个系统没救了

    作者回复: 不好整…

    2018-08-23
    10
    56
  • 钟悠
    在我看来,用通俗的话来讲,服务化就是把传统的单机应用中通过 JAR 包依赖产生的本地方法调用,改造成通过 RPC 接口产生的远程方法调用。这句话真的讲的很透彻👍

    作者回复: 实践出真知

    2018-08-24
    5
    45
  • 技术修行者
    看了文章和留言,讲的很清楚,请教一个问题,之前也有同学问了。 对于典型的复杂web应用,当由单体应用改造成微服务时,一般会按照业务进行服务划分,彼此独立的业务拆分到不同的微服务中。但是在数据层面,涉及到下面两个问题: 1. 数据库是否拆分?从数据架构的角度看,可能有三个选择:1) 一个db实例,所有微服务在一个schema中,2) 一个db实例,每个微服务有自己的schema,3) 每个微服务有自己的db实例。我们在实际项目中应该如何取舍? 2. DAO层是否拆分?可能有两个选择: 1) DAO层保持不变或者单独部署成微服务,所有业务微服务通过引用jar包或者HTTP的方式和DAO进行交互。2) 把DAO进行拆分,每个业务微服务内部管理自己会用到的db数据。在所有微服务采用的技术栈相同的情况下,上面哪种方式更可取?

    作者回复: 第一个问题:数据库拆分其实不是微服务拆分的关键,如果会引入分布式事务的话,最好不要拆分。 第二个问题:长远来看,建议方案2,这样会减少每个微服务同db的连接,在集群规模上千台的情况下,db的连接数不会成为瓶颈,服务启动也会变快,因为初始化连接也会变少。

    2018-08-25
    4
    20
  • null
    5 年的 php 单体应用,整个项目结构复杂混乱,php 前端和 php 后端各种函数调用。业务逻辑代码也穿插着大量已过期或无关的代码,项目可维护性越来越低。每次需求开发完毕合并分支时,需要花费大量的精力去解决代码冲突。开发的速度远跟不上需求的速度。 在去年所有新的需求使用 java 进行开发,同时一点一点将 php 的业务迁移到 java。 从一开始就没规划好,一股脑喊出了微服务化口号,前期也是真苦了运维和测试。 一年多过去了,项目现在的的状态: 1. 项目内结构依旧混乱,A 模块和 B 模块都依赖于 C 模块,我们的做法是,A 模块里写一次 C 模块,B 模块同样写一遍 C 模块。其中有两个原因,无法实现分布式事务,只好放到同一个系统内,整个流程可以同属于一个事务;另一个原因是模块的边界划分是很模糊的。 2. 项目之间的依赖关系就跟意大利面条一样,而且之间的接口,并没有想着去向下兼容,甚至发生过接口定义变更了,导致线上依赖的服务都无法正常提供服务。现在每次发布也是战战兢兢。 目前面临最大的问题便是分布式事务的问题,导致 DAO 层的代码,重复散落在各个模块之中,真是令人头大。

    作者回复: 第一点,可以抽离出哪些是公共的模块,并且请求量和重要性值得这么做。 第二点,接口定义最好不要随便变更,这是原则,可以添加参数,新增返回字段,也可以新增接口,但最好不要改参数名或者已有字段。

    2018-08-23
    13
  • Amorfati
    如何确定是过度膨胀也是比较难的问题,在膨胀前切分很有可能随着业务的发展,发现切错了,然后好尴尬,按照我的理解是,单体应用中已经经过足够时间业务上的检验,将其中模式比较稳定,整体高内聚的业务进行抽离。如有错误,还请老师指正。

    作者回复: 对

    2018-08-23
    13
  • WolvesLeader
    老师,问一下,一般和数据库交互的dao层,是单独拿出来做成服务好还是不做好,还有一些公共的模块是不是也要做成服务呢?谢谢啦

    作者回复: 我理解你这个需求中间件的需求

    2018-08-23
    13
  • jogin
    现在好多公司强推微服务,不考虑实际情况,单体应用并不是就一定很脆弱,系统不稳定,服务拆分了也不一定稳定,开发效率不高,没准是流程问题,系统本身设计问题耦合严重,单体应用设计不好,玩不转,服务拆分后更乱。 有些开发就是为了研究微服务在内部推广,大家都想学一下然后就达成默契了。

    作者回复: 嗯,微服务架构的技术门槛非常高,没有充裕的技术人员不要轻易入坑

    2018-08-25
    11
  • cc
    我的理解,微服务的重点在于拆分治理,spring boot,容器,这些只是实现拆分的一个工具而已,如果你想,使用传统的tomcat启动发布也是可以实现这样的目标的。

    作者回复: 是的,微服务架构的核心在于服务治理,而容器是对运维方式的改变,通过容器标准化发布部署。

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