dubbo k8s 服务发现_将Dubbo微服务迁移到k8s集群环境中前的思考与落地

将Dubbo微服务迁移到k8s中的思考与落地

说到容器化，不得不提kubernetes这个集群编排系统，它是一个开源系统，用于容器化应用的自动部署、扩缩和管理。

Kubernetes 将构成应用的容器按逻辑单位进行分组以便于管理和发现。 Kubernetes 基于自己公司的生产负载上的 15 年经验 打造，并融合了来自社区的最佳建议与实践。在2016年的时候，国外公司亚马逊，IBM这种大型公司，以及国内的阿里巴巴也都在自己原生对k8s进行了支持，近几年来，微服务也是非常的火热，说到微服务用的比较多的像spring cloud,spring boot,以及阿里开源的微服务框架dubbo，很多我们国内的公司也都是采用这种微服务的架构风格，也是由于传统的单体架构带来的一些问题，比如也有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。

相信也不是单单这几种问题，选择微服务，也是这种趋势，确实给我们的架构更清晰化，更好去管理更多的服务模块。

说说微服务为什么更适合容器化？

Netflix 云架构总监说微服务和 Docker 的结合是一种颠覆。Docker可以为微服务提供一个完美的运行环境。而kubernetes提供了这个集群编排系统，而容器可以轻松实现微服务化后的 DevOps。后面聊dubbo的时候再聊聊为什么微服务和k8s的关系，为什么dubbo更适合部署到k8s中。

说说Dubbo是什么？

Dubbo是阿里巴巴SOA服务化治理方案的核心框架，每天2000+个服务提供30亿+次访问量的支持，并广泛应用于阿里巴巴集团的个成员站点。也就是一个软件架构，也就是有很多互联网公司都在用这个Dubbo微服务，是一个非常好的微服务治理框架，

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

简单的说，dubbo就是一个服务框架，如果没有分布式的需求，其实是不需要用的， 只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是 个服务调用的东西，说白了就是个远程服务调用的分布式框架 ，而且dubbo和我们的k8s关系是非常紧密的，好像就是专门为k8s为生的，因为k8s也是一个分布式的基础服务框架，所以我们把dubbo微服务交付到k8s里是非常合适的

Dubbo能做什么

• 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。说白了就是dubbo是由消费者和提供者，消费者去消费提供者的方法，就好像调用本地方法一样，配置简单

• 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。 也就是dubbo提供负载均衡机制，比如一个提供者自己启动之后是自动注册的，它是由注册中心帮你调度，按照调度算法帮你调度给后端的提供者，无论你起了多少副本，不用关心是不是在负载均衡器上起的那些副本加上，它自己会加，他会提供这个负载均衡机制，而k8s呢也是这种思路，k8s定义一个service，后端的pod反正都是从这个service这个入口进去，dubbo和k8s设计的方法是不谋而合的。

• 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名 查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。 这个就非常重要了，无论是服务的提供者还是消费者，我们都需要注册中心，你现注册上，然后向外提供服务，找我的时候通过注册中心去找的

小结：三个最典型的特点

第一个就是完全透明的本地化调用

第二点就是负载均衡机制

第三点就是服务的自动注册与发现

然后看一下Dubbo的架构图

![]

Provider:暴露服务的服务提供方。 实际上提供者提供了一些过程调用的服务，是基于rpc机制调用方式的，Remote Procedure Call，比如提供一些计算服务，存储服务或者是一些跟数据库连接的一些服务，

Consumer: 调用远程服务的服务消费方。 主要是提供一些web接口，web页面主要提供一些ui层的一些服务，把后端重的一些服务都放在提供方去，然后调用的话，就是消费者去调用提供方，就好像调用本地方法一样，

Registry:服务注册与发现的注册中心。

Monitor: 统计服务的调用次调和调用 时间的监控中心。

Container: 服务运行容器。

下面说说具体的架构方案以及实现的方式

首先k8s环境集群这是首先齐要，一般这个肯定是自己要部署好的，另外就是你需要将你的k8s集群做成一个高可用的一个集群，这样的话，后续你去扩容还有你的环境比如master节点还有一个主控节点帮你去工作，这是首当其要，这里想必很多人也知道，另外要说就是你的pod的持久化，本身你的pod的生命周期就是非常短暂的，你的pod重启或者由于一些特殊的情况的话，那么你的pod的ip那么就会变了，所以这里在这个环境当中大家想必是要去考虑它本身的一个持久话的问题，比如你的jenkins这个要是在k8s中运行的话，那么就需要考虑它的一个工作目录,jenkins_home这个工作目录，也就是jenkins生成的文件，还有你的去拉代码的时候所产生的工作目录都会实地落到你的这个工作目录下的，这个目录你要是在k8s中去部署jenkins，我们就需要将这个工作目录采用这种持久化的这个功能将它共享挂载在我们的其他服务器中的一个目录当中，如果不去做持久化的话，你的工作目录当你的pod重启就会丢失，当然你的容器可能会用到一些维护的相关的命令，要是pod重启你的命令也是会丢失的，或者你想对这个容器做免登录的话，你是需要在你容器中去生成这个ssh-keygen的，这样的话，你容器重启这个目录也是会丢失的，将jenkins部署到k8s中也是可以，但是维护这个容器起来，还是相对来讲，比较麻烦的。

我们是将我们的jenkins部署到我们的单独一台服务器上。另外我们对jenkins使用的slave架构的方式可以用一台jenkins可以发布测试以及线上的环境。

部署到单独一台服务器的话，这里我是以这种war包的形式去启动的，这里我为了将我们的jenkins的工作目录进行修改，本身它这个工作目录是放在.jenkins下这个工作目录下的，所以我进行对它这个目录tomcat.catalina.sh的这个目录进行修改添加了export JENKINS_HOME=/opt/k8s/project这个共享目录下，并在你的环境变量中生效，启动你的war包这样的话，你的文件都会落地到这个共享存储中，这是我是使用的这个nfs，这个共享存储去做的这个。

其他这个共享存储也有很多，像这种的话，比如还有glusterFS,ceph,等等这些都是可以去做的。

然后接下来就是部署我们的coredns，这个主要也是来完成我们k8s的service的一个域进行解析的，比如我们去安装一个busybox的一个测试工具，可以去测试一下我们集群中的kubernetes.default，一般你的coredns还有你的网络CNI插件没问题的话，是可以正常去解析的，后面就是部署这个elk这个日志文件系统，这个的话，我是将它部署在k8s中的，也是为了方便管理，当然部署在外面也是可以的，我这里是使用的elasticsearch,filebeat，kibana，进行对我们微服务dubbo的项目进行对日志的收集的。

这里的话，这种pod类型也就是这种亲密性pod，也就是在一个pod中去部署两个容器。

然后通过这个filebeat在我们的容器中去部署，通过这个采集器去收集我们的日志，然后输出到es中，然后交给kibana来进行对我们dubbo微服务的日志进行输出，这是这一块。

另外就是我们对于我们的restful接口的一个对外的统一入口，这里我们是通过k8s中的cluster IP 进行发布，通过nginx做反向代理给我们的slb服务均衡器，提供一个公网地址对外统一入口。

然后就是使用jenkins去将我们的项目发布出去，部署到我们的k8s中，我们这里目前是使用的Jenkins配置自由式发布，每个项目的需求都不一样，我们使用写的脚本去发布的，或者你使用这种pipeline去发布这个也是可以的，因为我们是gitlab的形式去托管代码的，所以我们通过jenkins需要将对gitlab进行免交互登陆，第一在jenkins中ssh-keygen,生成id_rsa id_rsa.pub，一个是私钥一个是公钥，将这个私钥存放着jenkins上的key中，将pub这个公钥放到gitlab中的托管处就可以了， 配置git 执行参数化构建，选择maven，提前将所以的配置都部署好，jdk环境以及maven，放在/etc/profile下并执行好，然后构建执行后，在你项目下的target下面会有这个jar包，或者就是应用程序，我们这里是应用程序，我们将这个应用程序通过写dockerfile的形式将它封装成容器，然后给他一个jre环镜将这个服务部署进去，然后上传到我们的harbor仓库上，再通过k8s的yaml进行去执行，将我们的服务发布出去。