將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進行去執行，將我們的服務發布出去。