微服务架构在软件行业已成为一中发展趋势，微服务架构与传统的单体软件架构代表着IT产业处理软件开发方式的一个根本性转变。那么微服务架构与传统的单体架构相比，有何区别呢？我们从以下几点来看：

一、单体架构

单体架构，是指将开发好的项目打成war包，然后发布到tomcat等容器中的应用。

假设你正准备开发一款与Uber和滴滴竞争的出租车调度软件，经过初步会议和需求分析，你可能会手动或者使用基于Spring Boot、Play或者Maven的生成器开始这个新项目，它的六边形架构是模块化的 ，架构图如下：

应用核心是业务逻辑，由定义服务、领域对象和事件的模块完成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件，以及提供API或者UI访问支持的web模块等。

尽管也是模块化逻辑，但是最终它还是会打包并部署为单体式应用。具体的格式依赖于应用语言和框架。例如，许多Java应用会被打包为WAR格式，部署在Tomcat或者Jetty上，而另外一些Java应用会被打包成自包含的JAR格式，类似的，Rails和Node.js会被打包成层级目录。

这种应用开发风格很常见，因为IDE和其它工具都擅长开发一个简单应用，这类应用也很易于调试，只需要简单运行此应用，用Selenium链接UI就可以完成端到端测试。

单体式应用也易于部署，只需要把打包应用拷贝到服务器端，通过在负载均衡器后端运行多个拷贝就可以轻松实现应用扩展。在早期这类应用运行的很好。

单体架构存在的问题：

复杂性高

以某个百万行级别的单体应用xxx为例，整个项目包含的模块非常多，模块的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起，整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个Bug都会带来隐含的缺陷。

技术债务

随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务， 并且越积越多。“不坏不修”，这在软件开发中非常常见，在单体应用中这种思想更甚。已使用的系统设计或代码难以被修改，因为应用程序中的 其他模块可能会以意料之外的方式使用它。

部署频率低

随着代码的增多，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低。而部署频率 低又导致两次发布之间会有大量的功能变更和缺陷修复，出错概率比较高。

可靠性差

某个应用Bug，例如死循环、00M等，可能会导致整个应用的崩溃。

扩展能力受限

单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的 CPU ;有的模块则是 IO 密集型的，需要更大的内存。由于这些模块部署在一起，不得不在硬件的选择上做出妥协。

阻碍技术创新

单体应用往往使用统一的技术平台或方案解决所有的问题，团队中的每个成员都必须使用相同的开发语言和框架，要想引人新框架或新技术平台会非常困难。例如，一个使用 Struts 2构建的、有100万行代码的单体应用，如果想要换用 Spring MVC ，毫无疑问切换的成本是非常高的。

二、什么是微服务？

微服务的概念源于2014年3月Martin Fowler所写的一篇文章“Microservices”。

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。

每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

1、微服务架构优势

l 复杂度可控

在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。

l 独立部署

由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。

l 技术选型灵活

微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。

l 容错

当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。

l 扩展

单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

2、微服务架构示例

三、微服务架构VS单体架构

1.分工不同

以前我们通常是一个有规模的团队围绕一个单体应用工作，可能是一人一个模块；微服务架构可以为软件开发提供不同的方法，把传统模式下的单体应用拆分成独立的服务，从而可以单独开发、单独部署、单独维护，在微服务架构下可能是一人一个系统。

2. 存储方式不同

单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。

3.部署方式不同

在单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。微服务架构服务可独立部署，并且可以独立于其他服务进行扩展，如果部署得当，基于微服务的架构可以帮助业务避免欠下技术债务，以及大幅提高效率的重大价值。

4.容灾不同

当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。好的微服务可以隔离故障避免服务整体down掉，坏的微服务设计仍然可以因为一个子服务出现问题导致连锁反应。

5. 开发模式不同

单体架构所有的模块开发所使用的技术一样，开发模式比较受限，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

微服务架构在软件行业已成为一中发展趋势，微服务架构与传统的单体软件架构代表着IT产业处理软件开发方式的一个根本性转变。那么微服务架构与传统的单体架构相比，有何区别呢？我们从以下几点来看：

一、单体架构

单体架构，是指将开发好的项目打成war包，然后发布到tomcat等容器中的应用。

假设你正准备开发一款与Uber和滴滴竞争的出租车调度软件，经过初步会议和需求分析，你可能会手动或者使用基于Spring Boot、Play或者Maven的生成器开始这个新项目，它的六边形架构是模块化的 ，架构图如下：

应用核心是业务逻辑，由定义服务、领域对象和事件的模块完成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件，以及提供API或者UI访问支持的web模块等。

尽管也是模块化逻辑，但是最终它还是会打包并部署为单体式应用。具体的格式依赖于应用语言和框架。例如，许多Java应用会被打包为WAR格式，部署在Tomcat或者Jetty上，而另外一些Java应用会被打包成自包含的JAR格式，类似的，Rails和Node.js会被打包成层级目录。

这种应用开发风格很常见，因为IDE和其它工具都擅长开发一个简单应用，这类应用也很易于调试，只需要简单运行此应用，用Selenium链接UI就可以完成端到端测试。

单体式应用也易于部署，只需要把打包应用拷贝到服务器端，通过在负载均衡器后端运行多个拷贝就可以轻松实现应用扩展。在早期这类应用运行的很好。

单体架构存在的问题：

复杂性高

以某个百万行级别的单体应用xxx为例，整个项目包含的模块非常多，模块的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起，整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个Bug都会带来隐含的缺陷。

技术债务

随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务， 并且越积越多。“不坏不修”，这在软件开发中非常常见，在单体应用中这种思想更甚。已使用的系统设计或代码难以被修改，因为应用程序中的 其他模块可能会以意料之外的方式使用它。

部署频率低

随着代码的增多，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低。而部署频率 低又导致两次发布之间会有大量的功能变更和缺陷修复，出错概率比较高。

可靠性差

某个应用Bug，例如死循环、00M等，可能会导致整个应用的崩溃。

扩展能力受限

单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的 CPU ;有的模块则是 IO 密集型的，需要更大的内存。由于这些模块部署在一起，不得不在硬件的选择上做出妥协。

阻碍技术创新

单体应用往往使用统一的技术平台或方案解决所有的问题，团队中的每个成员都必须使用相同的开发语言和框架，要想引人新框架或新技术平台会非常困难。例如，一个使用 Struts 2构建的、有100万行代码的单体应用，如果想要换用 Spring MVC ，毫无疑问切换的成本是非常高的。

二、什么是微服务？

微服务的概念源于2014年3月Martin Fowler所写的一篇文章“Microservices”。

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。

每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

1、微服务架构优势

l 复杂度可控

在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。

l 独立部署

由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。

l 技术选型灵活

微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。

l 容错

当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。

l 扩展

单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

2、微服务架构示例

三、微服务架构VS单体架构

1.分工不同

以前我们通常是一个有规模的团队围绕一个单体应用工作，可能是一人一个模块；微服务架构可以为软件开发提供不同的方法，把传统模式下的单体应用拆分成独立的服务，从而可以单独开发、单独部署、单独维护，在微服务架构下可能是一人一个系统。

2. 存储方式不同

单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。

3.部署方式不同

在单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。微服务架构服务可独立部署，并且可以独立于其他服务进行扩展，如果部署得当，基于微服务的架构可以帮助业务避免欠下技术债务，以及大幅提高效率的重大价值。

4.容灾不同

当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。好的微服务可以隔离故障避免服务整体down掉，坏的微服务设计仍然可以因为一个子服务出现问题导致连锁反应。

5. 开发模式不同

单体架构所有的模块开发所使用的技术一样，开发模式比较受限，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。