没有合适的资源?快使用搜索试试~ 我知道了~
单体应用、集群和微服务,这个标题一出你们可能就知道我想说啥了,emm,就是架构的演进过程,很多人可能都看过相关知识,不过我为了文章的完整性还是打算简单讲一讲。首先是单体应用,在一个业务的起步阶段,往往是用户量不大且访问请求少的阶段,这个时候我们一般只需要部署一个Web应用和一台数据库就能满足我们的业务需求,且随着SpringBoot的流行,Web服务器可以内置在应用里面,能够更加方便快捷的部署应用。同时因为项目规模小,业务流程简单,维护和迭代起来也很方便,所以在当前这个阶段单体应用是非常适合的。但是随着业务增长,单体应用不可避免的会出现瓶颈,我举个例子:假如我们现在的单体Tomcat应用只能支
资源推荐
资源详情
资源评论
聊聊微服务与分布式系统聊聊微服务与分布式系统
单体应用与集群
单体应用、集群和微服务,这个标题一出你们可能就知道我想说啥了,emm,就是架构的演进过程,很多人可能都看过相关
知识,不过我为了文章的完整性还是打算简单讲一讲。
首先是单体应用,在一个业务的起步阶段,往往是用户量不大且访问请求少的阶段,这个时候我们一般只需要部署一个Web
应用和一台数据库就能满足我们的业务需求,且随着SpringBoot的流行,Web服务器可以内置在应用里面,能够更加方便快捷
的部署应用。
同时因为项目规模小,业务流程简单,维护和迭代起来也很方便,所以在当前这个阶段单体应用是非常适合的。
但是随着业务增长,单体应用不可避免的会出现瓶颈,我举个例子:
假如我们现在的单体Tomcat应用只能支撑QPS200,随着用户量的增大并发随之增大,慢慢超出了单台应用能承受的极限,
假如现在达到了QPS300,那么多出来的100请求就只能等着前面的请求处理完了之后才能请求进去,这样带来的后果就是响
应时间变长,影响用户体验。
或者我们应用中的业务比较复杂,单次请求响应时间比较长,这样的话大量请求挤压也会导致用户的体验很差,他们能明显的
感觉到点击某个按钮之后隔了1~2s才有结果返回。
这个时候我们就可以引入集群架构了,我们可以将单体应用同时部署两份,并通过Nginx进行反向代理和负载均衡进行流量分
流,这样每个单体应用承受的QPS就是150了,就在可以接受的范围内,而且维护集群应用和维护单机应用区别不大,只是在
涉及到锁的时候可能要借助分布式锁来做。
至此,每当访问量增大系统到达瓶颈时我们就可以通过加机器这种方式进行横向扩容,不断的扩大应用的负载能力,但是如果
这种方式完美无缺,我们也就不需要微服务的架构了~~~
从单体应用过渡到集群架构,解决的其实是性能的问题,单台机器已经无法满足人民日益增长的访问需求,所以出现了集群架
构。
那么从集群过渡到微服务架构的更多原因肯定就不在性能了,这里我说说我自己的看法与感悟:
首先既然项目已经是集群了证明业务量也不会非常小,这也就代表了代码一定有一些规模了,这时候要面临的第一个问题就是
所有开发人员都会在这一个项目里面修改代码,极大情况下是冲突不断。
其次这么多代码聚合在一块,当你进行一处功能修改的时候,如果需要进行全量回归测试的话那简直太要命了。
再者说,所有业务块都在一个系统这会导致资源无法最大化利用,比如一个电商系统肯定是商品搜索/推荐系统为最常用的系
统,理所当然在资源方面他们应该占有更多的机器资源,但是业务不进行拆分想进行横向扩展只能将所有业务一起扩展。
最后是有可能会引起雪崩效应,举个例子你的系统中假如有一块非常不重要的业务(比如签到)代码写的有问题在生产环境中
引发了OOM,那么它必然会连累到整个系统中的所有业务都变成不可用,因为不同业务之间并没有物理隔离。
通过这几条可以知道过渡到微服务更多的考虑的已经不是性能瓶颈,而是人,是业务,也是应用系统最重要的高可用。
微服务与分布式
剩余8页未读,继续阅读
资源评论
weixin_38747906
- 粉丝: 4
- 资源: 928
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功