微服务与面向服务架构简介

Introduction to Microservices and Service-Oriented Architecture

随着internet可用性的增加，数据通信技术正在不断发展。体系结构方面的改进非常具有创新性、可伸缩性和可跨环境采用性。需要在internet上提供软件组件，这些组件具有跨不同平台和编程语言进行通信的通用接口。

这就产生了这样一个概念:创建具有可伸缩性的易于部署的服务，并在internet上公开它们。在服务方面设计功能被广泛采用;以服务的形式向异构客户端提供特性是一个好主意。这种使用服务的概念导致了SOA(面向服务的体系结构:Service-Oriented Architecture)。

1.     SOA中的服务

服务是一种软件，它为系统内外的其他软件提供功能。

其他软件(客户端)可以是任何东西，从web应用程序(网站)到移动应用程序(本地或混合)，或桌面应用程序，甚至是另一个服务，它使用另一个服务来执行特定类型的功能。

在电子商务网站上下文中，当用户下订单时，web应用程序与服务通信，以执行数据库上的创建、读取、更新和删除(CRUD)操作。

软件组件(客户端)与服务之间的通信通常通过某种通信协议的网络进行，例如，移动应用程序通过internet与服务通信。

以这种方式使用服务或多个服务的系统具有面向服务的体系结构。

这种体系结构背后的主要思想是，不使用每个客户机应用程序中的模块，而是让我们使用服务来为它们提供功能。这允许我们有许多使用相同功能的客户端应用程序。SOA之所以成功，是因为它具有以下特征:

l 它允许我们我们的软件规模当需求增加使其服务在多个服务器上的副本,所以当交通,负载平衡器将请求重定向到特定服务的实例,我们可以有多个实例的服务。因此，当需求增加时，增加服务器上的实例数量可以帮助我们扩展它。

l SOA拥有标准化的契约或接口。当客户机应用程序调用服务时，它通过调用方法来调用服务。该方法的签名通常不会随着服务的更改而更改，因此只要契约和接口不变，我们就可以升级服务，而不必升级客户端。

l 服务实际上是无状态的，所以当一个请求从一个网站传入我们的服务时，该服务的实例不必记住来自特定客户的前一个请求。基本上，它拥有来自请求的所有信息，以便检索服务中与前一个请求关联的所有数据，因此，服务不必记住客户端对该服务的特定实例进行的前一个调用。

a)       服务的实现

SOA由于其服务的实现而流行起来，这些服务可以通过独立于操作系统平台和编程语言的标准internet协议进行访问。

来自开发人员视角(Point of View)的服务只是驻留在web服务器上的web服务，它们使用SOAP(简单对象访问协议:Simple Object Access Protocol)或JSON进行通信。有趣的是，web服务可以用作遗留系统的包装器，以使它们支持网络。

常见的可以实现SOA的技术包括:

k 基于WSDL(Web Service Description Language)网络服务描述语言和SOAP简单对象访问协议的网络服务.

k消息,例如:ActiveMQ,JMS,RabbitMQ

k WCF(微软Web服务实现方式)

k Apache Thrift

kSORCER

kRESTful HTTP

面向服务的体系结构在整体体系结构方法的经验被证明比之前认为的更痛苦时开始获得发展势头。让我们简要地了解一下什么是一体系统，以及它们导致采用SOA的缺点。

2.     一体架构(Monolithic Architecture)

基于整体架构的系统在SOA或微服务运动之前就已经存在了。这些类型的系统与SOA试图实现的目标完全相反。一个典型的单片系统是一个基于企业的应用程序，这个应用程序可能是一个大型网站的形式，所有的工作模块打包在一起成为一个单独的软件包，或者它可能是一个与网站对话的服务的形式。它可以打包为部署在机器上的大型可执行文件。在这些系统中，我们向应用程序添加不同的组件以保持增长;没有大小的限制，也没有分工。总是有一个包含所有内容的包，因此，我们最终会得到一个很大的代码库。

a)       一体架构的经常性支出(Overheads)

从长远来看，企业在将一体体系结构应用于系统时，会面临这些缺点:

u 由于代码库太大，团队花了更长的时间在应用程序中开发新功能。

u 大型系统的部署也可能具有挑战性，因为即使对于一个小的bug修复，我们也必须部署整个系统的新版本，因此，这将带来更大的风险。

u 这是一个很大的代码库，所以，我们也只能使用一个技术堆栈。

u 它使整个系统的竞争力降低，因为我们不能轻易采用可能给我们带来竞争优势的新技术。

u 因为代码在一个大的包中，所以我们可能也有高级别的耦合，这意味着如果在系统的一个部分进行了更改，那么它可能会影响系统的另一个部分，因为代码是相互交织的。

u 这种耦合可能出现在模块之间，也可能出现在不同的服务之间。

u 为了满足需求而扩展这个服务是非常低效的。例如，如果系统的Orders模块有需求，我们将不得不创建整个包的一个副本，整个服务的副本，以便按比例放大Orders部分。

u 需要购买更强大的服务器来高效地运行大量的单片应用程序。

u 对如此庞大的代码库进行单元测试需要时间，QA的回归测试也是一个耗时的过程。

一体架构的一个例子是ASP。NET MVC网站，网站本身是用户界面层，然后在业务层，你有业务逻辑随着数据访问层。多年以后，如果我们继续使用相同的方法，那么它将成为一个整体系统。

3.     微服务简介

微服务体系结构基本上是面向服务的体系结构。在多年使用面向服务的体系结构之后，软件开发人员已经认识到面向服务的体系结构应该是什么样的，这基本上就是微服务体系结构——它是面向服务的体系结构的演化。

微服务是小型的、自主的服务，它可以很好地执行一项功能，同时还可以与其他服务协同工作。

微服务引入了一组新的附加设计原则，这些原则告诉我们如何正确地确定服务的大小。在此之前，没有关于如何确定服务的大小以及在服务中包含什么内容的指导。传统的面向服务的体系结构导致了单片的大型服务，并且由于服务的大小，这些服务的扩展效率变得很低。

a)       轻量且可伸缩

微服务提供的服务具有更高效的可伸缩性和灵活性，并且可以在需要性能的领域提供高性能。

基于微服务体系结构的应用程序通常是由多个微服务支持的应用程序，每个微服务为应用程序的特定部分提供一组功能或一组相关功能。微服务体系结构通常为应用程序、客户机应用程序和客户机服务提供一组相关功能。

微服务体系结构还使用客户端与服务之间或两个或多个服务之间的轻量级通信机制。通信机制必须是轻量级的和快速的，因为当一个微服务架构的系统执行一个事务时，它是一个由多个服务完成的分布式事务。因此，服务需要通过网络以快速和有效的方式相互通信。

b)      技术无关性

微服务的应用程序接口，或者我们与微服务通信的方式，也需要与技术无关。这意味着服务需要使用开放的通信协议，这样它就不会规定客户机应用程序需要使用的技术。通过使用开放的通信协议，例如HTTP REST(基于JSON)，我们可以很容易地拥有一个. net客户端应用程序，它可以与基于java的微服务进行通信。

c)       独立变更性

微服务的另一个关键特性是它是独立可更改的。我们可以升级、增强或修复特定的微服务，而无需更改系统中的任何客户端或任何其他服务。

在微服务体系结构中，每个微服务都有自己的数据存储。通过修改一个微服务，我们应该能够在系统中独立地部署更改，而无需部署任何其他内容。

前面的图像描述了微服务系统的高级体系结构图。这是一个典型的电子商务系统的例子，你可以看到在左边，有一个购物网站在客户的浏览器中运行，或者它可以是一个使用API网关的移动应用程序。

浏览器通过互联网连接到演示购物网站——演示购物网站可能是一个ASP。NET MVC网站在IIS上运行。与网站的所有交互所需的所有处理实际上都是由一些在后台运行的微服务完成的。

每个微服务都有一个焦点，或一组相关功能，都有自己的数据存储，而且还可以独立地更改和部署。例如，我们可以升级订单服务，而无需升级系统的任何其他部分。

每种类型的微服务也可能有多个实例。例如，如果订单服务有需求，为了满足需求，我们可能有几个订单服务实例。为了将购物网站的请求定向到订单服务的正确实例，我们有一个API网关，它管理并将请求路由到系统内正确的微服务。

因此，在本例中，当客户下订单时，购物网站可能会在这些服务中使用多个服务和多个功能来满足交易。这就是为什么在微服务体系结构中，事务通常是分布式事务，因为事务实际上是由多个软件片段来满足的，也就是微服务。

4.     微服务的好处

n 微服务体系结构满足快速响应变化的需要。现在的软件市场竞争非常激烈。如果你的产品不能提供市场需要的功能，它将很快失去市场份额。

n 它满足了业务域驱动设计的需要。应用程序的体系结构需要与组织结构或组织内业务功能的结构相匹配。

n 微服务体系结构利用自动化测试工具。我们已经看到，在微服务体系结构中，事务是分布式的，因此，事务在完成之前将由多个服务处理。这些服务之间的集成需要进行测试，而手动地一起测试这些微服务可能是一项相当复杂的任务。自动化测试工具帮助我们执行集成测试，减少了手工的负担。

n 兼容云的微服务可以减轻部署和发布管理的负担。

n 微服务体系结构为采用新技术提供了一个平台。因为系统是由多个移动部件组成的，所以我们可以很容易地改变其中的一个部件，即从一个技术栈到另一个技术栈的微服务，以获得竞争优势。

n 通过使用异步通信，分布式事务不必等待各个服务完成它们的任务。

n 微服务的开发时间更短。因为系统被分割成更小的移动部分，所以我们可以单独处理移动部分，可以让团队同时处理不同的部分，而且因为微服务的规模很小，而且它们只有一个关注点，所以团队在范围方面不必太担心。

n 微服务体系结构还为我们增加了正常运行时间，因为在升级系统时，我们可能一次部署一个微服务，而不会影响系统的其他部分。

5.     小结

在过去十年中，随着互联网带宽、机器处理能力、更好的框架等方面的改进，架构服务的发展经历了许多变化。从开发人员的角度来看，微服务是基于Restful的Web api可以使用ASP.NET、Java、PHP或其他。在接下来的章节中，我们将学习开发ASP的各个方面。基于核心的Web API应用程序。