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-service
labels:
app: customer-service
spec:
ports:
- port: 18800
name: http
selector:
app: customer-service
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: customer-service
spec:
replicas: 1
selector:
matchLabels:
app: customer-service
template:
metadata:
labels:
app: customer-service
spec:
containers:
- name: customer-service
image: jcg-car-rentals/customer-service:0.0.1-SNAPSHOT
resources:
requests:
cpu: "200m"
imagePullPolicy: IfNotPresent
ports:
- containerPort: 18800
volumeMounts:
- name: config-volume
mountPath: /app/resources/META-INF/microprofile-config.properties
subPath: microprofile-config.properties
volumes:
- name: config-volume
configMap:
name: customer-service-config
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: customer-service-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: customer-service
spec:
hosts:
- "*"
gateways:
- customer-service-gateway
http:
- match:
- uri:
prefix: /api/customers
route:
- destination:
host: customer-service
port:
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 服务编排
所有评论(0)