1.關于柯基資料
南京柯基資料科技有限公司成立于2015年，提供一站式全生命周期知識圖譜建構和運維、智能應用服務，緻力于“連結海量資料，從大資料中挖掘智慧“。幫助企業運用知識圖譜技術打造世界領先的認知工作自動化智能引擎。
目前在藥企、醫療機構、軍工院所、科技情報及出版等領域服務了數十家大客戶，積累了豐富的行業知識圖譜運用開發經驗。典型客戶有國防科技大學、中國航空、中國電科等。
2.柯基資料的雲原生之路
大家好，我是南京柯基資料的解決方案架構師劉占峰，雲原生技術在傳遞運維上的優勢讓我獲益匪淺。作為項目合作夥伴，Rainbond持續助力柯基多套業務系統的快速開發和傳遞部署。在使用Rainbond之前，由于業務疊代周期短，涉及元件多，平台版本更新耗時耗力，服務運維難度大。很多項目中，客戶的運維能力儲備不足，基于傳統的傳遞和管理方式，客戶對于業務運維根本接管不起來，隻要風吹草動，必須要我們派工程師到現場解決。針對傳遞運維存在的問題，各個業務平台開始着手雲原生改造。最開始我們嘗試自己搭建公司内部的開發測試環境，過程中遇到的兩個小坑。
第一個坑是：環境搭建完成後使用體驗卻不佳，所有涉及到磁盤讀寫的操作都顯得異常卡頓，叢集中的 Etcd 叢集日志中不斷報告處于 “read_only” 狀态，随之而來的是伺服器負載的不斷飙升。
我們帶着懷疑的心情求助了Rainbond開源社群，經過多方面的排查，我們把目光落在了磁盤的IO性能上。替換了高性能的磁盤之後，我們重新安裝了整個開發測試環境，磁盤性能的提升的确解決了 Etcd 叢集時常不工作的問題。第二個坑是：使用了共享存儲的服務卻依然處于讀寫極慢的狀态，這着實令在場的所有工程師又開始頭大了。确認了硬體性能之後，開始将目光放在作業系統配置參數上面，作業系統核心在不斷報告與共享存儲有關的錯誤：
NFS:\_\_nfs4\_reclaim\_open\_state: Lock reclaim failed!指征 nfs client 和 nfs server 之間存在同步差異，差得多了就會開始報警。經過不斷摸索，工程師們終于鎖定了與 nfs 性能有關的兩個系統參數，Linux nfs 用戶端對于同時發起的NFS請求數量進行了控制，若該參數配置較小會導緻 IO 性能較差。
修改了這兩個參數後，共享存儲的性能得到了顯著的提升，令人摸不到頭腦的核心報警資訊也随之消失。開發測試環境終于可以順暢使用了。接下來面臨新的挑戰是如何将我們的多套業務系統順利遷移到 Rainbond 上去，所幸Rainbond 的使用很簡單，整體學習梯度并不陡峭，我們很輕松把業務系統分批的部署在 Rainbond 上去。然而 Rainbond 工程師組織的雲原生應用評估卻指出了業務系統有多處不符合雲原生特征之處，提出了一些整改意見。在整改過程中，我們對雲原生也有了更深入了解。
Elasticsearch等有狀态元件需要将元件部署類型調整成為有狀态單執行個體或有狀态多執行個體，不可以是無狀态
我們最開始并不了解什麼是有\\無狀态元件，是以并沒有注意區分元件的部署類型。Rainbond工程師提示我們，Elasticsearch在Rainbond平台中應該使用有狀态的元件部署類型進行部署。
> L1級雲原生應用特征——可伸縮性
>
> 雲原生應用注重部署元件所使用的資源類型，像資料庫類型、消息隊列類型的服務元件對在Rainbond平台上，應該使用StatefulSet資源類型進行部署。通過對服務元件定義有狀态或者無狀态的部署類型，來規定使用StatefulSet或Deployment資源類型來部署執行個體。
支援橫向伸縮
我們的多套業務系統，在接觸雲原生改造之前，都是傳統的單體架構，部署時也基本不考慮高可用特性。這使我們的業務系統相對而言脆弱許多，沒有任何容錯能力，一旦伺服器當機，整個業務系統就失去了服務能力。雲原生改造的過程中，我們借助于Rainbond天然的微服務能力，非常輕松的将我們的業務系統拆分成為更為合理的微服務架構。更令我們驚喜的是，這些拆分出來的微服務元件，大多數直接具備了橫向伸縮的能力，借助Rainbond的一鍵伸縮能力，迅速擴充成為多執行個體的叢集，極大的提高了系統的可用性。而針對某幾個不可以一鍵伸縮的元件，Rainbond工程師們也提供了合理的意見，引導我們對這幾個特殊的元件進行修改，使之實作了“無狀态化”。現在，經過雲原生改造的業務具備了“小強”一般頑強的生命力，再也不怕伺服器當機了。
> 通過程式資料分離等手段，實作應用程式的無狀态化，就讓雲原生應用可以随意橫向伸縮多個執行個體。執行個體數量的伸縮一方面使雲原生應用具備了高可用性，也直接影響其抗并發的能力。Rainbond還提供自動伸縮功能，實作削峰填谷。
所有配置支援環境變量配置，形如 <code>${GATEWAY_PORT:8083}</code>
以往我們都将服務的配置項寫成固定的值，這樣的做法使得我們每到一個新的部署環境，都要重新更改大量的配置檔案。Rainbond工程師指出，雲原生應用應該将配置儲存到環境當中，以環境變量加預設值的方式聲明出來。而大多數需要修改的配置項，如不同元件之間的連接配接位址資訊，就可以通過Rainbond依賴關系中的連接配接資訊來互相注入，省去了大量的配置工作。
> L1級雲原生應用特征——可配置性
> 雲原生應用推崇的一種最佳實踐，就是将配置儲存在環境之中。在不同的運作環境中，利用環境變量來進行配置，是一種非常好的體驗。Rainbond支援為每個服務元件設定環境變量，也可以基于配置組功能，批量配置環境變量。
元件主要端口通過環境變量 ${PORT} 定義
Rainbond工程師提供了一個小技巧，将元件監聽端口的配置，用一個固定的環境變量來配置，這個變量的值會随着我們在Rainbond控制台上手動添加的端口号來自動變更，這樣，我們就可以在不更改代碼和配置的情況下，随意變更想要監聽的端口号，這很友善。
> 作為對環境變量的補充，Rainbond提供了一系列可以自動生成的環境變量，這些特定的環境變量極大友善了使用者的使用。
所有元件需要統一時區
統一所有元件的時區配置是非常有必要的，Rainbond工程師提供了一個技巧，讓時區的設定變成了一個很簡單的事情。隻需要運作環境的鏡像中包含
<code>tzdata</code> 軟體包，我們就可以基于 <code>TZ=Asia/shanghai</code> 這樣一個環境變量的配置，完成時區的配置了。
> L1級雲原生應用特征——基礎可觀測性
> 統一時間在運維領域十分重要，在雲原生領域，時區的配置也可以基于環境變量進行配置。
所有業務需要定義健康檢查政策
Rainbond工程師要求我們為所有的服務元件定義健康檢查政策，這樣可以在服務元件遭遇問題時，快速識别到運作異常狀态，在根據事先的配置，完成下線或重新開機的操作。對于 http 服務，我們定義了一個檢測接口，通過探針請求傳回的狀态碼來判斷服務的狀态；對于一般中間件，則檢測其TCP端口的監聽狀态來判斷。
> L1級雲原生應用特征——高容錯性
> 在提高容錯性方面，雲原生應用需要配置合理的健康檢查政策。這有利于快速發現元件的異常狀況，并根據事先配置好的政策進行自動化的重新開機、下線等操作。
元件應支援優雅失敗與重試機制
Rainbond工程師向我們闡述我們的服務元件在被關閉時，應該做出怎樣的反應，來最大化的優化最終使用者的體驗。程序接收SIGTERM時，拒絕新請求，完成已接收請求後關閉端口，退出程序。而對于服務元件突然丢失了資料庫連接配接這樣的情況，也應該添加合理的重試機制，在多次重試依然無法重新連接配接到資料庫時，理應結束程序，用顯式的元件異常狀态來提醒運維人員。
> 雲原生應用強調容錯性，這不僅僅包含在某些錯誤被觸發時，應用本身和平台是否提供自動的處理手段，也包括在錯誤無法被處理時，提供更好的可觀測性，來提醒運維人員介入。
前端web元件調用後端api元件位址需要進行nginx代理
對于前後端分離的項目，合理的利用前端的web伺服器進行接口層的轉發是一種很好的體驗。Rainbond工程師在幫助我們完成前端VUE項目的源碼建構的同時，也教學了如何通過在代碼根目錄下添加配置檔案，來實作接口請求向後端元件的轉發。
> L2級雲原生應用特征——前後端分離配置
> Rainbond提供了便捷的方式來配置VUE等前端項目運作的Nginx，配置後隻需要将前後端元件依賴起來，就可以實作API的轉發。而不需要每部署一次，都要根據後端服務的位址變更而重新編譯。
實作一鍵傳遞
使用Rainbond的目的之一，是希望能夠借助其能力，實作業務系統的快速傳遞。通過與好雨科技傳遞團隊的合作，我們隻需要提供應用模闆離線包，好雨科技傳遞團隊就可以幫我們在最終生産環境中一鍵傳遞整套業務系統。這極大的降低了我們的傳遞成本。
> L2級雲原生應用特征——一鍵安裝
> 借助于 Rainbond 提供的應用釋出能力，我們可以将運作在平台上的企業應用一鍵釋出為一個應用模版。我們對應用模版最殷切的期待，是可以将這個應用模版以最簡單的操作方式、盡可能少的人為調試即可安裝成為一個應用。
實作一鍵更新
為了适應最終使用者的需求，我們需要不斷疊代自己的産品，并在生産環境中持續更新我們的業務系統。Rainbond 基于應用模闆的版本實作了一鍵更新的能力，這個功能對我們非常有用，我們隻需要提供更高版本的應用模闆離線包，好雨科技傳遞團隊就可以幫我們在最終生産環境中一鍵更新整套業務系統。
> L2級雲原生應用特征——一鍵更新
> Rainbond 的應用商店機制支援基于應用模闆的版本對已安裝的應用進行更新操作。平台的更新機制解決了服務元件版本、配置、依賴關系等絕大部份屬性的版本管理問題。尚需應用開發人員關注的問題在于資料的版本管理。
3.最終效果
應用完成改造後，通過Rainbond可以檢視我們産品的拓撲圖和依賴關系。
在實際項目當中，我們産品流轉了三個環境：
開發環境：我們在公司内部，使用開源版本的Rainbond在公司伺服器上搭建了開發測試環境，我們開發團隊通過源碼建構，很快将業務系統搬上了Rainbond。通過一段時間的測試和疊代，我們拿出了首個版本的應用模闆，并使用離線導出功能導出了離線包。準入測試環境：利用CD光牒等媒體，僅需一個工程師将離線包導入了最終客戶提供的私有雲準入測試環境，導入後産品一鍵安裝。對于客戶回報的意見，我們在開發環境中導出新的離線包，并再次導入了準入測試環境，進行了一鍵更新，經過多次疊代最終達到客戶的準入要求。
生産環境：最終生産環境是完全由客戶管理，我們僅需要提供經過準入的應用模闆離線包以及必要的文檔，客戶就可以非常快速的将我們的産品完成部署和更新。
相對于以前的傳遞方式和流程，接入Rainbond體系給我們帶來了這些更好的傳遞體驗：
更便捷的傳遞方式：傳遞物隻是離線包，不需要關心客戶複雜的運作環境。
更低的傳遞成本：無論從時間還是人力的角度，傳遞成本都極大的降低了。
應用運維過程自動化：雲原生技術切實的提升了業務系統的各項能力，可用性、容錯性以及應對流量陡增時動态的伸縮能力。
最終僅用一個星期，我們就完成了各個業務系統的雲原生改造工作，并測試通過雲原生應用标準規範認證L2級。之前項目傳遞過程中傳遞難、維護難的問題，是我們最大的隐形成本，客戶隻會看最終傳遞效果，并不會為傳遞過程而買單。
做了雲原生改造後，之前需要派駐傳遞團隊1個星期才能傳遞完的項目，現在一個基礎的運維工程師刻盤過去安裝，1小時就可以搞定。并且使用者可以通過Rainbond的可視化界面快速上手掌握，95%的運維問題都可以自行解決，或者遠端指導客戶操作。
4.什麼是雲原生應用标準規範認證？
「雲原生應用标準規範認證」為軟體廠商的應用傳遞過程中的便利性、傳遞客戶後的可維護性、以及必要時的可遷移性等需求，提供可信賴的技術背書。現階段，「雲原生應用标準規範認證」分為L1、L2、L3級，在應用傳遞及傳遞管理發揮重要作用。
L1關注：應用跨環境傳遞後的一鍵安裝和自動化運維。如高可用、可伸縮性、可觀測性等，提升最終客戶的可維護性，降低客戶的學習成本。
L2在L1基礎之上關注：應用跨環境傳遞後的一鍵更新。如全量/增量更新、版本復原等，滿足客戶小步快跑的持續疊代傳遞需求。
L3在L2基礎之上點關注：應用跨環境傳遞後的一鍵備份遷移。如包含完整資料的打包備份、可遷移性等，幫助客戶實作整體生産環境的遷移、災備。
5.關于Rainbond
Rainbond作為開源的雲原生應用管理平台，是「雲原生應用标準規範」落地實施的最佳工具。
https://github.com/goodrain/rainbond