单体服务，微服务服务的演变&各自优缺点
---- 一.单体服务
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> 服务增多，如果管控成百上千的服务。如何准确并快速定位问题。