微服务例举

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

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

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

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

从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架构以及传统单片应用架构的缺点。