溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
如何理解Rainbond插件體系設計，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。
過去幾年，利用容器打包和部署代碼的方式日益流行，越來越多企業開始測試或是已經在生產環境中運行了微服務架構應用，開始直接面對和解決分布式服務化架構演變中出現的各種問題。
在這樣的趨勢和大環境下，無服務器PaaS **Rainbond**圍繞著服務的拓展、監控、治理等角度，進行了一系列思考和嘗試，插件體系正是其中的重要一環。
Rainbond的插件體系抽象集中在平臺的業務層面，理論基礎源于Kubernetes的pod機制和一部分容器概念。針對平臺業務層面對kubernetes容器編排進行抽象，轉變為一個對用戶體驗友善的Rainbond插件產品的過程，方便用戶在不需要懂Kubernetes原理的情況下使用。
Rainbond插件體系的設計遵循易于理解和易于使用的原則：
在Rainbond插件體系中，插件使用的過程即主容器與init或sidecar等容器結合的過程，原理是將插件容器以sidecar容器（大部分）的形式編排至主應用的pod中，共享主應用容器的網絡和環境變量，因此可以插件化實現某些附加功能，例如對主應用進行流量分析等。
Pod是Kubernetes中模塊化容器服務的實例，由一個或多個共享資源的容器組合而成，共享包括文件系統、內核命名空間和IP地址等資源。它是Kubernetes集群中調度的原子單元，通過提供更高層次的抽象，實現靈活的部署和管理模式。
在以下Rainbond（www.rainbond.com）部署pod描述文件片段中，我們可以看到該pod中包含兩個containers：394d2f238a603bf01eb5215e23237691（主容器）與22dc8b12aeaf417fa7bd6466c136b9f4（副容器），兩者通過pod機制捆綁在一起，共同完成該server提供的服務。
kubectl describe pod -n b314b3e7e44e45a082a0d00e125e88bf b314b3e7e44e45a082a0d00e125e88bf Containers: 394d2f238a603bf01eb5215e23237691: Container ID: docker://44018fa19a268c1f9ea5b20e9793290cbd89b167bd1fc9017a04ecbd9606d379 Image: goodrain.me/tomcat:latest_gr237691 Image ID: docker-pullable://goodrain.me/tomcat@sha256:701d36cde0b55d07f59a65e525e258523aae46b033297f80b44b0b6c07fc0277 Port: 8080/TCP State: Running Started: Sun, 21 Jan 2018 14:56:35 +0800 Ready: True Restart Count: 0 Limits: cpu: 640m memory: 512Mi Requests: cpu: 120m memory: 512Mi 22dc8b12aeaf417fa7bd6466c136b9f4: Container ID: docker://4c8bd31c2ec2200ee323fb1abdd7b652544ce3d110b1621c36acab4bae434c77 Image: goodrain.me/tcm_20180117175939 Image ID: docker-pullable://goodrain.me/tcm_20180117175939@sha256:d2b20d7eec4da05d953fb7862b9c9ead76797ea5542bff4b93cf2bc98331d279 Port: State: Running Started: Sun, 21 Jan 2018 14:56:36 +0800 Ready: True Restart Count: 0 Limits: memory: 64Mi Requests: memory: 64Mi
一個pod可以封裝多個容器，應用運行在這些容器之中；同時，pod可以有一個或者多個init容器，init容器在應用容器啟動之前啟動。如果某個pod的init容器啟動運行失敗，Kubernetes將不斷重啟pod，直到init容器啟動運行成功為止。當然，我們可以設定pod restartPolicy值為Never，阻止它重復啟動。
利用pod中容器可以共享存儲和網絡的能力，sidecar容器得以擴展并增強“主要”容器，與之共存并使其工作得更好。在上面pod描述文件片段中，22dc8b12aeaf417fa7bd6466c136b9f4就是一個sidecar類型的容器，用來協助分析主容器的一些性能指標。
Rainbond插件體系易于使用的原則體現在類應用化、綁定使用、獨有的變量作用域等方面。
Rainbond插件體系為插件設計了與應用類似的生命周期，包含創建、啟用、關閉等模式，與Rainbond平臺用戶操作應用的習慣保持一致。同時，Rainbond插件體系簡化了插件創建類型，支持基于docker image和dockerfile創建，創建插件比創建應用更加簡單。
插件創建流程設計如下圖所示：
需要注意的是，當一個插件版本固定后，其內存、版本信息、插件變量無法再做修改，這些元素僅作用于當前插件版本。需要修改插件變量等元素時，對插件進行重新構建，重復創建流程即可。
插件的創建和使用過程步驟相對獨立，用戶可以使用當前租戶下創建的插件和其他團隊(或租戶)分享到云市的插件（初期Rainbond將陸續為用戶提供數款插件）。
如果用戶沒有創建自己的插件，在使用插件前，需要先將他人分享在云市的插件安裝至本地。這個過程會將分享出來的插件元數據存儲至用戶租戶下，相當于用戶“創建”了這個插件(并沒有耗時的構建過程)。
創建完成后，用戶可以對插件進行針對性設置，目前可以設置變量和插件生效與否(后續會增加內存設定，滿足主應用復雜情況下附加功能對應內存的需求)。內存的限制將在pod創建時進行限制，插件變量生效與實時修改在下文中會繼續介紹。
注入到容器內的變量設計為有兩類：共用變量與插件變量。
共用變量就是主容器的變量，為使插件參與甚至擴展主應用的功能，在pod創建過程中將主應用的環境變量注入到了插件容器中；插件變量則僅作用在該插件容器內部，防止插件間的變量重復與混用。
Rainbond目前默認為用戶提供性能分析和服務治理兩款插件，詳情訪問 http://www.rainbond.com/docs/stable/user-app-docs/myapps/myapp-platform-plugin.html 查看。
以下我們以網絡代理插件為例，介紹Rainbond插件體系的工作過程。
用戶填入插件相關信息后，Rainbond將根據這些信息生成插件創建任務，發送至Rainbond消息組件中，由任務發現器處理該任務消息。Rainbond的builder組件接受任務后，將會對插件進行構建，生成插件容器鏡像。一個插件容器鏡像對應一個構建版本，關聯其相應的功能特色。在Rainbond中，插件將以一個構建完成后的鏡像來進行流通。類似于應用，插件也可以在Rainbond及云市中進行分享。
參照插件使用文檔，在應用的插件tab中點擊安裝后，會對插件的當前最新版本與應用標記為關聯。此時重啟應用，在pod創建時，會對插件進行判斷，若存在插件，則進行PluginContainerCreate，pod的container list中將會包含主容器與插件容器。
網絡代理插件在Rainbond中又名servicemesh, 是一個功能增強容器，在pod中與主容器共享網絡。
網絡代理插件要完成其功能需要完全代理主容器的網絡, 接管主容器的出入口。結構如圖：
網絡代理分為出口網絡模式、入口網絡模式兩種。
出口網絡模式（示意圖中訪問tomcat應用為出口網絡模式），圖中service mesh2 plugin通過discover_service獲取tomcat應用的網絡信息，包括listen ports，routers，endpoints等。這些信息由discover_service通過watching kubernetes集群中tomcat應用的services和endpoints資源獲取。discover_service API相關請查看相關代碼 https://github.com/goodrain/rainbond/blob/master/pkg/node/api/router/discoverRouter.go
在service mesh2 plugin獲取所需的下游應用信息后則開始監聽本地對應tomcat的端口，代理當前應用訪問tomcat的請求，例如curl http://tomcat。
為何上述請求可以由pod內的容器代理呢？這是由于dns_service將tomcat這類規則域名解析至本地，路由及負載均衡則全權交由service mesh2 plugin進行，即客戶端負載均衡的模式。
入口網絡模式較之于出口模式類似（示意圖中由外網訪問進入main container為入口網絡模式），復雜之處在于是對當前應用用戶設置端口的轉發，由于本地監聽所以無法和主容器監聽相同的端口。
在處理這種場景時，將service mesh2 plugin的監聽端口進行了轉化，在開啟插件時會隨機生成一個不重復的端口port_outer1供給外層監聽，service mesh2 plugin繼續轉發主應用的原端口，在生成k8s的service和pod資源時由新端口替代原端口，并標注對應關系。
在外網負載均衡注冊這個應用的外網端口訪問時會使用port_outer1來進行注冊。分配給用戶使用的域名則基于原端口與新端口的映射規則保持不變，用戶并無感知
相關組件discover_service
用戶在控制臺將應用與插件首次關聯(安裝)后，插件就會對應當前應用產生配置。經由region端存儲至數據中心的etcd中。修改配置相應的設置，進行更新操作，則會修改對應服務的插件資源。
分布式服務化架構面臨的問題很多，想要實現服務化，服務治理是一個比較關鍵的點。在提供治理服務的基礎上，配置則需要實現實時生效和聯動。因此在rainbond設計中將插件的配置資源放置在了discover_service中，由該發現服務來支持動態配置。
在Kubernetes創建pod時，插件容器的env中注入了一個相關的環境變量DISCOVER_URL，該變量的值為插件可以通過GET請求獲取資源的url。后續用戶在使用平臺創建自己所需的功能插件時，這個變量也是你的插件獲取資源所必須的。
看完上述內容，你們掌握如何理解Rainbond插件體系設計的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
