作者|? 不四（死馬）螞蟻金服 語雀產(chǎn)品技術(shù)負(fù)責(zé)人

語雀是什么？

語雀是一個專業(yè)的云端知識庫，面向個人和團(tuán)隊，提供與眾不同的知識管理，打造輕松流暢的工作協(xié)同，它提供各種格式的在線文檔（富文本、表格、設(shè)計稿等）編輯能力，支持實時在線多人協(xié)同編輯，數(shù)據(jù)云端保存不丟失。而語雀與其他文檔工具最大的不同是，它通過知識庫來對文檔進(jìn)行組織，讓知識創(chuàng)作者更好的管理知識。

語雀技術(shù)架構(gòu)演進(jìn)

原型階段

語雀誕生于 2016 年，當(dāng)時螞蟻金融云需要一個工具來承載它的文檔。當(dāng)時負(fù)責(zé)的技術(shù)同學(xué)利用業(yè)余時間，開始搭建這個文檔工具。項目的初期，沒有任何人員和資源支持，同時也為了快速驗證原型，技術(shù)選型上選擇了最低成本的方案。

底層服務(wù)完全基于體驗技術(shù)部內(nèi)部提供的 BaaS 服務(wù)和容器托管平臺：

• Object 服務(wù)：一個類 MongoDB 的數(shù)據(jù)存儲服務(wù)；
• File 服務(wù)：阿里云 OSS 的基礎(chǔ)上封裝的一個文件存儲服務(wù)；
• DockerLab：一個容器托管平臺；

這些服務(wù)和平臺都是基于 Node.js 實現(xiàn)，專門給內(nèi)部創(chuàng)新型應(yīng)用使用，也正是由于有這些降低創(chuàng)新成本的內(nèi)部服務(wù)，才給工程師們提供了更好的創(chuàng)新環(huán)境。

應(yīng)用層服務(wù)端自然而然的選用了體驗技術(shù)部開源的 Node.js Web 框架 Egg（螞蟻內(nèi)部的封裝 Chair），通過一個單體 Web 應(yīng)用實現(xiàn)服務(wù)端。應(yīng)用層客戶端也選用了 React 技術(shù)棧，結(jié)合內(nèi)部的 antd，并采用 CodeMirror 實現(xiàn)了一個功能強(qiáng)大、體驗優(yōu)雅的 markdown 在線編輯器。

這時可以算作語雀的“原型階段”，它僅僅是一個工程師的業(yè)余項目，采用內(nèi)部專為創(chuàng)新應(yīng)用提供的 BaaS 服務(wù)和一系列的開源技術(shù)解決方案，驗證了在線文檔工具這個產(chǎn)品原型。

PS：當(dāng)時我還不在語雀團(tuán)隊，但是巧的是我卻在給語雀提供 Object、File 等 BaaS 服務(wù)和 Egg.js Web 框架的支持。

內(nèi)部服務(wù)階段

隨著在線文檔工具得到了團(tuán)隊內(nèi)部的認(rèn)可，語雀的目標(biāo)已經(jīng)不僅僅是金融云的文檔工具，而是志在替代 confluence 等競品，成為阿里內(nèi)部十萬員工的知識管理平臺。語雀要面向知識創(chuàng)作者，只提供 Markdown 編輯器肯定無法讓非技術(shù)人員更高效的使用語雀。盡管有不少真愛粉因為語雀開始學(xué)習(xí)甚至愛上了 Markdown，但是我們?nèi)匀涣x無反顧的踏入了富文本編輯器領(lǐng)域的深坑。同時和 Word 等富文本編輯器不同，我們選擇了更“Web”的路線，在富文本編輯器中加入了公式、文本繪圖、思維導(dǎo)圖等特色功能。而隨著語雀在知識管理領(lǐng)域的不斷探索，知識管理的三層結(jié)構(gòu)（團(tuán)隊、知識庫、文檔）開始成型。在此之上的協(xié)作、分享、搜索與消息動態(tài)等功能越來越復(fù)雜單純的依靠 BaaS 服務(wù)已經(jīng)無法滿足語雀的業(yè)務(wù)需求了。

為了應(yīng)對業(yè)務(wù)發(fā)展帶來的挑戰(zhàn)，我們主要從下面幾個點進(jìn)行改造：

• BaaS 服務(wù)雖然使用簡單成本低，但是它們提供的功能不足以滿足語雀業(yè)務(wù)的發(fā)展，同時穩(wěn)定性上也有不足。所以我們將底層服務(wù)由 BaaS 替換成了內(nèi)部的 IaaS 服務(wù)（MySQL、OSS、緩存、搜索等服務(wù)）。
• Web 層仍然采用了 Node.js 與 Egg 框架，但是業(yè)務(wù)層借鑒 rails 社區(qū)的實踐開始變成了一個大型單體應(yīng)用，通過引入 ORM 構(gòu)建數(shù)據(jù)模型層，讓代碼的分層更清晰；
• 前端編輯器從 codeMirror 遷移到 Slate。為了更好的實現(xiàn)語雀編輯器的功能，我們內(nèi)部 fork 了 Slate 進(jìn)行深入開發(fā)，同時也自定義了一個獨立的內(nèi)容存儲格式，以提供更高效的數(shù)據(jù)處理和更好的兼容性。

在內(nèi)部服務(wù)階段，語雀已經(jīng)成為了一個正式的產(chǎn)品，和螞蟻的其他項目沒有什么區(qū)別了，通過在阿里內(nèi)部的磨煉，語雀的產(chǎn)品形態(tài)基本定型。

商業(yè)化階段

隨著語雀的內(nèi)部影響力越來越大，一些離職出去創(chuàng)業(yè)的阿里校友們開始找到玉伯：“語雀挺好用的，有沒有考慮商業(yè)化之后讓外面的公司也能夠用起來？” 經(jīng)過小半年的醞釀和重構(gòu)，18 年初，語雀開始正式對外提供服務(wù)，進(jìn)行商業(yè)化。

當(dāng)一個應(yīng)用走出公司內(nèi)到商業(yè)化環(huán)境中，面臨的技術(shù)挑戰(zhàn)一下子就變大了。最核心的知識創(chuàng)作管理部分的功能越來越復(fù)雜，表格、思維導(dǎo)圖等新格式的加入，多人實時協(xié)同的需求對編輯器技術(shù)提出了更高的挑戰(zhàn)。而為了更好的服務(wù)企業(yè)用戶與個人用戶， 語雀在企業(yè)服務(wù)、會員服務(wù)等方面也投入了很大精力。在業(yè)務(wù)快速發(fā)展的同時，服務(wù)商業(yè)化對質(zhì)量、安全和穩(wěn)定性也提出了更高的要求。

為了應(yīng)對業(yè)務(wù)發(fā)展，語雀的架構(gòu)也隨之發(fā)生了演進(jìn)：

我們將底層的依賴完全上云，全部遷移到了阿里云上，阿里云不僅僅提供了基礎(chǔ)的存儲、計算能力，同時也提供了更豐富的高級服務(wù)，同時在穩(wěn)定性上也有保障。

• 豐富的云計算基礎(chǔ)服務(wù)，保障語雀的服務(wù)端可以選用最適合語雀業(yè)務(wù)的的存儲、隊列、搜索引擎等基礎(chǔ)服務(wù)；
• 更多人工智能服務(wù)給語雀的產(chǎn)品帶來了更多的可能性，包括 OCR 識圖、智能翻譯等服務(wù)，最終都直接轉(zhuǎn)化成為了語雀的特色服務(wù)；

而在應(yīng)用層，語雀的服務(wù)端依然還是以一個基于 Egg 框架的大型的 Node.js web 應(yīng)用為主。但是隨著功能越來越多，也開始將一些相對比較獨立的服務(wù)從主服務(wù)中拆出去，可以把這些服務(wù)分成幾類：

• 微服務(wù)類：例如多人實時協(xié)同服務(wù)，由于它相對獨立，且長連接服務(wù)不適合頻繁發(fā)布，所以我們將其拆成了一個獨立的微服務(wù)，保持其穩(wěn)定性；
• 任務(wù)服務(wù)類：像語雀提供的大量本地文件預(yù)覽服務(wù)，會產(chǎn)生一些任務(wù)比較消耗資源、依賴復(fù)雜。我們將其從主服務(wù)中剝離，可以避免不可控的依賴和資源消耗對主服務(wù)造成影響；
• 函數(shù)計算類：類似 plantuml 預(yù)覽、mermaid 預(yù)覽等任務(wù)，對響應(yīng)時間的敏感度不高，且依賴可以打包到阿里云函數(shù)計算中，我們會將其放到函數(shù)計算中運行，既省錢又安全；

隨著編輯器越來越復(fù)雜，在 slate 的基礎(chǔ)上進(jìn)行開發(fā)遇到的問題越來越多。最終語雀還是走上了自研編輯器的道路，基于瀏覽器的 contenteditable 實現(xiàn)了富文本編輯器，通過 canvas 實現(xiàn)了表格編輯器，通過 SVG 實現(xiàn)了思維導(dǎo)圖編輯器。

語雀富文本編輯器相關(guān)的介紹，可以看看 Lake Editor 之父隆昊的分享：富文本編輯器的技術(shù)演進(jìn)。

語雀的這個階段（也是現(xiàn)在所處的階段）是商業(yè)化階段，但是我們?nèi)匀槐３至艘粋€很小的團(tuán)隊，通過 JavaScript 全棧進(jìn)行研發(fā)。底層的服務(wù)全面上云，借力云服務(wù)打造語雀的特色功能。同時為企業(yè)級用戶和個人知識工作者者提供知識創(chuàng)作和管理工具。

JavaScript 全棧

在社交網(wǎng)絡(luò)上，大家好像對 JavaScript 全棧的看法都比較負(fù)面，“樣樣通，樣樣松”可能是大家聽到全棧工程師這個名詞后的第一印象。那為什么語雀選擇了 JavaScript 全棧的方向呢？

JavaScript 全棧與產(chǎn)品工程師

在語雀，我們并不將用 JavaScript 全棧進(jìn)行開發(fā)的工程師定義為全棧工程師，而是“一專多能”型的產(chǎn)品工程師：

• 他們是產(chǎn)品的“技術(shù)合伙人”，他們對產(chǎn)品有 owner 感，和產(chǎn)品經(jīng)理一起參與產(chǎn)品討論設(shè)計，從技術(shù)的角度上對產(chǎn)品設(shè)計方案提出建議，獨立的完成產(chǎn)品功能的全棧研發(fā)，并跟蹤發(fā)布后的產(chǎn)品結(jié)果。
• 同時他們也是某一個技術(shù)領(lǐng)域的領(lǐng)域?qū)＜?#xff0c;例如有人可能是服務(wù)端領(lǐng)域的專家、測試領(lǐng)域的專家、前端構(gòu)建領(lǐng)域的專家、CSS 領(lǐng)域的專家。他們可以用自己的專業(yè)領(lǐng)域知識來優(yōu)化團(tuán)隊研發(fā)工具鏈，提升產(chǎn)品研發(fā)效率。

在語雀，產(chǎn)品工程師們的產(chǎn)品研發(fā)流程是這樣的：

• 在產(chǎn)品設(shè)計階段，產(chǎn)品工程師就會參與進(jìn)去進(jìn)行討論，最終會產(chǎn)出一份 final design 的產(chǎn)品設(shè)計稿。由于前期產(chǎn)品工程師參與充分討論，一般此處定下的產(chǎn)品設(shè)計稿到后期的研發(fā)過程中不會遇到技術(shù)上的問題；
• 隨后會在語雀上進(jìn)行文檔化的系統(tǒng)分析設(shè)計。會在語雀上發(fā)起異步的評審。一些大的技術(shù)方案會有其他的領(lǐng)域?qū)＜壹尤脒M(jìn)來一起進(jìn)行評審，確保將所有的技術(shù)難點都梳理清楚；
• 系統(tǒng)設(shè)計清晰后，進(jìn)入研發(fā)階段；
• 對所有的代碼，都需要有自動化測試覆蓋。對所有新增代碼和修改的業(yè)務(wù)邏輯都需要有完全覆蓋的單元測試，對關(guān)鍵鏈路的功能同時也要提供端到端測試。編寫完自動化測試是進(jìn)入代碼評審前的必備流程。
• 階段性的功能研發(fā)完成、測試編寫完善后會發(fā)起異步的代碼評審。會邀請相關(guān)業(yè)務(wù)的負(fù)責(zé)人和對應(yīng)的一些領(lǐng)域?qū)＜襾磉M(jìn)行代碼評審。從業(yè)務(wù)邏輯的正確性，安全性，可維護(hù)性等多個角度來進(jìn)行代碼評審。
• 最終在發(fā)布上線時，必須遵循三板斧原則：可灰度、可應(yīng)急、可監(jiān)控。避免功能變更可能帶來的 bug 影響到大量用戶。

語雀是如何進(jìn)行全棧 JavaScript 測試的呢？感興趣的同學(xué)可以看看語雀團(tuán)隊大前端自動化測試大牛達(dá)峰老師的分享：大前端測試的思考和在語雀的實踐

通過 JavaScript 全棧，語雀團(tuán)隊可以更高效、高質(zhì)量的的完成產(chǎn)品研發(fā)：

• 從代碼層面上來說，有大量的代碼可以復(fù)用，以編輯器舉例，它不僅僅可以在 Web 端使用，也可以在桌面端使用。同時許多數(shù)據(jù)處理的能力還可以在服務(wù)端使用。
• 從產(chǎn)品研發(fā)效率上來說，全棧研發(fā)減少了大量溝通成本，在語雀當(dāng)前的階段是非常高效的。而 JavaScript 全棧避免了開發(fā)者在不同的語言中進(jìn)行切換，不用考慮前端使用的 lodash / moment 等工具類在其他語言中應(yīng)該用什么，大大提升全棧的研發(fā)效率。
• 最后從工程師角度來看，全棧研發(fā)讓工程師有機(jī)會深度參與到產(chǎn)品研發(fā)的整個流程中，大家會自發(fā)的去思考產(chǎn)品有什么優(yōu)化點，從技術(shù)上能幫助產(chǎn)品做什么。例如語雀最近新上的 OCR 搜圖功能，就是語雀的全棧工程師自發(fā)從技術(shù)預(yù)研到產(chǎn)品落地完成整個產(chǎn)品優(yōu)化的。

JavaScript 全棧與 Node.js

說到 JavaScript 全棧，有一個繞不過去的技術(shù)就是 Node.js。作為一個與前端結(jié)合緊密的服務(wù)端運行時，基本上就成為了全棧的代言人。那 Node.js 是不是真的是一個適合大型商業(yè)化項目的語言呢？大家對它都有頗多質(zhì)疑：

其實隨著 JS 語言的發(fā)展，許多問題已經(jīng)得到了解決，例如 Async Function 的出現(xiàn)，可以讓開發(fā)者以同步的方式編寫異步代碼，理解起來更簡單，異常處理也變簡單了。同時隨著社區(qū)的進(jìn)一步完善，大量高質(zhì)量的工具模塊、框架涌現(xiàn)出來。語雀的服務(wù)端部分基于 Egg 框架，已經(jīng)集成了大量 Web 開發(fā)需要的模塊和服務(wù)，同時基于 Async Function 編程模型也更加簡單。TypeScript 的出現(xiàn)也打消了許多人對 JavaScript 進(jìn)行大型項目開發(fā)的疑慮。除此之外，語雀還有一些其他的方式來保障代碼質(zhì)量和可維護(hù)性（語雀甚至是一個純 JavaScript 項目，沒有一行 TypeScript 代碼）。

語雀做的第一件事情就是確定核心系統(tǒng)和外部系統(tǒng)的邊界。通過六邊形架構(gòu)（也叫做端口適配器架構(gòu)），我們把語雀核心系統(tǒng)和外界系統(tǒng)和用戶之間的交互固定下來。通過“端口”的形式，來確定輸入和輸出。外部系統(tǒng)通過“適配器”來將系統(tǒng)對接到語雀暴露的端口之上，只需要按照“端口”定義來實現(xiàn)，外部系統(tǒng)可以自由替換。

在這個模型下，Controller 就是語雀暴露給用戶接口的 HTTP?適配器。在 Controller 中，我們對用戶請求參數(shù)進(jìn)行格式校驗和轉(zhuǎn)換，檢查用戶權(quán)限，并格式化輸出。

我們定義好語雀與第三方平臺和服務(wù)之間的交互方式（一般是一系列方法），通過適配器，將不同環(huán)境的不同服務(wù)封裝成統(tǒng)一的方法，并在調(diào)用時記錄好調(diào)用日志。

數(shù)據(jù)模型層即是數(shù)據(jù)層的 Model，以 Doc 模型舉例，它的 meta 信息數(shù)據(jù)被存儲在了 MySQL 中，而文檔正文數(shù)據(jù)被加密后存儲在 OSS 中。對于語雀核心的業(yè)務(wù)邏輯來說，完全不感知底層的存儲在哪里。更進(jìn)一步來說，只要語雀是使用 SQL 和數(shù)據(jù)庫進(jìn)行交互，底層數(shù)據(jù)可以無縫遷移到 OceanBase 等其他支持完整 SQL 語法的數(shù)據(jù)庫中，即使有少量修改也可以在 Model 層封裝掉。

最終以一次文檔發(fā)布舉例，用戶通過調(diào)用 HTTP 接口與語雀進(jìn)行交互，數(shù)據(jù)會通過 Model 層寫入到存儲中，包括 MySQL 和 OSS，更新文檔緩存。同時出發(fā)異步消息給其他系統(tǒng)，觸發(fā)釘釘?shù)?WebHook，并將數(shù)據(jù)同步到搜索引擎中。這些和外界系統(tǒng)的交互通過適配器封裝之后各司其職，參數(shù)轉(zhuǎn)換、權(quán)限校驗、日志記錄，不僅確保核心邏輯的精簡，也讓系統(tǒng)調(diào)用鏈路跟蹤更加簡單。

混合應(yīng)用架構(gòu)

當(dāng)系統(tǒng)發(fā)展到一定程度后，到底是應(yīng)該繼續(xù)在大單體應(yīng)用上加功能，還是拆分成微服務(wù)呢？這兩種架構(gòu)既然存在，肯定有各自的優(yōu)劣，具體選擇那種架構(gòu)形式，應(yīng)該是與當(dāng)前的業(yè)務(wù)規(guī)模和團(tuán)隊分布決定的。所以語雀的技術(shù)架構(gòu)隨著語雀的業(yè)務(wù)形態(tài)也變成了一個混合式的技術(shù)架構(gòu)。

語雀的主服務(wù)是一個大型的 Node.js 服務(wù)，集中了所有的應(yīng)用業(yè)務(wù)邏輯。而在主服務(wù)之外，還有一些不同形態(tài)的其他服務(wù)。

• 微服務(wù)：一些獨立而穩(wěn)定的功能模塊，或者有額外部署架構(gòu)需求的服務(wù)，會通過微服務(wù)的形式獨立部署，系統(tǒng)間暫時通過 HTTP 接口進(jìn)行交互。例如實時協(xié)同服務(wù)，由于其自身比較獨立穩(wěn)定，而且是長連接服務(wù)，不能頻繁發(fā)布重啟，所以將其部署成了一個獨立的微服務(wù)。
• 任務(wù)集群：一些 CPU 密集型的任務(wù)，或者依賴了一些復(fù)雜的第三方依賴的服務(wù)，會放到一個獨立的任務(wù)集群中。例如各種文件預(yù)覽服務(wù)，可能依賴到了其他服務(wù)，且需要消耗大量計算成本，放到任務(wù)集群通過隊列消除并發(fā)后最為合適。
• 函數(shù)計算：一些對響應(yīng)時間比較高且可以函數(shù)化的服務(wù)，我們會盡量遷移到阿里云的函數(shù)計算，例如plantuml、mermaid 等文本繪圖服務(wù)。

以 mermaid 的渲染舉例。用戶輸入一段 mermaid 代碼調(diào)用語雀，語雀調(diào)用一個部署在阿里云函數(shù)計算的函數(shù)，在函數(shù)中運行 puppeteer 渲染成 svg 返回。

為什么要特別把 Serverless 單獨拿出來說呢？還記得之前說 Node.js 是單線程，不適合 CPU 密集型任務(wù)么？由于 Serverless 的出現(xiàn)，我們可以將這些存在安全風(fēng)險的，消耗大量 CPU 計算的任務(wù)都遷移到函數(shù)計算上。它運行在沙箱環(huán)境中，不用擔(dān)心用戶的惡意代碼造成安全風(fēng)險，同時將這些 CPU 密集型的任務(wù)從主服務(wù)中剝離，避免出現(xiàn)并發(fā)時阻塞主服務(wù)。按需付費的方式也可以大大節(jié)約成本，不需要為低頻功能場景部署一個常駐服務(wù)。所以我們會盡量的把這類服務(wù)都遷移到 Serverless 上（如阿里云函數(shù)計算）。

語言之外的通用領(lǐng)域

除了語言之外，任何的商業(yè)化系統(tǒng)還有更多需要考慮的方面，其中最重要的兩點可能就是安全性和穩(wěn)定性了。

一個系統(tǒng)從前端、服務(wù)端到底層的依賴都存在著各種各樣的安全風(fēng)險：

• 前端安全風(fēng)險：XSS、跳轉(zhuǎn)釣魚、跨站請求等
• 服務(wù)端安全風(fēng)險：水平權(quán)限問題、未授權(quán)訪問、敏感信息泄露、SSRF、SQL 注入等
• 云服務(wù)的安全風(fēng)險：短信/郵件轟炸、數(shù)據(jù)泄露風(fēng)險、內(nèi)容安全等

這些安全問題想要解決基本都沒有銀彈，只能一個個單獨處理，但是有一些基本的原則：

• 不要信任用戶的任何輸入
  • 任何渲染富文本的地方都需要防范 XSS，內(nèi)容也可能并不是通過 IDE 輸入的；
  • 要在服務(wù)端執(zhí)行用戶的代碼一定要放在沙箱中；
  • 要從服務(wù)端請求用戶傳遞的資源，一定要經(jīng)過 SSRF 過濾；
• 沉淀標(biāo)準(zhǔn)的編碼范式來處理安全風(fēng)險，且需要在 Code Review 中重點關(guān)注
  • 所有接口都必須有權(quán)限校驗；
  • 響應(yīng)序列化方法過濾敏感信息；
  • 不允許拼接 SQL；

語雀從商業(yè)化一開始就和安全團(tuán)隊通力協(xié)作，從內(nèi)部的安全意識培訓(xùn)、內(nèi)部安全團(tuán)隊測試，到內(nèi)部的紅藍(lán)攻防、外部的白帽子滲透測試，安全是一場持久戰(zhàn)。

為了保障語雀的穩(wěn)定性，我們從前端到服務(wù)端和云服務(wù)上都做了許多工作，和安全一樣，穩(wěn)定性也是一個從前到后的長期工程。語雀的穩(wěn)定性保障主要在兩個維度：

• 保障服務(wù)可用性：從架構(gòu)設(shè)計上要杜絕單點，底層的數(shù)據(jù)都需要進(jìn)行容災(zāi)和備份，服務(wù)需要多單元、可用區(qū)部署。同時避免引入不必要的強(qiáng)依賴；
• 異常可監(jiān)控和追溯：從前端的業(yè)務(wù)埋點日志、異常日志監(jiān)控，到服務(wù)端的全鏈路日志跟蹤和采集，系統(tǒng)性能監(jiān)控和分析。最終我們可以達(dá)到異常可及時感知和追溯，性能問題可以定位分析；

什么叫做避免引入不必要的強(qiáng)依賴呢？以語雀的場景舉例，MySQL 就是一個無法去除的強(qiáng)依賴，而緩存不應(yīng)該是一個強(qiáng)依賴，但是最早語雀的 session 是存儲在緩存（Redis）中的，一旦 Redis 集群出問題，用戶資料無法獲取就導(dǎo)致用戶無法登錄。這就把緩存變成了一個強(qiáng)依賴。所以我們將 session 存儲放到了 MySQL 中，Redis 就變成了一個弱依賴，它掛了系統(tǒng)還能正常運行。另一個例子，語雀前段時間上線了多人實時協(xié)同編輯的功能，而在這個功能上線之前，是通過文檔加鎖的方式避免多個人同時編輯同一篇文檔的。然而多人實時協(xié)同引入了另一個服務(wù)，一旦實時協(xié)同服務(wù)掛了，用戶就無法編輯文檔了，它又變成了語雀系統(tǒng)的一個強(qiáng)依賴，為了解決他，我們在用戶連接協(xié)同服務(wù)失敗的時候，自動切換到老的鎖模式。這樣協(xié)同服務(wù)也變成了語雀的一個弱依賴。

語雀如何選擇技術(shù)棧

語雀這幾年一步步發(fā)展過來，背后的技術(shù)一直在演進(jìn)，但是始終遵循了幾條原則：

技術(shù)棧選型要匹配產(chǎn)品發(fā)展階段。產(chǎn)品在不同的階段對技術(shù)提出的要求是不一樣的，越前期，對迭代效率的要求越高，商業(yè)化規(guī)模化之后，對穩(wěn)定性、性能的要求就會變高。不需要一上來就用最先進(jìn)的技術(shù)方案，而是需要和產(chǎn)品階段一起考慮和權(quán)衡。

技術(shù)棧選型要結(jié)合團(tuán)隊成員的技術(shù)背景。語雀選擇 JavaScript 全棧的原因是孵化語雀的團(tuán)隊，大部分都是 JavaScript 背景的程序員，同時 Node.js 在螞蟻也算是一等公民，配套的設(shè)施相對完善。

最重要的一點是，不論選擇什么技術(shù)棧，安全、穩(wěn)定、可維護(hù)（擴(kuò)展）都是要考慮清楚的。用什么語言、用什么服務(wù)會變化，但是這些基礎(chǔ)的安全意識、穩(wěn)定性意識，如何編寫可維護(hù)的代碼，都是決定項目能否長期發(fā)展下去的重要因素。

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的技術(shù)圈。”

總結(jié)

以上是生活随笔為你收集整理的“云”端的语雀：用 JavaScript 全栈打造商业级应用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。