我们在前几期的文章中给大家简单介绍了单体架构以及微服务架构的一些基础知识和优缺点等内容，而本文我们就再来了解一下， 单体架构与微服务架构的区别都有哪些。

　　单体系统和微服务的区别在于，一个单体系统是一个大而全的功能集合，每个服务器运行的是这个应用的完整服务。而微服务是独立自治的功能模块，它是生态系统中的一部分，和其他微服务是共生关系。

　　现在，业界对单体系统和微服务的普遍观点是：单体系统非常容易开发、测试、部署，但是单体系统面对的问题也很多，例如开发效率变低、维护成本增加、部署影响变大、可扩展性较差、技术选型成本高，而引入了微服务可以实现每个微服务易于开发与维护，便于沟通与协作，很适合小团队敏捷开发与持续交付;每个微服务职责单一，高内聚、低耦合。同时，每个微服务能够独立开发、独立运行、独立部署;每个微服务之间是独立的，如果某个服务部署或者宕机，只会影响到当前服务，而不会对整个业务系统产生影响;每个微服务可以随着系统规模的不断扩大，面对海量用户和高并发，独立做水平扩展与垂直扩展;每个微服务可以使用不同的编程语言以及不同的存储技术，使得我们更容易尝试新的技术。此外，对单个服务进行业务重构，也不会面临很大的业务负担与技术债券。

　　我们经常忽视业务价值和成本考量，而太过追求技术，那么可能会导致我们精心设计的分布式架构严重影响我们开发的速度和业务的快速迭代，并且随着业务的不确定性往往导致我们的架构在半年到一年之内就已经不完全适用，推倒重来。

　　此外，如果业务没有发展起来也会导致前期大量的服务器资源盲目的浪费了，这对于初创业务得不偿失。因此，我们在项目前期为了保证快速增长业务，保证系统尽量减少依赖且独立完整，减低引入微服务架构后的技术复杂度，例如它对于运维难度提出了更高的要求，因为好的微服务架构需要稳定的基础设施。

　　随着业务发展良好，系统规模会不断扩大，它的扩展性、伸缩性、可用性和性能都限制了我们的业务发展，此时，我们怀着明确的业务思考和投入更多的资源再来考虑微服务改造。

　　微服务通过拆分单体系统使其成为多个体积更小的服务来降低单个服务的复杂性，但是，我们从整体来看，这种方式有造成了存在大量的服务，而服务之间的相互调用也会增多，从而导致整个系统架构变得更加复杂。因此，我们不单单只关注技术，而需要考量投入产出比，保障当前阶段的利益大化。