微服务和传统中间件平台

Posted 2021-04-10 程序你好

文摘

微服务与部署在中间件平台(esb、应用服务器)上的传统服务有何不同?什么是微服务体系结构模式，它解决了什么问题?本文将讨论所有这些重要的主题，并描述如何管理、管理和扩展微服务。

Microservices概述

微服务是一种体系结构模式，它将应用程序构建为松散耦合的服务的组合，这些服务不仅在逻辑上是分开的，而且在运行时也在物理上是分开的。微服务是细粒度的轻量级自主组件。它支持并行开发、测试和独立部署。它支持持续集成、交付和部署。每个微服务都可以单独缩放，这样可以有效地使用计算，并且能够实现高效且简单的弹性可伸缩性。它破坏了运行时整体体系结构，并防止单点故障。

微服务和SOA架构风格

面向服务的体系结构的大多数架构原则都适用于MSA(微服务体系结构)。微服务仍然是服务，但不是非常粗粒度的，不一定实现广泛的业务功能。它们更细粒度、更轻量，并且执行一个小的工作单元。SOA的原则是公开粗粒度的业务功能和聚合实体属性，以形成企业业务对象。微服务在小实体上工作，并公开服务来操作该实体。难怪大多数微服务都与HTTP REST方法对齐，这些方法允许创建(POST)、获取(GET)、修改(PUT)和删除(删除)实体。

Microservices Architecture (MSA)	SOA Architecture
Lightweight fine-grained services	Coarse-grained services
Doesn’t require an application server or centralized middleware platform for deployment	Services deployed on heavy centralized application servers/ middleware platforms.
Based on the principle that every microservice performs small units of work and hence doesn’t require complex middleware infrastructure.	Based on the principle that every service publishes a large business function and may require middleware services.
Ideal for request/ response services required to build web apps and mobile apps	Suitable for enterprise system integrations which require messaging based infrastructure
Services are autonomous at runtime. Every service has it’s own compute and storage and is not shared between services	All services are deployed on the central middleware platform and hence they all share the same compute and storage
Every service can be auto-scaled independent of the other by wrapping them into containers and scale them on demand.	Auto-scaling is not easy since the whole middleware platform will have to be replicated
Continuous delivery and deployment are at its core	Continuous delivery and deployment are not mainstream

MSA和ESB可以共存吗?

ESB仍然与微服务一起存在。微服务肯定会得到更多的构建，因为它们易于开发、操作成本更低、部署速度更快。当构建需要一组api的应用程序时，微服务是最适合的。它还用于公开现代企业应用程序的功能，这些应用程序公开REST api并执行系统到系统的同步通信。它是基于云的集成的一个重要体系结构模式，例如，通过封装微服务中的所有身份验证和授权握手，将sa平台公开的api组合起来，并提供更有意义和更容易使用的服务。

ESB将继续支持传统的体系结构，并且仍然与企业系统集成相关。不同企业系统的各种可重用适配器加速了开发。使用SOA实现、需要状态机和人工工作流的长时间运行的流程仍然很有用。

微服务的运营视图

部署

每个微服务都以分布式的方式部署。微服务可以打包到包含所有依赖项的容器中，并且可以部署到任何位置(on-prem、cloud和任何操作系统)。由于微服务包含打包在一起的所有运行时依赖项，它消除了在不同环境中部署时导致部署失败的运行时环境因素。它保证了应用程序的成功部署，因此降低了操作成本，并且由于应用程序稳定，给涉众带来了信心。部署是真正可重复的，这就是为什么它可以被复制并自动扩展到无穷大的原因。

部署过多的微服务时会发生什么?如何管理和操作它们?如何分配资源给他们?如何追踪它们?你是如何发现它们的?在大型企业中部署大量微服务时，需要回答这些问题。这就是您需要软件来编排和管理容器的地方。以下部分将回答这些问题。

进入Kubernetes

Kubernetes是一个领先的集装箱管理开源平台(2014年谷歌开源)管理的部署容器,容器的资源分配,健康检查和监控,复制和伸缩的容器,容器让它作为一个服务的抽象和负载平衡、服务发现、等等。

主节点负责管理Kubernetes集群。它有几个组件，允许对集群状态进行管理、监视和控制。

kube-apiserver

API服务器公开API以在集群资源上执行CRUD操作。它验证请求，执行驻留在不同组件中的业务逻辑，并在etcd中持久化结果状态。

API服务器可以在集群之外访问，以便客户端执行管理任务。

etcd

etcd是一个分布式的键值持久存储，其中所有集群状态都被持久化。

Kube-scheduler

调度程序负责监视未调度的pod，并将它们绑定到特定的节点上运行。它根据资源和复制需求自动安排容器在特定的节点上运行。调度器知道节点上可用的资源，并根据pod所需的资源可用性和资源选择运行pods的节点。

Kube-controller-manager

控制器管理器负责运行各种类型的控制器。控制器监视集群的当前状态，并采取纠正措施将集群带到期望的状态。控制器的一些例子是节点控制器和复制控制器。节点控制器负责监控节点并在节点下降时采取纠正措施。类似地，复制控制器监控运行的豆荚的数量，并安排创建新豆荚的时间，如果其中一些豆荚下降以实现已定义的复制状态。

Kubelet

Kubelet是在集群的每个节点上运行的代理，它实现了执行容器的Pod和节点api。它负责监视容器并确保它们正在运行。它采用Pod规范并按规范执行容器。

Kube-proxy

Kube-proxy是支持服务抽象的组件。它代理客户端请求，并将其路由到节点中的pods，以负载均衡请求。

pod

pod是Kubernetes创建和部署的基本单元。它封装应用程序容器并在节点上运行它们。Pods是创建和销毁的可变对象。一个Pod表示应用程序的单个实例。它可以跨节点复制，以提供高可用性和弹性可伸缩性。

在定义pod时，可以为容器指定计算资源的分配。

服务

由于可以创建和销毁pods，因此需要有一种通过一个端点访问应用程序的机制。服务是一种抽象，它定义了一组逻辑单元，并将客户端流量路由到它们。豆荚可以创建、销毁、复制到多个节点，但客户端仍然可以通过服务访问后端豆荚。

Kube DNS Pod

Kube DNS是一个内置的服务，计划作为Pod在集群中运行。集群中的每个服务都是给定的DNS名称。服务可以通过它们的DNS名称来发现。

Kube DNS Pod有三个容器:kubedns、dnsmasdq和healthz。Kubedns一直关注Kubernetes master对服务的更改，并维护对服务DNS请求的内存中查找。Dnsmasdq增加缓存以提高性能，而healthz则监控kubedns和Dnsmasdq的健康状况。

自动伸缩功能

豆荚可以通过水平的豆荚自动缩放仪自动缩放。水平Pod Autoscaler不断地根据Autoscaler中定义的指标监视平均资源利用率，并根据情况复制更多的Pod或删除Pod。

Kubernetes作为托管服务

如果您不想建立和管理自己的Kubernetes集群，那么可以使用AWS、Azure和谷歌云上的托管服务。

其他部署选项

Docker Swarm

Kubernetes有很多分布式组件，它需要时间来设置和启动，但是它是开源的，并且有一个很大的社区来支持它。Kubernetes是一个特性丰富的解决方案，用于管理中到大型集群。Docker Swarm是另一个选择，它更容易设置有限的特性。它与Docker集成得很好，并且具有轻量级安装。

No Containers（不使用容器技术）

如果您不想沿着容器化及其编排的道路走下去，还有其他更简单的方法来实现微服务体系结构。如果可伸缩性需求不是internet规模，并且每个应用程序都可以管理有限的实体，那么您可以为逻辑分组的资源(例如OrderManagement API、产品API、登录API)构建一个每个资源的微服务或一个微服务，并将它们部署为独立的Spring引导应用程序(或节点)。js应用程序)。将这些无状态应用程序复制到几个节点上，并分别监视这些单独的进程。这种方法的缺点是无法限制每个应用程序的计算资源(内存除外)，但是可以使用类似NFRs的api并将它们部署到相同的节点上。通过这样做，如果需求增加或减少，您仍然可以通过复制vm来实现弹性可伸缩性。记住，这并不是真正的微服务，因为所有应用程序依赖项都不是打包和复制在一起的。这种方法确实提供了使用更精简的堆栈来部署和管理服务层的好处。

No Container Orchestration Platform

上述选项的另一个变体是包含应用程序，但不使用容器编排平台。此选项惟一的缺点是您必须手动管理容器。您仍然可以自信地自动伸缩和复制。Docker容器可以通过诸如New Relic、Logic Controller等系统管理工具进行监控。

安全

正如您可能已经注意到的，使用MSA，您必须为需要在组织网络之外访问的每个微服务打开一个网络端口。这意味着打开的港口太多，增加了攻击面。您应该通过反向代理或使用API网关层代理您的微服务。通过这种方式，您可以保护您的微服务不被公开到公共网络中，并且它们可以安全地驻留在企业防火墙之后。

结论

与传统的中间件平台相比，微服务当然有很多优势。部署和管理微服务的生态系统非常健壮。传统的中间件平台被边缘化以支持现有的和有限的用例。开发和部署这些小型微服务并让它们自动伸缩以满足具有挑战性的可伸缩性需求，这是一个令人兴奋的时