微服务 & 微服务架构(一)

单体架构 VS 微服务架构

单体架构

一个工程对应一个归档包(war),这个war包 包含了该工程的所有功能。我们成为这种应用为单体应用,也就是我们常说的单体架构(一个war包打天下)。具体描述: 就是在我们的一个war包种,聚集了各种功能以及资源,比如JSPJS,CSS等。而业务种包含了我们的用户模块,订单模块,支付模块等一系列项目所需模块!

单体架构图

image-20210301090427181

单体架构优缺点总结

优点:

①: 架构简单明了,没有”花里胡哨“的问题需要解决。
②:开发,测试,部署简单(尤其是运维人员 睡着都会笑醒)

缺点:

①:随着业务扩展,代码越来越复杂,代码质量参差不齐(开发人员的水平不一),会让
你每次提交代码 ,修改每一个小bug都是心惊胆战的。
②:部署慢(由于单体架构,功能复杂) 能想像下一个来自200W+代码部署的速度(15分钟)
③:扩展成本高,根据单体架构图 假设用户模块是一个CPU密集型的模块(涉及到大量的运算)那么我们需要替换更加牛逼的CPU,而我们的订单模块是一个IO密集模块(涉及大量的读写磁盘),那我们需要替换更加牛逼的内存以及高效的磁盘。但是我们的单体架构上 无法针对单个功能模块进行扩展,那么就需要替换性能更好的CPU,更好的内存,更好的磁盘,预算价格会很高。
④:阻碍了新技术的发展:

比如我们的web架构模块 从struts2迁移到springboot,那么就会成为灾难!


微服务以及微服务架构

中文文档:

http://blog.cuicc.com/blog/2015/07/22/microservices/

微服务核心

微服务核心就是把传统的单机应用,根据业务将单机应用拆分为一个一个的服务,彻底的解耦,每一个服务都是提供特定的功能,一个服务只做一件事,类似进程,每个服务都能够单独部署,甚至可以拥有自己的数据库。这样的一个一个的小服务就是微服务.
①: 比如传统的单机电商应用, tulingshop 里面有 订单/支付/库存/物流/积分等模块(理解为service)
②:我们根据 业务模型来拆分,可以拆分为订单服务,支付服务,库存服务,物流服务,积分服务
③若不拆分的时候,我的非核心业务积分模块 出现了重大bug 导致系统内存溢出,导致整个服务宕机.,若拆分之后,只是说我的积分微服务不可用,我的整个系统核心功能还是能使用!

image-20210301090840584

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

icbugcoder

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值