MuleSoft网站的架构变迁

在过去四年中，我所在的MuleSoft网站经历了三种架构：单体，SOA与微服务。本文将讨论这些体系结构的演变以及如何采用它们。

单体架构（单机）

单体架构可以定义为大多数网站的第一个架构，这是简单且紧密耦合的应用程序，它们在单个应用程序层中执行，并将所有功能分组在同一个应用程序层中。

如果我们想通过API访问另一个服务或系统，需要在应用程序本身中开发业务逻辑和错误管理等。

下图展示了客户关系管理系统的单体架构的示例。

对于小型体系架构，它们运行良好，但是体系架构增长时，应用程序的管理和重构就会变复杂。此外，持续集成也会变复杂，这使DevOps的过程几乎无法完成。

单体架构的资源或应用程序之间的通信是直接的，没有任何其它中间件或ESB干预。这在使用某些语言（例如Java与SOAP服务的连接很复杂）实现与Web服务的通信时，也会增加很多复杂度。

SOA架构（粗粒度）

SOA（面向服务）已经可以有更大的架构解耦，它可以演变为更多样化的架构，也被称为粗粒度架构。

这是Mulesoft的第二版结构体系，ESB集中所有业务逻辑，并允许服务和应用程序之间的连接，无论其技术或语言，都会非常快速简便。

Mulesoft提供Mule Runtime，类似于Apache Tomcat，它可以作为Servlet容器使用，如下图所示。

通过这种方式，我们通过单一架构体系消除了应用程序没必要的工作和大多数业务逻辑。ESB负责转换数据，路由，访问必要的服务，管理错误等。源应用程序只需要简单地生成消息（如果需要）并通过HTTP请求将其发送到ESB上。

但是，还存在一个问题，那就是部署的全部集成都通过ESB引入，耦合和继续具有单一性质的架构仍在同一体系运行工作。例如，在运行时应用配置时，它将应用于所有已部署的应用程序。

微服务架构（细粒度）

接下来，细粒度架构的微服务上场。该体系结构与SOA很像，但是一种体积小且独立的服务。微服务为架构层面带来了很多复杂性，因为涉及许多小型角色，但优点是它们都是独立的。

微服务的限制非常明确，减少太多可能导致非常复杂和过度的架构。微服务的开发使用需要开发者彻底改变心态，事情必须简单，文档齐全，易于执行。

Mulesoft也不断发展，不再只是SOA架构的中间件，还专注于微服务架构及其集成即服务（SaaS）平台Anypoint Platform。通过这种方式，通过其Cloudhub存储平台（与Anypoint平台集成），用户可以部署应用程序，以便在不必知情的情况下在不同的实例中自动创建它们。

此外，Mulesoft通过可重用且有用的API连接数据和应用程序的方法，帮助在实现层和API之间进行分离。API引导的连接分为3个层，体验层，进程层和系统层。第一层是与客户端交互但没有实现的层，只有可以管理和保护的公开API。

其余层包含实现、流程层在公开的API和连接到必要的服务（如数据库，SAP，Salesforce，邮件，电子商务站点等）的系统层之间进行交互。

借助Anypoint Runtime Fabric和Runtime Manager（与Anypoint Platform集成），这些应用程序可以在运行部署在由AWS，Google Cloud，Azure，虚拟机或单机中的客户端管理的基础架构上。

也适用于容器，虽然它需要Docker的一些知识。

小结

关于采用微服务，有许多人认为它是一种规范的架构，它必须以某种规范方式完成，例如Netflix。但是，采用微服务这种方式对许多组织来说是不可行或不现实的，并且极有可能导致失败。

对于具有特定结构和文化的团队，由于各种技术和文化限制，微观服务的观点也只能走得那么远。如果组织在微服务空间中过于遵循规范的观点，产品需求与纯粹的方法不兼容，那么微服务架构的实施一定会不成功。

标签：SOA,服务,变迁,应用程序,API,ESB,架构,MuleSoft
来源： https://blog.51cto.com/15127566/2665780