大王闲语001 -- 单体架构VS微服务架构

大王闲语，是新开的一个系列，给自己定个小目标，我想写100篇内容。

当然是要抄的，哈哈哈，不抄，哪来的灵感。

我们就先从微服务说起，和自己的工作内容相关，边学习，边总结。

 

影响因素	单体系统	微服务架构
日益增加的不同业务需求	所有逻辑在一起，越来越臃肿	针对不同的需求迭代对应的模块
修改一个小功能	部署上线，可能影响其他的功能运行	不影响
资源评估	各个功能模块在一起，使用场景、并发量、消耗资源类型都不同，互相影响，很难正确评估。	单独模块评估，独立扩展资源
维护成本	成本越来越大	单独开发维护

应该还有很多区别，以后找到了，再修改一下。

微服务框架诞生之后，被世人所关注。我们将系统的不同功能模块拆分为不同的服务，这些服务独立部署和扩展，每个服务都不会影响其他的服务运行。由于每个服务是独立部署的，我们可以更准确的为每个服务进行评估，通过配合服务间的协作流程也可以更容易的发现系统的瓶颈位置，以及给出较为准确的系统级性能容量评估。