1.单体架构单体架构是指将开发的项目打包成war包，然后发布到tomcat等容器中的应用。假设你正准备开发一款出租车调度软件来与优步和滴滴竞争。在初步会议和需求分析之后，您可以手动或使用基于SpringBoot、Play或Maven的生成器启动这个新项目。它的六个多边形架构是模块化的，架构图如下：应用程序的核心是业务逻辑，由定义服务、领域对象和事件的模块来完成。核心周围是处理外部世界的适配器。适配器包括数据库访问组件、产生和处理消息的消息组件以及提供API或UI访问支持的Web模块。虽然也是模块化逻辑，但最终还是会被打包部署成一个单体应用。确切的格式取决于应用程序语言和框架。例如，许多Java应用程序被打包为WAR以部署在Tomcat或Jetty上，而其他应用程序则被打包为独立的JAR。同样，Rails和Node.js被打包为分层目录。这种应用程序开发风格很常见，因为IDE和其他工具擅长开发简单的应用程序，而且这种应用程序也很容易调试。您只需要简单地运行应用程序，并使用Selenium链接UI即可完成端到端测试。单体应用程序的优点：单体应用程序也易于部署。只需要将打包后的应用复制到服务器上，在负载均衡器后端运行多份副本即可轻松扩展应用。在早期，此类应用程序运行良好。单体架构存在的问题：l复杂度高以一个百万行级别的单体应用xxx为例，整个项目包含了很多模块，模块边界模糊，依赖不明确，代码质量参差不齐堆叠混乱，整个项目非常复杂。每次修改代码，我都感到害怕。即使增加一个简单的功能或修改一个bug也会带来隐藏的缺陷。l技术债随着时间的推移，需求的变化，人员的变动，应用的技术债会逐渐形成，并且越来越多。“Ifit'snotbroken,don'tfixit”，这在软件开发中很常见，这种思想在单体应用中更甚。使用过的系统设计或代码很难修改，因为应用程序中的其他模块可能会以意想不到的方式使用它。l部署频率低随着代码的增加，构建和部署的时间也会增加。在单体应用程序中，每个功能更改或错误修复都需要重新部署整个应用程序。全量部署的方式耗时长、影响面广、风险大，使得单体应用项目上线部署频率较低。部署频率低导致两次发布之间有大量的功能变更和缺陷修复，出错概率比较高。l可靠性差一个应用程序的bug，比如死循环、00M等，都可能导致整个应用程序崩溃。l可扩展性有限单个应用只能作为一个整体进行扩展，不能根据业务模块的需要进行扩展。例如，应用程序中的某些模块是计算密集型的，需要强大的CPU；一些模块是IO密集型的，需要更多的内存。由于这些模块一起部署，因此必须在硬件选择上做出妥协。l技术创新的障碍单体应用往往使用统一的技术平台或解决方案来解决所有问题。团队的每个成员都必须使用相同的开发语言和框架，引入新的框架或新技术平台非常困难。比如一个100万行代码的单体应用是用Struts2搭建的，如果要切换到SpringMVC，毫无疑问切换的成本是非常高的。2.什么是微服务？微服务架构是一种架构模式，提倡将单个应用划分为一组小的服务，服务之间相互协调配合，为用户提供最终价值。每个服务都在自己独立的进程中运行，服务之间使用轻量级通信机制（通常是基于HTTP的RESTful-API）进行通信。每个服务都围绕特定的业务构建，可以独立部署到生产环境、类生产环境等。另外，要尽量避免统一集中的服务管理机制。对于具体的服务，要根据业务上下文选择合适的语言和工具来构建。微服务是一种架构风格，其中大型复杂的软件应用程序由一个或多个微服务组成。系统中的每个微服务都可以独立部署，每个微服务都是松耦合的。每个微服务只专注于完成一项任务并将其做好。在所有情况下，每个任务都代表一个小型业务能力。1.微服务架构的优势l复杂度可控在分解应用的同时，避免了原本无休止的复杂度积累。每个微服务都专注于一个功能，并通过定义良好的接口清楚地表达服务边界。由于体积小、复杂度低，每个微服务都可以完全由一个小规模的开发团队来控制，易于保持较高的可维护性和开发效率。l独立部署由于微服务有独立的运行进程，所以每个微服务也可以独立部署。当微服务发生变化时，无需编译和部署整个应用程序。由微服务组成的应用相当于拥有一系列并行的发布流程，使得发布更加高效，降低了生产环境的风险，最终缩短了应用的交付周期。l灵活的技术选择在微服务架构下，技术选择是去中心化的。每个团队都可以根据自身的业务需求和行业发展现状，自由选择最合适的技术栈。由于每个微服务都比较简单，升级技术栈的风险也比较低，甚至完全重构一个微服务也是可行的。l容错当某个组件发生故障时，在传统的单进程架构下，故障很可能在进程内扩散，导致应用全局不可用。在微服务架构中，故障被隔离在单个服务中。如果设计得当，其他服务可以通过重试、平滑降级等机制在应用层面实现容错。l扩展一个单体架构的应用也可以实现水平扩展，即将整个应用完全复制到不同的节点上。当应用的不同组件有不同的扩展需求时，微服务架构体现了它的灵活性，因为每个服务都可以根据实际需要独立扩展。三、微服务架构VS单体架构1、分工不同过去，我们通常有一个大型团队围绕一个单体应用工作，可能一个人一个模块；微服务架构可以为软件开发提供不同的方法，取代传统模式微服务架构下的单体应用被拆分成独立的服务，从而可以单独开发、部署和维护。在微服务架构下，可能是一人一个系统。2、存储方式不同单一架构的所有模块共享一个数据库，存储方式比较简单；微服务的各个模块可以使用不同的存储方式（比如有的使用redis，有的使用mysql等），数据库也是单个模块对应自己的数据库。3、部署方式不同在单个应用中，每一次功能变更或缺陷修复都会导致需要重新部署整个应用；微服务架构服务可以独立部署，可以独立于其他服务进行扩展。如果部署得当，基于A的微服务架构对于帮助业务避免产生技术债务，以及大幅提升效率都具有很大的价值。4.容灾不同。当某个组件发生故障时，在传统的单进程架构下，故障很可能在进程内扩散，导致应用全局不可用。在微服务架构中，故障被隔离在单个服务中。一个好的微服务可以隔离故障，防止服务整体宕机，而一个糟糕的微服务设计仍然会因为某个子服务出现问题而引发连锁反应。5、开发模式不同单体架构所有模块的开发所采用的技术是相同的，开发模式相对有限；微服务的各个模块可以使用不同的开发技术，开发模式更加灵活；
