java 服务编排

在这篇文章中，我们拥有一个全面的文章微服务针对Java开发：部署和协调。

1.简介

如今，越来越多的组织依靠云计算和托管服务产品来托管其服务。 这种策略有很多好处，但是您仍然必须为您的微服务团队选择最佳的部署游戏计划。

使用某种PaaS可能是最简单的选择，但从长远来看，由于这种模型具有固有的约束和局限性，因此从长远来看，这是不可持续的。 从另一方面来说，使用IaaS确实可以减轻基础架构管理和维护的成本，但是在部署应用程序和服务并使它们持续运行方面仍需要大量工作。 最后但并非最不重要的一点是，许多组织仍然更喜欢在内部管理其软件堆栈，仅将虚拟（或裸机）计算机管理工作转移给云提供商 。

决定哪种模型适合大多数组织的挑战很长一段时间仍未解决（总体上），等待某种突破发生。 幸运的是，“大爆炸”适时出现了。

2.容器

尽管种子已经播种很久了，但革命是由Docker发起的，它彻底改变了我们用来处理应用程序和服务的分发，部署和开发的方式。 游戏改变者以操作系统级虚拟化和容器的形式弹出。 它是一种非常轻量级的（与传统虚拟机相比 ）架构，几乎没有开销，共享相同的操作系统内核，并且不需要特殊的硬件支持即可有效地执行。

如今， 容器映像已成为事实上的打包和分发蓝图，而容器已成为主流的执行和隔离模型。 关于Docker和基于容器的虚拟化有很多话要说，特别是关于JVM平台上的应用程序和服务 ，但是在本教程的这一部分中，我们将重点关注部署和操作方面。

围绕容器的工具几乎可用于任何编程语言或平台，并且在大多数情况下，可以轻松地集成到构建和部署管道中。 例如，对于JCG租车平台， 客户服务部使用jib （更准确地说是jib-maven-plugin ）构建了容器映像，该容器映像可以组装和发布该映像，而无需Docker守护程序。

<plugin><groupId>com.google.cloud.tools</groupId><artifactId>jib-maven-plugin</artifactId><version>1.3.0</version><configuration><to><image>jcg-car-rentals/customer-service</image><tags><tag>${project.version}</tag></tags></to><from><image>openjdk:8</image></from><container><user>1000</user><mainClass>ws.ament.hammock.Bootstrap</mainClass></container></configuration>
</plugin>

那么我们现在可以用容器做什么？ 向基于容器的运行时的过渡催生了基础架构组件的新类别，即容器编排和管理。

3. Apache Mesos

我们将从Apache Mesos开始， Apache Mesos是用于细粒度资源共享的最古老且完善的开源平台之一。

Apache Mesos 从计算机（物理或虚拟）中提取CPU，内存，存储和其他计算资源，从而使容错和弹性的分布式系统易于构建和有效运行。 – http://mesos.apache.org/

严格来说， Apache Mesos不是容器编排器，更像是集群管理平台，但是不久前它还获得了对启动容器的原生支持。 与传统集群管理框架（例如Apache Helix ）有某些重叠，因此Apache Mesos通常被称为数据中心操作系统，以强调其更大的覆盖范围和范围。

4.Titus

Netflix的另一个开源项目Titus是专用容器管理解决方案的一个示例。

Titus 是一个容器管理平台，可提供可扩展且可靠的容器执行以及与Amazon AWS的云原生集成。 Titus 在Netflix内部建立，并在生产中用于驱动Netflix流，推荐和内容系统。 – https://netflix.github.io/titus/

本质上， Titus是基于Apache Mesos的框架。 毕竟 ，与AWS以及Spinnaker ， Eureka和Archaius的无缝集成使其非常适合。

5.Nomad民族

Nomad是HashiCorp的另一种开放源代码的宝石，是一种工作负载编排器，适用于部署微服务 ，批处理作业，容器化和非容器化应用程序的混合。

Nomad 是一种高度可用的分布式数据中心感知群集和应用程序调度程序，旨在通过支持长期运行的服务，批处理作业等来支持现代数据中心。 – https://www.nomadproject.io/

除了非常易于使用之外，它还与Consul和Vault进行了出色的本机集成，以补充服务发现和秘密管理 （我们在本教程的前面部分中进行了介绍）。

6. Docker Swarm

如果您是经验丰富的Docker用户，那么您可能会了解swarm ，这是一种特殊的Docker操作模式，用于本地管理Docker Engines集群。 这可能是编排容器化部署的最简单方法，但同时并未得到广泛采用。

7. Kubernetes

真正的宝石我们一直走到尽头。 Kubernetes基于在Google上运行生产工作负载15年的经验而建立，是一个开源，超人气且生产级的容器编排器。

Kubernetes （K8s）是一个开源系统，用于自动化容器化应用程序的部署，扩展和管理。 – https://kubernetes.io/

毫无疑问， 如今 ， Kubernetes是占主导地位的容器管理平台。 它实际上可以在任何基础架构上运行，并且不久之后我们将看到，所有主要的云提供商都提供了它 。

JCG租车平台将利用Kubernetes功能运行其所有微服务和支持组件（例如API网关和BFF ）。 尽管我们可以立即开始制作YAML清单，但还有另外一件事要谈。

Kubernetes 是用于构建平台的平台。 这是一个更好的起点。 不是结局。- https: //twitter.com/kelseyhightower/status/935252923721793536 ? lang = en

这是一个非常有趣的声明，这些天已经被OpenShift等平台和许多商业产品付诸实践。

8.服务网格

容器编排平台显着简化并改善了部署和操作实践，特别是与微服务有关的实践。 但是，服务和应用程序开发人员必须处理许多横切问题，例如安全通信，弹性，身份验证和授权，跟踪和监视等。 API网关减轻了一些负担，但是服务到服务的通信仍然很困难。 寻找可行的解决方案导致了服务网格的兴起。

服务网格是处理服务到服务通信的基础结构层，使应用程序不必了解复杂的通信网络。 网格提供高级功能，包括加密，身份验证和授权，路由，监视和跟踪。 – https://medium.com/solo-io/https-medium-com-solo-io-supergloo-ff2aae1fb96f

公平地说，服务网格就像救生员一样。 它们沿着所选的容器协调器部署，使组织可以继续专注于实现业务问题和功能，而网格则负责其余的工作。

服务网格是云原生应用程序的未来– https://medium.com/solo-io/https-medium-com-solo-io-supergloo-ff2aae1fb96f

野外有许多服务网格，它们已经相当成熟并且在生产中经过了考验。 让我们简要介绍一下其中的一些。

Linkerd

我们将从开源服务网格的先驱之一Linkerd开始。 它已成为管理，控制和监视服务到服务通信的专用层。 从那时起，它被重写并重新集中在Kubernetes集成上。

Linkerd 是一种超轻服务网 Kubernetes 。 它为您提供了可观察性，可靠性和安全性，而无需更改任何代码。 – https://linkerd.io/

“超光”的含义听起来并不重要，但实际上是。 您可能会对服务网格可能消耗多少群集资源感到惊讶，并且取决于您的部署模型，它可能会招致大量额外费用。

Istio

如果有每个人都听说过的服务网格，则很有可能是Istio 。

它是一个完全开源的服务网格，可以透明地分层到现有的分布式应用程序上。 它也是一个平台，包括使它们可以集成到任何日志记录平台，遥测或策略系统中的API。 Istio 的各种功能集使您能够成功，高效地运行分布式微服务体系结构，并提供统一的方式来保护，连接和监视微服务– https://istio.io/docs/concepts/what-is-istio /

尽管Istio通常与Kubernetes一起使用 ，但实际上它与平台无关。 例如，到目前为止，它可以与基于Consul的部署 （带有或不带有Nomad ）一起运行。

Istio周围的生态系统确实蓬勃发展。 社区的一项杰出贡献是Kiali ，它可以可视化服务网格拓扑并提供对功能的可见性，例如请求路由，断路器，请求速率，延迟等。

JCG租车平台对服务网格的需求显而易见，我们将部署Istio来弥补这一差距。 这是使用Is t io和先前构建的容器映像为客户服务提供的Kubernetes部署清单的简单示例。

apiVersion: v1
kind: Service
metadata:name: customer-servicelabels:app: customer-service
spec:ports:- port: 18800name: httpselector:app: customer-service---apiVersion: apps/v1
kind: Deployment
metadata:name: customer-service
spec:replicas: 1selector:matchLabels:app: customer-servicetemplate:metadata:labels:app: customer-servicespec:containers:- name: customer-serviceimage: jcg-car-rentals/customer-service:0.0.1-SNAPSHOTresources:requests:cpu: "200m"imagePullPolicy: IfNotPresentports:- containerPort: 18800volumeMounts:- name: config-volumemountPath: /app/resources/META-INF/microprofile-config.propertiessubPath: microprofile-config.propertiesvolumes:- name: config-volumeconfigMap:name: customer-service-config---apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:name: customer-service-gateway
spec:selector:istio: ingressgatewayservers:- port:number: 80name: httpprotocol: HTTPhosts:- "*"---apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: customer-service
spec:hosts:- "*"gateways:- customer-service-gatewayhttp:- match:- uri:prefix: /api/customersroute:- destination:host: customer-serviceport:number: 18800

领事连接

从教程的上半部分我们知道， Consul最初是作为服务发现和配置存储的。 Consul最近新增的功能之一是Connect功能，该功能允许其进入服务网格的空间。

Consul Connect 使用相互传输层安全性（TLS）提供服务到服务的连接授权和加密。 应用程序可以 在服务网格配置中 使用 sidecar代理 来自动为入站和出站连接建立TLS连接，而根本不知道Connect。 – https://www.consul.io/docs/connect/index.html

领事已经为每个服务网格提供了理想的基础，添加缺失的功能是适应这种快速变化的形势的逻辑步骤。

SuperGloo

有了许多可用的服务网格，现在还不清楚哪一种是您的微服务的最佳选择，以及如何部署和操作它？ 如果这是您当前面临的问题，则可以查看服务网格编排平台SuperGloo 。

SuperGloo ，一个开源项目，用于大规模管理和协调服务网格。 SuperGloo 是经过 深思熟虑 的抽象层，无论您是在现场，在云中还是在任何拓扑上使用（或计划使用）单个网格或多种 网格技术 ，都可以简化服务网格的安装，管理和操作最适合您 – https://supergloo.solo.io/

从服务网格的角度来看， SuperGloo当前（ 在某种程度上 ）支持Istio ， Consul Connect ， Linkerd和AWS App Mesh 。

在同一主题上，最近宣布了更广泛的服务网格接口 （ SMI ）规范，这是一项旨在将不同的服务网格实现对齐的倡议，以便可以互换使用。 。

9.云

整个行业向基于容器的部署的转变迫使云提供商提出了相关的产品。 到目前为止，云业务中的每个主要参与者都已经管理了Kubernetes产品以及服务网格。

Google Kubernetes引擎（GKE）

自从Kubernetes诞生于Google并凭借其管理全球最大的计算集群的经验以来， Google Cloud对其提供了出色的支持是很自然的。 确实如此， 谷歌的Kubernetes引擎 （ GKE ）是托管在Google Cloud中的完全托管的Kubernetes平台。

Kubernetes Engine 是一个托管的，可用于生产环境的环境，用于部署容器化的应用程序。 它带来了我们在开发人员生产力，资源效率，自动化操作和开源灵活性方面的最新创新，以加快您的上市时间。 – https://cloud.google.com/kubernetes-engine/

至于服务网格， Google Cloud通过Istio在 Kubernetes Engine的 GKE附加组件上提供Istio支持（当前为beta ）。

Amazon Elastic Kubernetes服务（EKS）

相当长一段时间以来， AWS以Amazon Elastic Container Service （ ECS ）的形式提供运行容器化应用程序的支持。 但是自去年以来， AWS宣布了Amazon Elastic Kubernetes服务 （ EKS ）的全面可用性 。

Amazon EKS 在多个AWS可用区中为您运行Kubernetes管理基础架构，以消除单点故障。 – https://aws.amazon.com/eks/

从服务网格方面来看，您可以使用可与Amazon Elastic Kubernetes Service一起使用的AWS App Mesh 。 它由Envoy服务代理提供支持。

Azure容器服务（AKS）

Microsoft Azure云遵循类似于AWS的方法，首先提供Azure容器服务 （顺便说一句，它可以与Kubernetes或Docker Swarm一起部署），然后不推荐使用Azure容器服务 （ AKS ）。

完全托管的 Azure Kubernetes服务 （ AKS ）使部署和管理容器化的应用程序变得容易。 它提供了无服务器的Kubernetes，集成的持续集成和持续交付（CI / CD）体验以及企业级安全性和治理。 – https://azure.microsoft.com/zh-cn/services/kubernetes-service/

有趣的是，截至本文撰写之时， Microsoft Azure Cloud尚未将任何服务网格的支持与其Azure Kubernetes Service产品捆绑在一起，但可以按照手动步骤在IKS上安装Istio组件 。

Rancher

您的微服务舰队极不可能部署在一个Kubernetes集群中。 至少，您可能有生产和暂存的，最好将它们分开。 如果您关心客户，那么您可能会考虑高可用性和灾难恢复，这实际上意味着多区域或多云部署。 除非您了解Rancher ，否则在广泛的环境中管理许多Kubernetes集群可能既麻烦又困难。

Rancher 是供采用容器的团队使用的完整软件堆栈。 它解决了在任何基础架构上管理多个Kubernetes集群的运营和安全挑战，同时为DevOps团队提供了用于运行容器化工作负载的集成工具。 – https://rancher.com/what-is-rancher/overview/

总的来说， Rancher成为一个可操作您的Kubernetes集群的单一平台，包括托管云产品甚至是裸机服务器。

10.部署和编排–结论

在本教程的这一部分中，我们讨论了基于容器的部署和编排。 尽管如此，桌上还是有一些选择可以说， Kubernetes是当今事实上的选择，这是有充分理由的。 尽管不是严格要求的，但是服务网格的存在将极大地减轻微服务运营问题的某些麻烦，并让您专注于对业务重要的事情。

11.接下来

在本教程的下一部分中，我们将讨论日志管理，合并和聚合。

翻译自: https://www.javacodegeeks.com/2019/07/microservices-java-devs-deployment-orchestration.html

java 服务编排