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 左右，包括我們海外版本。
我給大家的分享就到此結束了 , 其實我們的產品實現起來本身就沒有這麼困難，只是說我們沒有通過技術去驅動，我們通過用戶需求去驅動，用戶需要什麼，我們就以最快的方式，最簡單的辦法給用戶實現，這是我們產品目標。謝謝大家。
