[GitHub Global] Translate Vibe Coding 零基础教程/50 产品变现/04 技术选型实战指南.md to zh-TW

translations/zh-TW/Vibe Coding 零基础教程/50 产品变现/04 技术选型实战指南.md

@@ -0,0 +1,310 @@
+# 技術選型實戰指南
+
+> 選對技術，事半功倍
+
+
+
+大家好，我是魚皮。本篇要分享的內容是 **技術選型**，是技術方向的朋友們必須要掌握的內容，也是做產品時在前期準備階段必須要做的核心工作。
+
+這篇文章中，我會結合自己做產品的實踐經驗，依次給大家分享：什麼是技術選型？技術選型選什麼？為什麼要做技術選型？如何做好技術選型？
+
+無論你是用 Vibe Coding 做個人項目，還是想做一款真正的產品，掌握技術選型的方法都能讓你少走很多彎路。
+
+
+
+## 一、什麼是技術選型？
+
+技術選型這個詞聽起來很高大上，但其實就是 “技術選擇”，即選擇使用哪些技術來實現項目。比如使用 HTML 來開發網頁、使用 C++ 來開發 Windows 桌面應用。
+
+打個比方，如果把做項目想像成帶兵打仗，技術選型就相當於打仗前選擇武器。你要根據自身的兵種、敵人的種族、敵軍的排兵佈陣等來綜合選擇最適合的武器，才能以最小的代價勝利。
+
+需要注意的是，技術選型不僅僅是在項目初期的規劃和設計階段進行。每當我們給項目增加一個新功能時，都有可能要選擇新的技術來實現；而隨著你項目的擴展，也可能需要對原有的技術棧進行升級。
+
+
+
+## 二、技術選型選什麼？
+
+“用哪些技術來實現項目”，這句話聽起來很簡單。就像上面說的，用 HTML 來開發網頁，一個技術名詞就帶過了。
+
+但事實上，這只是最淺顯的一層。做技術選型並不是一件輕鬆的事，又分為很多層次和細節。
+
+由淺入深來看，技術選型包括：
+
+1）選哪類技術？
+
+比如編程語言、開發框架、數據存儲、緩存、隊列等。
+
+2）具體選什麼技術？
+
+比如編程語言選 Java、Go 還是 C++？開發框架選 Spring 還是 Play？緩存選 Redis 還是 Memcached？
+
+3）技術具體選哪個版本？
+
+比如選 Java 8 還是 11？選 Vue 2 還是 Vue 3？選 Redis 5 還是 6？同一個技術的不同版本，往往也會有很大的差異。
+
+4）選用技術的哪些具體特性？
+
+比如 Spring 的 AOP 切面、Redis 的 GEO 高級數據結構等。
+
+
+
+這麼看來，技術選型還是有點兒麻煩的。而且一般來說，規模越大的項目，技術選型往往越謹慎，周期也就越長。
+
+記得我在騰訊從 0 到 1 建設 BI 可視化項目時，光是技術選型，就做了好幾週，從多個角度深入且綜合地對比了國內外主流的數據存儲技術。
+
+既然技術選型可能花費這麼多的時間精力，那我們為什麼還要做技術選型呢？
+
+
+
+## 三、為什麼要做技術選型？
+
+相信很多還未工作過的朋友，是從來沒有系統地做過技術選型的。
+
+這很正常，因為大家在學習階段，都是跟著網上的教程做項目，用什麼技術、用哪個版本、甚至寫什麼代碼，全部都是講師給你提前規劃好的。
+
+![](https://pic.yupi.icu/1/image-20230331134500590-20230706153049690-20230706153117049-20230706163222417.png)
+
+但其實，並不是沒有做技術選型，而是講師幫你做了而已。講師選擇用什麼技術帶你做項目時，本質上也是在做技術選型，會結合市場需求、技術流行度等多方面因素。
+
+那麼為什麼要做技術選型呢？
+
+答案很簡單，為了 **更好** 地開發和維護項目。
+
+這裡的 “更好” 可能是提高效率、節約成本、提升開發體驗、提高項目可擴展性等。
+
+想像一下，當我們在企業中團隊開發項目時，如果領導（或架構師）為了省事兒，選擇了一個只有他自己熟悉、其他成員卻完全不會用的技術，整個項目的開發進度會快麼？如果為了貪圖小便宜，選擇了一個低成本、做工粗糙的雲數據庫，整個項目的性能會高麼？
+
+在開發一個 **完整項目** 前，如果我們不假思索，直接確定某個技術就開始寫代碼，那麼有可能等到後面，才突然出現翻車。就好像魚皮給自己的電動車選了個便宜的輪胎，剛開始也能正常地跑，結果有天半路爆胎了，只能傻傻地原地等待。。。
+
+舉個我自己大學時期的翻車經歷。大學我帶團隊做過一個校園貼吧網站，記得我是用 React  來開發前端頁面的。剛開始很順利，一口氣寫了幾十個頁面；但直到有一天需要開發帖子頁面信息狀態保存功能的時候，才發現 React 不像 Vue Router 一樣有現成的 keep-alive（緩存組件狀態）。後來又花了好久才找到一個類似的組件，結果還一堆 Bug！
+
+而且，越是對項目代碼侵入性強的技術（比如開發框架），後期的切換成本就越大。像我上面舉的翻車例子，等頁面都寫了幾十個了，再去切換開發框架，就會非常麻煩；而且有的時候，你給項目引入新的組件或類庫，可能會和現有的依賴版本衝突，導致後面項目跑不起來。這個時候，你是選擇切換老的技術、還是再花更大的精力去找和舊技術不衝突的新技術呢？更有甚者，為了兼容項目原本用到的老到不行的技術框架，不敢引入任何的新技術，導致什麼都自己開發。。。可謂一步錯，步步錯！
+
+這些其實都是未做技術選型、或者技術選型不當帶來的問題，也印證了我們做技術選型的必要性。
+
+現在看來，確實是當時經驗不足。如果我在最開始就能考慮到這點，先全局確認實現項目功能可能會用到的技術，並且選擇合適的技術，就能減少後期風險、節省很多時間了。
+
+
+
+## 四、如何做好技術選型？
+
+在了解技術選型的重要性後，我們來聊聊如何做好技術選型。
+
+接下來，我會結合自己團隊的技術選型經驗，從幾個方面帶大家掌握技術選型的要點。
+
+
+
+### 4.1、明確上下文
+
+首先要明確一點：沒有絕對完美的技術，我們做技術選型的目標是在 **有限的條件** 下、選取 **特定場景** 下的技術 **最優解** 。
+
+幾個關鍵詞：
+
+
+
+#### 1）有限條件
+
+指團隊的人數、人員的技能、時間成本、金錢成本等。
+
+比如大家都只會 Java、項目又急著上線，那肯定優先選擇 Java 相關技術棧，不要因為聽說 Go 語言的性能高，就讓大家加班去學 Go。
+
+比如公司缺資金、沒資源，那麼相較於選擇付費的服務（比如雲數據庫），不妨直接在一台服務器上自主搭建。
+
+再比如公司資源很多，但是缺人力，那麼像數據庫等服務就不用自己搭建了，直接買第三方的雲服務即可。
+
+比較常見的選型方案是先從人力的角度出發，看看團隊的同學都會哪些技術。如果需求很緊急的話，那肯定優先選擇大家用的比較熟的技術，先完成一期需求快速交付，後面再調研更合適的技術架構，不斷地優化。再比如團隊內對於某個技術有比較成熟的實踐經歷和知識沉澱、也有相應的技術大佬，那麼可以優先選用該技術。舉個最典型的例子，阿里的研發團隊優先選用 Java、字節優先選 Go。
+
+再從資源的角度考慮，要看團隊的資源是否適合運用這個技術。比如創業小團隊，沒什麼資金，那麼可以用 MySQL 代替 Elasticsearch 來實現搜索功能，犧牲靈活性來省錢。再比如公司只能提供 4G 內存的服務器，那在選用一些開源技術的時候就要關注它們的內存佔用，不能超過這個閾值。
+
+
+
+#### 2）特定場景
+
+是指我們的技術選型一定要圍繞著 **特定的業務和需求** 來做，貼合實際，而不是為了用技術而用技術。
+
+可以思考以下幾個問題：
+
+1. 你要實現哪些功能？比如要做一個網盤系統，就要重點選型文件存儲技術；要做一個聊天室系統，就要重點選擇實時通信技術。
+2. 你的業務量級有多大？如果用戶數量多、數據存儲量大，可以選用分佈式數據庫、或者分庫分表；如果同時使用系統的用戶數多（併發量大），可以選用 Nginx 或者 LVS 來實現負載均衡。
+3. 系統的核心業務流程及關鍵數據結構是什麼？比如要做一個管理系統，那麼數據庫選擇主流的關係型數據庫 MySQL 就好；而如果要做數據分析系統，那麼應該選擇 OLAP 型數據庫，比如 ClickHouse 等。
+4. 系統更注重哪些性能指標？比如日誌收集的場景更注重高性能和吞吐量，那麼可以選擇 Kafka 消息隊列來採集；比如注重低延遲以及消息的準確性，那麼可以選擇 RabbitMQ。
+
+
+
+有限條件 + 特定場景 = 上下文，也可以理解為團隊、項目的實際情況。
+
+
+
+#### 3）最優解
+
+很多時候，我們做技術選型和設計算法一樣，沒有絕對的最優解，而是對時間、空間、穩定性、可用性、性能等等的綜合權衡。
+
+不同的上下文，選取的最優解也不同。這才是技術選型最有趣、同時也是最折磨人的地方！
+
+> CAP 理論也是如此，它是指在一個分佈式系統中，無法同時滿足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition Tolerance）這三個特性，只能根據實際情況在三者間進行權衡。
+
+
+
+### 4.2、充分調研
+
+在明確了我們團隊和項目的實際情況後，我們要進行充分的調研。可以利用某度、某歌、GitHub 等各搜索引擎，或者文章和視頻等等來探尋可能要用到的各類技術的信息。
+
+包括：
+
+- 這個技術是什麼？有什麼用？
+- 這個技術有什麼優點和不足？
+- 這個技術的使用成本如何？
+- 這個技術更適用於什麼場景？
+- 這個技術的背景和口碑等等
+
+
+
+有很多網站，也可以幫助我們獲取技術選型信息，比如：
+
+- 技術雷達：https://www.thoughtworks.com/zh-cn/radar
+- 框架性能對比：[https://www.techempower.com/benchmarks](https://www.techempower.com/benchmarks/#section=data-r21)
+
+
+
+不過我很久沒用過這些網站了，自從人工智能對話技術流行後，我在做技術選型時，會直接去問 AI（GPT 或魚聰明），讓它幫我獲取信息。
+
+比如問它：你是一位計算機編程領域的專家，現在我要做一個 XX 系統，大致有 XX 功能，限定條件為 XX。請幫我列舉實現這些所需的技術，要求多推薦一些同類技術並列舉每個技術的介紹、優缺點和適用場景，便於我評估實現該系統的技術選型最優解。
+
+
+
+注意，在調研階段，大家應該先盡可能多地搜索相關技術，而不要把視野局限於某個技術。
+
+建議把調研到的所有技術信息以表格或清單的形式記錄在文檔中，持續完善和補充，便於對比和最終選擇技術。
+
+就像下面這樣：
+
+![](https://pic.yupi.icu/1/image-20230706180955933.png)
+
+在大公司大項目中，技術選型一定要提供充分的依據和理由，才會得到上級或其他成員的認可。
+
+
+
+### 4.3、對比選擇
+
+收集到足夠多的信息後，我們就可以根據上下文 + 收集到的信息來綜合選擇最合適的技術。
+
+除了上下文之外，建議大家優先選擇：知名度高的、有大公司背書的、持續維護的、活躍度高的、開源的、文檔齊全的、用戶多生態好的技術。
+
+比如大名鼎鼎的前端框架 Vue 和 Java 後端框架 Spring Boot，大家對它們的印象就是功能強大、簡單好用、學習資源多，所以這兩個技術是主流，公司需求量也大。
+
+千萬不要選擇缺失文檔的、沒幾個人用的冷門技術！一旦後面出了問題，網上又找不到解決方案，說不定整個項目都無法繼續推進！
+
+
+
+### 4.4、最簡 Demo 驗證
+
+在最終確認要選擇的技術前，不要忘了驗證一下該技術是否能夠運用到咱們的項目中，而不是直接拍板！
+
+推薦的做法是編寫一個最簡 Demo 來快速驗證技術是否可用。比如使用 Vue Router 頁面路由技術，那就編寫一個點擊按鈕，快速跳轉到 `/about` 頁面的 Demo。
+
+這個過程，本質上就是實現了理論到實踐落地的過渡。
+
+也是感謝人工智能技術的發展，現在想編寫 Demo 快速驗證，都不用自己寫代碼了，直接問 GPT 即可：
+
+![](https://pic.yupi.icu/1/image-20230706182008022.png)
+
+
+
+如果我們的系統是老項目，需要重點關注新引入的技術和老項目依賴的兼容性。這個時候，編寫最簡 Demo 驗證是非常有必要的，可以提前規避版本衝突。
+
+
+
+### 4.5、日常積累
+
+除了上面這些方法外，想做好技術選型，經驗值的積累也是很重要的。比如某個電商領域的十年架構師，要做一個新的電商系統，立刻就能想到合適的技術選型、甚至是整個系統的完整實現方案。
+
+給大家兩個建議：
+
+1）持續記錄
+
+把自己看到的 **每個** 和你學習方向或工作相關的技術都先記錄到文檔中，有時間的時候可以快速了解該技術的大致信息，知道這個技術是做什麼的、有什麼用。等需要用到的時候能想起來、或者能從文檔中搜索到即可。
+
+2）拓寬邊界
+
+不要幻想用一門技術吃遍天，也不要滿足於自己的技術領域。尤其是在自學階段、做一些小項目時，可以偶爾嘗試使用一些平時不接觸的新技術，橫向拓寬自己的技術選型範圍。
+
+比如雖然我的工作是 Java 後端，但經常會做一些前端項目，而且每次都換著用技術，比如 Vue、React、Svelte 等。
+
+
+
+## 五、技術選型實踐
+
+介紹完方法論，最後再分享下我們團隊關於魚聰明 AI 的技術選型實踐。
+
+按照上面分享的幾個步驟，首先是明確上下文。
+
+
+
+### 5.1、明確上下文
+
+#### 1）有限條件
+
+我們團隊人力少，大家最熟悉的技術框架是後端 Java Spring Boot + 前端 React，所以前後端的技術框架基本確定。
+
+也沒有足夠的資金去購買很多服務器和第三方服務，所以對大多數非核心服務，使用 Java Tomcat 單機部署，並且使用寶塔 Linux 進行服務器管理。
+
+
+
+#### 2）特定場景
+
+4 問 4 答：
+
+1. 你要實現哪些功能？我們要實現的 P0 級核心功能有：AI 對話、AI 助手、內容審核。AI 對話和內容審核都可以使用第三方 GPT 服務實現。
+2. 你的業務量級有多大？網站初期，用戶的併發量不會很大，暫定 qps（每秒請求數）不超過 3，目前還不需要用到負載均衡技術。
+3. 系統的核心業務流程及關鍵數據結構是什麼？核心業務流程是用戶發送對話 => AI 自動回覆 => 存儲消息記錄。那麼就涉及了對話和消息記錄的保存，由於一個對話可以包含多個消息記錄，所以很適合選用關係型數據庫 MySQL 來實現。
+4. 系統更注重哪些性能指標？由於自己之前網站經常被攻擊，所以這次非常注重系統的安全性和可用性。為了控制併發，可以選用 Redis + Redisson 實現分佈式限流，控制每個用戶發送消息的頻率不能過於頻繁。
+
+
+
+#### 3）最優解
+
+這裡就舉一個例子吧：是消耗成本使用第三方的雲數據庫服務，還是在自己服務器上搭建數據庫呢？
+
+還在學校的時候，我肯定會選擇後者。因為很多項目就是自己學習練手用的，能跑就行；自己搭建數據庫本身也能幫我熟悉 Linux 服務器的命令。當然最關鍵的還是省米，省下來給自己午餐加個雞腿它不香麼？
+
+但現在要做面向用戶的線上項目了，我就會更傾向於使用現成的雲數據庫服務，數據庫的搭建、運維、管理、調優別人都給你做好了，你拿到數據庫賬號密碼就能直接用，還不用擔心數據庫宕機。相比於多投入的一些資金，能大幅節省我們 “本就不富裕” 的開發和運維成本。
+
+這是我們當下對於數據庫技術選型的最優解。
+
+
+
+### 5.2、充分調研
+
+上文也提到了，我們系統的 **絕大多數功能** 都使用主流技術 Spring Boot + React 實現，它們都屬於我們團隊人員的看家本領、也都是生態好的知名技術，不必做更多的調研。
+
+相反，我們投入了比較多的時間在 **內容審核** 這個小功能的調研上。
+
+為什麼？
+
+因為對 AIGC 類產品，內容審核是至關重要的；而更關鍵的是，內容審核要成本啊！
+
+為了兼顧內容審核的質量和成本，我們把目光鎖定到了國內的幾家大廠提供的雲服務上，也就是 BAT。
+
+並且通過閱讀官方文檔和客服詢問的方式，整理出了如下的對比表格：
+
+> 數據僅為示例參考，請以官方為準
+
+![](https://pic.yupi.icu/1/image-20230706195734818.png)
+
+
+
+### 5.3、對比選擇
+
+有了上圖的對比表格，我們就可以結合實際的業務情況來選擇使用哪種內容審核技術了。
+
+比如我們的對話功能中，允許用戶單次輸入的最大字符數為 1000 - 2000 左右，對話功能的使用 QPS 不超過 10，那麼選擇服務商 A 或 B 都是合理的。
+
+> 我們可以將用戶的單次輸入拆分為多個段落，通過發多次請求來繞過字符數限制。
+
+
+
+### 5.4、最簡 demo 驗證
+
+確定了要使用的技術後，剩下的工作就很簡單了。對於第三方提供的內容審核雲服務，我們只需打開官方文檔，就能找到現成的示例代碼，下載到本地執行成功即可。
+
+![](https://