资讯专栏INFORMATION COLUMN

天天吹微服务,单体应用有啥不好?

fish / 2599人阅读

摘要:单体应用,由于就是一个项目,所有的功能都是写在一个项目中,不可避免的出现项目过度复杂的情况。

单体应用确实有问题!

最近在研究微服务架构,有一点点心得,打算在公众号上写几篇文章和大家慢慢分享下。

这个话题有点大,我会分几篇文章和大家慢慢说,今天就先来说说传统的单体应用有哪些弊端,正是因为单体应用存在的弊端,使得我们不得不考虑发展微服务。

人类发展的历史就是一个社会分工不断细化的历史,从这个角度来讲,微服务这种将一个复杂的大项目拆分为众多小项目,然后程序员分工合作,共同完成项目,这种协作方式是符合历史潮流的。

这是我们站在今天的角度来说的,曾经的单体应用也是先进生产力的代表。

但是,随着互联网的发展,我们对一个系统的要求越来越高,单体应用已经很难适应当前的开发,因此在回答我们为什么要使用微服务这个问题之前,我们有必要来聊一聊单体应用目前都面临哪些问题。

面临的问题 1.项目过度复杂

你要创建一个简单的用户管理系统,二话不说,直接创建 Maven 项目然后开干就完事了,这没问题,因为这很简单。

但是你要说想搞一个淘宝网站,或者你想搞一个用友 U8 系统,那你恐怕就得先慢慢设计系统架构了。单体应用,由于就是一个项目,所有的功能都是写在一个项目中,不可避免的出现项目过度复杂的情况。而且这种复杂情况会不断恶化。

有的小伙伴可能有这样的经验,刚入职了一家公司,新接手了一个项目,上面催的很急,让你赶快修复几个 bug ,项目复杂,光是实体类的包就有好几个 bean、model、pojo 等,一个项目被很多人经手之后,到你手里,早已经一团乱麻,你小心翼翼尽量不碰触到已有的功能,终于修完了几个 bug,搞了俩礼拜,你觉得这个项目太坑爹了,不想干了,于是接盘侠从你手里接到了一个复杂度又上升了一步的项目。

就这样,一个原本简简单单的单体项目,在变复杂的路上一去不复返。

2.开发速度缓慢

单体应用开发速度缓慢,因为单体应用复杂了之后,项目变得异常臃肿而且庞大,每一次编译构建、运行以及测试,都需要花费大量时间,而且如果测试有问题,又得从头来一遍,注意,这里的每一次从头编译构建等都是整个项目的从头编译构建。

即使你可能只要修改某一个参数,你也得把上面整个流程走一遍,相当于每一次的修改都是牵一发而动全身的操作。

速度没法快。

3.不易扩展

项目中不同模块对计算机的性能要求不一样,例如使用 Redis 来保存了大量的热点数据,那么我们希望服务器的内存非常大,另外有一个模块涉及到了图片处理,我们又希望服务器的 CPU 非常强,如果是单体应用部署的话,那么这些条件服务器都要满足。

4.技术栈不易扩展

单体应用还有一个劣势就是技术栈不易扩展,一旦你选定了某一个技术栈来开发项目,以后很难在技术栈上做切换。有的公司还会自己搞一套系统,这种在当时看起来好像都没有啥问题,可是经过几年之后,回头再看,已经很过时了,很 low 了,当初设计系统的人可能已经离职了,刚入职的新手也不敢动这个老古董,只能在这个老古董上面忍痛开发。

有的时候,有一个服务需要处理高并发,你很想用 Go 语言来做,可是做不到,没法引入其他语言。

这些都是单体应用的劣势,如果有微服务,上面这些问题都将得到解决。

曾经的优势

当然,事物都是有两面性的,单体应用也有它自己的优势,例如:

开发简单,一个 IDE 就可以快速构建出一个单体应用

测试简单

部署简单,Tomcat 安装好之后,应用扔上去就行了

集群化部署也很容易,多个 Tomcat + 一个 Nginx 分分钟就搭建好集群环境了

这么多优势,还是难掩劣势。

不过大家在做项目的时候,还是要结合实际情况来选择,不能因为微服务厉害,所有项目都是微服务,如果你仅仅只想做一个用户的增删改查,那么很明显,创建一个简单的单体应用是最合适的。

好了,本文主要和大家分享了传统单体应用存在的一些问题,正是因为这些问题,我们需要引入微服务,下篇文章,我们就来看看微服务有哪些优势。

参考资料:

[1] Chris Richardson.微服务架构设计模式[M].北京:机械工业出版社,2019.

关注公众号【江南一点雨】,专注于 Spring Boot+微服务以及前后端分离等全栈技术,定期视频教程分享,关注后回复 Java ,领取松哥为你精心准备的 Java 干货!

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/75632.html

相关文章

  • 可落地的DDD(1)-目标讨论

    摘要:最近发现文章老是被窃取,有些平台举报了还没有用。最后不了了之,产品很配合,但是内驱力不强。为什么内驱力不强,因为给他带来的收益不够。所以在千个团队中实行可能有千套不同的方案。最近发现文章老是被窃取,有些平台举报了还没有用。请识别我的id方丈的寺院。 摘要 DDD领域驱动设计,起源于2004年著名建模专家Eric Evans发表的他最具影响力的著名书籍:Domain-Driven Design...

    fox_soyoung 评论0 收藏0
  • 我眼中的PHP

    摘要:趁着吃下午茶,我也来简单谈谈对甚至的一些看法。然而放眼现在,其实这些东西,感觉像是入门级别的要求了。说说我自己吧,不可否认,在工作中,我确实是个打杂,说好的架构呢,说还的管理呢,说好的技术支持呢,,到头来,还是东忙西忙,一无所事。 趁着吃下午茶,我也来简单谈谈对 PHP 甚至 PHPer 的一些看法。 况且最好的语言要是没有优秀的人,那几本就是扯淡,没错,就是你们在大大小小的群经常看到...

    Lin_R 评论0 收藏0
  • 从0到千万级并发服务架构演化

    摘要:包括服务的自动化部署,以及链路监控等并未细说提及。结语诚然,整个服务架构可以轻松应对千万级并发。期望,整个服务架构能伴随公司继续成长壮大。 背景介绍 回顾 ShareSDK,顾名思义,分享的SDK组件,公司基于互联网,早期主要以ShareSDK起家。今日思来,很幸运,能陪着ShareSDK一起成长。 showImg(https://segmentfault.com/img/bV0Wo5...

    starsfun 评论0 收藏0
  • 深入理解Spring Cloud与微服务构建【一】 - 1.2微服务

    摘要:熔断机制为了防止雪崩效应事件的发生,分布式系统采用了熔断机制。为了解决这一难题,微服务架构引入了熔断机制。由于微服务系统是分布式系统,服务与服务之间没有任何的祸合。 1.2.1 什么是微服务 按业务划分为一个独立运行的程序,即服务单元。 服务之间通过 HTTP 协议相互通信。 自动化部署。 可以用不同的编程语言。 可以用不同的存储技术。 服务集中化管理。 微服务是一个分布式系统。 ...

    AlexTuan 评论0 收藏0
  • 如何学JavaScript

    摘要:书籍如下面向对象编程指南,风格轻松易懂,比较适合初学者,原型那块儿讲得透彻,种继承方式呢。还有另一件事情是,比如发现自己某个知识点不太清楚,可以单独去百度。 作者:小不了链接:https://zhuanlan.zhihu.com/p/...来源:知乎著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 鉴于时不时,有同学私信问我(老姚,下同)怎么学前端的问题。这里统一回...

    light 评论0 收藏0

发表评论

0条评论

fish

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<