服务化改造实践(二)| Dubbo + Kubernetes

简介: “没有最好的技术,只有最合适的技术。”我想这句话也同样适用于微服务领域,没有最好的服务框架,只有最适合自己的服务改造。在Dubbo的未来规划中,除了保持自身技术上的领先性,关注性能,大流量,大规模集群领域的挑战外,围绕Dubbo核心来发展生态,将Dubbo打造成一个服务化改造的整体方案也是重点之一。

_2018_09_07_9_40_07

“没有最好的技术,只有最合适的技术。”我想这句话也同样适用于微服务领域,没有最好的服务框架,只有最适合自己的服务改造。在Dubbo的未来规划中,除了保持自身技术上的领先性,关注性能,大流量,大规模集群领域的挑战外,围绕Dubbo核心来发展生态,将Dubbo打造成一个服务化改造的整体方案也是重点之一。这是我们将推出“服务化改造”系列文章的第二篇,通过在一些外围系统和服务化基础组件上的开发实践,分享Dubbo生态下的服务化改造收获和总结。

第一篇回顾:Dubbo + ZooKeeper

大体目标

大体上:Dubbo的provider不在关心服务注册的事宜,只需要把其Dubbo服务端口打开,由kubernetes来进行服务的声明和发布;Dubbo的consumer在服务发现时直接发现kubernetes的对应服务endpoints,从而复用Dubbo已有的微服务通道能力。好处是无需依赖三方的软负载注册中心;同时无缝融入kubernetes的多租户安全体系。

闲淡

Kubernates是建立在扩展性的具备二次开发的功能层次丰富的体系化系统

  • 首先其最核心的功能是管理容器集群,能管理容器化的集群(包括存储,计算),当然这个是建立在对容器运行时(CRI),网络接口(CNI),存储服务接口(CSI/FV)的基础上;
  • 其次是面向应用(包括无状态/有状态,批处理/服务型应用)的部署和路由能力,特别是基于微服务架构的应用管理,具备了其服务定义和服务发现,以及基于configmap的统一配置能力;
  • 在基础资源(主要是抽象底层IaaS的资源)和应用层的抽象模型之上是治理层,包含弹性扩容,命名空间/租户,等。当然,基于其原子内核的基础能力,在Kubernetes的核心之上搭建统一的日志中心和全方位监控等服务是水到渠成的,CNCF更是有其认定推荐。

来张Kubernetes Architecture的一张图解释下上述描述。在2018年Kubernetes往事实的paas底座的标配迈出质的一步,有人说原因在于基于扩展的二次开发能力,有人说在于其声明式编程和背靠Google和Redhat的强大社区运作,我觉得回归本质是在于下图中的Layered架构和其问题域的领域建模抽象

无标题.png | center | 747x399

以微服务架构视角,Kubernetes在一定意义上是微服务框架(这时较叫微服务平台或toolkit集更合适),支持微服务的服务发现/注册的基本能力。借用如下图做一个简单描述。

16dcf318fcebcba9d81b74761583ba87.jpg | center | 747x289

话题再展开一下,微服务领域涉及众多问题,大概可以用下图说明。

16_34_47__07_02_2018.jpg | center | 747x523

kubernetes解决得只是少部分,而像动态路由,稳定性控制(断路器,隔水舱等),分布式服务追踪等是个空白,这也就是servicemesh要解决的,是在CNCF的Trail Map占有重要一席;当然Dubbo是基本具备完备的微服务,也就是使得其集成到k8s体系下具有相当的意义。Dubbo在serviemesh中基于sidecar的方案是解决跨语言诉求的通用servicemesh方案,需要新开一个话题来展开说;

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application.

首先服务网格是一个云原生环境下基础设施层,功能在于处理服务间通信,职责是负责实现请求的可靠传递,被使得被监控跟踪,被治理,最终使得微服务架构被赋予高可控的稳定性和快速的问题定位排查能力。

可以得出现有Dubbo集成云原生基础设施kubernetes的基础能力而并解决微服务相关核心问题也算是一种狭义上的servicemesh方案,只是是Java领域的罢了;当玩笑理解也行,哈哈。

思路/方案

kubernetes是天然可作为微服务的地址注册中心,类似于zookeeper, 阿里巴巴内部用到的VIPserver,Configserver。 具体来说,kubernetes中的Pod是对于应用的运行实例,Pod的被调度部署/启停都会调用API-Server的服务来保持其状态到ETCD;kubernetes中的service是对应微服务的概念,定义如下

A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.

概括来说kubernetes service具有如下特点

  • 每个Service都有一个唯一的名字,及对应IP。IP是kubernetes自动分配的,名字是开发者自己定义的。
  • Service的IP有几种表现形式,分别是ClusterIP,NodePort,LoadBalance,Ingress。 ClusterIP主要用于集群内通信;NodePort,Ingress,LoadBalance用于暴露服务给集群外的访问入口。

乍一看,kubernetes的service都是唯一的IP,在原有的Dubbo/HSF固定思维下:Dubbo/HSF的service是有整个服务集群的IP聚合而成,貌似是有本质区别的,细想下来差别不大,因为kubernetes下的唯一IP只是一个VIP,背后挂在了多个endpoint,那才是事实上的处理节点。

此处只讨论集群内的Dubbo服务在同一个kubernetes集群内访问;至于kubernetes外的consumer访问kubernetes内的provider,涉及到网络地址空间的问题,一般需要GateWay/loadbalance来做映射转换,不展开讨论。针对kubernetes内有两种方案可选:

  1. DNS: 默认kubernetes的service是靠DNS插件(最新版推荐是coreDNS), Dubbo上有个proposal是关于这个的。我的理解是static resolution的机制是最简单最需要支持的一种service discovery机制,由于HSF/Dubbo一直突出其软负载的地址发现能力,反而忽略Static的策略。同时蚂蚁的SOFA一直是支持此种策略,那一个SOFA工程的工程片段做一个解释。这样做有两个好处,1)当软负载中心crash不可用造成无法获取地址列表时,有一定的机制Failover到此策略来处理一定的请求。 2)在LDC/单元化下,蚂蚁的负载中心集群是机房/区域内收敛部署的,首先保证软负载中心的LDC化了进而稳定可控,当单元需要请求中心时,此VIP的地址发现就排上用场了。

无标题.png | center | 747x162

  1. API:DNS是依靠DNS插件进行的,相当于额外的运维开销,所以考虑直接通过kubernetes的client来获取endpoint。事实上,通过访问kubernetes的API server接口是可以直接获取某个servie背后的endpoint列表,同时可以监听其地址列表的变化。从而实现Dubbo/HSF所推荐的软负载发现策略。具体可以参考代码:

以上两种思路都需要考虑以下两点

  1. kubernetes和Dubbo对于service的名字是映射一致的。Dubbo的服务是由serviename,group,version三个来确定其唯一性,而且servicename一般其服务接口的包名称,比较长。需要映射kubernetes的servie名与dubbo的服务名。要么是像SOFA那样增加一个属性来进行定义,这个是改造大点,但最合理;要么是通过固定规则来引用部署的环境变量,可用于快速验证。
  2. 端口问题。默认Pod与Pod的网络互通算是解决了。需要验证。

Demo验证

下面通过阿里云的容器镜像服务和EDAS中的kubernetes服务来做一次Demo部署。

  1. 访问阿里云-》容器镜像服务,创建镜像仓库并绑定github代码库。如下图

无标题.png | center | 826x380

  1. 点击管理进行创建好的仓库,通过镜像服务下的构建功能,把demo构建成image,并发布到指定仓库。如下图。

无标题.png | center | 826x392

  1. 切换到企业级分布式应用服务(EDAS产品,在资源管理 - 》集群 下创建kubernetes集群并绑定ECS,如下图.

无标题.png | center | 826x370

  1. 应用管理 -》创建应用,类型为kubernetes应用 并且指定在容器镜像服务中的镜像。如下图。

无标题.png | center | 826x280

无标题.png | center | 826x391

  1. 创建完成后,进行应用部署。如下图

无标题.png | center | 826x350

补充

  • 应用名不能有大写字母,是要小写,否则有部署失败的问题。
  • 在创建应用时,选中镜像后,下一步的按钮无法点击,需要点击选择继续。
  • EDAS有两套独立的kubernetes服务,一套是基于阿里云的容器服务,一套是Lark自己搞的。本人体验的是后者。
  • Docker与IDE集成的开发联调,需要考虑集成IDEA的相关插件。
相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
5月前
|
存储 负载均衡 测试技术
ACK Gateway with Inference Extension:优化多机分布式大模型推理服务实践
本文介绍了如何利用阿里云容器服务ACK推出的ACK Gateway with Inference Extension组件,在Kubernetes环境中为多机分布式部署的LLM推理服务提供智能路由和负载均衡能力。文章以部署和优化QwQ-32B模型为例,详细展示了从环境准备到性能测试的完整实践过程。
|
6月前
|
存储 人工智能 Kubernetes
ACK Gateway with AI Extension:面向Kubernetes大模型推理的智能路由实践
本文介绍了如何利用阿里云容器服务ACK推出的ACK Gateway with AI Extension组件,在Kubernetes环境中为大语言模型(LLM)推理服务提供智能路由和负载均衡能力。文章以部署和优化QwQ-32B模型为例,详细展示了从环境准备到性能测试的完整实践过程。
|
6月前
|
存储 人工智能 物联网
ACK Gateway with AI Extension:大模型推理的模型灰度实践
本文介绍了如何使用 ACK Gateway with AI Extension 组件在云原生环境中实现大语言模型(LLM)推理服务的灰度发布和流量分发。该组件专为 LLM 推理场景设计,支持四层/七层流量路由,并提供基于模型服务器负载感知的智能负载均衡能力。通过自定义资源(CRD),如 InferencePool 和 InferenceModel,可以灵活配置推理服务的流量策略,包括模型灰度发布和流量镜像。
|
10月前
|
Kubernetes 持续交付 开发者
探索并实践Kubernetes集群管理与自动化部署
探索并实践Kubernetes集群管理与自动化部署
383 93
|
7月前
|
Kubernetes 监控 Serverless
基于阿里云Serverless Kubernetes(ASK)的无服务器架构设计与实践
无服务器架构(Serverless Architecture)在云原生技术中备受关注,开发者只需专注于业务逻辑,无需管理服务器。阿里云Serverless Kubernetes(ASK)是基于Kubernetes的托管服务,提供极致弹性和按需付费能力。本文深入探讨如何使用ASK设计和实现无服务器架构,涵盖事件驱动、自动扩展、无状态设计、监控与日志及成本优化等方面,并通过图片处理服务案例展示具体实践,帮助构建高效可靠的无服务器应用。
|
7月前
|
监控 Kubernetes Cloud Native
基于阿里云容器服务Kubernetes版(ACK)的微服务架构设计与实践
本文介绍了如何基于阿里云容器服务Kubernetes版(ACK)设计和实现微服务架构。首先概述了微服务架构的优势与挑战,如模块化、可扩展性及技术多样性。接着详细描述了ACK的核心功能,包括集群管理、应用管理、网络与安全、监控与日志等。在设计基于ACK的微服务架构时,需考虑服务拆分、通信、发现与负载均衡、配置管理、监控与日志以及CI/CD等方面。通过一个电商应用案例,展示了用户服务、商品服务、订单服务和支付服务的具体部署步骤。最后总结了ACK为微服务架构提供的强大支持,帮助应对各种挑战,构建高效可靠的云原生应用。
|
7月前
|
监控 Cloud Native Java
基于阿里云容器服务(ACK)的微服务架构设计与实践
本文介绍如何利用阿里云容器服务Kubernetes版(ACK)构建高可用、可扩展的微服务架构。通过电商平台案例,展示基于Java(Spring Boot)、Docker、Nacos等技术的开发、容器化、部署流程,涵盖服务注册、API网关、监控日志及性能优化实践,帮助企业实现云原生转型。
|
9月前
|
人工智能 运维 监控
阿里云ACK容器服务生产级可观测体系建设实践
本文整理自2024云栖大会冯诗淳(花名:行疾)的演讲,介绍了阿里云容器服务团队在生产级可观测体系建设方面的实践。冯诗淳详细阐述了容器化架构带来的挑战及解决方案,强调了可观测性对于构建稳健运维体系的重要性。文中提到,阿里云作为亚洲唯一蝉联全球领导者的容器管理平台,其可观测能力在多项关键评测中表现优异,支持AI、容器网络、存储等多个场景的高级容器可观测能力。此外,还介绍了阿里云容器服务在多云管理、成本优化等方面的最新进展,以及即将推出的ACK AI助手2.0,旨在通过智能引擎和专家诊断经验,简化异常数据查找,缩短故障响应时间。
阿里云ACK容器服务生产级可观测体系建设实践
|
9月前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
阿里云容器服务ACK提供强大的产品能力,支持弹性、调度、可观测、成本治理和安全合规。针对拥有IDC或三方资源的企业,ACK One分布式云容器平台能够有效解决资源管理、多云多集群管理及边缘计算等挑战,实现云上云下统一管理,提升业务效率与稳定性。
|
10月前
|
Kubernetes Cloud Native 微服务
云原生入门与实践:Kubernetes的简易部署
云原生技术正改变着现代应用的开发和部署方式。本文将引导你了解云原生的基础概念,并重点介绍如何使用Kubernetes进行容器编排。我们将通过一个简易的示例来展示如何快速启动一个Kubernetes集群,并在其上运行一个简单的应用。无论你是云原生新手还是希望扩展现有知识,本文都将为你提供实用的信息和启发性的见解。

推荐镜像

更多