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

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

第一篇回顾:Dubbo + ZooKeeper

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

http://gitlab.alibaba-inc.com/kongming.lrq/dubbo-kubernetes/tree/master

1

闲谈

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

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

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

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

借用如下图做一个简单描述。

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

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

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的基础能力而并解决微服务相关核心问题也算是一种狭义上的Servie Mesh方案,只是是Java领域的罢了;当玩笑理解也行,哈哈。

2

思路和方案

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聚合而成,貌似是有本质区别的,细想下来差别不大,因为Subernetes下的唯一IP只是一个VIP,背后挂在了多个Endpoint,那才是事实上的处理节点。

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

  • DNS: 默认Kubernetes的Service是靠DNS插件(最新版推荐是coreDNS), Dubbo上有个Proposal是关于这个的。我的理解是static resolution的机制是最简单最需要支持的一种Service Discovery机制,具体也可以参考Envoy在此的观点,由于HSF/Dubbo一直突出其软负载的地址发现能力,反而忽略Static的策略。同时蚂蚁的SOFA一直是支持此种策略,那一个SOFA工程的工程片段做一个解释。这样做有两个好处,1)当软负载中心crash不可用造成无法获取地址列表时,有一定的机制Failover到此策略来处理一定的请求。 2)在LDC/单元化下,蚂蚁的负载中心集群是机房/区域内收敛部署的,首先保证软负载中心的LDC化了进而稳定可控,当单元需要请求中心时,此VIP的地址发现就排上用场了。
  • API:DNS是依靠DNS插件进行的,相当于额外的运维开销,所以考虑直接通过Kubernetes的Client来获取Endpoint。事实上,通过访问Kubernetes的API Server接口是可以直接获取某个Servie背后的Endpoint列表,同时可以监听其地址列表的变化。从而实现Dubbo/HSF所推荐的软负载发现策略。具体可以参考代码。

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

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

3

Demo验证

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

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

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

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

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

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

4

补充

  • 应用名不能有大写字母,是要小写,否则有部署失败的问题。
  • 在创建应用时,选中镜像后,下一步的按钮无法点击,需要点击选择继续。
  • EDAS有两套独立的Kubernetes服务,一套是基于阿里云的容器服务,一套是Lark自己搞的。本人体验的是后者。
  • Docker与IDE集成的开发联调,需要考虑集成IDEA的相关插件。

原文发布于微信公众号 - 云计算与大数据(heidcloud)

原文发表时间:2018-11-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏程序员与猫

单元测试之道

标签: 单元测试 前言 系列 1. 前言 在一个项目当中,开发者常常要做大量的测试工作,如单元测试,集成测试,回归测试,压力测试 .etc。当然,依据项目情况大...

1846
来自专栏IT技术精选文摘

ZStack 的伸缩性秘密(一)异步架构

ZStack 核心架构设计使得 99% 的任务异步执行,因此确保了单个的管理节点能够管理十万级的物理服务器,百万级的虚拟机,数万级的并行任务。

1212
来自专栏腾讯Bugly的专栏

Luakit的前世今生

最近发布了一个跨平台的app开发框架Luakit。那怎么会想到做这样一个东西呢?

3684
来自专栏SDNLAB

SDNLAB技术分享(二):从Toaster示例初探ODL MD-SAL架构

Toaster是wiki上的一个例子。通过学习它,我们可以了大致了解MD-SAL架构的实现原理和设计思想。下面我们就直奔主题,看看Toaster例子吧。例子原文...

37910
来自专栏何俊林

微信小程序—仿芒果TV(已开源)

前言:1月9号(今天)是小程序上线的日子,各厂小程序,纷纷在线上发布,便用极其便捷,下面我体验的腾讯视频,及大众点评的小程序。 腾讯视频 ? 大众点评 ? 很...

3385
来自专栏美团技术团队

“小众”之美——Ruby在QA自动化中的应用

2043
来自专栏何俊林

FFmpeg总结(十二)用ffmpeg与nginx实现直播多路流并发播放

图:撒哈拉沙漠 下载 nginx 和 nginx-rtmp源码: http://nginx.org/download/nginx-1.5.10.tar.gz ...

39110
来自专栏java一日一条

13个不容错过的Java项目

GitHub可谓一座程序开发的大宝库,有些素材值得fork,有些则能帮助我们改进自有代码或者学习编程技能。无论如何,开发工作当中我们几乎不可能绕得开GitHub...

6251
来自专栏申龙斌的程序人生

零基础学编程027:站在巨人的肩膀上

在《零基础学编程021:获取股票实时行情数据》这一节里,我们利用urllib抓取新浪财经中的股票数据,可以取出谷歌股票的开盘价,回顾一下代码: import u...

3506
来自专栏java一日一条

Facebook移动架构:Android Flux架构详解

要为Android应用找到一个好的架构不是一件容易的事情。谷歌似乎不太在乎这个事情,因此在设计模式上,除了Activity 生命周期管理之外,再也没有官方的推荐...

611

扫码关注云+社区

领取腾讯云代金券