## 一、单体应用与微服务 在我之前的章节中，已经通过“开饭店”的例子，为大家说明了从单体应用到微服务的应用架构发展的过程。本节主要是为大家介绍一下单体应用和微服务的优缺点以及应用场景。  ## 二、单体应用架构 **单体应用架构**被认为是构建应用程序的传统架构方式。单体应用程序是作为一个不可分割的单元构建的。通常，这种解决方案包括客户端用户界面，服务器端应用程序和数据库。 ### 单体架构（monolithic architecture）的优势： * 上手容易，学习成本低，通常技术栈比较简单。 * 易于部署，单体应用部署的复杂度要比微服务低得多。 * 适合小型团队开发“小而美”的，对业务复杂度不高，对应用扩展能力要求不高的应用程序架构。 ### 单体架构的缺点： * 随着应用需求的增加以及规模的扩大，由于其代码耦合度高，单体应用自身的代码复杂度会很高，从而变得难以维护。 * 难以维护的一个典型场景就是：修改任何一处细节的代码，都会影响整个系统。因此必须全面协调开发、测试、部署。这使软件迭代变的很慢，交付的效率低。 * 扩展性差：很难去针对某个模块进行扩展，只能针对整个应用程序扩展。IO密集型和计算密集型模块混合在一起，无法独立升级及扩容。 * 新技术壁垒，在单体应用程序中应用新技术极其困难，因为这样就必须重写整个应用程序。 ## 三、微服务架构 单体架构应用程序是一个统一的整体，而**微服务体系结构**则将其分解为较小的独立单元的集合。 > 简而言之，微服务架构风格是一种将单个应用程序拆分为一组小服务的方法，每个小服务都在自己的进程中运行并使用轻量级机制（通常是HTTP资源API）进行通信。 ----马丁·福勒 在微服务架构中，功能被分解为可独立部署的模块，这些模块通过远程调用方法相互通信。每个服务都涵盖了自己的范围，**每个服务可以独立更新，部署和扩展**。  ### 微服务架构的优势 * **独立组件：**首先，所有服务都可以独立部署和更新，从而提供了更大的灵活性。比如：针对IO密集型服务增加内存，针对计算密集型服务增加服务器的CPU等等，达到资源的合理分配。 * **业务关注更加集中：**将应用程序分解为更小和更简单的组件后，将更易于业务关注理解和管理。您只需专注于与您的业务目标相关的特定服务即可。所以：很多大厂都是面试造火箭，工作拧螺丝。因为微服务化只需要开发人员更专注于自己的服务领域。生产线尽管很庞大，但是只要拆分合理，开发人员只需要拧好自己的“微服务螺丝”就可以了。 * **更好的可扩展性:**微服务另一个优点是每个服务都可以独立缩放。结合容器化编排管理（k8s、docker等），可以快速的实现服务的扩容与缩放。比如：赶上双十一，电商可以快速地增加部署微服务数量以应对更多的并发需求。待高峰过后，可以将微服务容器释放，回收资源。 * **选择技术的灵活性：**工程团队不受一开始就选择的技术的限制。他们可以自由地为每个微服务应用各种技术和框架。只要保证接口通信协议一致即可。 ### 微服务架构的缺点 * **编码复杂度增加：**由于微服务架构是分布式系统，因此会产生分布式的数据库操作及分布式事务等复杂度更高的编码需求。所以一定要进行合理的微服务拆分，合理的确定服务边界，保证服务内部高内聚，降低分布式事务等操作出现的概率。 * **额外关注：**微服务由于其多主机、分布式部署，所以它们需要很多的额外关注：如统一配置，统一日志记录，统一的指标监控，统一的运行状况检查等。 * **测试：**虽然单个微服务的测试复杂度降低，但是众多可独立部署的服务使集成测试变的更加困难。 ## 四、哪种架构最适合您的业务需求呢？ ### 选择单体架构 * **小团队：**如果您是一家初创公司，而您的团队很小，则可能不需要处理微服务架构的复杂性。整体组件可以满足您的所有业务需求，因此无需紧跟炒作。 * **一个简单的应用程序：**不需要大量业务逻辑，小型应用程序与单体应用架构可以更好地协作。 * **没有微服务专业知识：**微服务需要深厚的专业知识才能运作良好并带来业务价值。如果您想从头开始没有任何技术专业知识的微服务应用程序，那么很可能不会成功。 * **快速应用：**如果您要开发应用程序并尽快应用它，则单体应用架构是更好的选择。当您的公司打算花最少的钱验证您的经营理念时，它会很好地发挥作用。 ### 选择微服务架构 * **用户数量或应用规模庞大：**微服务架构使扩展和添加新功能变得更加容易。因此，如果您打算开发具有多个模块和高用户体验的大型并发应用程序时，那么微服务架构可能是您的最佳选择。 * **团队庞大并有足够的技能：**由于微服务项目由负责多个服务的多个团队组成，因此您需要有足够的资源来处理所有流程。包括人力（技术人员）、物力（服务器）、财力等等。 * **具有微服务专业知识。**没有适当的技能和知识，构建微服务应用程序将具有极大的风险。但是仅具有架构知识还不够，还需要有DevOps和Containers专家。此外，必须具有领域建模专业知识。处理微服务意味着将系统分成单独的功能并划分职责，**合理的划分成就效能，不合理的划分导致灾难**。