微服务简介

最新推荐文章于 2022-07-11 17:04:04 发布

多纤果冻

最新推荐文章于 2022-07-11 17:04:04 发布

阅读量600

点赞数 1

分类专栏： java 微服务

java 同时被 2 个专栏收录

51 篇文章 2 订阅

订阅专栏

微服务

13 篇文章 0 订阅

订阅专栏

微服务简介

克里斯·理查森(ChrisRichardson)。

编辑-这个由七部分组成的系列文章现已完成：

您还可以下载完整的文章集，以及有关使用Nginx Plus作为电子书实现微服务的信息-微服务：从设计到部署.另外，请看新的微服务解决方案页面.

目前，微服务正受到广泛关注：文章、博客、关于社交媒体的讨论和会议报告。他们正迅速走向通胀预期的顶峰。高德纳炒作周期。与此同时，软件界也有一些怀疑论者，他们认为微服务并不是什么新鲜事。反对者声称，这一想法只是SOA品牌的重新命名。然而，尽管大肆宣传和怀疑，微服务体系结构模式具有显著的好处-特别是在启用复杂企业应用程序的敏捷开发和交付时。

这篇博客文章是关于设计、构建和部署微服务的七部分系列文章中的第一篇。您将了解该方法及其与传统方法的比较。单片建筑模式。本系列将描述微服务体系结构的各种元素。您将了解MicroServicesArchitecture模式的优缺点，它对您的项目是否有意义，以及如何应用它。

让我们先来看看为什么您应该考虑使用微服务。

建筑整体应用

让我们想象一下，你正开始打造一个全新的叫车应用，旨在与优步(Uber)和海洛(Hailo)展开竞争。在一些初步会议和需求收集之后，您将手动或使用Rails、SpringBoot、Play或Maven附带的生成器创建一个新项目。这个新的应用程序将有一个模块六角形建筑，如下图所示：

Modular, but still monolithic, architecture used as basis for sample microservices application

应用程序的核心是业务逻辑，它由定义服务、域对象和事件的模块实现。核心周围是与外部世界接口的适配器。适配器示例包括数据库访问组件、生成和使用消息的消息传递组件，以及公开API或实现UI的Web组件。

尽管有一个逻辑模块化的体系结构，但应用程序被打包并部署为一个单点结构。实际格式取决于应用程序的语言和框架。例如，许多Java应用程序被打包为WAR文件，并部署在应用服务器(如Tomcat或Jetty)上。其他Java应用程序打包为自带的可执行JAR。类似地，Rails和Node.js应用程序打包为目录层次结构。

用这种风格编写的应用程序非常常见。它们很容易开发，因为我们的IDE和其他工具专注于构建单个应用程序。这些应用程序也很容易测试。您可以通过简单地启动应用程序并使用Selenium测试UI来实现端到端测试。单块应用程序也很容易部署。您只需将打包的应用程序复制到服务器。还可以通过在负载均衡器后面运行多个副本来扩展应用程序。在项目的早期阶段，它运行良好。

走向整体式地狱

不幸的是，这种简单的方法有很大的局限性。成功的应用程序有一个习惯，随着时间的推移，最终变得巨大。在每个sprint期间，您的开发团队实现了更多的故事，当然，这意味着要添加许多代码行。几年后，您的小而简单的应用程序将发展成为巨石。为了给出一个极端的例子，我最近采访了一个开发人员，他正在编写一个工具来分析他们数百万行代码(LOC)应用程序中的数千个JAR之间的依赖关系。我相信，多年来，大量开发人员共同努力，才创建了这样一个庞然大物。

一旦您的应用程序成为一个大的、复杂的单点，您的开发组织可能处于一个痛苦的世界。任何敏捷开发和交付的尝试都将举步维艰。一个主要问题是应用程序极其复杂。它太大了，任何一个开发人员都无法完全理解。因此，修复错误和正确实现新特性变得困难和耗时。更重要的是，这往往是一个向下的螺旋。如果代码基很难理解，那么更改将无法正确进行。你最终会有一个令人无法理解的怪物大泥球.

应用程序的规模也会减缓开发速度。应用程序越大，启动时间就越长。例如，在最近的一项调查中，一些开发人员报告说，启动时间长达12分钟。我还听说过应用程序启动时间长达40分钟的轶事。如果开发人员必须定期重新启动应用程序服务器，那么他们一天中的大部分时间将被用于等待，他们的生产力将受到影响。

大型复杂单块应用程序的另一个问题是，它是连续部署的一个障碍。今天，SaaS应用程序的最新进展是每天将更改多次推向生产。这对于复杂的Monolith来说是非常困难的，因为您必须重新部署整个应用程序才能更新其中的任何一部分。我前面提到的漫长的启动时间也于事无补。另外，由于更改的影响通常不是很清楚，所以很可能需要进行大量的手动测试。因此，持续部署几乎是不可能的。

当不同的模块有冲突的资源需求时，单块应用程序也很难扩展。例如，有一个模块可能实现cpu密集型的图像处理逻辑，并在理想情况下部署在Amazon中。EC2计算优化实例。另一个模块可能是内存中的数据库，最适合EC2内存优化实例。但是，由于这些模块是一起部署的，所以您必须在硬件选择上做出妥协。

单片应用程序的另一个问题是可靠性。因为所有模块都在同一个进程中运行，因此任何模块中的一个bug，比如内存泄漏，都可能导致整个进程崩溃。此外，由于应用程序的所有实例都是相同的，该bug将影响整个应用程序的可用性。

最后但并非最不重要的是，单块应用程序使采用新的框架和语言变得非常困难。例如，假设您有200万行使用XYZ框架编写的代码。重写整个应用程序以使用较新的ABC框架将非常昂贵(时间和成本都是如此)，即使该框架要好得多。因此，采用新技术存在巨大障碍。无论你在项目开始时做了什么技术选择，你都被困住了。

总结一下：您有一个成功的关键业务应用程序，它已经发展成为一个非常可怕的单体，很少(如果有的话)开发人员能够理解。它是使用过时的、无成效的技术编写的，这使得招聘有才华的开发人员变得困难。应用程序很难扩展，而且不可靠。因此，应用程序的敏捷开发和交付是不可能的。

那么你能做些什么呢？

微型服务-解决复杂性问题

许多组织，如亚马逊，易趣，和Netflix，通过采用现在称为微服务体系结构模式。与其构建一个单一的、单块的应用程序，不如将应用程序拆分为一组更小、更互联的服务。

服务通常实现一组不同的功能或功能，如订单管理、客户管理等。每个微服务都是一个微型应用程序，它有自己的六角结构，包括业务逻辑和各种适配器。一些微服务会公开其他微服务或应用程序客户端使用的API。其他微服务可能实现WebUI。在运行时，每个实例通常是一个云VM或一个Docker容器。

例如，下面的图表显示了前面描述的系统的可能分解：

Microservices architecture for a sample ride-for-hire app, with each microservice presenting a RESTful API

应用程序的每个功能区域现在都由自己的微服务实现。此外，web应用程序被分成一组更简单的web应用程序(例如，在我们的打车示例中，一个是针对乘客的，另一个是针对司机的)。这使得为特定用户、设备或专用例部署不同体验变得更加容易。

每个后端服务公开一个RESTAPI，大多数服务使用其他服务提供的API。例如，驱动程序管理使用通知服务器告知可用的驱动程序可能的行程。UI服务调用其他服务以呈现网页。服务还可以使用异步的、基于消息的通信。本系列后面将详细介绍服务间通信。

一些REST API也暴露在司机和乘客使用的移动应用程序中。然而，这些应用程序不能直接访问后端服务。相反，通信是由一个称为API网关。API网关负责负载平衡、缓存、访问控制、API计量和监视等任务，以及可以使用nginx有效地实现。。本系列后面的文章将介绍API网关.

The 'Scale Cube' with functional decomposition into microservices on the Y-axis

微服务体系结构模式对应于鳞片立方体，这是一本优秀的书中关于可伸缩性的3D模型。可伸缩性艺术。另外两个缩放轴是X轴缩放，它包括在负载均衡器后面运行多个相同的应用程序副本，以及Z轴缩放(或数据分区)，其中使用请求的一个属性(例如，行的主键或客户的标识)将请求路由到特定的服务器。

应用程序通常在一起使用这三种类型的缩放。y轴缩放将应用程序分解为微服务，如本节的第一个图所示。在运行时，X轴扩展在负载均衡器后面运行多个服务实例，以提高吞吐量和可用性。一些应用程序也可能使用Z轴缩放来划分服务。下图显示如何在AmazonEC 2上运行Docker来部署Trip Management服务。

Sample microservices app for ride-for-hire service, deployed in Docker containers and fronted by a load balancer

在运行时，Trip Management服务由多个服务实例组成。每个服务实例都是一个Docker容器。为了提高可用性，容器在多个CloudVM上运行。在服务实例前面是一个负载均衡器(如Nginx)它在实例之间分发请求。负载均衡器还可能处理其他问题，如缓存, 存取控制, API计量，和监测.

MicroServicesArchitecture模式对应用程序和数据库之间的关系有很大的影响。每个服务都有自己的数据库架构，而不是与其他服务共享单个数据库架构。一方面，这种方法不符合企业范围数据模型的思想。而且，它常常导致一些数据的重复。但是，要想从微服务中受益，每个服务都必须有一个数据库模式，因为它可以确保松散的耦合。下图显示了示例应用程序的数据库体系结构。

Database architecture in sample microservices application for ride service

每个服务都有自己的数据库。此外，服务可以使用一种最适合其需求的数据库类型，即所谓的Polyglot持久性体系结构。例如，司机管理(DriverManagement)发现司机接近潜在乘客，必须使用支持高效地理查询的数据库。

表面上，MicroServicesArchitecture模式与SOA类似。通过这两种方法，体系结构由一组服务组成。然而，对MicroServicesArchitecture模式的一种思考方式是，它是SOA，没有商业化和感知的包袱Web服务规范(WS-*)和企业服务总线(ESB)。基于微服务的应用程序倾向于更简单、轻量级的协议，如REST，而不是WS-*。它们还非常避免使用ESB，而是在微服务本身中实现类似ESB的功能。MicroServicesArchitecture模式还拒绝SOA的其他部分，例如规范模式的概念。

微型服务的好处

MicroServicesArchitecture模式有许多重要的优点。首先，它解决了复杂性问题。它将原本是巨大的单块应用程序分解成一组服务。虽然功能总量保持不变，但应用程序已被分解为可管理的块或服务。每个服务都有一个定义良好的边界，其形式是RPC或消息驱动的API。MicroServicesArchitecture模式实现了一个模块化水平，在实践中，使用单块代码库是非常困难的。因此，单个服务的开发速度要快得多，理解和维护起来也容易得多。

第二，该体系结构允许每个服务由专注于该服务的团队独立开发。开发人员可以自由选择任何有意义的技术，只要服务遵守API合同。当然，大多数组织都希望避免完全无政府状态，限制技术选择。然而，这种自由意味着开发人员不再有义务使用新项目开始时可能存在的过时技术。在编写新服务时，他们可以选择使用当前的技术。此外，由于服务相对较小，因此使用现有技术重写旧服务变得可行。

第三，MicroServicesArchitecture模式允许独立地部署每个微服务。开发人员从不需要协调其服务的本地更改的部署。这些更改一旦经过测试就可以部署。例如，UI团队可以执行A/B测试并快速迭代UI更改。MicroServicesArchitecture模式使持续部署成为可能。

最后，MicroServicesArchitecture模式允许独立地缩放每个服务。您可以只部署满足其容量和可用性约束的每个服务的实例数。此外，您可以使用最适合服务资源需求的硬件。例如，可以在EC2计算优化实例上部署CPU密集型图像处理服务，并在EC2内存优化实例上部署内存数据库服务。

微服务的弊端

正如弗雷德·布鲁克斯(FredBrooks)30年前所写的那样，这里没有银弹。和其他技术一样，Microservices体系结构也有缺点。一个缺点是名字本身。术语微服务过分强调服务规模。事实上，有些开发人员主张构建非常细粒度的10-100 LOC服务.虽然小型服务更可取，但重要的是要记住，它们是达到目的手段，而不是主要目标。微服务的目标是充分分解应用程序，以促进敏捷应用程序的开发和部署。

微服务的另一个主要缺点是由于微服务应用程序是分布式系统这一事实而产生的复杂性。开发人员需要选择并实现基于消息传递或RPC的进程间通信机制。此外，他们还必须编写代码来处理部分故障，因为请求的目标可能是缓慢的或不可用的。虽然这些都不是火箭科学，但它比单块应用程序要复杂得多，在这个应用程序中，模块通过语言级方法/过程调用相互调用。

微服务的另一个挑战是分区数据库体系结构。更新多个业务实体的业务事务相当常见。在单块应用程序中实现这些事务非常简单，因为只有一个数据库。然而，在基于微服务的应用程序中，需要更新由不同服务拥有的多个数据库。使用分布式事务通常不是一个选项，而且不仅仅是因为盖定理。现在许多高度可伸缩的NoSQL数据库和消息代理都不支持它们。最后，您必须使用最终的基于一致性的方法，这对开发人员来说更具挑战性。

测试微服务应用程序也要复杂得多。例如，使用SpringBoot这样的现代框架，编写一个启动单块Web应用程序并测试其RESTAPI的测试类是非常简单的。相反，服务的类似测试类需要启动该服务和它所依赖的任何服务(或至少为这些服务配置存根)。再说一次，这不是火箭科学，但重要的是不要低估这样做的复杂性。

MicroServicesArchitecture模式的另一个主要挑战是实现跨多个服务的更改。例如，让我们假设您正在实现一个需要更改服务A、B和C的故事，其中A依赖于B，B依赖于C。在单块应用程序中，您可以简单地更改相应的模块，集成更改，并一次性部署它们。相反，在MicroServicesArchitecture模式中，您需要仔细规划和协调对每个服务的更改的推出。例如，您需要更新服务C，然后是服务B，最后是服务A。幸运的是，大多数更改通常只影响一个服务和需要协调的多服务更改相对较少。

部署基于微服务的应用程序也要复杂得多。单块应用程序简单地部署在传统负载均衡器后面的一组相同的服务器上。每个应用程序实例都配置了基础设施服务(如数据库和消息代理)的位置(主机和端口)。相反，微服务应用程序通常由大量服务组成。例如，Hailo有160种不同的服务，Netflix有600多种服务。阿德里安·科克克罗夫特[编辑-海洛已被Mytaxi收购。]。每个服务都有多个运行时实例。这是更多需要配置、部署、缩放和监视的移动部件。此外，您还需要实现一种服务发现机制(在后面的文章中讨论)，该机制使服务能够发现它需要与之通信的任何其他服务的位置(主机和端口)。传统的基于故障票和手工操作的方法不能扩展到这种复杂程度。因此，成功部署微服务应用程序需要开发人员更好地控制部署方法和高度自动化。

自动化的一种方法是使用现成的PaaS，例如云铸造。PaaS为开发人员提供了一种部署和管理其微服务的简单方法。它将它们与诸如获取和配置IT资源之类的问题隔离开来。同时，配置PaaS的系统和网络专业人员可以确保符合最佳实践和公司政策。实现微服务部署自动化的另一种方法是开发本质上是您自己的PaaS。一个典型的起点是使用集群解决方案，例如库伯奈特斯，与诸如Docker这样的技术相结合。在本系列的后面，我们将研究如何基于软件的应用交付像Nginx这样的方法可以帮助解决这个问题，它可以轻松地处理缓存、访问控制、API计量和微服务级别的监视。