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 性能較差。
echo "options sunrpc tcp_slot_table_entries=128" >> /etc/modprobe.d/sunrpc.conf
修改了這兩個參數後，共享存儲的性能得到了顯著的提升，令人摸不到頭腦的內核報警信息也隨之消失。開發測試環境終於可以順暢使用了。
接下來面臨新的挑戰是如何將我們的多套業務系統順利遷移到 Rainbond 上去，所幸Rainbond 的使用很簡單，整體學習梯度並不陡峭，我們很輕鬆把業務系統分批的部署在 Rainbond 上去。然而 Rainbond 工程師組織的雲原生應用評估卻指出了業務系統有多處不符合雲原生特徵之處，提出了一些整改意見。在整改過程中，我們對雲原生也有了更深入理解。
-
Elasticsearch等有狀態組件需要將組件部署類型調整成爲有狀態單實例或有狀態多實例，不可以是無狀態
我們最開始並不瞭解什麼是有\無狀態組件，所以並沒有注意區分組件的部署類型。Rainbond工程師提示我們，Elasticsearch在Rainbond平臺中應該使用有狀態的組件部署類型進行部署。
L1級雲原生應用特徵——可伸縮性
雲原生應用注重部署組件所使用的資源類型，像數據庫類型、消息隊列類型的服務組件對在Rainbond平臺上，應該使用StatefulSet資源類型進行部署。通過對服務組件定義有狀態或者無狀態的部署類型，來規定使用StatefulSet或Deployment資源類型來部署實例。
-
支持橫向伸縮
我們的多套業務系統，在接觸雲原生改造之前，都是傳統的單體架構，部署時也基本不考慮高可用特性。這使我們的業務系統相對而言脆弱許多，沒有任何容錯能力，一旦服務器宕機，整個業務系統就失去了服務能力。雲原生改造的過程中，我們藉助於Rainbond天然的微服務能力，非常輕鬆的將我們的業務系統拆分成爲更爲合理的微服務架構。更令我們驚喜的是，這些拆分出來的微服務組件，大多數直接具備了橫向伸縮的能力，藉助Rainbond的一鍵伸縮能力，迅速擴展成爲多實例的集羣，極大的提高了系統的可用性。而針對某幾個不可以一鍵伸縮的組件，Rainbond工程師們也提供了合理的意見，引導我們對這幾個特殊的組件進行修改，使之實現了“無狀態化”。現在，經過雲原生改造的業務具備了“小強”一般頑強的生命力，再也不怕服務器宕機了。
L1級雲原生應用特徵——可伸縮性
通過程序數據分離等手段，實現應用程序的無狀態化，就讓雲原生應用可以隨意橫向伸縮多個實例。實例數量的伸縮一方面使雲原生應用具備了高可用性，也直接影響其抗併發的能力。Rainbond還提供自動伸縮功能，實現削峯填谷。
-
所有配置支持環境變量配置，形如
${GATEWAY_PORT:8083}以往我們都將服務的配置項寫成固定的值，這樣的做法使得我們每到一個新的部署環境，都要重新更改大量的配置文件。Rainbond工程師指出，雲原生應用應該將配置保存到環境當中，以環境變量加默認值的方式聲明出來。而大多數需要修改的配置項，如不同組件之間的連接地址信息，就可以通過Rainbond依賴關係中的連接信息來相互注入，省去了大量的配置工作。
L1級雲原生應用特徵——可配置性
雲原生應用推崇的一種最佳實踐，就是將配置保存在環境之中。在不同的運行環境中，利用環境變量來進行配置，是一種非常好的體驗。Rainbond支持爲每個服務組件設置環境變量，也可以基於配置組功能，批量配置環境變量。
-
組件主要端口通過環境變量 ${PORT} 定義
Rainbond工程師提供了一個小技巧，將組件監聽端口的配置，用一個固定的環境變量來配置，這個變量的值會隨着我們在Rainbond控制檯上手動添加的端口號來自動變更，這樣，我們就可以在不更改代碼和配置的情況下，隨意變更想要監聽的端口號，這很方便。
L1級雲原生應用特徵——可配置性
作爲對環境變量的補充，Rainbond提供了一系列可以自動生成的環境變量，這些特定的環境變量極大方便了用戶的使用。
-
所有組件需要統一時區
統一所有組件的時區配置是非常有必要的，Rainbond工程師提供了一個技巧，讓時區的設置變成了一個很簡單的事情。只需要運行環境的鏡像中包含
tzdata軟件包，我們就可以基於TZ=Asia/shanghai這樣一個環境變量的配置，完成時區的配置了。L1級雲原生應用特徵——基礎可觀測性
統一時間在運維領域十分重要，在雲原生領域，時區的配置也可以基於環境變量進行配置。
-
所有業務需要定義健康檢查策略
Rainbond工程師要求我們爲所有的服務組件定義健康檢查策略，這樣可以在服務組件遭遇問題時，快速識別到運行異常狀態，在根據事先的配置，完成下線或重啓的操作。對於 http 服務，我們定義了一個檢測接口，通過探針請求返回的狀態碼來判斷服務的狀態；對於一般中間件，則檢測其TCP端口的監聽狀態來判斷。
L1級雲原生應用特徵——高容錯性
在提高容錯性方面，雲原生應用需要配置合理的健康檢查策略。這有利於快速發現組件的異常狀況，並根據事先配置好的策略進行自動化的重啓、下線等操作。
-
組件應支持優雅失敗與重試機制
Rainbond工程師向我們闡述我們的服務組件在被關閉時，應該做出怎樣的反應，來最大化的優化最終用戶的體驗。進程接收SIGTERM時，拒絕新請求，完成已接收請求後關閉端口，退出進程。而對於服務組件突然丟失了數據庫連接這樣的情況，也應該添加合理的重試機制，在多次重試依然無法重新連接到數據庫時，理應結束進程，用顯式的組件異常狀態來提醒運維人員。
L1級雲原生應用特徵——高容錯性
雲原生應用強調容錯性，這不僅僅包含在某些錯誤被觸發時，應用本身和平臺是否提供自動的處理手段，也包括在錯誤無法被處理時，提供更好的可觀測性，來提醒運維人員介入。
-
前端web組件調用後端api組件地址需要進行nginx代理
對於前後端分離的項目，合理的利用前端的web服務器進行接口層的轉發是一種很好的體驗。Rainbond工程師在幫助我們完成前端VUE項目的源碼構建的同時，也教學瞭如何通過在代碼根目錄下添加配置文件，來實現接口請求向後端組件的轉發。
L2級雲原生應用特徵——前後端分離配置
Rainbond提供了便捷的方式來配置VUE等前端項目運行的Nginx，配置後只需要將前後端組件依賴起來，就可以實現API的轉發。而不需要每部署一次，都要根據後端服務的地址變更而重新編譯。
-
實現一鍵交付
使用Rainbond的目的之一，是希望能夠藉助其能力，實現業務系統的快速交付。通過與好雨科技交付團隊的合作，我們只需要提供應用模板離線包，好雨科技交付團隊就可以幫我們在最終生產環境中一鍵交付整套業務系統。這極大的降低了我們的交付成本。
L2級雲原生應用特徵——一鍵安裝
藉助於 Rainbond 提供的應用發佈能力，我們可以將運行在平臺上的企業應用一鍵發佈爲一個應用模版。我們對應用模版最殷切的期待，是可以將這個應用模版以最簡單的操作方式、儘可能少的人爲調試即可安裝成爲一個應用。
-
實現一鍵升級
爲了適應最終用戶的需求，我們需要不斷迭代自己的產品，並在生產環境中持續升級我們的業務系統。Rainbond 基於應用模板的版本實現了一鍵升級的能力，這個功能對我們非常有用，我們只需要提供更高版本的應用模板離線包，好雨科技交付團隊就可以幫我們在最終生產環境中一鍵升級整套業務系統。
L2級雲原生應用特徵——一鍵升級
Rainbond 的應用商店機制支持基於應用模板的版本對已安裝的應用進行升級操作。平臺的升級機制解決了服務組件版本、配置、依賴關係等絕大部份屬性的版本管理問題。尚需應用開發人員關注的問題在於數據的版本管理。
3.最終效果
應用完成改造後，通過Rainbond可以查看我們產品的拓撲圖和依賴關係。
在實際項目當中，我們產品流轉了三個環境：
開發環境：我們在公司內部，使用開源版本的Rainbond在公司服務器上搭建了開發測試環境，我們開發團隊通過源碼構建，很快將業務系統搬上了Rainbond。通過一段時間的測試和迭代，我們拿出了首個版本的應用模板，並使用離線導出功能導出了離線包。
准入測試環境：利用光盤等介質，僅需一個工程師將離線包導入了最終客戶提供的私有云准入測試環境，導入後產品一鍵安裝。對於客戶反饋的意見，我們在開發環境中導出新的離線包，並再次導入了准入測試環境，進行了一鍵升級，經過多次迭代最終達到客戶的准入要求。
生產環境：最終生產環境是完全由客戶管理，我們僅需要提供經過准入的應用模板離線包以及必要的文檔，客戶就可以非常快速的將我們的產品完成部署和升級。
相對於以前的交付方式和流程，接入Rainbond體系給我們帶來了這些更好的交付體驗：
-
更便捷的交付方式：交付物只是離線包，不需要關心客戶複雜的運行環境。
-
更低的交付成本：無論從時間還是人力的角度，交付成本都極大的降低了。
-
應用運維過程自動化：雲原生技術切實的提升了業務系統的各項能力，可用性、容錯性以及應對流量陡增時動態的伸縮能力。
最終僅用一個星期，我們就完成了各個業務系統的雲原生改造工作，並測試通過雲原生應用標準規範認證L2級。之前項目交付過程中交付難、維護難的問題，是我們最大的隱形成本，客戶只會看最終交付效果，並不會爲交付過程而買單。
做了雲原生改造後，之前需要派駐交付團隊1個星期才能交付完的項目，現在一個基礎的運維工程師刻盤過去安裝，1小時就可以搞定。並且用戶可以通過Rainbond的可視化界面快速上手掌握，95%的運維問題都可以自行解決，或者遠程指導客戶操作。
4.什麼是雲原生應用標準規範認證？
「雲原生應用標準規範認證」爲軟件廠商的應用交付過程中的便利性、交付客戶後的可維護性、以及必要時的可遷移性等需求，提供可信賴的技術背書。現階段，「雲原生應用標準規範認證」分爲L1、L2、L3級，在應用交付及交付管理髮揮重要作用。
-
L1關注：應用跨環境交付後的一鍵安裝和自動化運維。如高可用、可伸縮性、可觀測性等，提升最終客戶的可維護性，降低客戶的學習成本。
-
L2在L1基礎之上關注：應用跨環境交付後的一鍵升級。如全量/增量升級、版本回滾等，滿足客戶小步快跑的持續迭代交付需求。
-
L3在L2基礎之上點關注：應用跨環境交付後的一鍵備份遷移。如包含完整數據的打包備份、可遷移性等，幫助客戶實現整體生產環境的遷移、災備。
5.關於Rainbond
Rainbond作爲開源的雲原生應用管理平臺，是「雲原生應用標準規範」落地實施的最佳工具。