“没有最好的技术,只有最合适的技术。”我想这句话也同样适用于微服务领域,没有最好的服务框架,只有最适合自己的服务改造。在Dubbo的未来规划中,除了保持自身技术上的领先性,关注性能,大流量,大规模集群领域的挑战外,围绕Dubbo核心来发展生态,将Dubbo打造成一个服务化改造的整体方案也是重点之一。这是我们将推出“服务化改造”系列文章的第二篇,通过在一些外围系统和服务化基础组件上的开发实践,分享Dubbo生态下的服务化改造收获和总结。
大体上,Dubbo的Provider不再关心服务注册的事宜,只需要把其Dubbo服务端口打开,由Kubernetes来进行服务的声明和发布;Dubbo的Consumer在服务发现时直接发现Kubernetes的对应服务Endpoints,从而复用Dubbo已有的微服务通道能力。好处是无需依赖三方的软负载注册中心;同时无缝融入Kubernetes的多租户安全体系。Demo的代码参照:
http://gitlab.alibaba-inc.com/kongming.lrq/dubbo-kubernetes/tree/master
1
闲谈
Kubernates是建立在扩展性的具备二次开发的功能层次丰富的体系化系统上的:
来张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具有如下特点:
乍一看,Kubernetes的Service都是唯一的IP,在原有的Dubbo/HSF固定思维下:Dubbo/HSF的Service是有整个服务集群的IP聚合而成,貌似是有本质区别的,细想下来差别不大,因为Subernetes下的唯一IP只是一个VIP,背后挂在了多个Endpoint,那才是事实上的处理节点。
此处只讨论集群内的Dubbo服务在同一个Kubernetes集群内访问;至于Kubernetes外的Consumer访问Kubernetes内的Provider,涉及到网络地址空间的问题,一般需要GateWay/loadbalance来做映射转换,不展开讨论。针对Kubernetes内有两种方案可选:
以上两种思路都需要考虑以下两点
3
Demo验证
下面通过阿里云的容器镜像服务和EDAS中的Kubernetes服务来做一次Demo部署。
1. 访问阿里云-》容器镜像服务,创建镜像仓库并绑定Github代码库。如下图
2. 点击管理进行创建好的仓库,通过镜像服务下的构建功能,把Demo构建成image,并发布到指定仓库。如下图。
3. 切换到企业级分布式应用服务(EDAS)产品,在资源管理 - 》集群 下创建Kubernetes集群并绑定ECS,如下图。
4. 应用管理 -》创建应用,类型为Kubernetes应用 并且指定在容器镜像服务中的镜像。如下图。
5. 创建完成后,进行应用部署。如下图。
4
补充