实践中的微服务:从架构到自动化运维（上）

实践中的微服务:从架构到自动化运维（上）

概述

微服务是软件架构领域中最流行的词语之一，本文将介绍如何在真实的企业场景中使用微服务的资源

单体架构

企业软件架构设计是为了快速响应不断变化的业务需求;通常一个软件系统提供数百种功能，所有这些功能都被堆积到一个单一架构的系统中。例如ERP、CRM和其他各种软件系统都是作为一个具有数百个功能的整体构建的。部署、故障排除、扩展和升级将上一场噩梦。

面向服务的体系结构(Service Oriented Architecture, SOA)旨在通过引入服务的概念、应用程序提供的类似功能的聚合和分组来克服前面提到的一些限制。使用SOA，可以将软件应用程序设计为粗粒度服务的组合。但是，在SOA中，服务范围非常广泛。这导致具有数十种操作（功能）的复杂而庞大的服务，以及复杂的消息格式和标准（例如：所有WS *标准）。

在大多数情况下，SOA中的服务彼此独立。但是它们与所有其他服务一起部署在同一运行时中（考虑一下将多个Web应用程序部署到同一Tomcat实例中）。与整体软件应用程序相似，这些服务的功能会随着时间而增长的，变得庞大臃肿难以扩展。从字面上看，这将这些应用程序变成了与整体应用程序（如ERP）没有区别的整体结构。上图显示了包含多个服务的零售软件应用程序。所有这些服务都部署到同一应用程序运行时中。

整体应用程序被设计，开发和部署为一个单元。整体应用极其复杂。这导致维护，升级和添加新功能的噩梦。使用整体架构来实践敏捷开发和交付方法是很困难的。为了更新整个应用程序的一部分，需要重新部署整个应用程序。应用程序必须按单个单元进行扩展，这样就很难管理相互冲突的资源需求(例如，一个服务需要更多的CPU，而另一个需要更多的内存)一个不稳定的服务可能导致整个应用程序宕机。采用新技术和框架会变得很困难，因为所有功能都必须基于同类技术/框架。

微服务架构

微服务体系结构(MSA)的基础是将单个应用程序开发为一组小型的独立服务，这些服务在它们自己的流程中运行、开发和独立部署。

在微服务架构的大多数定义中，将其解释为将整体中可用的服务分离为一组独立服务的过程。但是，在我看来，微服务不仅仅是将整体中可用的服务拆分为独立的服务。