Laf 雲開發平臺及其實現原理
Laf 產品介紹
自我介紹
大家好，我是來自 Laf 團隊的王子俊，很高興今天能在這裡給大家分享我們 Laf 雲開發平臺及其實現原理。本來想說一點什麼天氣之類的話作為開頭，但主持人都說完啦，我就不多說了，還是直接開始今天的分享吧。
產品介紹
在準備 PPT 的時候，我想過很多種的方式來介紹我們是一個什麼樣的產品，但後來我發現在我們檔案和官網上面這兩句話完全就可以說明我們是一個什麼樣的產品 :
第一就是說我們是一個像寫部落格一樣，寫程式碼可以隨時隨地上線。
其次就是專注業務本身，讓開發者能快速地釋放創意。
為什麼說像寫部落格一樣呢 ? 因為寫部落格的時候，你可能會開啟一個部落格平臺，你的電腦開啟一個瀏覽器，然後你碼完字，點一下發布，你的部落格就可以被別人看到了。
那我們開發的時候是不是也可以說，我只要有一臺電腦能開啟瀏覽器，然後我進去就可以直接寫程式碼，寫完程式碼之後，我點一下發布，我的一個介面，我的一個應用可能就寫完了。
第二就是說專注業務本身。在座有很多都是開發者，我們身為一個開發者，很多時候會有想做一個小工具，或者說想做一個應用的這麼一個想法。
但等我們把環境部署好，準備好之後，這個環境是指我們電腦中的環境，比如說資料庫等等這些資源，也有可能是我們身邊的環境，比如說沒帶自己的電腦出門。
但如果說我們產品存在的話，你可能只需要摸到一臺能開啟瀏覽器的電腦，就可以進行你的編碼工作了。
然後下一個環節，我是打算給大家演示一下我們產品。
產品演示
本來我是準備了一個視訊的，但我覺得視訊做的有一點早了，很多功能在我們官網上沒有展示出來，所以我還是跟主辦方溝通了一下，準備現場演示一下，我會在後面用電腦給大家演示一下，大家稍等我一下。
這裡是產品演示，大家可以存取 laf.run 或者 laf.dev 來體驗。
產品特點總結
好，演示環節就到此結束了。我用三點給大家總結一下，就是我們專案的特點 :
-
開箱即用的應用資源，包括提供計算資源、資料庫資源、紀錄檔網路儲存等應用所需要的一切資源，不需要準備任何環境，包括電腦環境和物理環境。
-
目標是儘可能縮短開發流程，降低開發門檻。如果一個應用部署一個環境需要一天，我們可能一天已經做一個 demo 出來，已經上線發給使用者或群友測試了。
-
開源開放的態度，Laf 所有的原始碼是開源的，我們用的元件也都是開源的，不包含任何廠商繫結，可以跑在任何雲上，沒有後顧之憂。
技術實現介紹
技術選型
然後介紹一下我們整體的技術選型。在程式語言方面，我們選擇了 Node，最大的原因還是降低開發門檻，因為一個專案中你會用到前端，用到前端你可能會用到 JS，你前端寫 JS 後端也寫 JS，開發就不會割裂，可以覆蓋更多使用者。
然後儲存方面我們選擇了 MinIO，MinIO 最主要它是一個開源，除了開源之外，它提供了非常不錯的橫向擴充套件能力，我們可以通過增加節點來增加它的儲存能力和處理能力。
資料庫方面我們選擇的是 MongoDB，MongoDB 有一個最大的優點，對於我們來說，它是非關係型的資料庫。那麼如果使用關係型的資料庫，開發者可能門檻會提高一點，他需要去設計表，在做應用之前，他去設計一下表結構。如果用 MongoDB 的話，你可能不需要設計表，先去寫業務邏輯，等你覺得你需要儲存資料了，你再去使用 MongoDB 資料庫。
閘道器我們選擇的是 APISIX，它可以無縫地修改動態路由，還有它有豐富的外掛。最重要的是它開源開放的能力。我們每一個雲函數，每一個應用，每一個 bucket 都會分配一個給它一個二級域名。就會通過它動態路由的修改來不同的對映，就可以在我們建立雲函數和建立 bucket 的時候，無縫給大家起一個二級域名，讓大家應用還沒有域名的時候，可以直接上線，直接進行存取。
實現流程圖
然後下面是一個具體的實現流程圖。我們從左邊看是一個開發者的視角，我們可以通過外部 IDE，或者說我們提供的 CLI 本地開發，然後建立一個應用，連線到 Laf 的 server，然後它會把我們應用的資訊，儲存到資料庫中，然後準備對應的資源，通過 Kubernetes 建立一個應用範例，然後裡面放一個 Node 的 runtime，然後分配一個資料庫，分配一個儲存，整個應用從建立到啟動，成功的流程就完成了。
然後從右下方開始看，這就是我們使用者呼叫我們一個雲函數，或者呼叫一個介面的過程。我們的流量先打到我們的閘道器，然後閘道器根據 APPID 找到，確定的某一個 runtime，然後在 runtime 中，我們雲函數的名字又是唯一的，就可以確定執行哪一段函數程式碼，然後直接響應返回到外網。
Serverless 實現方案比較
說到 Serverless 它有一個傳統的解決方案，就是說一個請求會對應一個程序，也就是說我們每次請求，它就給你建立一個 runtime，建立一個 pod，然後進行這麼一個排程。
它的優點是比較明顯的，說無縫彈性伸縮，因為它每次都會重新建立一個，所以就不存在彈性伸縮的概念了。因為它每一個都是一個新的 pod。技術選型的也比較性感，是一個非常優美的模型。
但它缺點也同樣的明顯，就會存在很多開發者介意的冷啟動問題，還有長連結無法完美支援，導致開發習慣割裂。
這開發習慣割裂是指什麼 ? 因為我們傳統開發用一個雲資料庫的話，它也是一直跑在那裡的，不會說我們每次請求過來，它會重啟一個，就像現在很多的 AI 專案，它會接入 ChatGPT 的 OpenAI 介面。如果說用我們長連線記憶體的方案的話，我們只需要儲存一個對談 ID 就可以支援上下文的呼叫了。如果沒有全域性快取的話，你就需要把所有的聊天記錄儲存到資料庫中，然後每次再輸入進去，這樣才能進行一個上下文的關聯。
然後我們的技術選型，就是一個長連線記憶體的方案。它天然就不存在冷啟動問題，我們容器是一直跑在那裡的，就跟你一個雲伺服器一樣，你每次請求打過來之後，它就能及時的響應。當然我們天然就支援長連結了，同樣的記憶體，我們可以負載更多的請求，因為我們沒有資源準備，資源建立，資源銷燬的這麼一個過程，我們的資源是一直跑在那裡的。
關於彈性伸縮，我們用 Kubernetes 的 HPA 來實現，你輸入自己的預期值，它會根據你負載過高，它會增加不同數量的 pod。如果說你的流量很低了，它可能會幫你縮減減少不同的 pod。當然這麼做實現起來稍微要複雜一點。
但是我們把複雜留給了自己，簡單留給使用者，就是我們這套技術選型，它是以使用者為驅動，而不是以技術為驅動的。使用者需要長連結，我們就去支援了長連結。使用者不喜歡冷啟動，我們就把冷啟動給幹掉。這樣我們可以做到你的呼叫次數越多，你的流量越多，你的成本就越低。
雲函數排程流程
然後這裡就大概一個流程圖，展現了一下排程的方案。左側是傳統的方式，一個函數請求進來，它就會新建一個執行時來處理常式，處理請求。
而如果用我們的方案，所有的函數打到 Laf server，然後有一個任務佇列，用一個執行時來處理這些所有的請求。如果說達到我們設定的負載了，它可能會新建一個 pod 去分散一下流量的處理。
然後兩種方式的資源利用率，我這裡也是用圖簡單概括了一下。傳統方式它會在沒有請求的時候，資源利用它確實是零，沒有任何消耗。但是如果隨著請求越來越多，它有資源建立和銷燬的過程，就會導致請求隨著資源利用率，就會線性的增加。
那 Laf 可以做到在負載比較高的時候，仍然能夠保持非常低的資源佔用。還是那句話，我們不需要經歷建立和銷燬的過程，我們是一直執行的，跟一個伺服器沒有任何區別，我們只需要準備一下程式碼段所需要的上下文就可以了。
雲函數開發體驗
然後後面是一些關於我們怎麼實現這個方案的一些細節，就是一個雲函數從動態釋出到執行，到底經歷過哪些過程，才能做到讓我們的雲函數比其他要快很多。
一個使用者編寫完雲函數之後點選釋出，因為我們是 TS 支援型別提示的，我們要把它編譯成 JS，然後先存到資料庫中，同時也把編譯好的函數釋出到應用對應的 runtime 中，然後我們還會用 Node VM 模組，把它處理成 VM 的 script 的物件，快取到記憶體中的一個 map 中。這樣的話我們每次呼叫雲函數的時候，就直接從記憶體中去取那個 VM 的 script 物件直接執行就好了。
我們沒有編譯的過程，所以每次響應就快了一點。通過 HTTP 呼叫的過程，也就是從記憶體中取出我們編譯好的物件，準備好上下文，比如說傳入的引數等等，以引數的方式傳進去，然後直接執行程式碼，然後執行結果 HTTP 返回就好了。這就是我們雲函數從編寫到入庫，釋出執行呼叫的一個過程。
那麼我們團隊認為一個能夠像寫部落格一樣，寫程式碼最重要的體驗就是說，我們要有一個完備的 web IDE，因為如果說這個 IDE 用起來非常的不方便，大家都不想用，我們就失去了像寫部落格一樣寫程式碼的體驗了。我們認為一個完備的線上編輯器，需要有以下能力的支援 :
- 完整的程式碼型別提示，如果程式碼量稍微大一點，沒有型別提示的，寫起來是非常痛苦的。我們就會在雲函數使用者端那裡去分析一下，我們所需要的依賴的列表，然後去請求 runtime 去遞迴的遍歷依賴的 node_modules，找到它依賴的型別檔案，再把它扔回來，給前端的編譯器，編輯器我們用的是 VS Code 的，它對 TS 支援就比較友好。
- 可線上執行偵錯，因為我們隨便拿過來一臺電腦，就可以寫程式碼。
- 可以安裝使用者需要的 npm 依賴。
- 有變更記錄，可以回滾指定版本。
- 最下面就是我們剛剛演示的 AI 自動生成雲函數這個功能是基於我們公司另外一個產品實現的，叫 FastGPT，它可以把你自己公司的資料庫輸入給 GPT 進行微調，然後它就能掌握你所提供的知識庫的知識，根據你的知識庫幫你回答問題。
後面我也會分享一下 FastGPT 具體的實現原理。
雲函數是最基本的一個程式碼單元，那麼有一些邏輯需要複用，或者說你寫一些庫的時候，就需要一些互相呼叫。在這裡我們是 hack 了一下 node require，如果說我們去參照一個雲函數的時候，我們確定它是一個雲函數，就會把它處理成一個 node module，直接返回，就像我們引入一個 node 包一樣，就非常的自然。
多租戶隔離
關於 MinIO，我們如何實現多租戶的隔離策略。其實我們每一個 MinIO 的儲存的 bucket，我們會強制的在它的 bucket name 之前，給它加一個它的 APPID。
然後我們把 APPID 作為一個 MinIO 的 user name，我們會建立每個應用建立一個 user，然後我們只要給 s3 設定一個存取策略，就可以讓它只存取自己 user name 開頭的 bucket 就可以了。然後配上一些許可權，就可以實現多租戶的隔離，因為 MinIO 是一個叢集，所以每個人只能存取到自己的 bucket，才是對檔案的保護。
然後資料庫也會同樣遇到多租戶隔離的問題，但還好 MongoDB 它自身有一個使用者管理機制，所以我們也只需要給每個應用建立一個 user，然後利用它自身的管理機制，實現許可權隔離就好了。
但在這裡有一個比較重要的問題，如果我們用了多租戶，就會需要去限制一下，或者說設計一個請求的頻率對每個租戶，因為如果有這種惡意請求都打到整個機器上的話，可能會影響到平臺上其他的使用者。
我們就會對連線到 MongoDB 所有的流量進行一個拆包，然後看看它的請求頻率是否超過了我們限制，如果超出了，我們就把它丟棄掉，然後沒有丟棄的我們就打入進來，然後從此來統計一下，也可以實現資料庫的計量計費。
閘道器和路由
閘道器我們選用的 APISIX，剛剛簡單介紹一下它可以無縫地修改動態路由，還有它有豐富的外掛。最重要的是它開源開放的能力。我們每一個雲函數，每一個應用，每一個 bucket 都會分配一個給它提供一個二級域名。那就會通過它動態路由的修改來不同的對映，就可以在我們建立雲函數和建立一個 bucket 的時候，無縫給大家起一個二級域名。
AI 編寫程式碼實現
然後這裡就是剛剛 AI 寫程式碼能力的一個實現分享了。從上往下看就是資料處理這個部分，我們會通過模板市場和我們的技術內容，就是檔案，然後把資料向量化之後，存入到向量的資料庫。
然後使用者提問的時候，問題可能就分為三類，一個是寫業務程式碼，一個是關於我們基本檔案使用的問題，還有其他問題。
如果是其他問題就直接回復我們，就是說不相關的問題，我們不回答就好了。如果是程式碼問題，它就會到程式碼資料庫去搜尋相似內容，作為大模型的知識，然後扔給大模型，比如說我告訴你，我們產品的程式碼是這麼實現的，關於登入的三個函數是這樣的，然後你重新給我寫一個使用者需要的登入函數，返回給使用者就可以了。具體就是通過拆分問題，預訓練來實現的功能。
產品展望
然後就是關於擴充套件性了，因為我們給大家提供的，比如說 MongoDB，比如說雲端儲存等等一些能力，都是我們固定好的。
如果說有的使用者，我就需要 Redis，我就需要訊息佇列等等，一些其他的雲服務，甚至說是我們自己的業務系統，我們 Laf 是放在 Sealos 上執行，Sealos 是另外一個產品。一句話總結就是一個雲作業系統，在雲作業系統上面，可以跑任何的其他服務，包括 Redis 等等這些。如果他們都跑在同一底層上面，就可以通過內網呼叫，也就是說我們的擴充套件性非常強，你需要其他什麼樣的場景支援，我們只需要去跑一個就可以了。
講完基礎的實現，我們這個產品，有一些下一步需要做的東西，也就是說我們未來規劃。剛剛我們講了，我們現在支援的程式語言是 Node，是因為我們想把 Node 做得更好，更多的覆蓋更多的使用者。下一步我們可以考慮其他語言的擴充套件，比如說 Python、Go 甚至是 Java 等等，因為我們實現原理剛剛講過了，都很簡單，只要塞一個執行時就可以了。
然後就是更強的 AI 能力，現在我們的 AI 它只能寫程式碼價值有限，所以我們下一步可能會讓它具備自己偵錯，自己上線的功能。
我在下面大概畫了一個簡圖，就是 AI 編碼之後，它會自己生成一個測試用例，自己去測試結果，然後反饋，然後去驗收，驗收如果不通過的話，它會扔回來自己 bug 修復，再去測試，再去驗收，就這麼一個反覆的邏輯來走通，自己寫完程式碼自己上線。現在程式碼我們還可能還需要去改一改，等我們這個功能完成之後，可能就不需要去改了。
然後就是更豐富的函數模板市場。函數模板現在我們是已經上線了，在函數市場中有很多我們重複的業務邏輯，比如說登入支付等等這些共用的，我們就不用每個人都寫一遍了。因為大家用我們的產品寫的都差不多，我們只需要點一下，就可以載入到自己的應用中。
函數模板跟 AI 能力，它其實是可以相互關聯的，因為 AI 它會寫程式碼，它就可以創造更多的函數模板市場。有更多的函數模板，就可以讓 AI 訓練的資料越來越多，它給出的答案就會越來越準確。
但是我們現在雖然解決了環境的問題，和重複造輪子的問題，但這還不夠快。
最快的開發就是不用開發。下一步我們有一個應用市場上線，很多應用它都是重疊的，比如說像我們樓下健身房的約課系統等等，一些系統，它都是重複的，一個人開發就好，不用大家都開發。我們會上線一個應用市場，應用市場你只需要點一下，就可以把這個應用部署起來。如果這個應用適合你的場景，你只需要點一下就行了。這才是我們最終極的目標，就是最快的開發是不用開發。
案例介紹
然後給大家分享一下我們目前 Laf 上的一些比較有趣的案例。上面前三個是我們社群同學貢獻的一些外掛，像 VS Code 這些外掛，有些人還是不喜歡我們的 IDE，他可以用這個外掛就可以在自己本地進行 VS Code 或者說其他的編輯器進行開發。然後是兩個關於後臺管理的快速開發平臺。
第一個要稍微強調一下，這個是兩個大三的學生，用一個晚上的時間用我們的產品來寫出來的一個專案，叫 Chat Mind，就是一個 AI 生成思維導圖的工具，你可以告訴他，比如說幫我生成一個旅遊攻略等等，他會給你畫好思維導圖，或者總結一個支援點，這個專案目前已經被 XMind 收購了。大概上線一個多月被收購的吧，兩個大三的學生一晚上寫出來的。如果不是我們產品存在，他可能要寫更久的時間，甚至說他們就把這個事情給忘記了，放棄了。
然後下面是我們一些關於教育系統和電商系統的一些案例。中間這個稍微提一句比較有意思，它是一個貓譜，中大的一個學生寫的，就是把他們校園裡的流浪貓，可以收集進來，通過這個貓臉識別，可以掃出來這隻貓它的資訊是什麼，它的名字是什麼。我們現在也在做了這個支援活動，就是對所有的高校，如果他們部署這個貓譜專案的話，我們是給他提供一年的免費，就是用我們的這個東西是不收他們錢的。然後我們 Laf 一部分的收入，也會拿出來去救助那些流浪貓，這是我們覺得一個比較有意思的專案。
生態介紹
然後因為我們是一個開源的專案，現在生態就是給大家展示一下這裡 STAR 5.3K，我們 1.0 版本上線至今，還不到三個月，我們線上使用者數已經是 14000 了，應用總數量也接近 10000，活躍應用在 2300 左右，包括我們海外版本。
我給大家的分享就到此結束了 , 其實我們的產品實現起來本身就沒有這麼困難，只是說我們沒有通過技術去驅動，我們通過使用者需求去驅動，使用者需要什麼，我們就以最快的方式，最簡單的辦法給使用者實現，這是我們產品目標。謝謝大家。
