单体服务,微服务服务的演变&各自优缺点
---- 一.单体服务
web-->service-->infrastructure-->mysql
web-->service-->redis
web-->service-->rabbitMQ
优点:
随着服务的演变
1.1> 单体服务
● 优点:
1> 架构简单,清晰。服务之间调??便,快捷。
2> 服务部署简单。部署量少。运维量很低。
● 缺点:
1> 随着项目进展时间变长,整个项目的代码复杂度越来越高,很容易1个小改动,导致很大的系统问
题。
2> 由于代码量很大,编译和部署会越来越慢,甚致20~30分钟都很正常。
3> 由于有的功能属于大量运算的CPU密集型模块,有的是大量读写磁盘的IO密集型模块。但是由于融
合在了1个项目中,无法针对单个功能模块进行扩展。那么只能CPU和内存和磁盘都要提升,资源投
入很大。
4> 如果我们想要针对已有项目改变技术选型,那么就需要针对整个项目进行修改,工作量将会巨大。
----- 二.微服务
● 微服务的核心就是把传统的单体服务,根据业务拆分为1个个的服务,实现解耦;每个服务都可以
提供特定业务的功能,每个服务都能够单独部署,也可以拥有自己的数据库。这样的1个个的小服
务就是微服务。
web-->user-service-->user-domain-->infrastructure-->mysql-user(共享redis,rabbitmq)
web-->prod-service-->prod-domain-->infrastructure-->mysql-prod(共享redis,rabbitmq)
web-->order-service-->order-domain-->infrastructure-->mysql-order(共享redis,rabbitmq)
● 优点:
1> 每个服务足够小,足够内聚,专注于1个业务功能点提供服务。代码更容易理解。
2> 有代码修改或部署上线,只会影响对应的微服务,不会是整个服务。
3> 可针对服务是计算型还是IO型进行针对性的硬件升级。
4> 可以针对某些高吞吐服务进行硬件升级或者服务横向扩容,而不是对所有服务都升级。节约投入成本。
● 缺点:
1> 极大的增加了运维工作量,以前几个war包,现在可能需要部署几百个。
2> 微服务之间的互相调用,会增加通讯成本。
3> 分布式事务问题会引出数据一致性的问题。
4> 服务增多,如果管控成百上千的服务。如何准确并快速定位问题。