微服务举例

Posted 2021-12-02 alpine-enterprise

由于技术领域的范式转变，以及希望以快速且可靠的方式找到更好的方法来构建应用程序，企业软件架构总是伴随新的架构风格而发展。

微服务架构已被广泛采用的架构风格，允许快速，安全地构建软件应用程序。微服务架构促进软件系统结构成为：松散耦合且独立自治的服务（独立开发，部署和扩展）的集合。这些服务通过集成所有此类服务和其他系统形成的单个软件应用程序。

在本章中，将探讨微服务是什么，实例示例的微服务的特征，以及企业软件架构环境中微服务的优缺点。

为了更好地理解微服务是什么，我们需要看一下微服务之前使用的一些架构风格，以及企业架构如何发展到包含微服务架构。

从Monolith到微服务架构

探索从单一应用程序到微服务的企业架构的演变是理解微服务的关键动机和特征的好方法。让我们开始讨论单片应用程序。

整体应用

企业软件应用程序旨在促进众多业务需求。在单片架构风格中，所有业务功能都集成在一个单一的应用程序中，并构建为一个单元。考虑一个真实的例子来进一步理解单片应用程序。图1-1显示了使用单片架构风格构建的在线零售应用程序。

图1-1使用单片架构开发的在线零售应用程序

整个零售应用程序是几个组件的集合，例如订单管理，付款，产品管理等。这些组件中的每一个都提供广泛的业务功能。由于其整体性质，向组件添加或修改功能是非常昂贵的。此外，为了促进整体业务需求，这些组件必须相互通信。这些组件之间的通信通常建立在专有协议和标准之上，并且它们基于点对点通信方式。因此，修改或替换给定组件也非常复杂。例如，如果零售企业想要在保留其余部分的同时切换到新的订单管理系统，那么这样做也需要对其他现有组件进行相当多的更改。

我们可以将单片应用的共同特征概括如下：

作为一个单元设计，开发和部署。

对于大多数现实世界的商业用例来说，这是非常复杂的，这导致了维护，升级和添加新功能的噩梦。

实施敏捷开发和交付方法很难。由于应用程序必须构建为一个单元，因此它提供的大多数业务功能都没有自己的生命周期。

必须重新部署整个应用程序才能更新它的任何部分。

随着整体应用程序的增长，启动可能需要更长时间，这会增加总体成本。

它必须作为单个应用程序进行扩展，并且难以根据相互冲突的资源需求进行扩展。（例如，由于单片应用程序提供多种业务功能，因此一种功能可能需要更多CPU，而另一种功能需要更多内存。很难满足这些功能的个性化需求。）

一个不稳定的服务可以降低整个应用程序。

采用新技术和框架非常困难，因为所有功能都必须建立在同质技术/框架之上。 （例如，如果您使用的是Java，那么所有新项目都必须基于Java，即使那是更好的替代技术。）

作为单片应用程序体系结构的一些局限性的解决方案，出现了面向服务的体系结构（SOA）和企业服务总线（ESB）。

SOA和ESB

SOA试图通过将单片应用程序的功能分离为可重用，松散耦合的实体（称为服务）来应对大型单片应用程序的挑战。这些服务可通过网络呼叫访问。服务是可通过网络访问的定义明确的业务功能的自包含实现。 SOA中的应用程序是基于服务构建的。服务是具有明确定义的接口的软件组件，这些接口与实现无关。 SOA的一个重要方面是将服务接口（什么）与其实现（如何）分离。消费者只关心服务接口而不关心它的实现。

服务是独立的（执行预定任务）和松散耦合（独立）。可以动态发现服务。消费者通常不需要知道服务的确切位置和其他细节。通过服务元数据存储库或服务注册表发现服务的元数据。当服务元数据发生更改时，服务可以在服务注册表中更新其元数据。可以从其他服务的聚合构建组合服务。

使用SOA范例，每个业务功能都构建为具有多个子功能的（粗粒度）服务（通常实现为Web服务）。这些服务部署在应用程序服务器中。在涉及业务功能的消耗时，我们经常需要集成/检测多个此类服务（并创建组合服务）和其他系统。企业服务总线（ESB）用于集成这些服务，数据和系统。消费者使用从ESB层公开的组合服务。因此，ESB用作连接所有这些服务和系统的集中总线（见图1-2）。

 

图1-2基于SOA / ESB样式的在线零售系统
例如，回到在线零售应用程序用例。图1-2说明了使用SOA / Web服务的在线零售应用程序的实现。在这里，我们定义了多种Web服务，满足各种业务功能，如产品，客户，购物，订单，支付等。在ESB层，集成这些业务功能并创建复合业务功能，这些功能可以向消费者展示。或者ESB层可以只用于公开功能，具有额外的交叉功能，例如安全性。因此，显然ESB层还包含整个应用程序的重要业务逻辑部分。其他横切关注点（如安全性，监控和分析）也可能应用于ESB层。 ESB层是一个单一的实体，所有开发人员共享相同的运行时来开发/部署他们的服务集成。
APIS蜜蜂
将业务功能公开为托管服务或API已成为现代企业架构的关键要求。但是，Web服务/ SOA实际上并不是满足此类需求的理想解决方案，因为Web服务相关技术（如用作服务间通信的消息格式）的复杂性，WS-Security（到服务之间的安全消息传递），WSDL（定义服务合同）等，以及缺乏围绕API构建生态系统的功能（自助服务等）
因此，大多数组织在现有SOA实现之上放置了一个新的API Management / API Gateway层。该层称为API外观，它为给定的业务功能公开了一个简单的API，并隐藏了ESB / Web服务层的所有内部复杂性。 API层还用于安全性，限制，缓存和货币化。
例如，图1-3在ESB层之上引入了API网关。我们的在线零售应用程序提供的所有业务功能现在都作为托管API公开。 API管理层不仅要将功能公开为托管API，还要构建一个完整的业务功能生态系统及其消费者。

图1-3通过API网关层将业务功能公开为托管API
随着对复杂业务功能的需求不断增加，单片架构无法满足现代企业软件应用程序的开发需求。 单片应用程序的集中性导致无法独立扩展应用程序，阻碍独立应用程序开发和部署的应用程序间依赖性，由于集中性而导致的可靠性问题以及使用各种技术进行应用程序开发的限制。 为了克服大多数这些限制并满足现代，复杂和分散的应用程序需求，必须构思一种新的体系结构范例。
微服务架构已经成为一种更好的架构范例，可以克服ESB / SOA架构以及传统单片应用架构的缺点。