01 | 到底什么是微服务?
该思维导图由 AI 生成,仅供参考
- 深入了解
- 翻译
- 解释
- 总结
微服务架构:解决单体应用痛点的技术趋势 微服务架构是近年备受关注的技术趋势,通过对单体应用、服务化和微服务的对比分析,生动地阐释了微服务的发展历程和技术特点。文章首先指出了单体应用的局限性,包括部署效率低下、团队协作开发成本高、系统高可用性差等问题,引出了服务化的思想。随后,以微博系统为例,阐述了服务化对解决单体应用问题的重要性。文章详细解释了微服务相对于服务化的不同之处,包括服务拆分粒度更细、独立部署和维护、以及对服务治理能力的要求。最后,总结了微服务架构的优势,强调了其对应用交付效率的提升和在各大互联网公司中的普遍应用。 总的来说,本文通俗易懂,适合技术人员和对微服务感兴趣的读者阅读。通过深入探讨微服务的概念和发展历程,为读者提供了深入了解微服务的概览。对于中小规模团队了解微服务的本质和对业务的价值,以及做出正确判断具有一定的指导意义。微服务架构能有效解决单体应用过度膨胀所带来的问题,提升应用交付效率,因此对于业务开发中遇到的问题具有一定的解决能力。 如果你在业务开发中也遇到过因单体应用过度膨胀所带来的问题,欢迎在留言区与我们一起讨论,分享你的思考和经验。
《从 0 开始学微服务》,新⼈⾸单¥59
全部留言(108)
- 最新
- 精选
- Colin服务化最难的是在数据库层,因为数据库中很多数据都是相互关联的,比如用户用户跟订单,订单和商品等等这些数据之间都是有关联的,服务拆分之后会面临以下问题:1当需要读取关联数据时,如果采用表连接的方式查询数据会出现跨数据库查询的可能,2如果是通过RPC的方式多次调用(比如要查订单,就需要查询商品及订单详细信息),也会出现多次调用导致的频繁多次的数据库连接,而如果使用缓存,也会面临数据库与缓存之间的数据同步问题,特别是数据库与缓存服务器都存在集群的情况下,会更难处理,这也是在做微服务之前必须要考虑的问题。
作者回复: 是的,服务化拆分最好不要涉及跨数据库表交互
2018-08-235204 - 少帅看到留言里面好多正在经历从单体到微服务的拆分过程,拆分微服务先要把业务梳理清楚,做到心中有数,梳理清楚了那么业务的边界自然清晰了,自然而然对应拆分哪些服务也出来了,拆分的过程中一定是绞杀式的,新的需求自然放到拆分的微服务,老的逻辑按照优先级和重要程度一个点一个点的从单体迁移微服务,服务化上线之后,渐渐取代老的单体,等全部拆分完毕,线上稳定之后,自然就可以下掉老的单体应用
作者回复: 实践出真知👍
2018-08-23276 - Neo_PJ现在的系统代码量50w,单体应用,但是拆分成微服务太麻烦了,领导不敢动,系统是金融管理基金托管计算的,太多复杂场景耦合,10几年的代码,好几个团队的代码堆积,俗话就是 又臭又硬的系统,只能不断维护,不敢重新搭建新的框架,不敢拆,拆不得,拆了谁负责,谁敢保证拆后所有功能按照原有一样逻辑呢? 唉,老员工都是吐槽,继续码代码,分支也多,团队也多,部署一次1小时,每次有代码提交就催着部署,意味着系统动不动挂一小时,部署相当麻烦,文件对比,打包等等 这个系统没救了
作者回复: 不好整…
2018-08-231056 - 钟悠在我看来,用通俗的话来讲,服务化就是把传统的单机应用中通过 JAR 包依赖产生的本地方法调用,改造成通过 RPC 接口产生的远程方法调用。这句话真的讲的很透彻👍
作者回复: 实践出真知
2018-08-24545 - 技术修行者看了文章和留言,讲的很清楚,请教一个问题,之前也有同学问了。 对于典型的复杂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-25420 - null5 年的 php 单体应用,整个项目结构复杂混乱,php 前端和 php 后端各种函数调用。业务逻辑代码也穿插着大量已过期或无关的代码,项目可维护性越来越低。每次需求开发完毕合并分支时,需要花费大量的精力去解决代码冲突。开发的速度远跟不上需求的速度。 在去年所有新的需求使用 java 进行开发,同时一点一点将 php 的业务迁移到 java。 从一开始就没规划好,一股脑喊出了微服务化口号,前期也是真苦了运维和测试。 一年多过去了,项目现在的的状态: 1. 项目内结构依旧混乱,A 模块和 B 模块都依赖于 C 模块,我们的做法是,A 模块里写一次 C 模块,B 模块同样写一遍 C 模块。其中有两个原因,无法实现分布式事务,只好放到同一个系统内,整个流程可以同属于一个事务;另一个原因是模块的边界划分是很模糊的。 2. 项目之间的依赖关系就跟意大利面条一样,而且之间的接口,并没有想着去向下兼容,甚至发生过接口定义变更了,导致线上依赖的服务都无法正常提供服务。现在每次发布也是战战兢兢。 目前面临最大的问题便是分布式事务的问题,导致 DAO 层的代码,重复散落在各个模块之中,真是令人头大。
作者回复: 第一点,可以抽离出哪些是公共的模块,并且请求量和重要性值得这么做。 第二点,接口定义最好不要随便变更,这是原则,可以添加参数,新增返回字段,也可以新增接口,但最好不要改参数名或者已有字段。
2018-08-2313 - Amorfati如何确定是过度膨胀也是比较难的问题,在膨胀前切分很有可能随着业务的发展,发现切错了,然后好尴尬,按照我的理解是,单体应用中已经经过足够时间业务上的检验,将其中模式比较稳定,整体高内聚的业务进行抽离。如有错误,还请老师指正。
作者回复: 对
2018-08-2313 - WolvesLeader老师,问一下,一般和数据库交互的dao层,是单独拿出来做成服务好还是不做好,还有一些公共的模块是不是也要做成服务呢?谢谢啦
作者回复: 我理解你这个需求中间件的需求
2018-08-2313 - jogin现在好多公司强推微服务,不考虑实际情况,单体应用并不是就一定很脆弱,系统不稳定,服务拆分了也不一定稳定,开发效率不高,没准是流程问题,系统本身设计问题耦合严重,单体应用设计不好,玩不转,服务拆分后更乱。 有些开发就是为了研究微服务在内部推广,大家都想学一下然后就达成默契了。
作者回复: 嗯,微服务架构的技术门槛非常高,没有充裕的技术人员不要轻易入坑
2018-08-2511 - cc我的理解,微服务的重点在于拆分治理,spring boot,容器,这些只是实现拆分的一个工具而已,如果你想,使用传统的tomcat启动发布也是可以实现这样的目标的。
作者回复: 是的,微服务架构的核心在于服务治理,而容器是对运维方式的改变,通过容器标准化发布部署。
2018-08-2310