🔍 搜尋結果:架構

🔍 搜尋結果:架構

從 SDE1 到 SDE2,甚至更高! 🚀 實際需要什麼。

> ***「我擅長寫程式碼。就在這個月,我發了 11 個 PR!我甚至按時更新了我的大部分票。也沒有請那麼多假!而且我也比 Sam 工作了更多時間!為什麼沒有我沒有升職,但他們卻升職了?*** > *-- 一些不幸的人,這次沒有得到促銷。* 這聽起來有關聯嗎? 我以前見過這個。 很多。 有時原因是辦公室政治。 🤬 有時,這只是期望沒有得到良好的溝通。那可能很糟糕。 🥲 有時,你如何達到既定的期望與實際的標準之間**存在不匹配**。 🤔 您可能無法控製或改變您的辦公環境。但你當然可以控制自己,確保沒有任何事情可以阻止你**在職業階梯上的上升**。 ![你明白了,規劃辦公室](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6htoz012vjxxtc5po2hk.gif) > ### 涼爽的!你能快速引導我完成我需要做的事情嗎? 首先要知道身為軟體開發人員的職責是什麼。我不是指您在目前組織中的職責,而是指作為整體和個人開發人員的職責。 #### 目錄 我認為開發人員應該致力於涵蓋**5 個廣泛的領域**。 *點擊連結可跳轉至該部分。* 1. [技術](#1-technical-skills-)(程式碼品質、語言熟練度、測試、效能) 2. [生產力](#2-productivity-)(可靠性和效率) 3. [協作](#3-collaboration-)(溝通和評論) 4. [所有權](#4-ownership-)(責任和主動性) 5. [影響](#5-impact-)(系統/產品改進和創新) *“至此,我們製作 D&D 角色表的工作就完成了一半。滾動 Nat 20!🤣”* **我只會介紹您可以控制的事情。** 我特別提到這一點是因為我看到許多組織犯錯的一件事是,評估的各個領域最終都包括您可能無法控制的事情。 例如,您可能無法控制您的工作對公司的影響力。在大多數情況下,您只能完成直接要求您做的事情。 > ### 好吧!我們走吧!我已經準備好升職了! ![辦公室一百萬美元](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2q5npkuc8euhcnb2pvtm.gif) 我上面提到的 5 個領域並不是 SDE1 所特有的。這是每個開發人員都需要掌握的東西。但每個領域的標準和期望都會改變。 讓我們討論一下每個領域的基線期望是什麼,以及您需要做什麼才能達到下一個水平。 **稍安毋躁。這會很長。** **但請記住,下面只有 5 個部分...👇** ![這需要一段時間](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qaj5r04sxuc1fsfsaqtv.png) ### 1. 技術能力[\[🔝\]](#table-of-contents) 在 SDE1,沒有人指望您能引起轟動、改變世界、節省數十億美元! 他們希望您以最少或最多偶爾需要指導的方式完成工作,並且您交付的工作不需要重新審視或修復(只要合理)。 **太長了;博士** 編寫其他人可以閱讀的體面程式碼,並且不會每 2 秒就中斷一次。 有幾種方法可以做到這一點。 **寫愚蠢的程式碼。不是“智能”程式碼。** - 您可能是 Leetcode、Hackerrank 或類似事物的奇才。但不幸的是,這些網站鼓勵初級人員如此努力地追求效能,以至於常常以**犧牲可讀性為代價**。 - 如果您知道兩個循環僅針對`i`和`j`的較小值執行,那麼使用嵌套循環並不是一個壞主意。 - 如果保證陣列最多只有幾個專案,那麼不使用映射/字典而不是陣列並不是一個壞主意。 ![編寫與閱讀程式碼](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/amla8isarsp66etjd99v.png) **了解該語言為您提供的所有工具。** - 您可能習慣於對所有事情使用 for 循環,但箭頭/lambda 函數可以使您的程式碼更具可讀性。 - \[JS 範例\] 你可能習慣將事物儲存在物件`{}`中,每次尋找的時間複雜度為 O(1),但是`set.has(thing)`比`!!obj[thing]` (甚至`Boolean(obj[thing])` **了解為什麼測試有價值,然後編寫測試** - 人們常常只是在寫測試,因為這是「最佳實踐」。 - 如果不了解背後的原因,您可能會編寫無效或毫無意義的測試。 - 這個想法是,**做任何你需要做的事情,以增加對程式碼穩定性的信心**。您需要使用類型嗎?當然。您需要聘請 QA 人員嗎?有點低效,但很酷。**也許你需要寫...測試?**好吧,但是……我的目標是什麼? - 這可以是一個單獨的部落格。**但這裡有一個簡短的簡短介紹...** - 您是否需要編寫單元測試、整合測試、驗收測試,無論您如何稱呼它們,都沒關係。人們可能對此感到「宗教」。但只要你的測試做了一件基本的事情,這一切都不重要…提高你對程式碼不會破壞的信心。 - 有時您可能需要重構程式碼,使其更易於測試,但是一旦您這樣做了幾次,您就會開始從可測試性的角度考慮程式碼。 - 在實現任何東西之前,為您預期的實作編寫測試也是一個好主意!導致測試套件一開始就完全失敗,而當您實施一些東西時,它會逐漸保持通過!順便說一句,這基本上就是測試驅動開發(TDD)。 **關心表現** - 沒有人會期望您始終以 60 FPS 的速度執行所有內容,或者所有內容的延遲都低於 100 毫秒。 - 但請注意,您的程式碼何時可能會導致對資料庫發出過多請求,或載入過多資料。不要讓你的元件渲染 5 次,因為你無法弄清楚如何正確使用`useEffect`和`useState` 。在需要的地方尋求協助,但要夠小心,不要讓這些東西進入生產階段。 ![延遲紙飛機](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/57g9q3qria2u6k6s3of5.gif) **⏫ 進入 SDE2:** - 更深入地了解您使用的語言和框架的內部結構。 🧠 了解 React 如何實際渲染事物。了解瀏覽器如何處理從瀏覽器到伺服器的多個請求。了解 Postgres 如何選擇優化或不優化查詢。了解應用程式部署管道的配置方式。 - 詢問有關專案、元件、API 等是如何建構的問題。了解這些設計模式的名稱以及它們的優點和缺點。開始參與架構討論並提出改進建議。誰知道?您可能有更有經驗的人沒有考慮到的想法。 - 指導他人最佳編碼實務。團隊中常常會有比你資歷低的人。查看他們的程式碼。讓他們審查您的程式碼並分享他們應該關注的內容。像尤達一樣,你應該分享你的智慧。 🧠 ### 2. 生產力[\[🔝\]](#table-of-contents) 作為 SDE1,您的生產力是透過您按時可靠地完成任務、有效管理工作負載以及保持專案一致進度的能力來衡量的。您還應該能夠處理輕微的干擾和依賴性,而不會失去焦點或需要持續的指導。 您可能經常需要依靠工具或應用程式或腳本來更有效地完成某些事情。有時您可能需要自己製作這些工具。 如果感覺太多了也沒關係。它不會總是完美的。即使是更資深的開發人員也並不總是能確定這一點。 你會到達那裡的。重要的是,如果您無法履行承諾,請儘早溝通。 **太長了;博士** 目標是按時出色地完成任務。當您覺得自己做不到時,請盡快讓人們知道。 **知道什麼時候該做什麼,什麼時候該說「不」🙅** - 學會區分什麼是緊急的,什麼是重要的。使用艾森豪威爾矩陣等工具有效地確定優先順序。 - 專注於高影響力的任務,但不要忽略那些讓車輪轉動的小任務。 - **學會說不。**天哪,這是一個很大的。這非常重要,以至於它可以單獨成為一個部落格。我有故事。 - 如果你不善於拒絕,你偶爾會發現自己的工作負擔過重。如果你能簡單、清楚地解釋你正在做的事情,以及你何時能夠處理下一件事情,人們通常會認為這是可以接受的。 - 如果你發現自己被逼入絕境,你需要依靠你的經理來為你確定優先事項。只需詢問他們認為最重要的是什麼。 ![沒有上帝請不](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/46j4r2r8b9oho91fduvw.gif) *你看到這個人來了,不是嗎?* **管理好你的時間,別讓自己精疲力竭** - 使用番茄鐘等技巧來保持工作效率而不至於精疲力竭。我有很多朋友使用某種數字或實體番茄計時器來管理他們的工作日。 - 追蹤您在不同任務上的時間,以了解您可能在哪些方面花費了過多或過少的時間。 ![番茄計時器](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ktom06mrbpkg10u0vslo.png) *我的朋友以前常用的番茄計時器* **如果必須的話,可以透過製作自己的工具來自動化無聊的工作** - 自動執行重複性任務以節省時間。腳本和工具可以處理很多平凡的事情。我已經建立了一大堆腳本、用於內部偵錯的 Slack 命令等,這已經為我和團隊在[Middleware](https://github.com/middlewarehq/middleware)節省了無數的時間。 - 熟悉 IDE 快捷方式、插件和其他可以加快開發過程的工具。如果您的團隊中的大多數人都使用 VSCode 進行開發,您甚至可以就通用 IDE 配置達成一致,並透過將 .vscode 目錄提交到儲存庫來共享該程式碼庫! **⏫ 進入 SDE2:** - 開始更獨立地管理您的專案。建立現實的時間表並滿足它們。 SDE1 可能會不時錯過時間表。 SDE2,則不然。你走得越高,你就越有可能提前完成你的專案! - 主動辨識並解決工作流程中的瓶頸。向團隊提出流程改善建議。通常,您可能沒有時間或支援來實施此類改進。一個可靠的 SDE2+ 舉措就是在其他工作之間的零碎時間裡自己完成,突然有一天,團隊的一些關鍵工作流程痛點神奇地得到了解決!都是因為你。 - 平衡多個專案和任務,同時不忘記最後期限,並了解您並不總是透過每天工作 28 小時來滿足最後期限,您會找到更有效地完成同一件事的方法。因此,表明您可以以相同的生產力水平承擔更多的責任。像托尼史塔克管理他的套裝技術一樣升級你的多任務遊戲! 🦾 ### 3. 合作[\[🔝\]](#table-of-contents) 在 SDE1,您需要清晰溝通、分享您的進步並成為樂於助人的團隊成員。您與他人有效協作的能力對於團隊的成功至關重要。 有很多人依賴你按時交付東西。他們是您的工程經理、產品經理,也許還有他們報告的其他經理,還有等待您完成專案部分的同事。 人們通常可能會晚一點理解某些事情,特別是如果儘早得知的話。但真正導致問題的是: - 不到最後一刻才告訴你會遲到。 - 您的估計不清楚或非常不準確。 我仍然把其中的一些搞砸了。但總體而言,情況確實有所改善。 👌 **太長了;博士** 做一個好的隊友並進行良好的溝通。 ![團隊合作](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/385iu3jjbits6zfgq6zz.gif) **早說、常說,但最重要的是──傾聽** - 讓您的團隊了解您的最新進展。透過站立會議和 Jira 或 Trello 等專案管理工具進行定期更新可以幫助每個人保持一致。 (我知道,Jira 很糟糕,但你必須明白,對於你的經理和高層來說,這是一個相當不錯的工具,可以用來追蹤事情的運作情況。) - 在會議和討論期間積極傾聽。在做出回應之前先了解別人在說什麼。 - 成為一個好的傾聽者也會讓你更快找到女朋友/男朋友🤣。如果你不這樣做,我們希望你能通過規則 1 和 2。 **保護您的生產,檢查程式碼** - 積極參與程式碼審查。提供建設性的回饋並樂於接受。非常關心不要讓可讀性差或有潛在風險(效能、使用者體驗或安全性方面)的程式碼最終出現在產品中。 - 從您收到的回饋中學習並將其應用到您未來的工作中。 如果您需要令人信服地了解為什麼程式碼審查至關重要以及如何正確執行,也許這會有所幫助: {% 嵌入 https://dev.to/middleware/the-senior-engineers-guide-to-the-code-reviews-1p3b %} **讓您的團隊隨時了解您所學到的知識** - 與您的團隊分享您所學到的知識。無論是新工具、編碼技巧還是有趣的文章,讓您的團隊了解情況有助於每個人成長。如果您使用 Slack,#engineering 頻道是進行此類活動的好地方。 #memes 也是如此。 😄 - 為程式碼庫或流程的複雜部分撰寫文件並建立指南。這有助於其他人更有效地理解和使用您的工作。記住這個文件需要可搜尋是非常重要的。無法搜尋到的文件就不存在。 [Glean](https://www.glean.com)可能是一個很好的工具來幫助解決這個問題,但它是一個付費(而且昂貴)的東西。 **⏫ 進入 SDE2:** - 發揮指導作用。幫助初級開發人員應對任務和挑戰。幫助他們規劃、估算、記錄等。 - 領導小型專案或倡議。表明您可以協調努力並將團隊聚集在一起以實現共同目標。 - 促進團隊內部的溝通。幫助解決衝突並確保每個人的意見都得到傾聽。每個團隊都有內向的人,通常他們是最難溝通的,盡可能幫助他們。成為團隊中的美國隊長,團結一致,以身作則! 🛡️ ### 4. 所有權[\[🔝\]](#table-of-contents) 擁有所有權意味著對你的工作及其影響負責。作為 SDE1,這意味著您應該確保您的程式碼按預期工作,勤奮地處理您的任務,並履行您的承諾。 就像創始人或執行長必須盡一切努力確保公司生存、繁榮和盈利一樣,你也必須盡一切努力確保你的工作符合規定的時間表,並以以下方式交付:不僅滿足,而且超越標準。 可以理解的是,有時設定的時間表或期望可能根本不切實際。這就是你的溝通技巧需要發揮的地方。 **太長了;博士** 擁有你的工作及其品質。完成你開始的事情。 ![德懷特覆蓋](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hc5yu0726kgkxrws7xmy.gif) *也許不像……那樣。* **學會承諾** - 如果您致力於一項任務,請堅持到底直至完成。如果遇到障礙,請儘早溝通。 - 不要推卸責任。如果您的程式碼或任務有問題,請努力解決它,而不是責怪他人。 **積極主動:看到一些事情,做一些事情** - 不要等待問題被分配給您。如果您發現有問題需要修復,請主動解決。當然,您需要適當地確定優先順序。並非所有需要修復的東西都需要您先停放正在處理的任何東西並先修復它。 - 提前想好。預測潛在問題並在它們成為問題之前解決它們。對於技術或工程相關的工作,ERD(工程需求文件)可以大大幫助您制定工作計劃。 - 您的經理可能會從他們的角度關注您團隊的生產力,但作為積極主動的開發人員,您也可以這樣做。畢竟,您才是真正了解是什麼讓您有生產力的人。如果你能想出一種方法向你的經理進行生產力分析,向他們展示你的團隊實際上做得很好,或者在需要他們注意的事情上遇到了阻礙,這會讓你得到一些嚴肅的觀點。 DORA 指標是衡量開發團隊生產力的一種相當流行的方法。如果您不確定如何開始衡量這樣的事情,也許這個部落格會有所幫助: [什麼是 DORA 指標?](https://www.middlewarehq.com/blog/what-are-dora-metrics-how-they-can-help-your-software-delivery-process) **每一天,都要比前一天更好** - 反思你的工作。什麼進展順利?還有什麼可以更好的呢?利用這種反思來不斷改進。這將是您的經理將(或應該)進行的 Sprint 回顧的更個人化版本。 - 積極尋求回饋並應用它。努力讓您承擔的每個專案變得更好。對於提供回饋的人來說,共享回饋也是一項艱鉅的工作。如果您的組織沒有為此定義流程,那麼每季、每月等阻止一些時間可能是個好主意。 - 嘗試遵循童子軍規則,該規則基本上規定您應該留下比您發現時更好的程式碼庫。[在這裡閱讀更多內容](https://deviq.com/principles/boy-scout-rule)。 **⏫ 進入 SDE2:** - 從頭到尾推動專案。承擔需要您在最少監督的情況下規劃、執行和交付的任務。如果你證明自己有足夠的自我能力,你的經理可能會讓你監督更多的開發人員來執行這個專案。現在這是一些高級開發的東西。 💪 - 辨識並實施流程、工具或程式碼庫的改進。之前也提到過,但這裡的重點略有不同。表明您正在著眼於更大的前景並為組織的長期成功做出貢獻。 - 倡導最佳實踐並確保它們得到遵循。成為您專案中的蝙蝠俠—可靠、警惕並始終提供卓越服務。 🦇 ### 5.影響[\[🔝\]](#table-of-contents) 作為 SDE1,您的影響可能僅限於分配給您的任務和專案。然而,表現出更廣泛的理解並在你的直接職責之外做出貢獻可以讓你與眾不同。影響力不僅指你所做的事情,也指你的工作如何影響和造福你的團隊、你的專案和整個組織。 **太長了;博士** 做出改變。不只是做,而是改進。 ![往前想](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ikxg6wmu8bnj72alus4c.png) **不要局限於“你的工作”** - 了解您所從事的業務和行業。 - 確定改進或創新的機會。建議可以使團隊或產品受益的增強功能。 - 關注產品的最終用戶。了解他們的需求和痛點可以引導您做出更有影響力的貢獻。不要只是建立你要求的任何東西,還要分析你的努力對使用者和組織有多成功。 **為社區做出貢獻** - 參與內部和外部開發者社群。參加聚會、為開源專案做出貢獻或撰寫技術部落格。 - 分享您的知識和專業知識,幫助他人成長和學習。組織技術講座、網路研討會或程式設計訓練營或在技術講座、網路研討會或程式設計訓練營中發表演講。 - 與組織內的其他團隊合作。為跨職能專案提供協助和協作,以擴大您的影響力。 ![瑞安社區服務](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zh2nexhrfd6azq4cz6qm.gif) *您可能不會被「要求」在工作中幫助您的社區🤣* **積極主動地解決問題** - 超越任務的直接要求。考慮一下您的解決方案如何使其他專案或未來的工作受益。 - 養成批判性思考您使用的工具和流程的習慣。提出並實施可以節省時間、減少錯誤或提高效能的改進措施。 - 不要等待有人給您分配有影響力的工作。尋找機會做出有意義的貢獻,即使這意味著走出你的舒適圈。 有時您可能必須依賴第三方工具來辨識流程中的問題。像[中間件](https://github.com/middlewarehq/middleware)這樣的工具可以讓您發現軟體交付中的問題。現在這是高級開發人員的舉動。 {% 嵌入 https://github.com/middlewarehq/middleware %} **創新與改進** - 隨時了解您所在領域的最新趨勢和技術。嘗試可以使您的專案受益的新工具和方法。 - 考慮工作中的可擴展性和可維護性。設計系統並編寫可以隨著業務需求而成長和發展的程式碼。 - 鼓勵團隊內部的創新文化。促進腦力激盪會議和黑客馬拉松,以產生新的想法和解決方案。 **⏫ 進入 SDE2:** - 開始戰略性思考。找出對團隊目標和公司成功產生重大影響的方法。尋找您和團隊的工作模式,並提出可以使每個人受益的改進建議。大多數人都不太擅長這一點,所以如果你能做到這一點,那絕對會讓你脫穎而出。 - 領導推動創新和改進的措施。表明您可以創造性地思考並提出有效的解決方案。這可能涉及提出新功能、優化現有系統或改進開發流程。 - 倡導可以提高生產力或品質的新技術或方法。 🚀 帶頭將這些技術整合到您的專案中並指導其他人使用它們。 --- 請記住,從 SDE1 升級到 SDE2 以及更高版本是一個旅程。專注於你可以控制的事情,尋求回饋,並不斷改進。作為開發人員,您的成長是技術技能、生產力、協作、所有權和影響力的結合。透過奉獻和努力,您不僅會升級,而且會享受成為更好的工程師和有價值的團隊成員的過程。遊戲開始! 🎮 **PS:資深工程師擅長辨識阻礙團隊準時交付的各種問題,同時又不影響輸出品質。** 其中一些使用[中間件](https://github.com/middlewarehq/middleware)等工具。 {% 嵌入 https://github.com/middlewarehq/middleware %} --- 原文出處:https://dev.to/middleware/going-from-sde1-to-sde2-and-beyond-what-it-actually-takes-1cld

給中級開發人員的建議

序幕 == 我五年前寫了[這個博客](https://dev.to/rampa2510/3-tips-for-new-developers-49hj),當時我還是一名初級開發人員。我當時分享的技巧至今仍然是我遵循的規則,並且已經成為我不可或缺的一部分。作為一名開發人員,我已經成長了很多,所以現在我想作為中級開發人員回饋社區。 這裡提到的建議是針對那些熱愛自己的手藝並希望做得更好的人,不是為了更好的報酬,而是為了享受程式設計的樂趣。 1)熱愛你的工作 -------- 我看過人們把程式設計當作只是一份工作,只是為了錢。他們透過程式設計謀生並過上日常生活。這種生活方式很好,這是你的選擇。但如果你的技能沒有提高並且你變得停滯不前,請不要感到驚訝。要擅長編程,你必須熱愛你的工作。你一天的大部分時間都花在日常工作上編程,如果你不喜歡它,你就不會在工作的同時主動提高你的技能。 我有一個個人故事可以分享。我曾經在一家我討厭的公司工作過。我沒有主動改進程式碼庫或學習新東西來增強應用程式架構。現在,我從事著自己熱愛的工作,並將其視為自己的產品。這通常會引導我學習新事物並以結構良好的方式開發程式碼庫,因為我不想破壞它。如果你做你不喜歡的事,弊大於利。你可以在下班後學習,但你一天會浪費大約六個小時,但收效甚微。 2)成為多面手 ------- 永遠不要把自己放在一個盒子裡。不要認為自己只是前端開發人員或後端開發人員。將自己視為軟體開發人員。優秀的開發人員不會將自己局限於特定的技術,他們專注於解決問題,而不僅僅是問題的一部分。如果你將自己限制在某個堆疊上,你就不會成為一個偉大的問題解決者。軟體開發就是解決問題,如果你不了解如何建立端到端產品,你就不會成為一個好的問題解決者。 在職業生涯開始時,您可能必須選擇特定的堆疊來證明自己是一名出色的軟體開發人員。但不要讓它限制你。如果您在一家優秀的公司工作,請與資深或其他開發人員交談,以深入了解不同的團隊並學習新事物。開始負責公司程式碼庫的其他部分,以轉變為更全端的開發人員角色。這樣,您將開始更多地考慮解決整個問題,而不僅僅是解決部分問題。如果不歡迎您與其他堆疊一起工作,我建議您從事另一份工作。公司永遠不應該限制工程師的學習。 所以,做個多面手。不要將自己限制在堆疊的某一部分。學習作為軟體開發人員解決問題。通才發現更容易擅長解決特定問題,因為他們已經有了廣泛的理解,因此可以更快地掌握新技術。 3)永遠不要停止學習新技術(當修補匠) ------------------- 這是許多開發人員忽略的關鍵點。要成為優秀的問題解決者,您必須隨時了解科技的最新進展。我在嗜好專案中找到了很多樂趣,這幫助我發展了許多技能。當你修補新東西時,你會學到很多東西,而且你永遠不知道它什麼時候會變得有用。 例如,假設您的任務是為您的公司建立一個部落格應用程式。他們想要一個客製化的解決方案,而不是使用 Webflow 和其他類似服務的解決方案。如果您跟上了最新的進步,您可以使用 Supabase 或 Pocketbase 等現代 CMS 工具來快速開發後端。為您的部落格網站設定 CMS 可能只需要 30 分鐘,使您無需建立和管理資料庫和後端程式碼。然後你就可以根據你公司的需求專注於前端。 這是一個個人例子:我已經業餘學習了一個月的 Go。最近,我必須寫一個 cron 作業來每 30 分鐘更新一次使用者指標。我知道 Go 對於此類任務來說非常出色且速度非常快,因此我在 Go 中建立了 cron 作業,建置了二進位文件,並每 30 分鐘安排一個帶有計時器的系統守護程序任務。它工作效率高,消耗的資源更少。如果我沒有在業餘時間修修補補,只在日常工作中編寫程式碼,我就不會在合理的時間內想出最好的解決方案。 cron 作業將以 Node 編寫,隨著使用者群的成長,這將需要更多時間。 因此,永遠不要停止學習和創造。最好的學習方法是創造和修補。我一直在業餘學習 Ruby on Rails 和 Go,並且開始欣賞各種生態系統提供的不同功能。這幫助我將新想法融入我的工作流程中。 4)取得所有權 ------- 我最近觀看了 ThePrimagen 的一段[影片](https://www.youtube.com/watch?v=5i_O6NLXYsM&t=1586s),這激發了我寫這個博客的靈感。他提到解決問題或成為優秀軟體開發人員的最佳方法是擁有產品。他談到《毀滅戰士》是如何由四個人創造出來的,他們因為擁有所有權而交付瞭如此好的產品。他們知道自己沒有其他人可以依賴,因此他們將開發最好的軟體作為自己的責任。沒有備用計劃。 他們從未感到倦怠或放棄,因為他們擁有產品,而不僅僅是任務。 為了提高軟體開發人員的技能,您需要開始掌控您正在建立的產品,而不僅僅是功能或任務。當您將任何功能或錯誤視為您要解決的問題,而不僅僅是其他人的另一項任務時,您會發現開發產品會更加有趣。這是戰勝倦怠的最好方法。當您擁有所有權時,您會發現改進產品並使產品更有效率的樂趣。 如果你正在開發一個產品,當使用者發現它們時,你不能將出現的任何錯誤歸咎於其他人。如果出現問題,你就是問題的一部分,所以你必須承擔起解決問題的責任並創造出出色的產品。好的、可擴展的產品是由團隊建立的,如果你不承擔責任,你就不是一個好的團隊成員。當您擁有所有權時,您可以編寫最好的程式碼來建立最好的軟體,而不僅僅是另一個軟體產品。 就像製作《毀滅戰士》的四個人一樣,他們投入了大量的時間來創造屬於他們的東西,他們從不滿足於只是另一款遊戲,他們創造了一款定義時代的遊戲。其餘的,正如他們所說,是歷史。這同樣適用於你,如果你想製作最好的軟體,你必須開始擁有所有權並將該產品視為你自己的產品。 結語 == 寫完這個部落格並與社區分享我的想法後,我感覺很好。我們可能會爭論框架、語言和工具,但這些爭論有助於我們改進。他們推動技術進步,使我們的社區極具競爭力。讓我們保持激情! --- 原文出處:https://dev.to/rampa2510/advice-for-intermediate-developers-4777

建構強大的 CI/CD 管道:綜合指南

歡迎參加 DevSecOps in 5 的第 2 週:您獲得安全開發超級大國的門票! \_嘿,安全冠軍和編碼戰士! 您是否渴望提升 DevSecOps 水平並成為堅如磐石的軟體架構師?好吧,您來對地方了!這個為期 5 週的部落格系列是您掌握安全開發和部署的快速通道。 準備好拋棄開發戲劇,對您的安全實踐建立不可動搖的信心。我們同舟共濟,所以係好安全帶,讓我們踏上這段史詩般的旅程! --- 軟體開發環境處於不斷變化的狀態。更快的發布週期、不斷發展的技術以及不斷增長的品質需求正在推動團隊採用敏捷方法並擁抱自動化。進入 CI/CD 管道—簡化軟體交付背後的主力。這篇部落格深入探討了 CI/CD 的世界,提供了從入門到探索先進技術的全面指南。 為什麼 CI/CD 管道是您的秘密武器 ------------------- 在深入研究之前,讓我們先了解 CI/CD 管道無可否認的優勢: #### 更快的上市時間: 漫長的發布週期的日子已經一去不復返了。 CI/CD 可自動執行建置、測試和部署流程,從而實現頻繁且更快的部署。新功能可以更快地觸及用戶,保持他們的參與度並培養競爭優勢。 例:想像一家公司正在開發一個新的電子商務平台。透過實施 CI/CD 管道,他們可以自動部署新功能,例如改進的搜尋功能或更快的結帳流程。這使他們能夠快速響應用戶反饋和市場趨勢,在競爭中保持領先地位。 #### 提升軟體品質: 想像一下,儘早發現錯誤並在影響生產之前防止回歸。 CI/CD 在整個管道中整合了自動化測試。單元測試、集成測試,甚至端到端測試都可以無縫集成,確保每個階段的程式碼品質。 範例:開發金融服務應用程式的公司可以利用具有強大單元和整合測試的 CI/CD 管道。這確保帳戶管理和交易處理等關鍵功能在投入生產之前經過徹底測試,從而最大限度地減少錯誤和財務損失的風險。 #### 提高協作和效率: CI/CD 透過打破開發和營運團隊之間的孤島來促進協作。開發人員可以充滿信心地編寫程式碼,因為他們知道自動化測試提供了安全網。營運團隊受益於可預測和簡化的部署。這培育了一種共同所有權和責任的文化。 範例:在傳統的開發過程中,開發人員可能會將程式碼「越過牆」扔給操作,導致相互指責和延遲。透過 CI/CD 管道,兩個團隊都參與整個過程。開發人員可以看到他們的程式碼在自動化測試中的執行情況,而操作人員可以更了解即將進行的部署。這可以促進更順暢的協作和更快的問題解決。 設定您的第一個 CI/CD 管道(不僅僅是 Jenkins) ------------------------------ 雖然 Jenkins 仍然是一個流行的選擇,但 CI/CD 環境提供了大量工具來滿足您的特定需求。以下是一些受歡迎的競爭者,以及他們的優勢的簡要概述: #### GitLab CI/CD: 與 GitLab 緊密整合,實現無縫版本控制和 DevOps 工作流程。非常適合已經使用 GitLab 進行程式碼管理的團隊。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1masi4ldtu7fm6bz5kva.png) #### Circle CI: 基於雲端的平台以其易用性、可擴展性和注重開發人員體驗而聞名。對於尋求用戶友好且可擴展解決方案的團隊來說,這是一個不錯的選擇。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l3sozor0d4vf3iik92n6.png) #### Azure DevOps: Microsoft 提供全面的 DevOps 工具鏈,提供 CI/CD 管道以及建置管理和工件儲存庫等其他功能。非常適合大量投資於 Microsoft 生態系統的組織。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hxmg0lxkoduvbopjhtll.png) #### Travis CI: 開源平台以其簡單性和專注於持續整合而聞名。對於小型團隊或從 CI/CD 開始的團隊來說,這是一個不錯的選擇。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hd6fr17cr7ckgfn5isyl.png) 現在,讓我們探討 CI/CD 管道的常見階段及其用途: #### 程式碼提交: 將變更推送到版本控制系統 (VCS)(如 Git)的觸發點。 #### 建造: 程式碼被編譯成可部署的工件(例如,可執行檔、WAR 檔)。 #### 測試: 針對建置的工件執行自動化測試,以辨識任何錯誤或回歸。 #### 部署: 測試成功後,工件將部署到目標環境(暫存、生產)。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kr66y6ycum7sd9suxpdd.png) #### CI/CD 工作流程設定範例(使用 GitLab CI/CD): ``` stages: - build - test - deploy build: stage: build script: - npm install - npm run build test: stage: test script: - npm run test deploy: stage: deploy script: - scp -r dist/ user@server_ip:/var/www/html/my_app only: - master ``` 將版本控制與 CI/CD 整合:自動化的力量 ---------------------- VCS 在 CI/CD 管道中發揮著至關重要的作用。這就是它的工作原理: #### 版本控制系統 (VCS): Git 等工具追蹤程式碼更改,允許開發人員協作並在需要時恢復到先前的版本。 CI/CD 管道利用此功能來確保可追溯性並在部署失敗時促進回溯。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mikn0zfpeydo5oiv2mno.png) #### 管道執行的觸發器: CI/CD 管道可以設定為自動觸發 VCS 內的特定事件。常見的觸發因素包括: ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t3t78w8ex3pzkjpnwkg2.png) #### 程式碼提交: 每當開發人員將程式碼變更推送到特定分支時,管道就會啟動。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gxx9bnifs1go7mw4frhx.png) #### 合併到特定分支: 僅當程式碼合併到特定分支(例如 master 或 staging)時才能觸發管道。這允許對部署進行更多控制。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vwx42no4pb94b3xxovzw.png) #### 被推送的標籤: 將標籤推送到儲存庫可以觸發管道,通常用於與版本相關的部署。 #### 分支策略: CI/CD 管道可以客製化以適應不同的分支策略。以下是兩種常見的方法: #### 功能分支工作流程: 開發人員為開發工作建立功能分支。完成並進行程式碼審查後,程式碼將合併到主分支(例如 master),觸發 CI/CD 管道進行部署。這種方法允許單獨開發和測試新功能。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r8hmkjpemri80yjn2h9m.png) #### Git 流程工作流程: 此策略利用專用的開發分支進行持續開發。功能從開發中分支出來,並在測試後合併回來。合併以開發觸發 CI/CD 管道以部署到臨時環境。最後,從開發部署到生產需要手動升級。這種方法在開發、登台和生產環境之間提供了明確的分離。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6l6zc5zq47nljqjs17w4.png) #### 選擇分支策略: 最佳策略取決於您的團隊規模、專案複雜性以及所需的部署控制等級。功能分支工作流程適合專案較簡單的小型團隊。 Git Flow 為大型團隊或複雜專案提供了更多的環境控制和分離。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tsvx28v0iigzvwfobfng.png) 持續交付與持續部署: ---------- 了解差異 這些術語經常互換使用,但有一個關鍵區別: #### 持續部署: 成功完成管道後,變更將自動部署到生產中。這種方法需要強大的測試和對程式碼品質的高度信心。它非常適合風險承受能力低且注重快速迭代的應用程式。 範例:開發社交媒體應用程式的公司可能會利用持續部署來實現不影響核心功能的功能。自動化測試可確保品質,快速部署可實現快速實驗和功能推出。 #### 持續交付: 該管道自動建置、測試並部署到臨時環境。在部署到生產之前需要手動批准。這種方法為關鍵應用程式提供了一個安全網,並允許在實施變更之前進行手動監督。 例如:開發金融交易平台的公司可能會從持續交付中受益。管道成功執行後,部署將在投入生產之前進行分階段和審查。這確保了關鍵功能在影響現實世界的交易之前經過徹底的測試和批准。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7rlprqoto2rihmk28xu3.png) #### 選擇正確的策略: 持續部署和持續交付之間的選擇取決於以下因素: #### 風險承受能力: 對於具有高風險或影響的應用程式,可能首選透過手動批准進行持續交付。 #### 應用關鍵性: 關鍵任務應用程式可能會受益於生產部署之前手動批准的額外安全網。 #### 測試覆蓋範圍: 強大而全面的測試對於持續部署至關重要。如果測試範圍較小,則透過手動審核進行持續交付可能是更安全的選擇。 #### 回滾策略:總是有一個 B 計劃 無論您的 CI/CD 管道多麼細緻,都可能會出現不可預見的問題。制定回滾策略可確保您可以快速恢復到穩定狀態: ### 版本控制的救援: 如果部署出現問題,VCS 允許您輕鬆恢復到先前的程式碼提交。這是一種快速可靠的回滾部署方法。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/doul01tn1rf1bn51cs95.png) #### 回滾腳本: 在 CI/CD 管道中定義腳本,以便在發生故障時自動回滾部署。這可能涉及恢復基礎架構變更或降級配置。這些腳本提供了一種更自動化的回滾方法。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4swhforiux7h7sxnykkn.png) #### 藍/綠部署: 此策略涉及將新版本部署到單獨的環境(綠色),同時保持現有版本運作(藍色)。如果新版本正常執行,流量將切換到綠色環境。如果出現問題,可以無縫切換回藍色。藍/綠部署可最大限度地減少回滾期間的停機時間。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4rhcwn0cwttal0yfymgk.png) #### 選擇回滾策略: 最佳方法取決於您的特定需求。 VCS 回滾簡單可靠,但需要手動介入。回滾腳本提供自動化,但需要仔細的設計和測試。藍/綠部署提供了更強大的回滾方法,但可能需要額外的基礎設施設定。 將您的 CI/CD 管道提升到新的水平 ------------------- #### CI/CD 管道安全: 安全性在任何軟體開發過程中都是至關重要的,CI/CD 管道也不例外。以下是保護管道安全的一些最佳實踐: ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2hl4xwf0krot2nlx54p0.png) #### 管理秘密: 使用機密管理工具安全地儲存密碼、API 金鑰和資料庫憑證等敏感資訊。這些工具對機密進行加密並限制對 CI/CD 管道內授權使用者和應用程式的存取。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1ieww0aoauvexapf9dkq.png) #### 限制存取控制: 在 CI/CD 工具中定義明確的存取控制,以限制誰可以修改或觸發管道。實施基於角色的存取控制 (RBAC) 以根據使用者角色和職責授予權限。這確保只有授權的個人才能更改管道配置。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wxvwarjo75beumbr0swk.png) #### 定期安全審核: 對 CI/CD 管道進行定期安全審核,以辨識和解決潛在漏洞。這種主動方法可以最大限度地降低未經授權的存取或安全漏洞的風險。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p0gobpx2nw8b0u9e867h.png) #### 監控和記錄: 密切監控 CI/CD 管道的性能和錯誤檢測。實施日誌記錄解決方案來追蹤管道執行並辨識潛在的瓶頸或故障。用於監控和記錄的常用工具包括: ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fzg4r2y894s742wbxd04.png) #### 格拉法納: 一個開源平台,用於視覺化來自各種來源(包括 CI/CD 管道)的指標和日誌。這允許您建立儀表板來監控管道執行狀況、建置時間和部署成功率。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9vrob5ut2ipkrq6iz6y4.png) #### ELK 堆疊(Elasticsearch、Logstash、Kibana): 用於收集、儲存、分析和視覺化日誌的強大工具組合。您可以使用 ELK Stack 集中來自 CI/CD 管道和其他系統的日誌,以進行全面監控和故障排除。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gg5aqvi50jyoyd0rh81q.png) #### 內建監控工具: 許多 CI/CD 平台提供內建的監控和日誌記錄功能。利用這些工具深入了解管道執行並辨識潛在問題。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/djrjfa9uk1if4jux25zg.png) #### 不同程式語言的 CI/CD: CI/CD 管道與語言無關。特定於您的程式語言的建置工具和測試框架可以無縫整合在管道中。這裡有些例子: #### 爪哇: Maven 或 Gradle 等建置工具可用於自動化 Java 應用程式的建置流程。可以整合 JUnit 等測試框架以進行單元測試和整合測試。 #### JavaScript: 對於 JavaScript 專案,npm 或yarn 等工具可以管理依賴項。 Jest 或 Mocha 等測試框架可用於自動化測試。 #### Python: Python 專案經常利用 setuptools 或 Poetry 等建置工具。像unittest或pytest這樣的測試框架是自動化測試的流行選擇。 請記住:雖然 CI/CD 管道的核心概念在不同語言中保持一致,但特定工具和配置可能會有所不同。研究適合您選擇的程式語言的最佳實踐和工具,以優化您的 CI/CD 管道。 加深您的 CI/CD 專業知識:進階主題 -------------------- CI/CD 是一個不斷發展的領域。讓我們探索一些進階概念,將您的管道推向極限: #### 先進的 CI/CD 技術: #### 基礎設施即程式碼 (IaC): Terraform 或 Ansible 等工具可讓您將基礎架構配置定義為程式碼。這些配置可以整合到您的 CI/CD 管道中,以自動化基礎設施配置和管理。 IaC 促進基礎設施的一致性、可重複性,並減少手動配置錯誤。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rpivmcb9c1792csuhjdo.png) #### 與遺留系統的持續整合: 將遺留系統整合到 CI/CD 管道中可能具有挑戰性。策略包括使用包裝器或適配器透過 API 公開遺留功能。這允許遺留系統與管道互動以進行自動化測試和部署。 #### 藍/綠部署: 前面討論過,藍/綠部署可最大限度地減少應用程式更新期間的停機時間。透過先部署到單獨的環境,您可以確保在出現問題時無縫回滾。 #### 金絲雀部署: 此策略涉及將應用程式的新版本部署到一小部分使用者(金絲雀),以便在全面部署之前辨識並修復問題。金絲雀部署可讓您在將新版本公開給所有使用者之前在有限的範圍內測試新版本,從而最大限度地降低風險。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g5df1jw6f9ckmtop4t7y.png) #### 不同專案類型的 CI/CD: #### 微服務架構: 基於微服務的應用程式可以受益於旨在處理單一微服務的獨立建置、測試和部署的 CI/CD 管道。這允許更快地部署和更輕鬆地管理複雜的應用程式。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5uqrrbc30qetaklxuvmn.png) #### 使用 Docker 進行容器化: Docker 容器提供了一種打包和部署應用程式的標準化方法。 CI/CD 管道可用於跨環境自動建置和部署 Docker 映像。容器化簡化了部署並確保跨環境的應用程式行為一致。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xakuitegoux6baihwdb4.png) #### 用於機器學習 (ML) 專案的 CI/CD: 機器學習專案通常需要管理大型資料集和複雜模型。 CI/CD 管道可以客製化為: #### 自動化資料版本控制和管理: 確保用於培訓和測試的資料與程式碼變更一起進行追蹤和版本控制。這樣可以實現可重複性並更輕鬆地進行故障排除。 #### 整合模型訓練與測試: 在管道中利用 TensorFlow 或 PyTorch 等工具來自動化模型訓練和測試過程。這確保了模型在部署之前經過嚴格評估。 #### 管理模型部署: CI/CD 管道可用於將經過訓練的模型部署到生產環境。這簡化了流程並確保開發和生產模型之間的一致性。 持續改進與優化: -------- #### 效能優化: CI/CD 管道可能會遇到效能瓶頸,尤其是隨著專案的成長。以下是一些優化策略: #### 快取依賴: 快取經常使用的依賴項(例如,庫、套件)以減少建置期間的下載時間。這可以顯著提高建置速度,尤其是對於大型專案。 #### 並行化: 分解可以同時執行的管道階段(例如,不同模組的單元測試)並並行執行它們。這減少了整體管道執行時間。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tb4qguz8vmi4vb6anaiw.png) #### 資源優化: 根據管道階段的要求分配適當的資源(CPU、記憶體)。這確保了資源的有效利用並避免了瓶頸。 #### 指標和監控: 不要只是建立管道,還要積極監控其效能和運作狀況。就是這樣: #### 定義關鍵績效指標 (KPI): 確定代表管道有效性的指標,例如建置時間、部署頻率和回滾率。隨著時間的推移追蹤這些 KPI,以確定需要改進的領域。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8quogqkfkkjbkul4ype8.png) #### 利用監控工具: 實施 Grafana 或 Prometheus 等監控工具來視覺化管道指標並辨識潛在問題。這使您能夠主動解決瓶頸和效能下降。 #### 追蹤管道日誌: 日誌提供了有關管道執行的寶貴見解。利用 ELK Stack 等日誌分析工具來分析日誌並辨識可能表明潛在問題的錯誤或警告。 #### CI/CD 版本控制: 就像程式碼一樣對 CI/CD 管道配置進行版本控制。原因如下: #### 追蹤變化: 版本控制允許您追蹤對管道配置所做的更改,類似於追蹤程式碼更改的方式。這有助於在必要時進行回滾,並確保您可以恢復到先前的工作配置。 #### 協作與評審: 透過版本控制,多個團隊成員可以協作處理管道配置並在部署之前檢查變更。這可以促進最佳實踐並降低錯誤風險。 #### 災難復原: 如果您的 CI/CD 管道出現重大問題,版本控制可以讓您快速恢復到已知的良好狀態。這可以最大限度地減少停機時間並確保您可以從意外問題中恢復。 CI/CD 的未來:展望未來 -------------- CI/CD 格局不斷發展。以下是一些值得關注的令人興奮的趨勢: #### CI/CD 中的人工智慧和機器學習: 人工智慧可以自動化管道內的任務、優化資源分配並預測潛在問題。機器學習可用於分析歷史資料並提出管道的改進建議。這裡有些例子: ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/frk52c5r06hdj3dvhc6r.png) #### 自動測試用例產生: AI可用於分析程式碼並自動產生測試案例,提高測試覆蓋率並減少手動工作。 #### 預測管道分析: 機器學習演算法可以分析管道資料,以在潛在瓶頸或故障發生之前預測它們。這允許主動幹預並確保管道平穩執行。 #### 自癒管道: 想像一下可以自動偵測故障並從故障中恢復的管道。這可能涉及重新啟動失敗的階段或回滾部署。人工智慧和機器學習在開發自我修復管道方面可以發揮至關重要的作用。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9uf4xg8jl4yvtcy4fqyd.png) #### 無伺服器應用程式的 CI/CD: 無伺服器功能變得越來越流行。 CI/CD 管道可用於自動部署和管理無伺服器功能。就是這樣: ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f7lflsufhkb84dsqk7dk.png) #### 建置與打包無伺服器功能: CI/CD 管道可用於建置無伺服器函數並將其打包到特定於雲端提供者的部署工件中(例如,AWS Lambda 套件、Azure Functions)。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9mnbn81w0w66yw39aq3x.png) #### 部署和管理無伺服器功能: 此管道可以自動將無伺服器功能部署到目標雲端平台。此外,它還可以根據流量模式管理配置更新和擴充。 #### 監控和優化無伺服器功能: CI/CD 管道可以與監控工具集成,以追蹤無伺服器功能的效能和成本。這允許持續優化和成本管理。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4qv998kwcpr7cbo3fug4.png) 透過採用這些進步並不斷改進您的 CI/CD 實踐,您可以確保您的軟體交付快速、高效且可靠。以下是一些鞏固您的 CI/CD 知識的結論: CI/CD 是一段旅程,而不是目的地 建立防彈 CI/CD 管道是一個持續的過程。隨著專案的發展,調整和完善您的管道以滿足不斷變化的需求。隨時了解最新趨勢和工具,以持續優化您的 CI/CD 工作流程。 溝通和協作是關鍵成功的 CI/CD 管道需要開發、營運和安全團隊之間的密切協作。促進開放式溝通並鼓勵回饋,以確保管道符合每個人的需求。 測量和分析 不要只是建造管道並設置它就忘記它了。定期監控管道性能、分析指標並確定需要改進的領域。使用資料驅動的見解來優化您的 CI/CD 流程並確保其提供最大價值。 結論 -- CI/CD 管道是現代軟體開發的主力。透過了解本綜合指南中探討的核心概念、最佳實踐和先進技術,您可以幫助您的團隊更快、更有效率地交付高品質的軟體。擁抱 CI/CD,不斷改進您的管道,並見證您的軟體交付飆升至新的高度。 --- 我很高興有機會與您一起深入研究《建立防彈 CI/CD 管道:綜合指南》。這是一個令人著迷的領域,具有改善安全狀況的巨大潛力。 感謝您與我一起探索《建立防彈 CI/CD 管道:綜合指南》。您持續的興趣和參與推動了這趟旅程! 如果您發現有關建立防彈 CI/CD 管道:綜合指南的討論有幫助,請考慮與您的網路分享!知識就是力量,尤其是在安全方面。 讓我們繼續談話吧!在下面的評論中分享您的想法、問題或經驗《建立防彈 CI/CD 管道:綜合指南》。 渴望了解有關 DevSecOps 最佳實踐的更多資訊?請繼續關注下一篇文章! 透過共同努力並採用安全的開發實踐,我們可以建立一個更具彈性和值得信賴的軟體生態系統。 請記住,安全開發之旅是一個持續學習的過程。這是為了持續改進! --- 原文出處:https://dev.to/gauri1504/building-a-bulletproof-cicd-pipeline-a-comprehensive-guide-3jg3

✨ 6 個您應該造訪的學習寶石網站!

介紹 -- 那麼您是軟體開發人員?太棒了。您可以建立應用程式並製作💸💸💸,但是您是否考慮過長期場景或您是否真正意識到這一點? 在五年的軟體開發生涯中,建立應用程式並不是為了完成工作或為啟動活動提供軟體。這不是🙅‍♂️。 如果您是優秀的開發人員,您應該了解軟體的後期開發階段... 🤨:來吧,我的「學習寶石」在哪裡?標題不是關於工程職位的! 好吧,我知道這跟工程職位無關。美好的! 但... ![阿塞爾瓦斯格爾](https://i.pinimg.com/564x/5c/89/b7/5c89b75128a05063ddfccbf36be74e75.jpg) 讓我們透過這些精彩的學習材料來增強我們的知識!從如何建立應用程式、編寫可維護的程式碼,甚至了解 CPU 的實際運作原理! 順便說一句,讓我們向所有製作這些優秀學習材料的作者致敬🙇‍♂️! [模式.dev](https://www.patterns.dev/) ----------------------------------- ![圖案縮圖](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a2sca89gm5igy58byojn.png) Patterns.dev 由 Addy Osmani 和 Lydia Hallie 建立,旨在幫助您將網站架構提升到新的水平。 Patterns.dev 將幫助您設計、渲染和效能模式,以便使用普通 JavaScript 或現代框架建立強大的 Web 應用程式。 [將“你”放入CPU](https://cpu.land/) ------------------------------ ![CPU 區域縮圖](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xqdzvm4uaub99aop9g70.png) 接下來,我們有CPU Land! 你有沒有想過CPU在幕後到底是如何運作的? 🤨:如果它已經在幕後工作了,為什麼我還要考慮它? 阿喲,兄弟。來吧,你是認真的嗎?你不會被人工智慧取代吧? 這就是為什麼你應該知道 CPU 如何執行你的程式! 幸運的是,這個網站為您提供了幫助。在這裡,您可以了解多處理的工作原理、系統呼叫的真正含義、電腦如何透過硬體中斷管理記憶體以及 Linux 如何載入可執行檔。 感謝 Lexi Mattick 建立了這個網站! [重構大師](https://refactoring.guru/) --------------------------------- ![重構大師縮圖](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/j2fubawobhmqkyogab86.png) 🤨:啊,我不想碰這個程式碼庫。很脆弱! 嘿,你兩年前寫了這段程式碼... 🤨:啊,對不起。我的意思是是的...為什麼你不給我一些解決方案,阿克巴? 我?沒有人,但是 Refactoring Guru 可以幫助你! Alexander Shvets 已經建立了很酷的網站來重構您的 💩 程式碼庫。這個網站將改變您對如何建立可長期維護的東西的看法。 [元件庫](https://component.gallery/) --------------------------------- ![元件庫縮圖](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jqsl23fpudyj78pn8k2f.png) 對 UI 元件的命名及其外觀感到困惑嗎?不用擔心,我經常遇到這個問題。但幸運的是,Iain Bean 建立了 Component Gallery 網站! 在這裡,我們沒有看到預先建置的 UI 元件,而是為您提供了元件應該是什麼樣子以及它的具體用途。 [學習 Git 支撐](https://learngitbranching.js.org/) ---------------------------------------------- ![學習 Git 支撐縮圖](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jbqvf9qc0jszns878xwk.png) 我有一個表情包給你,你去看看吧… ![凱伊瑟爾](https://miro.medium.com/v2/resize:fit:600/0*VcMPr1unIjAIHw2j.jpg) 但是,除非你知道如何正確使用 Git,否則它只是模因。如果你不這樣做,不用擔心。只需學習 Git 分支即可! Peter Cottle 建立此網站是為了幫助您以互動方式學習 Git。你知道,因為如果你能將某件事形象化,就更容易理解它。 [十二要素應用程式](https://www.12factor.net/) ------------------------------------- ![十二要素應用程式縮圖](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ojf6okkbrng5meghecwe.png) 最後一個是十二要素應用程式! 您將學習如何在微服務叢集中建置 SaaS 或簡單的服務。在這裡,您不是了解使用了什麼技術,而是了解使您的應用程式可移植且易於在任何地方部署的意識形態或概念! 讓我們感謝亞當·威金斯的奉獻精神。 結論 -- 好吧,現在你已經知道了。不要放棄並保持學習精神。歸根結底,這只是某人的寫作,但它的價值在於當你應用它並且它起作用時。 如果您有任何建議,請隨時在下面的評論部分寫下來! 再見! ![烹飪霍馬特](https://i.pinimg.com/564x/2e/84/89/2e84892562d68742930e7641520beb38.jpg) --- 原文出處:https://dev.to/thexdev/5-website-learning-gems-you-should-visit-2pn5

使用 NextJS 建立電子商務商店

在本教程中,您將學習如何建立電子商務商店,客戶可以在其中透過 Stripe 購買產品並付款。成功付款後,將向客戶發送電子郵件通知,並向管理員用戶發送應用程式內通知。管理員用戶也可以在應用程式中建立和刪除產品。 為了建立這個應用程式,我們將使用以下工具: - [Appwrite](https://appwrite.io/) - 用於驗證使用者身份,以及保存和檢索產品詳細資訊。 - [Next.js](https://nextjs.org/) - 用於建立應用程式的使用者介面和後端。 - [Novu](https://docs.novu.co/getting-started/introduction) - 用於發送電子郵件和應用程式內通知。 - [React Email](https://react.email/docs/introduction) - 用於建立電子郵件範本。 - [Stripe](https://docs.stripe.com/) - 用於將付款結帳整合到應用程式中。 ![應用程式](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t02iyysrqjfqw8imuqxn.png) --- 使用 Next.js 建立應用程式介面 ------------------- 應用程式頁面根據指派給使用者的角色分為兩部分。客戶可以在付款前存取主頁並登入應用程式。管理員使用者可以存取所有頁面,包括登入頁面和儀表板頁面,他們可以在其中新增和刪除產品。 現在,讓我們建立應用程式。 ![https://media1.giphy.com/media/iopxsZtW2QVRs4poEC/giphy.gif?cid=7941fdc6aot3qt7vvq4voh5c1iagyusdpuga713m8ljqcqmd&ep=v1_gifs_searchiagyusdpuga713m8ljqcqmd&ep=v1_gifs_searchiagyusdpugagif&ct](https://media1.giphy.com/media/iopxsZtW2QVRs4poEC/giphy.gif?cid=7941fdc6aot3qt7vvq4voh5c1iagyusdpuga713m8ljqcqmd&ep=v1_gifs_search&rid=giphy.gif&ct=g) 透過執行以下程式碼片段來建立一個新的 Next.js Typescript 專案: ``` npx create-next-app novu-store ``` 接下來,安裝[React Icons](https://react-icons.github.io/react-icons)和[Headless UI](https://headlessui.com/)包。 React Icons 允許我們在應用程式中使用各種圖標,而 Headless UI 則提供易於使用的現代 UI 元件。 ``` npm install react-icons @headlessui/react ``` 將此程式碼片段從[GitHub 儲存庫](https://github.com/dha-stix/ecom-store-with-nextjs-appwrite-novu-and-stripe/blob/main/src/app/page.tsx)複製到`app/page.tsx`檔案中。它在螢幕上呈現產品列表,並允許用戶選擇購物車中的商品,類似於下圖。 ![1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dj69givzhqfapgsg12rk.gif) 建立登入路由,使用戶能夠使用其 GitHub 帳戶進行簽署。將下面的程式碼片段複製到`app/login/page.tsx`檔案中。 ``` //👉🏻 create a login folder containing a page.tsx file export default function Home() { const handleGoogleSignIn = async () => {}; return ( <main className='w-full min-h-screen flex flex-col items-center justify-center'> <h2 className='font-semibold text-3xl mb-2'>Customer Sign in</h2> <p className='mb-4 text-sm text-red-500'> You need to sign in before you can make a purchase </p> <button className='p-4 border-[2px] border-gray-500 rounded-md hover:bg-black hover:text-white w-2/3' onClick={() => handleGoogleSignIn()} > Sign in with GitHub </button> </main> ); } ``` ![客戶登入](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3nh2rowpfg4hgksj5diy.png) 當使用者點擊「登入」按鈕時,會將他們重新導向到 GitHub 驗證頁面並提示他們登入應用程式。您很快就會了解如何使用[Appwrite](https://appwrite.io/)執行此操作。 接下來,讓我們建立管理頁面。在`app`資料夾中新增包含`login`和`dashboard`路由的`admin`資料夾。 ``` cd app mkdir admin && cd admin mkdir dashboard login ``` 在`dashboard`和`login`資料夾中新增`page.tsx`文件,並將下面的程式碼片段複製到`login/page.tsx`檔案中。 ``` "use client"; import Link from "next/link"; import { useState } from "react"; export default function Login() { const [email, setEmail] = useState<string>(""); const [password, setPassword] = useState<string>(""); const handleLogin = async (e: React.FormEvent) => { e.preventDefault(); console.log({ email, password }); }; return ( <main className='w-full min-h-screen flex flex-col items-center justify-center'> <h2 className='font-semibold text-3xl mb-4'> Admin Sign in</h2> <form className='w-2/3' onSubmit={handleLogin}> <label htmlFor='email' className='block'> Email </label> <input type='email' id='email' className='w-full px-4 py-3 border border-gray-400 rounded-sm mb-4' required value={email} placeholder='[email protected]' onChange={(e) => setEmail(e.target.value)} /> <label htmlFor='password' className='block'> Password </label> <input type='password' id='password' className='w-full px-4 py-3 border border-gray-400 rounded-sm mb-4' required value={password} placeholder='admin123' onChange={(e) => setPassword(e.target.value)} /> <button className='p-4 text-lg mb-3 bg-blue-600 text-white w-full rounded-md'> Sign in </button> <p className='text-sm text-center'> Not an Admin?{" "} <Link href='/login' className='text-blue-500'> Sign in as a Customer </Link> </p> </form> </main> ); } ``` 上面的程式碼片段呈現一個表單,該表單接受管理員的電子郵件和密碼,驗證憑證,然後將使用者登入應用程式中。 ![管理員登入](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gjd9wsi63t96d5cls9om.png) 管理儀表板頁面呈現可用的產品,並允許管理員使用者在應用程式中新增和刪除產品。將此[程式碼片段複製](https://github.com/dha-stix/ecom-store-with-nextjs-appwrite-novu-and-stripe/blob/main/src/app/admin/dashboard/page.tsx)到`dashboard/page.tsx`檔案中以建立使用者介面。 ![2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p1gd1uq1eq6n76fesjxu.gif) 恭喜!您已經建立了應用程式介面。在接下來的部分中,您將了解如何將應用程式連接到 Appwrite 後端並在客戶端和伺服器之間發送資料。 --- 如何將 Appwrite 新增到 Next.js 應用程式 ----------------------------- Appwrite 是一項開源後端服務,可讓您建立安全且可擴展的軟體應用程式。它提供多種身份驗證方法、安全性資料庫、文件儲存、雲端訊息傳遞等功能,這些對於建立全端應用程式至關重要。 在本部分中,您將了解如何設定 Appwrite 專案,包括身份驗證、資料庫和檔案儲存等功能。 首先,請造訪[Appwrite Cloud](https://cloud.appwrite.io/register) ,並為您的專案建立一個帳戶和組織。 接下來,建立一個新專案並選擇您的首選區域來託管該專案。 ![應用程式寫入1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/as6302olk60oklfo70x5.png) 選擇`Web`作為應用程式的平台 SDK。 ![應用程式編寫2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bb5ae82i9fyoyrowsy96.png) 請依照螢幕上顯示的步驟進行操作。由於您目前正在開發模式下建置,因此您可以使用通配符 ( `*` ) 作為主機名,並在部署應用程式後將其變更為您的網域名稱。 ![應用程式寫入3](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y5ccs0hzgs9ujf5lzh83.png) 在 Next.js 專案中安裝 Appwrite 用戶端 SDK。 ``` npm install appwrite ``` 最後,在 Next.js 應用程式資料夾中建立一個`appwrite.ts`文件,並將下面的程式碼片段複製到該文件中以初始化 Appwrite。 ``` import { Client, Account, Databases, Storage } from "appwrite"; const client = new Client(); client .setEndpoint("https://cloud.appwrite.io/v1") .setProject(<YOUR_PROJECT_ID>); export const account = new Account(client); export const db = new Databases(client); export const storage = new Storage(client); ``` ### 使用 Appwrite 設定 GitHub 身份驗證 在這裡,您將了解如何使用 Appwrite 設定 GitHub 和電子郵件/密碼驗證。預設已配置電子郵件/密碼身份驗證,因此我們專注於設定 GitHub 身份驗證。 在繼續之前,您需要使用您的 GitHub 帳戶建立[GitHub OAuth 應用程式](https://github.com/settings/developers)。 Appwrite 將需要客戶端 ID 和金鑰來設定 GitHub 身份驗證。 ![GitHub 1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9znk1yr7tffus7soitq2.png) 透過從側邊欄選單中選擇`Auth`並導覽至`Settings`選項卡,啟用 Appwrite 的 GitHub 驗證方法。 ![應用程式編寫4](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/43uo6nho1bz9su14zsno.png) 將您的 GitHub 用戶端 ID 和金鑰複製到 Appwrite 的 GitHub OAuth 設定中。 最後,確保將 Appwrite 產生的 URI 複製到 GitHub 應用程式設定中。 ![GitHub 2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g75q5r5hc6l5pi09k88m.png) ### 設定 Appwrite 資料庫 從側邊欄選單中選擇資料庫並建立新資料庫。您可以將其命名為`novu store` 。 ![應用程式寫入5](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y7kn1llmu7olqirfcrpa.png) 接下來,建立`products`集合。它將包含應用程式中的產品清單。 ![應用程式寫入 6](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7p8laty6z37x0q1g6az4.png) 將名稱、價格和圖像屬性新增至集合。 ![應用程式寫入 7](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nzom3ptlz8t1rh9dtt1k.png) 在「設定」標籤下,更新權限以允許每個使用者執行 CRUD 操作。但是,您可以在部署應用程式後變更此設置,以確保只有經過身份驗證的使用者才能執行各種操作。 ![應用程式寫入 8](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/37cqr8s0crtcttocjagk.png) 最後,將專案、資料庫和集合 ID 複製到**`.env.local`**檔案中。這可以確保您的憑證安全,並允許您引用其環境變數中的每個值。 ``` NEXT_PUBLIC_PROJECT_ID=<YOUR_PROJECT_ID> NEXT_PUBLIC_DB_ID=<YOUR_DATABASE_ID> NEXT_PUBLIC_PRODUCTS_COLLECTION_ID=<YOUR_DB_COLLECTION_ID> ``` ### 設定應用程式寫入存儲 從側邊欄選單中選擇`Storage` ,然後建立新儲存桶來儲存所有產品影像。 ![應用程式編寫 9](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b84t9mk3k0wrkgiy4uca.png) 在`Settings`標籤下,更新「權限」以暫時允許任何使用者。 ![應用程式寫入 10](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zi3iozkaera7fohkwanm.png) 設定可接受的文件格式。由於我們上傳的是圖像,因此您可以選擇**`.jpg`**和**`.png`**檔案格式。 ![應用寫入 11](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zzxqpoq5dcpokkvdcsce.png) 最後,將您的儲存桶 ID 複製到`.env.local`檔案中。 ``` NEXT_PUBLIC_BUCKET_ID=<YOUR_BUCKET_ID> ``` 恭喜!您已成功配置 Appwrite。我們現在可以開始與其各種功能進行互動。 --- 如何使用Appwrite執行CRUD操作 -------------------- 在本部分中,您將了解如何從 Appwrite 建立、檢索和刪除產品。用戶需要能夠在購買前查看現有產品,而管理員用戶應有權在應用程式中新增和刪除產品。 首先,在 Next.js **`app`**資料夾中建立一個**`utils.ts`**檔案。該文件將包含所有 Appwrite 資料庫交互,然後您可以將其導入到必要的頁面中。 ``` cd app touch utils.ts ``` ### 將產品儲存到 Appwrite 回想一下, `products`集合有三個屬性:名稱、圖像和價格。因此,在將產品新增至資料庫時,您需要先上傳產品的圖像,從回應中檢索其 URL 和 ID,然後將 URL 作為產品的圖像屬性上傳,使用圖像的儲存 ID 作為產品資料。 這是解釋這一點的程式碼片段: ``` import { db, storage } from "@/app/appwrite"; import { ID } from "appwrite"; export const createProduct = async ( productTitle: string, productPrice: number, productImage: any ) => { try { //👇🏻 upload the image const response = await storage.createFile( process.env.NEXT_PUBLIC_BUCKET_ID!, ID.unique(), productImage ); //👇🏻 get the image's URL const file_url = `https://cloud.appwrite.io/v1/storage/buckets/${process.env.NEXT_PUBLIC_BUCKET_ID}/files/${response.$id}/view?project=${process.env.NEXT_PUBLIC_PROJECT_ID}&mode=admin`; //👇🏻 add the product to the database await db.createDocument( process.env.NEXT_PUBLIC_DB_ID!, process.env.NEXT_PUBLIC_PRODUCTS_COLLECTION_ID!, response.$id, //👉🏻 use the image's ID { name: productTitle, price: productPrice, image: file_url, } ); alert("Product created successfully"); } catch (err) { console.error(err); } }; ``` 上面的程式碼片段將圖像上傳到 Appwrite 的雲端存儲,並使用儲存桶 ID、圖像 ID 和專案 ID 檢索準確的圖像 URL。圖片成功上傳後,其 ID 將用於產品資料中,以便輕鬆檢索和參考。 ### 從 Appwrite 檢索產品 若要從 Appwrite 取得產品,您可以在頁面載入時在 React **`useEffect`**掛鉤中執行下列函數。 ``` export const fetchProducts = async () => { try { const products = await db.listDocuments( process.env.NEXT_PUBLIC_DB_ID!, process.env.NEXT_PUBLIC_PRODUCTS_COLLECTION_ID! ); if (products.documents) { return products.documents; } } catch (err) { console.error(err); } }; ``` `fetchProducts`函數傳回`products`集合中的所有資料。 ### 從 Appwrite 中刪除產品 管理員使用者也可以透過產品 ID 刪除產品。 **`deleteProduct`**函數接受產品的 ID 作為參數,並從資料庫中刪除所選產品(包括其圖像),因為它們使用相同的 ID 屬性。 ``` export const deleteProduct = async (id: string) => { try { await db.deleteDocument( process.env.NEXT_PUBLIC_DB_ID!, process.env.NEXT_PUBLIC_PRODUCTS_COLLECTION_ID!, id ); await storage.deleteFile(process.env.NEXT_PUBLIC_BUCKET_ID!, id); alert("Product deleted successfully"); } catch (err) { console.error(err); } }; ``` --- 如何使用 Appwrite 驗證使用者身份 --------------------- 在前面的部分中,我們已經設定了 GitHub 身份驗證方法。在這裡,您將了解如何處理使用者登入應用程式。 若要使客戶能夠使用其 GitHub 帳戶登入應用程式,請在按一下`Sign in`按鈕時執行以下功能。該函數將使用者重定向到 GitHub,在那裡他們可以向應用程式授權或授予權限,然後登入應用程式: ``` import { account } from "../appwrite"; import { OAuthProvider } from "appwrite"; const handleGoogleSignIn = async () => { try { account.createOAuth2Session( OAuthProvider.Github, "http://localhost:3000", "http://localhost:3000/login" ); } catch (err) { console.error(err); } }; ``` 管理員使用者可以使用電子郵件和密碼登入應用程式。 Appwrite 在授予對應用程式儀表板的存取權之前會驗證憑證。 ``` import { account } from "@/app/appwrite"; const handleLogin = async (e: React.FormEvent) => { e.preventDefault(); try { await account.createEmailPasswordSession(email, password); alert(`Welcome back 🎉`); router.push("/admin/dashboard"); } catch (err) { console.error(err); alert("Invalid credentials ❌"); } }; ``` Appwrite 還允許您取得目前使用者的資料。例如,如果只有經過身份驗證的使用者才能付款,您可以透過執行下面的程式碼片段來完成此操作。它會檢索目前使用者的資料,如果使用者未登錄,則傳回 null。 ``` import { account } from "@/app/appwrite"; useEffect(() => { const checkAuthStatus = async () => { try { const request = await account.get(); setUser(request); } catch (err) { console.log(err); } }; checkAuthStatus(); }, []); ``` --- 如何將 Stripe 付款結帳新增至 Next.js -------------------------- 在本節中,您將了解如何在應用程式中實現 Stripe 付款結帳。 Stripe 是一種流行的線上支付處理平台,可讓您建立產品並將一次性和定期支付方式整合到您的應用程式中。 首先,您需要[建立一個 Stripe 帳戶](https://dashboard.stripe.com/login)。您可以在本教學中使用測試模式帳戶。 ![條紋1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nibs7bxb09i167mxm918.png) 點擊頂部選單中的`Developers` ,然後從 API 金鑰選單中複製您的金鑰。 ![條紋2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/up8757knbquc3k0577ps.png) 將您的 Stripe 金鑰貼到`.env.local`檔案中。 ``` STRIPE_SECRET_KEY=<your_secret_key> ``` 安裝[Stripe Node.js SDK](https://docs.stripe.com/libraries) 。 ``` npm install stripe ``` 接下來,在 Next.js `app`資料夾中建立一個`api`資料夾。 `api`資料夾將包含應用程式的所有 API 路由和端點。 ``` cd app mkdir api ``` 透過在`api`資料夾中新增`checkout`資料夾來建立`checkout`端點。 ``` cd api mkdir checkout && cd checkout touch route.ts ``` 將下面的程式碼片段複製到`route.ts`檔中。 ``` import { NextRequest, NextResponse } from "next/server"; import Stripe from "stripe"; const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!); export async function POST(req: NextRequest) { //👇🏻 accepts the customer's cart const cart = await req.json(); try { //👇🏻 creates a checkout session const session = await stripe.checkout.sessions.create({ payment_method_types: ["card"], line_items: cart.map((product: Product) => ({ price_data: { currency: "usd", product_data: { name: product.name, }, unit_amount: product.price * 100, }, quantity: 1, })), mode: "payment", cancel_url: `http://localhost:3000/?canceled=true`, success_url: `http://localhost:3000?success=true&session_id={CHECKOUT_SESSION_ID}`, }); //👇🏻 return the session URL return NextResponse.json({ session: session.url }, { status: 200 }); } catch (err) { return NextResponse.json({ err }, { status: 500 }); } } ``` 上面的程式碼片段建立了一個接受 POST 請求的結帳端點。它為客戶建立結帳會話並傳回會話 URL。 **`cancel_url`**和**`success_url`**確定完成或取消付款後將用戶重新導向到何處。 最後,當用戶決定為產品付款時,您可以透過執行以下程式碼片段將客戶的購物車發送到`/checkout`端點: ``` const processPayment = async (cart: Product[]) => { try { if (user !== null) { //👇🏻 saves cart to local storage localStorage.setItem("cart", JSON.stringify(cart)); //👇🏻 sends cart to /checkout route const request = await fetch("/api/checkout", { method: "POST", body: JSON.stringify(cart), headers: { "Content-Type": "application/json" }, }); //👇🏻 retrieves the session URL const { session } = await request.json(); //👇🏻 redirects the user to the checkout page window.location.assign(session); } else { //👇🏻 redirects unauthenticated users router.push("/login"); } } catch (err) { console.error(err); } }; ``` 上面的程式碼片段將購物車儲存到瀏覽器的本機儲存體並將其傳送到 API 端點,然後從後端伺服器檢索回應(會話 URL)並將使用者重新導向至 Stripe 結帳頁面。 ![條紋3](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i5hokf2qyqyey3kwsg9x.gif) --- 使用 Novu 發送應用程式內通知和電子郵件通知 ------------------------ [Novu](https://github.com/novuhq/novu)是第一個提供統一 API 的通知基礎架構,用於透過多種管道(包括應用程式內、推播、電子郵件、簡訊和聊天)發送通知。 在本部分中,您將了解如何將 Novu 加入到您的應用程式,以便您能夠發送電子郵件和應用程式內訊息。 首先,安裝所需的 Novu 軟體包: ``` npm install @novu/node @novu/echo @novu/notification-center ``` 當用戶進行購買時,他們將收到一封付款確認電子郵件,管理員用戶也會收到一條應用程式內通知。 為此,您需要[在 Novu 上建立帳戶](https://web.novu.co/auth/login)並設定主要電子郵件提供者。在本教程中,我們將使用[“重新發送”](https://resend.com/docs/introduction) 。 在 Novu 上建立帳戶後,建立一個[重新傳送帳戶](https://resend.com/docs/introduction),然後從儀表板上的側邊欄選單中選擇`API Keys`來建立帳戶。 ![重新發送 1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jhehx7s45x180zpir1ti.png) 接下來,回到 Novu 儀表板,從側邊欄選單中選擇`Integrations Store` ,然後新增 Resend 作為電子郵件提供者。您需要將重新傳送 API 金鑰和電子郵件地址貼到必填欄位中。 ![新 1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f03vb6nftyi8g790vg7m.png) 從側邊欄選單中選擇**「設定」** ,然後將您的`Novu API`金鑰和`App ID`複製到**`.env.local`**檔案中,如下所示。另外,將您的`subscriber ID`複製到其欄位中 - 您可以從`Subscribers`部分獲取此資訊。 ``` NOVU_API_KEY=<YOUR_API_FOR_NEXT_SERVER> NEXT_PUBLIC_NOVU_API_KEY=<YOUR_API_FOR_NEXT_CLIENT> NEXT_PUBLIC_NOVU_APP_ID=<YOUR_API_ID> NOVU_SUBSCRIBER_ID=<YOUR_API_FOR_NEXT_SERVER> NEXT_PUBLIC_NOVU_SUBSCRIBER_ID=<YOUR_API_FOR_CLIENT> ``` ![新2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/voeofvvtv88pex9rpr1s.png) 最後,將 Novu 通知鈴新增至管理儀表板,以使管理員使用者能夠在應用程式內接收通知。 ``` import { NovuProvider, PopoverNotificationCenter, NotificationBell, } from "@novu/notification-center"; export default function AdminNav() { return ( <NovuProvider subscriberId={process.env.NEXT_PUBLIC_NOVU_SUBSCRIBER_ID!} applicationIdentifier={process.env.NEXT_PUBLIC_NOVU_APP_ID!} > <PopoverNotificationCenter colorScheme='light'> {({ unseenCount }) => <NotificationBell unseenCount={unseenCount} />} </PopoverNotificationCenter> </NovuProvider> ); } ``` ![儀表板](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m62ft87ue9orse2yww9z.png) --- 如何使用 Novu Echo 建立通知工作流程 ----------------------- [Novu](https://docs.novu.co/echo/quickstart)提供程式碼優先的工作流程引擎,讓您能夠在程式碼庫中建立通知工作流程。它允許您將電子郵件、簡訊、聊天範本和內容產生器(例如[React Email](https://react.email/docs/introduction)和[MJML](https://mjml.io/) )整合到 Novu 中,以建立高級且強大的通知。 在本部分中,您將了解如何在應用程式中建立通知工作流程、如何使用 Novu 的電子郵件通知範本以及如何使用 Novu 發送應用程式內通知和電子郵件通知。 透過執行以下命令安裝[React Email](https://react.email/docs/introduction) : ``` npm install react-email @react-email/components -E ``` 將以下腳本包含在您的 package.json 檔案中。 `--dir`標誌使 React Email 能夠存取位於專案內的電子郵件範本。在本例中,電子郵件範本位於`src/emails`資料夾中。 ``` { "scripts": { "email": "email dev --dir src/emails" } } ``` 接下來,在 Next.js `app`資料夾中建立一個包含`email.tsx`的`emails`資料夾,並將以下程式碼片段複製到該檔案中: ``` import { Body, Column, Container, Head, Heading, Hr, Html, Link, Preview, Section, Text, Row, render, } from "@react-email/components"; import * as React from "react"; const EmailTemplate = ({ message, subject, name, }: { message: string; subject: string; name: string; }) => ( <Html> <Head /> <Preview>{subject}</Preview> <Body style={main}> <Container style={container}> <Section style={header}> <Row> <Column style={headerContent}> <Heading style={headerContentTitle}>{subject}</Heading> </Column> </Row> </Section> <Section style={content}> <Text style={paragraph}>Hey {name},</Text> <Text style={paragraph}>{message}</Text> </Section> </Container> <Section style={footer}> <Text style={footerText}> You&apos;re receiving this email because your subscribed to Newsletter App </Text> <Hr style={footerDivider} /> <Text style={footerAddress}> <strong>Novu Store</strong>, &copy;{" "} <Link href='https://novu.co'>Novu</Link> </Text> </Section> </Body> </Html> ); export function renderEmail(inputs: { message: string; subject: string; name: string; }) { return render(<EmailTemplate {...inputs} />); } const main = { backgroundColor: "#f3f3f5", fontFamily: "HelveticaNeue,Helvetica,Arial,sans-serif", }; const headerContent = { padding: "20px 30px 15px" }; const headerContentTitle = { color: "#fff", fontSize: "27px", fontWeight: "bold", lineHeight: "27px", }; const paragraph = { fontSize: "15px", lineHeight: "21px", color: "#3c3f44", }; const divider = { margin: "30px 0", }; const container = { width: "680px", maxWidth: "100%", margin: "0 auto", backgroundColor: "#ffffff", }; const footer = { width: "680px", maxWidth: "100%", margin: "32px auto 0 auto", padding: "0 30px", }; const content = { padding: "30px 30px 40px 30px", }; const header = { borderRadius: "5px 5px 0 0", display: "flex", flexDireciont: "column", backgroundColor: "#2b2d6e", }; const footerDivider = { ...divider, borderColor: "#d6d8db", }; const footerText = { fontSize: "12px", lineHeight: "15px", color: "#9199a1", margin: "0", }; const footerLink = { display: "inline-block", color: "#9199a1", textDecoration: "underline", fontSize: "12px", marginRight: "10px", marginBottom: "0", marginTop: "8px", }; const footerAddress = { margin: "4px 0", fontSize: "12px", lineHeight: "15px", color: "#9199a1", }; ``` 上面的程式碼片段使用 React Email 建立了一個可自訂的電子郵件範本。您可以找到更多[易於編輯的靈感或模板](https://demo.react.email/preview/notifications/vercel-invite-user)。該元件還接受訊息、主題和名稱作為屬性,並將它們填入元素中。 最後,您可以在終端機中執行`npm run email`來預覽範本。 接下來,讓我們將電子郵件範本整合到 Novu Echo 中。首先,關閉 React Email 伺服器,然後執行下面的程式碼片段。它會在瀏覽器中開啟[Novu Dev Studio](https://docs.novu.co/echo/concepts/studio) 。 ``` npx novu-labs@latest echo ``` 在 Next.js 應用程式資料夾中建立一個包含`client.ts`檔案的`echo`資料夾,並將此程式碼片段複製到該檔案中。 ``` import { Echo } from "@novu/echo"; import { renderEmail } from "@/app/emails/email"; interface EchoProps { step: any; payload: { subject: string; message: string; name: string; totalAmount: string; }; } export const echo = new Echo({ apiKey: process.env.NEXT_PUBLIC_NOVU_API_KEY!, devModeBypassAuthentication: process.env.NODE_ENV === "development", }); echo.workflow( "novu-store", async ({ step, payload }: EchoProps) => { //👇🏻 in-app notification step await step.inApp("notify-admin", async () => { return { body: `${payload.name} just made a new purchase of ${payload.totalAmount} 🎉`, }; }); //👇🏻 email notification step await step.email( "email-customer", async () => { return { subject: `${payload ? payload?.subject : "No Subject"}`, body: renderEmail(payload), }; }, { inputSchema: { type: "object", properties: {}, }, } ); }, { payloadSchema: { type: "object", properties: { message: { type: "string", default: "Congratulations! Your purchase was successful! 🎉", }, subject: { type: "string", default: "Message from Novu Store" }, name: { type: "string", default: "User" }, totalAmount: { type: "string", default: "0" }, }, required: ["message", "subject", "name", "totalAmount"], additionalProperties: false, }, } ); ``` 此程式碼片段定義了一個名為`novu-store` Novu 通知工作流程,該工作流程接受包含電子郵件主題、訊息、客戶姓名和總金額的有效負載。 此工作流程有兩個步驟:應用程式內通知和電子郵件通知。應用程式內通知使用通知鈴聲向管理員發送訊息,而電子郵件則向客戶的電子郵件發送訊息。 接下來,您需要為 Novu Echo 建立 API 路由。在`api`資料夾中,建立一個包含`route.ts`檔案的`email`資料夾,並將下面提供的程式碼片段複製到該檔案中。 ``` import { serve } from "@novu/echo/next"; import { echo } from "@/app/echo/client"; export const { GET, POST, PUT } = serve({ client: echo }); ``` 在終端機中執行`npx novu-labs@latest echo` 。它將自動開啟 Novu Dev Studio,您可以在其中預覽工作流程並將其與雲端同步。 ![新3](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ed2sl38m7zrlgjoj4a6y.gif) `Sync to Cloud`按鈕會觸發一個彈出窗口,其中提供有關如何將工作流程推送到 Novu 雲端的說明。 ![新4](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8ch8ba7y9klyudmmv9jz.png) 若要繼續,請在終端機中執行以下程式碼片段。這將產生一個唯一的 URL,表示您的開發環境和雲端環境之間的本機隧道。 ``` npx localtunnel --port 3000 ``` 將產生的連結與 Echo API 端點一起複製到 Echo Endpoint 欄位中,按一下`Create Diff`按鈕,然後部署變更。 ``` https://<LOCAL_TUNNEL_URL>/<ECHO_API_ENDPOINT (/api/email)> ``` 恭喜!您剛剛從程式碼庫建立了 Novu 工作流程。 ![新5](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6bdugs6g15y1e7xeixux.png) 最後,讓我們建立在用戶付款時發送電子郵件和應用程式內通知的端點。建立一個`api/send`路由並將下面的程式碼片段複製到檔案中: ``` import { NextRequest, NextResponse } from "next/server"; import { Novu } from "@novu/node"; const novu = new Novu(process.env.NOVU_API_KEY!); export async function POST(req: NextRequest) { const { email, name, totalAmount } = await req.json(); const { data } = await novu.trigger("novu-store", { to: { subscriberId: process.env.NOVU_SUBSCRIBER_ID!, email, firstName: name, }, payload: { name, totalAmount, subject: `Purchase Notification from Novu Store`, message: `Your purchase of ${totalAmount} was successful! 🎉`, }, }); console.log(data.data); return NextResponse.json( { message: "Purchase Completed!", data: { novu: data.data }, success: true, }, { status: 200 } ); } ``` 端點接受客戶的電子郵件、姓名和支付總額,並在付款成功後觸發 Novu 通知工作流程發送所需的通知。 --- 結論 -- 到目前為止,您已經學會如何執行以下操作: - 實施多種身份驗證方法,從 Appwrite 儲存和檢索資料和檔案。 - 使用 React Email 建立電子郵件模板,並使用 Novu 發送應用程式內和電子郵件通知。 如果您希望在應用程式中發送通知,Novu 是您的最佳選擇。使用 Novu,您可以為應用程式加入多個通知管道,包括聊天、簡訊、電子郵件、推播和應用程式內通知。 本教學的源程式碼可在此處取得: <https://github.com/novuhq/ecom-store-with-nextjs-appwrite-novu-and-stripe> 感謝您的閱讀! --- 原文出處:https://dev.to/novu/building-an-e-commerce-store-with-nextjs-49m

我在 IT 產業工作了 10 多年。這是我希望在開始時就知道的 5 件事

我需要吐露一些心聲,所以我在這裡,希望能與年輕的 IT 專業人士分享一些有用的東西。在我的職業生涯中,我經歷了自由工作、實習、公司工作、職業轉變,甚至推出了自己的 SaaS(這個故事下次再說…)。我犯過無數的錯誤,也學到了一些慘痛的教訓。以下是我希望 10 年前就知道的 5 件重要事情。 1. 一致性是關鍵 --------- 曾經有一段時間,我懷疑自己所做的一切——品質、選擇、從方向到技術堆疊。我在技術之間切換,考慮放棄我正在做的事情,並再次改變職業。這導致我對自己的技能缺乏信心,常常感到非常沮喪。再加上自由職業的收入和普遍的內向——我甚至沒有任何更有經驗的人可以諮詢來衡量我的進步。這很艱難——當時我主要建立 WordPress 網站。如果我把時間浪費在懷疑和優柔寡斷上,專注於一條職業道路,我會取得更多、更快的成就。選擇一條道路並堅持下去——它會比廣泛的平庸發展的技能產生更多的結果,尤其是在開始時。 這也適用於尋找你的第一份工作。如果您一開始無法找到夢想的工作或任何 IT 工作,那麼這還沒結束。是的,這可能需要幾個月甚至幾年的時間!但如果您覺得 IT 是您的位置,請繼續挖掘該位置。找臨時工作維持生計。尋找更便宜的住房,如果有必要的話,和父母住在一起。購買便宜且健康的食物(提示:您吃的蛋白質越多,您一整天感到的飢餓感就越少)。如果您有系統地投入時間來發展和找工作 – 您就會成功。 2. 你會掙扎並且不理解事情-這是正常的(隨著時間的推移,情況會好起來,但不會完全好) ------------------------------------------- 隨著時間的推移,它會變得更容易,但鬥爭永遠不會完全消失。我在大學逃課,留下了我的電腦科學基礎知識中的空白,而這些空白是經驗無法填補的。但這還不是最重要的。最重要的是,在工作中,你會存在著知識上的空白。也許不是在特定的工作、角色或專案中——你可以徹底學習一個專案,特別是如果你在它上工作的時間足夠長的話。但總體上不了解有關您職業的某些事情是正常的。您不需要了解曾經建立的每一個處理器架構;系統架構師不需要了解特定的測試工具。您不需要徹底了解亞馬遜的每項服務來建立強大的測試系統。這是正常的。 3.不要執著於一份糟糕的工作 -------------- 有時你最終會得到一份糟糕的工作。認識到一份糟糕的工作很簡單——一天結束時,你想把自己裹在毯子裡,躲在角落裡,最重要的是,工作中沒有人可以與你談論改善情況。糟糕的工作可能有多種原因 - 有時是團隊,有時是管理層,有時是你 - 不適合該職位,招聘錯誤,但沒關係。不好的是堅持那份工作。原因可能有很多——沒有安全網、沒有合適的替代方案、對新工作的到來沒有信心……你決定等待。等待、忍受、拖拖拉拉,直到你完全精疲力盡,或者儘管你付出了努力,但還是被明確地趕出了家門。這種情況可能發生在你職業生涯的任何階段,你絕對不能讓它發展到極端。如果你覺得有什麼不對勁,那你可能是對的。如果你強烈地不想去上班——那就是有問題了。切斷這些聯繫,否則你會精疲力竭,或在一個糟糕的地方紮根數週、數月、甚至數年,而沒有力量去改變任何事情。當臨界點到來時,你會面臨更疲憊的情況。 4. 經常換工作可能有好處,但不適合所有人 --------------------- 我仍然看到對初學者程式設計師的建議:多換工作。他們說,這樣你就會獲得更多經驗。在這裡一年,在那裡六個月,三、四年後,你的經驗就和高年級學生一樣了。這可以工作。但這並不適合所有人。 人們在如何集中和保持注意力方面存在差異。如果你沒有註意力不集中的問題,你可以輕鬆地在一個地方工作幾年,並徹底學習所有流程——這將增加你在當前公司的價值,並為你在未來的面試中提供故事。人們低估了深刻的理解,但許多職位和公司卻很重視它。 跳槽也很有用,但對於那些在任務被理解後難以保持注意力的人來說可能是有益的。對這些人來說,當工作中的驚喜消失或接近消失時,工作就變成例行公事,他們可能會開始破壞它。如果你有這樣的感覺——這可能就是你的情況,你需要從熟悉的地方跳到未知的地方。一次又一次。隨著時間的推移,這些人會成為具有超強適應性的專家,對他們來說,新語言或新領域都不會成為障礙。 及時辨識什麼適合您個人非常重要。 5. 不要錯過機會,即使它們看起來很小或微不足道 ------------------------ 測試自動化的職業生涯讓我的生活變得更好。這個機會一直就在我面前。我不只一次想過嘗試它,甚至開始學習一些東西,但我放棄了——我認為測試並不認真,而且在經過幾年的 Web 開發後轉向測試是個壞主意(哈哈)。事實證明,我不需要付出很大的努力就可以在這個領域建立一份嚴肅的職業生涯。從酒吧工作轉向網頁開發對我來說是一個更大的努力。 為了養活自己而工作也是如此。我的第一份 Web 開發工作賺了 50 美元。我製作了兩個 WordPress 網站——一個 30 美元,另一個 20 美元。自從我從頭開始學習以來,這還不錯。我之前的工作經驗大部分都是在酒吧度過的。儘管我將自己(主要是在我的腦海中)定位為網頁開發人員,但我從事了任何工作——從編寫文字到編輯圖像。在自由業的前 2-3 年裡,我最大的單筆收入是用 Photoshop 編輯了數千張電影海報。三天三夜幾乎不間斷的工作讓我賺到了 500 美元——這對那個時代來說是一個了不起的結果。 還有一件事:行話和抽象 ----------- 你讀到的、聽到的和做的很多事情都可能非常混亂和複雜,以至於變成了白噪音。有時,一件難以理解的事情會流入另一件事情中,留下不愉快的痕跡和限制感。但這是正常的!一旦你開始解開抽象概念的結,並意識到術語和行話背後的含義,一切都會很快步入正軌。看起來這種混亂沒有盡頭,但事實並非如此——遲早,你會明白一切(或幾乎一切)。 實際上,程式設計論壇和技術播客對我幫助很大。我只是閱讀和聆聽所有內容,谷歌搜尋每個未知的單字和術語。在某些時候,這會導致您的手機和電腦上的瀏覽器中出現數十個和數百個選項卡,但最終,此流程開始縮小。透過每個新的閱讀選項卡,您會變得更聰明,對自己的知識更有信心,即使在很長一段時間內看起來並非如此。 --- 我希望這篇文章能對大家有所幫助,並激勵人們不要害怕變化,尋找自己的位置,不要在遇到困難時就放棄。請記住,每條道路都是獨一無二的,重要的是要找到自己的道路,遵循自己的興趣、願望並專注於自己的感受。一切都會好起來的,但還是祝你好運。 --- 原文出處:https://dev.to/vorniches/ive-worked-in-it-for-over-10-years-here-are-5-things-i-wish-i-knew-when-i-started-43pe

系統設計面試的資料庫分片

*揭露:這篇文章包含附屬連結;如果您透過本文中提供的不同連結購買產品或服務,我可能會獲得補償。* [![資料庫分片的類型](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/42ob2tziqrlt820gdsy7.jpg)](https://bit.ly/3pMiO8g) image\_credit -[設計大師](https://bit.ly/3pMiO8g) 朋友們大家好,在這個資料驅動的世界中,有效處理大量資料的能力對於企業和組織來說至關重要。 傳統的整體資料庫往往難以跟上現代應用程式和服務的需求,並成為效能瓶頸。 這就是**資料庫分片發揮**作用的地方,它為**水平擴展資料提供了強大的解決方案。** 如果你不知道什麼是Sharding?分片是一種資料庫架構技術,它將大型資料庫劃分為更小、更易於管理的部分,稱為“分片”,分佈在多個伺服器上。 每個分片都包含資料的子集,它們一起形成完整的資料集。這種方法透過分配工作負載、減少延遲和啟用並行處理來增強效能和可擴展性。 分片對於處理大規模應用程式和高流量系統特別有用,確保沒有單一伺服器成為瓶頸,並提高資料庫系統的整體效率和可靠性。 過去,我討論過常見的系統設計問題,例如[API 網關與負載平衡器](https://dev.to/somadevtoo/difference-between-api-gateway-and-load-balancer-in-system-design-54dd)、[水平與垂直擴展](https://dev.to/somadevtoo/horizontal-scaling-vs-vertical-scaling-in-system-design-3n09)、 [正向代理與反向代理](https://dev.to/somadevtoo/difference-between-forward-proxy-and-reverse-proxy-in-system-design-54g5),在這份全面的**資料庫分片指南**中,您將了解資料庫分片,探索其概念、優點、實施策略和實際用例。 分片也是系統設計面試的重要議題,因為 因為它展示了對如何處理大規模資料並提高系統效能和可擴展性的理解,這是開發人員的關鍵技能和經驗。 在這些面試中,通常會評估候選人設計能夠有效管理高流量和大量資料的系統的能力。分片展示了分散式系統、資料庫管理的知識以及解決潛在瓶頸和故障點的能力。 它反映了候選人設計彈性、高效能和可擴展架構的能力,這是在現實場景中建立強大且高效的軟體系統的關鍵技能。 順便說一句,如果您正在準備系統設計面試並想深入學習系統設計,那麼您還可以查看[**ByteByteGo**](https://bit.ly/3P3eqMN) 、 [**Design Guru**](https://bit.ly/3pMiO8g) 、 [**Exponent**](https://bit.ly/3cNF0vw) 、 [**Educative**](https://bit.ly/3Mnh6UR)和[**Udemy**](https://bit.ly/3vFNPid)等網站,這些網站有許多很棒的系統設計課程,這裡有一個很好的系統設計 Exponent 的面試備忘單,以快速修改面試的基本系統設計概念。 [![軟體設計面試備忘錄](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k3i7ytpm4lzhad3dclk5.png)](https://bit.ly/3cNF0vw) ***PS 繼續閱讀直到最後。我有一份獎金給你。*** 用於系統設計的資料庫分片 ------------ 現在,我們來了解一下什麼是資料庫分片?為什麼需要它以及它如何幫助擴展您的應用程式。我們還看到不同類型的資料庫分片,例如基於哈希和基於範圍的分片。 目錄 1. 介紹 2. 什麼是資料庫分片? 3. 為什麼要分片?對可擴展性的需求 4. 資料庫分片如何運作? 5. 分片策略 6. 挑戰和考慮因素 7. 現實世界的用例 8. 實施資料庫分片 9. 最佳實踐 10. 結論 一、簡介 ---- 在當今資料驅動的世界中,企業和組織被大量資訊淹沒。有效管理和處理這些資料是傳統整體資料庫難以應對的挑戰。 隨著用戶群的成長、應用程式工作負載的增加以及對即時分析的需求的飆升,對可擴展資料庫解決方案的需求變得至關重要。 > 這就是資料庫分片作為實現水平可擴展性的強大工具的作用。 [![資料庫分片概述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gx9climi3dpc0fpgie24.png)](https://bit.ly/3Mnh6UR) --- 2.什麼是資料庫分片? ----------- **資料庫分片是一種資料庫架構策略,用於跨多個資料庫執行個體或伺服器分割和分佈資料。**術語“分片”是指整個資料集的分區或子集。 每個分片獨立運作並包含一部分資料。透過將資料分佈在多個分片上,系統可以實現水平可擴展性,從而能夠處理更大的資料量和更高的工作負載。 分片對於資料集快速成長或高吞吐量要求的應用程式尤其有利,例如社交媒體平台、電子商務網站和遊戲應用程式。 它使這些應用程式能夠跨多個伺服器或叢集分配資料庫負載,從而防止任何單一資料庫伺服器成為瓶頸。 這是一個**簡單的圖表,將資料庫分片解釋為水平擴展:** [![什麼是資料庫分片](https://miro.medium.com/v2/resize:fit:609/1*Dmb3LCxTWjyGj_uYjEGnHA.png)](https://bit.ly/3P3eqMN) --- 3. 為什麼要進行資料庫分片?對可擴展性的需求 ----------------------- 現在,讓我們看看為什麼需要資料庫分片 ### 3.1.單體資料庫中的可擴展性挑戰 傳統的整體資料庫在可擴展性方面有其限制。在整體架構中,所有資料都儲存在單一資料庫執行個體中。 隨著資料量和使用者負載的增加,單體資料庫可能面臨幾個挑戰: - **效能瓶頸:**單一資料庫伺服器可能成為效能瓶頸,導致查詢回應時間緩慢且應用程式停機。 - **儲存有限:**單一伺服器的儲存容量有限,難以處理超大資料集。 - **垂直擴展成本**:透過升級硬體進行垂直擴展可能成本高昂,而且回報遞減。 - **複雜性:**管理大型整體資料庫可能很複雜且容易出錯,需要大量維護和最佳化。 ### 3.2.解決方案:透過分片實現水平可擴展性 資料庫分片透過將資料分佈在多個分片上(每個分片駐留在單獨的資料庫伺服器或叢集上)來解決這些可擴展性挑戰。這種方法有幾個優點: - **提高效能:**分片將資料庫負載均勻分佈在多個伺服器上,從而提高查詢效能和回應能力。 - **無限的可擴展性:**隨著資料的成長,可以加入新的分片,從而實現近乎無限的可擴展性。 - **成本效益:**與不斷升級單一伺服器相比,分片是一種經濟高效的解決方案。 - **高可用性**:分片可以提高容錯性和可用性,因為一個分片的故障不會影響整個系統。 這是資料庫的水平分片和垂直分片的樣子 [![如何使用分片擴充資料庫](https://miro.medium.com/v2/resize:fit:609/1*0j0DLUHN8EeykY-XxVSzJA.png)](https://medium.com/javarevisited/top-3-system-design-cheat-sheets-templates-and-roadmap-for-software-engineering-interviews-53012952db28) --- ### 4. 資料庫分片如何運作? 資料庫分片背後的核心思想是將資料分成更小的、可管理的部分,稱為分片。每個分片都是一個獨立的資料庫子集,用於儲存整個資料集的一部分。 分片可以分佈在多個資料庫伺服器或叢集\*\*,從而實現並行處理並提高效能。 以下是資料庫分片工作原理的進階概述: ![資料庫分片如何運作?](https://miro.medium.com/v2/resize:fit:609/1*1FCBTWUliqTM-VYNcd_YHA.png) 您可以看到資料庫分片提供了一種邏輯方法來將資料等級分割到多個伺服器和叢集上。 ### 4.1.資料分割區 分片的第一步是決定如何對資料進行分區。有幾種常見的分區策略,我們將在下一節中詳細探討。 分區策略的選擇取決於應用程式的要求和資料分佈。 ![資料分割區](https://miro.medium.com/v2/resize:fit:375/1*jsHUuhNxK-goazpSQUfAMg.png) ### 4.2.片鍵 **分片鍵**是用來決定特定資料屬於哪個分片的欄位或屬性。選擇合適的分片鍵至關重要,該鍵可以在分片之間均勻分佈資料,以防止熱點(分片接收的流量明顯多於其他分片)。 ### 4.3.資料分佈 一旦對資料進行了分區並選擇了分片鍵,資料就會分佈在可用的分片中。分發過程可以自動化,通常涉及分片機製或服務,根據分片鍵將資料路由到正確的分片。 ### 4.4.查詢路由 當對資料庫進行查詢或請求時,查詢路由器或協調器會根據分片鍵決定要查詢的分片。涉及多個分片的查詢可能需要結果的協調和聚合。 ### 4.5.聚合 在某些情況下,可能需要聚合多個分片的查詢結果才能產生最終結果。這種聚合可以發生在應用程式層級或透過專用聚合層。 ### 4.6.資料一致性 確保分片之間的資料一致性是分片的關鍵方面。兩階段提交或最終一致性等技術用於維護資料完整性。 [![資料庫分片完整指南](https://miro.medium.com/v2/resize:fit:497/1*ZVrIULaZsBFrzfEeoO63IQ.png)](https://www.java67.com/2019/09/top-5-courses-to-learn-system-design.html) --- 5. 分片策略 ------- 選擇正確的分片策略對於分片資料庫系統的成功至關重要。選擇取決於資料的性質、存取模式和可擴展性要求。以下是一些常見的分片策略: ### 5.1.基於範圍的分片 基於範圍的分片涉及根據分片鍵中特定值範圍對資料進行分區。例如,如果您要對客戶資料進行分片,則可以使用基於範圍的策略,其中每個分片包含姓氏以特定字母開頭或屬於特定範圍的客戶。 當資料分佈不均勻且您希望將相關資料保留在一個分片中時,基於範圍的分片非常有用。 以下是[DesignGuru.io](https://bit.ly/3pMiO8g)基於範圍的分片範例: [![基於範圍的資料庫分片](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3j4ttcmk6e1oifbd4sr6.png)](https://bit.ly/3pMiO8g) --- ### 5.2.基於哈希的分片 基於雜湊的分片使用雜湊函數將分片鍵映射到特定分片。這種方法在分片之間均勻分佈資料,有助於避免熱點。 當資料存取模式不可預測或您想要確保資料均勻分佈時,基於雜湊的分片特別有效。 以下是[DesignGuru.io](https://bit.ly/3pMiO8g)在資料庫上基於哈希的分片範例: [![基於哈希的分片](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hoks5uj5825fjwo9zd6m.png)](https://bit.ly/3pMiO8g) --- ### 5.3.基於目錄的分片 基於目錄的分片維護一個中央目錄,將分片鍵對應到對應的分片。此目錄有助於將查詢有效地路由到適當的分片。但是,它可能會引入單點故障。 基於目錄的分片適用於需要對分片分配保持高度控制的場景。 這是[DesignGuru.io](https://bit.ly/3pMiO8g)的基於目錄的分片範例 [![基於目錄的分片](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s8691g3i2seemih5in0p.png)](https://bit.ly/3pMiO8g) --- ### 5.4.地理分片 在處理基於位置的資料(例如使用者位置)時,地理分片是相關的。資料根據與分片鍵關聯的地理區域進行分區。 此策略對於具有地理分佈的使用者或資料的應用程式很有價值。 正如他們所說,一張圖片勝過 1000 個單詞,這是來自[**Architecture Notes**](https://architecturenotes.co/database-sharding-explained/)的漂亮圖表,它解釋了不同類型的資料庫分片 ![資料庫分片策略](https://miro.medium.com/v2/resize:fit:609/1*_X8CwmkPPT1JLyiwSN6ZlQ.jpeg) 信用 --- <https://architecturenotes.co/database-sharding-explained/> --- 6. 挑戰和考慮 -------- 雖然資料庫分片提供了顯著的好處,但它也帶來了一系列挑戰和考慮因素: 6.1.資料遷移 在分片之間遷移資料可能非常複雜且耗時。正確的規劃和工具對於確保遷移過程順利進行至關重要。 6.2.備份與復原 管理備份並確保跨多個分片的資料復原需要仔細的規劃和強大的備份解決方案。 6.3.查詢複雜度 涉及來自多個分片的資料的查詢的實施和最佳化可能很複雜。應用程式程式碼可能需要處理查詢路由和結果聚合。 6.4.資料一致性 在分片環境中維護資料一致性可能具有挑戰性。開發人員需要考慮分散式事務、衝突解決和最終一致性等因素。 6.5.監控和擴展 有效的監控和擴展策略對於確保分片資料庫的健康和效能至關重要。辨識效能瓶頸並根據需要加入新分片至關重要。 ![資料庫分片的挑戰與注意事項](https://miro.medium.com/v2/resize:fit:609/1*GXRq3DgwsPpvG72EDUkX2Q.png) --- 7. 資料庫分片的實際用例 ------------- 資料庫分片適用於可擴展性和效能至關重要的各種現實場景。讓我們探討一些值得注意的例子: 7.1.社群媒體平台 Facebook、Twitter 和 Instagram 等社群媒體平台處理大量用戶生成的內容,包括貼文、圖像和影片。分片使這些平台能夠有效地分發和管理用戶資料。 7.2.電子商務網站 電子商務網站面臨著劇烈的流量波動,尤其是在促銷活動期間。分片幫助他們處理增加的負載並提供無縫的購物體驗。 7.3.遊戲應用 線上遊戲應用程式通常需要即時互動和低延遲回應時間。分片可確保遊戲資料的分佈以獲得最佳效能。 7.4.金融服務 金融機構每天處理大量的交易資料。分片允許他們擴展資料庫以處理負載,同時保持資料完整性。 ![MongoDB 中的資料庫分片](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c5rwxxozvp46xalmhu8r.png) --- 8. 如何實現資料庫分片? ------------- 實施資料庫分片需要仔細的規劃和執行。以下是涉及的步驟: 8.1.評估與規劃 首先評估應用程式的可擴展性要求和資料分佈模式。選擇合適的分片策略和分片鍵。 8.2.資料庫設計 設計資料庫架構以適應分片。定義資料如何跨分片分區和分佈。 8.3.分片實施 實施分片機製或使用適合您選擇的策略的分片資料庫系統。跨分片分佈現有資料。 8.4.查詢路由 發展一種查詢路由機制,根據分片鍵將查詢定向到適當的分片。如有必要,處理查詢聚合。 8.5。資料一致性 實施資料一致性機制,例如分散式交易或最終一致性,以維護資料完整性。 8.6。測試與優化 徹底測試分片資料庫系統,優化查詢並監控效能。根據需要擴展系統。 讓我告訴你一個秘密,分片還可以讓你的資料庫更快: ![分片如何使資料庫更快](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a4xuebb3yiyfkg4bebaz.png) --- ### 9. 資料庫分片最佳實踐 若要充分利用資料庫分片,請考慮遵循以下最佳實務: - **選出正確的分片鍵:** 選擇能夠均勻分佈資料並避免熱點的分片鍵。 - **監控和規模**: 持續監控分片資料庫的運作狀況和效能。隨著資料的成長加入新的分片。 - **備份和災難復原:** 實施強大的備份和復原程序來保護您的資料。 - **資料遷移:** 仔細規劃資料遷移並使用高效率的工具和流程。 - **查詢最佳化:** 優化分片環境中的查詢效能。 - **資料一致性:** 了解並實施適合您的應用程式的資料一致性模型。 而且,如果您需要備忘單,這裡有[**ByteByteGo**](https://bit.ly/3P3eqMN)提供的一份不錯的資料庫分片備忘單,可幫助您快速修改關鍵分片概念 [![資料庫分片備忘單](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wgf23bifr1mvth1hol9j.jpg)](https://bit.ly/3P3eqMN) --- ### 系統設計訪談資源: 而且,這裡列出了最佳系統設計書籍、線上課程和練習網站,您可以查看這些內容,以便更好地為系統設計面試做好準備。這些課程中的大多數也回答了我在這裡分享的問題。 1. [**DesignGuru 的 Grokking 系統設計課程**](https://bit.ly/3pMiO8g):一個互動式學習平台,提供實作練習和真實場景,以增強您的系統設計技能。 2. [**《系統設計面試》作者:Alex Xu**](https://amzn.to/3nU2Mbp) :這本書深入探討了系統設計概念、策略和麵試準備技巧。 3. Martin Kleppmann 的[**「設計資料密集型應用程式」**](https://amzn.to/3nXKaas) :綜合指南,涵蓋了設計可擴展且可靠的系統的原則和實踐。 4. [LeetCode 系統設計 標籤](https://leetcode.com/explore/learn/card/system-design):LeetCode 是一個受歡迎的技術面試準備平台。 LeetCode 上的系統設計標籤包含各種練習問題。 5. GitHub 上的[**「系統設計入門」**](https://bit.ly/3bSaBfC) :精選的資源列表,包括文章、書籍和影片,可幫助您準備系統設計面試。 6. [**Educative 的系統設計課程**](https://bit.ly/3Mnh6UR):一個互動式學習平台,提供實作練習和真實場景,以增強您的系統設計技能。 7. **高可擴展性部落格**:該部落格包含有關高流量網站和可擴展系統架構的文章和案例研究。 8. **[YouTube 頻道](https://medium.com/javarevisited/top-8-youtube-channels-for-system-design-interview-preparation-970d103ea18d)**:請參閱「Gaurav Sen」和「Tech Dummies」等頻道,以取得有關係統設計概念和麵試準備的富有洞察力的影片。 9. [**ByteByteGo**](https://bit.ly/3P3eqMN) :Alex Xu 的一本現場書籍和課程,用於系統設計面試準備。它包含《系統設計訪談》第一捲和第二卷的所有內容,並將隨即將推出的第三卷進行更新。 10. [**Exponent**](https://bit.ly/3cNF0vw) :一個專為面試準備的網站,特別是針對亞馬遜和谷歌等 FAANG 公司,他們還有很棒的系統設計課程和許多其他材料,可以幫助您破解 FAAN 面試。 [![如何為系統設計做準備](https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fkqv3p46jmw5qc0newuiu.jpg)](https://bit.ly/3P3eqMN) image\_credit - [ByteByteGo](https://bit.ly/3P3eqMN) 請記住透過參與實際專案和參加模擬面試將理論知識與實際應用結合。不斷的練習和學習無疑會提高你在系統設計面試中的熟練程度。 --- ### 10. 結論 這就是關於**資料庫分片及其工作原理的**全部內容。資料庫分片是實現水平可擴展性以及處理大量資料和高工作負載的強大策略。 透過跨多個分片分佈資料,組織可以提高效能、確保高可用性並滿足現代應用程式的需求。 然而,**分片並不是萬能的解決方案**,並且有其自身的一系列挑戰和考慮因素。正確的規劃、仔細的實施和遵守最佳實踐是成功分片的關鍵。 隨著資料量和複雜性不斷增長,掌握資料庫分片技術對於企業和開發人員來說變得越來越重要。 獎金 --- 正如承諾的,這是給你的獎金,一本免費的書。我剛剛找到一本新的免費書籍來學習分散式系統設計,您也可以在 Microsoft 上閱讀它 --- [https://info.microsoft.com/rs/157-GQE-382/images/EN-CNTNT -eBook-設計分散式系統.pdf](https://info.microsoft.com/rs/157-GQE-382/images/EN-CNTNT-eBook-DesigningDistributedSystems.pdf) ![學習分散式系統的免費書籍](https://miro.medium.com/v2/resize:fit:317/0*ICrIesz1fT-KtmUZ.png) --- 原文出處:https://dev.to/somadevtoo/database-sharding-for-system-design-interview-1k6b

使用 Langchain 為您的文件建立 QA 機器人 😻

--- 標題:使用 Langchain 為您的文件建立 QA 機器人 😻 描述:使用 Wing Framework、NextJS 和 Langchain 建立的 ChatGPT 用戶端應用程式 canonical\_url:https://www.winglang.io/blog/2024/05/29/qa-bot-for-your-docs-with-langchain 發表:真實 --- 長話短說 ---- 在本教學中,我們將為您的網站文件建立一個人工智慧驅動的問答機器人。 - 🌐 建立一個用戶友好的 Next.js 應用程式來接受問題和 URL - 🔧 設定一個 Wing 後端來處理所有請求 - 💡 透過使用 RAG 抓取和分析文件,將 @langchain 納入 AI 驅動的答案 - 🔄 前端輸入和人工智慧處理的回應之間的完整連接。 ![問題](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ykw5f2sos4fdhj8akowt.gif) 什麼是翼? ----- [Wing](https://wing.cloud/redirect?utm_source=qa-bot-reddit&redirect=https%3A%2F%2Fwww.winglang.io%2Fblog%2F2024%2F05%2F29%2Fqa-bot-for-your-docs-with-langchain)是一個雲端開源框架。 它允許您將應用程式的基礎架構和程式碼組合為一個單元,並將它們安全地部署到您首選的雲端提供者。 Wing 讓您可以完全控制應用程式基礎架構的配置方式。除了其易於學習的[程式語言](https://www.winglang.io/docs/language-reference)之外,Wing 還支援 Typescript。 在本教學中,我們將使用 TypeScript。所以,別擔心,您的 JavaScript 和 React 知識足以理解本教學。 ![翼登陸頁面](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u366v255drbwqmcoagrz.png) {% cta https://wingla.ng/github %} 看 Wing ⭐️ {% endcta %} --- 使用 Next.js 建立前端 --------------- 在這裡,您將建立一個簡單的表單,它接受文件 URL 和使用者的問題,然後根據網站的資料回傳回應。 首先,建立一個包含兩個子資料夾的資料夾 - `frontend`和`backend` 。 `frontend`資料夾包含 Next.js 應用程式, `backend`資料夾用於 Wing。 ``` mkdir qa-bot && cd qa-bot mkdir frontend backend ``` 在**`frontend`**資料夾中,透過執行以下程式碼片段來建立 Next.js 專案: ``` cd frontend npx create-next-app ./ ``` ![下一個應用程式](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pyq8dnmmmplvzl7g41ir.png) 將下面的程式碼片段複製到`app/page.tsx`檔案中,以建立接受使用者問題和文件 URL 的表單: ``` "use client"; import { useState } from "react"; export default function Home() { const [documentationURL, setDocumentationURL] = useState<string>(""); const [question, setQuestion] = useState<string>(""); const [disable, setDisable] = useState<boolean>(false); const [response, setResponse] = useState<string | null>(null); const handleUserQuery = async (e: React.FormEvent) => { e.preventDefault(); setDisable(true); console.log({ question, documentationURL }); }; return ( <main className='w-full md:px-8 px-3 py-8'> <h2 className='font-bold text-2xl mb-8 text-center text-blue-600'> Documentation Bot with Wing & LangChain </h2> <form onSubmit={handleUserQuery} className='mb-8'> <label className='block mb-2 text-sm text-gray-500'>Webpage URL</label> <input type='url' className='w-full mb-4 p-4 rounded-md border text-sm border-gray-300' placeholder='https://www.winglang.io/docs/concepts/why-wing' required value={documentationURL} onChange={(e) => setDocumentationURL(e.target.value)} /> <label className='block mb-2 text-sm text-gray-500'> Ask any questions related to the page URL above </label> <textarea rows={5} className='w-full mb-4 p-4 text-sm rounded-md border border-gray-300' placeholder='What is Winglang? OR Why should I use Winglang? OR How does Winglang work?' required value={question} onChange={(e) => setQuestion(e.target.value)} /> <button type='submit' disabled={disable} className='bg-blue-500 text-white px-8 py-3 rounded' > {disable ? "Loading..." : "Ask Question"} </button> </form> {response && ( <div className='bg-gray-100 w-full p-8 rounded-sm shadow-md'> <p className='text-gray-600'>{response}</p> </div> )} </main> ); } ``` 上面的程式碼片段顯示了一個表單,該表單接受使用者的問題和文件 URL 並將它們暫時記錄到控制台。 ![QA 機器人表單](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7b4w3tq0srua93gnk73n.png) 完美的! 🎉您已經完成了應用程式的使用者介面。接下來,讓我們設定 Wing 後端。 --- 如何在電腦上設定 Wing ------------- Wing 提供了一個 CLI,使您能夠在專案中執行各種 Wing 操作。 它還提供[VSCode](https://marketplace.visualstudio.com/items?itemName=Monada.vscode-wing)和[IntelliJ](https://plugins.jetbrains.com/plugin/22353-wing)擴展,透過語法突出顯示、編譯器診斷、程式碼完成和片段等功能增強開發人員體驗。 在繼續之前,請停止 Next.js 開發伺服器並透過在終端機中執行下面的程式碼片段來安裝 Wing CLI。 ``` npm install -g winglang@latest ``` 執行以下程式碼片段以確保 Winglang CLI 已安裝並按預期工作: ``` wing -V ``` 接下來,導航到`backend`資料夾並建立一個空的 Wing Typescript 專案。確保選擇`empty`模板並選擇 Typescript 作為語言。 ``` wing new ``` ![永新](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ezy04zqvz9lura0d25dj.png) 將下面的程式碼片段複製到`backend/main.ts`檔案中。 ``` import { cloud, inflight, lift, main } from "@wingcloud/framework"; main((root, test) => { const fn = new cloud.Function( root, "Function", inflight(async () => { return "hello, world"; }) ); }); ``` **`main()`**函數充當 Wing 的入口點。 它建立一個雲端函數並在編譯時執行。另一方面, **`inflight`**函數在執行時執行並返回`Hello, world!`文字. 透過執行下面的程式碼片段啟動 Wing 開發伺服器。它會自動在瀏覽器中開啟 Wing 控制台,網址為`http://localhost:3000` 。 ``` wing it ``` ![Wing TS 最小控制台](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z1ejobkm0dq5akhut732.png) 您已在電腦上成功安裝 Wing。 --- 如何將 Wing 連接到 Next.js 應用程式 ------------------------- 在前面的部分中,您已在`frontend`資料夾中建立了 Next.js 前端應用程式,並在`backend`資料夾中建立了 Wing 後端。 在本部分中,您將了解如何在 Next.js 應用程式和 Wing 後端之間通訊和發送資料。 首先,透過執行以下程式碼在後端資料夾中安裝[Wing React](https://github.com/winglang/winglibs/tree/main/react)函式庫: ``` npm install @winglibs/react ``` 接下來,更新`main.ts`文件,如下所示: ``` import { main, cloud, inflight, lift } from "@wingcloud/framework"; import React from "@winglibs/react"; main((root, test) => { const api = new cloud.Api(root, "api", { cors: true }) ; //👇🏻 create an API route api.get( "/test", inflight(async () => { return { status: 200, body: "Hello world", }; }) ); //👉🏻 placeholder for the POST request endpoint //👇🏻 connects to the Next.js project const react = new React.App(root, "react", { projectPath: "../frontend" }); //👇🏻 an environment variable react.addEnvironment("api_url", api.url); }); ``` 上面的程式碼片段建立了一個 API 端點 ( `/test` ),它接受 GET 請求並傳回`Hello world`文字。 `main`函數也連接到 Next.js 專案並將`api_url`新增為環境變數。 環境變數中包含的 API URL 使我們能夠將請求傳送到 Wing API 路由。我們如何在 Next.js 應用程式中檢索 API URL 並發出這些請求? 更新 Next.js `app/layout.tsx`檔案中的`RootLayout`元件,如下所示: ``` export default function RootLayout({ children, }: Readonly<{ children: React.ReactNode; }>) { return ( <html lang='en'> <head> {/** ---👇🏻 Adds this script tag 👇🏻 ---*/} <script src='./wing.js' defer /> </head> <body className={inter.className}>{children}</body> </html> ); } ``` 透過執行`npm run build`重新建置 Next.js 專案。 最後,啟動Wing開發伺服器。它會自動啟動 Next.js 伺服器,可以在瀏覽器中透過**`http://localhost:3001`**存取該伺服器。 ![控制台到 URL](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t7rkxw9bds97a0qzg5vh.gif) 您已成功將 Next.js 連接到 Wing。您也可以使用`window.wingEnv.<attribute_name>`存取環境變數中的資料。 ![視窗.wingEnv](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0up5430jmxufmyeb9e4h.gif) 使用LangChain和Wing處理用戶請求 ---------------------- 在本節中,您將學習如何向 Wing 發送請求,使用[LangChain 和 OpenA](https://js.langchain.com/docs/get_started/quickstart#llm-chain) I 處理這些請求,並在 Next.js 前端顯示結果。 首先,我們更新 Next.js **`app/page.tsx`**檔案以檢索 API URL 並將使用者資料傳送到 Wing API 端點。 為此,請透過在**`page.tsx`**檔案頂部新增以下程式碼片段來擴充 JavaScript **`window`**物件。 ``` "use client"; import { useState } from "react"; interface WingEnv { api_url: string; } declare global { interface Window { wingEnv: WingEnv; } } ``` 接下來,更新`handleUserQuery`函數以將包含使用者問題和網站URL 的POST 請求傳送到Wing API 端點。 ``` //👇🏻 sends data to the api url const [response, setResponse] = useState<string | null>(null); const handleUserQuery = async (e: React.FormEvent) => { e.preventDefault(); setDisable(true); try { const request = await fetch(`${window.wingEnv.api_url}/api`, { method: "POST", headers: { "Content-Type": "application/json", }, body: JSON.stringify({ question, pageURL: documentationURL }), }); const response = await request.text(); setResponse(response); setDisable(false); } catch (err) { console.error(err); setDisable(false); } }; ``` 在建立接受 POST 請求的 Wing 端點之前,請在`backend`資料夾中安裝下列套件: ``` npm install @langchain/community @langchain/openai langchain cheerio ``` [Cheerio](https://js.langchain.com/v0.2/docs/integrations/document_loaders/web_loaders/web_cheerio/)使我們能夠抓取軟體文件網頁,而[LangChain 軟體包](https://js.langchain.com/v0.1/docs/get_started/quickstart/)使我們能夠存取其各種功能。 LangChain OpenAI整合包使用OpenAI語言模型;因此,您需要一個有效的 API 金鑰。您可以從[OpenAI 開發者平台](https://platform.openai.com/api-keys)取得。 ![朗查恩](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/omg4o524oklrssso5rqc.png) 接下來,讓我們建立處理傳入請求的`/api`端點。 端點將: - 接受來自 Next.js 應用程式的問題和文件 URL, - 使用[LangChain 文件載入器](https://js.langchain.com/v0.1/docs/modules/data_connection/document_loaders/)載入文件頁面, - 將檢索到的文件分成區塊, - 轉換分塊文件並將它們保存在[LangChain 向量儲存](https://js.langchain.com/v0.1/docs/modules/data_connection/vectorstores/)中, - 並建立一個[檢索器函數](https://js.langchain.com/v0.1/docs/modules/data_connection/),從向量儲存中檢索文件。 首先,將以下內容匯入`main.ts`檔案: ``` import { main, cloud, inflight, lift } from "@wingcloud/framework"; import { ChatOpenAI, OpenAIEmbeddings } from "@langchain/openai"; import { ChatPromptTemplate } from "@langchain/core/prompts"; import { createStuffDocumentsChain } from "langchain/chains/combine_documents"; import { CheerioWebBaseLoader } from "@langchain/community/document_loaders/web/cheerio"; import { RecursiveCharacterTextSplitter } from "langchain/text_splitter"; import { MemoryVectorStore } from "langchain/vectorstores/memory"; import { createRetrievalChain } from "langchain/chains/retrieval"; import React from "@winglibs/react"; ``` 在`main()`函數中加入以下程式碼片段以建立`/api`端點: ``` api.post( "/api", inflight(async (ctx, request) => { //👇🏻 accept user inputs from Next.js const { question, pageURL } = JSON.parse(request.body!); //👇🏻 initialize OpenAI Chat for LLM interactions const chatModel = new ChatOpenAI({ apiKey: "<YOUR_OPENAI_API_KEY>", model: "gpt-3.5-turbo-1106", }); //👇🏻 initialize OpenAI Embeddings for Vector Store data transformation const embeddings = new OpenAIEmbeddings({ apiKey: "<YOUR_OPENAI_API_KEY>", }); //👇🏻 creates a text splitter function that splits the OpenAI result chunk size const splitter = new RecursiveCharacterTextSplitter({ chunkSize: 200, //👉🏻 characters per chunk chunkOverlap: 20, }); //👇🏻 creates a document loader, loads, and scraps the page const loader = new CheerioWebBaseLoader(pageURL); const docs = await loader.load(); //👇🏻 splits the document into chunks const splitDocs = await splitter.splitDocuments(docs); //👇🏻 creates a Vector store containing the split documents const vectorStore = await MemoryVectorStore.fromDocuments( splitDocs, embeddings //👉🏻 transforms the data to the Vector Store format ); //👇🏻 creates a document retriever that retrieves results that answers the user's questions const retriever = vectorStore.asRetriever({ k: 1, //👉🏻 number of documents to retrieve (default is 2) }); //👇🏻 creates a prompt template for the request const prompt = ChatPromptTemplate.fromTemplate(` Answer this question. Context: {context} Question: {input} `); //👇🏻 creates a chain containing the OpenAI chatModel and prompt const chain = await createStuffDocumentsChain({ llm: chatModel, prompt: prompt, }); //👇🏻 creates a retrieval chain that combines the documents and the retriever function const retrievalChain = await createRetrievalChain({ combineDocsChain: chain, retriever, }); //👇🏻 invokes the retrieval Chain and returns the user's answer const response = await retrievalChain.invoke({ input: `${question}`, }); if (response) { return { status: 200, body: response.answer, }; } return undefined; }) ); ``` API 端點接受使用者的問題和來自 Next.js 應用程式的頁面 URL,初始化[`ChatOpenAI`](https://js.langchain.com/v0.2/docs/integrations/chat/openai/)和[`OpenAIEmbeddings`](https://js.langchain.com/v0.2/docs/integrations/text_embedding/openai/) ,載入文件頁面,並以文件的形式檢索使用者查詢的答案。 然後,將文件分割成區塊,將區塊保存在`MemoryVectorStore`中,並使我們能夠使用[LangChain 檢索器](https://js.langchain.com/v0.1/docs/modules/data_connection/)來取得問題的答案。 從上面的程式碼片段來看,OpenAI API金鑰直接輸入到程式碼中;這可能會導致安全漏洞,使 API 金鑰可供攻擊者存取。為了防止這種資料洩露,Wing 允許您將私鑰和憑證保存在名為`secrets`的變數中。 當您建立機密時,Wing 會將此資料保存在`.env`檔案中,確保其安全且可存取。 更新`main()`函數以從 Wing Secret 取得 OpenAI API 金鑰。 ``` main((root, test) => { const api = new cloud.Api(root, "api", { cors: true }); //👇🏻 creates the secret variable const secret = new cloud.Secret(root, "OpenAPISecret", { name: "open-ai-key", }); api.post( "/api", lift({ secret }) .grant({ secret: ["value"] }) .inflight(async (ctx, request) => { const apiKey = await ctx.secret.value(); const chatModel = new ChatOpenAI({ apiKey, model: "gpt-3.5-turbo-1106", }); const embeddings = new OpenAIEmbeddings({ apiKey, }); //👉🏻 other code snippets & configurations ); const react = new React.App(root, "react", { projectPath: "../frontend" }); react.addEnvironment("api_url", api.url); }); ``` - 從上面的程式碼片段來看, ``` - The `secret` variable declares a name for the secret (OpenAI API key). ``` ``` - The [`lift().grant()`](https://www.winglang.io/docs/typescript/inflights#permissions) grants the API endpoint access to the secret value stored in the Wing Secret. ``` ``` - The [`inflight()`](https://www.winglang.io/docs/typescript/inflights) function accepts the context and request object as parameters, makes a request to LangChain, and returns the result. ``` ``` - Then, you can access the `apiKey` using the `ctx.secret.value()` function. ``` 最後,透過在終端機中執行此命令將 OpenAI API 金鑰儲存為機密。 ![翅膀的秘密](https://www.winglang.io/assets/images/qa-bot-wing-secrets-883db5e81515894ae280d77b7f72bb25.gif) 恭喜!您已成功完成本教學的專案。 以下是該應用程式的簡短演示: ![QA 機器人演示](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ropklqge2xzpibl29vye.gif) --- 讓我們更深入地研究 Wing 文件,看看我們的 AI 機器人可以提取哪些資料。 ![QA 機器人演示](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hnmf6n6mszc6go0uiw1v.gif) --- 總結一下 ---- 到目前為止,我們已經討論了以下內容: - 什麼是翼? - 如何使用Wing並使用Langchain查詢資料, - 如何將 Wing 連接到 Next.js 應用程式, - 如何在 Next.js 前端和 Wing 後端之間發送資料。 > [Wing](https://github.com/winglang/wing)旨在恢復您的創意流並縮小想像力與創造之間的差距。 Wing 的另一個巨大優勢是它是開源的。因此,如果您希望建立利用雲端服務的分散式系統或為雲端開發的未來做出貢獻, [Wing](https://github.com/winglang/wing)是您的最佳選擇。 請隨意為[GitHub 儲存庫做出貢獻,](https://github.com/winglang/wing)並與團隊和大型開發人員社群[分享您的想法](https://t.winglang.io/discord)。 本教學的源程式碼可[在此處](https://github.com/NathanTarbert/wing-langchain-nextjs)取得。 感謝您的閱讀! 🎉 --- 原文出處:https://dev.to/winglang/build-a-qa-bot-for-your-documentation-with-langchain-27i4

開始使用 Kubernetes 最簡單的方法

他們說第一步總是最難的。當這一步朝著 Kubernetes 的方向邁出時,它會讓人感覺更加令人生畏。有時,您會因為不明白的事情太多而感到「癱瘓」。或者更好地說,你**還不**明白。 但一旦踏出了第一步,剩下的事情就變得更容易實現了。那麼,就讓我們一起踏出第一步。哦,我們將使用一些工具來幫助我們。畢竟,我們正在努力盡可能簡單😉 ### 支持我們🙏 我們知道 Kubernetes 可能很困難。這就是我們建立 Cyclops 的原因,這是一個**真正**面向開發人員的 Kubernetes 平台。抽象化 Kubernetes 的複雜性,並透過 UI 部署和管理您的應用程式。由於其平台性質,UI 本身是高度可自訂的 - 您可以更改它以滿足您的需求。 我們正在將 Cyclops 開發為開源專案。如果您熱衷於嘗試一下,我們的[儲存庫](https://github.com/cyclops-ui/cyclops)中提供了快速入門指南。如果您喜歡所看到的內容,請考慮給我們一顆星來表示您的支持⭐ ![gh星](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gp8slhkg99fzbu6u9683.gif) 一個集群🌐 ----- 開始使用 Kubernetes 需要的第一件事是叢集。通常,叢集代表執行應用程式的伺服器集區。但目前,您不需要伺服器集區。讓我們從簡單的事情開始:一個可以幫助我們掌握訣竅的當地遊樂場。 快速執行叢集的最簡單方法之一是使用 Minikube。 Minikube 是一個在您的電腦上設定本機 Kubernetes 叢集的工具。它非常適合開發和測試目的。首先,您需要: 1. **安裝 Docker** :docker 將允許我們在隔離環境中執行 Minikube,您可以[在此處](https://docs.docker.com/engine/install/)了解如何下載它 2. **安裝 Minikube** :按照[Minikube 網站](https://minikube.sigs.k8s.io/docs/)上的說明將其安裝到您的電腦上。 3. **啟動 Minikube** :安裝後,您可以使用下列命令啟動本機叢集: ``` minikube start ``` 這將在您的電腦上設定一個單節點(單一伺服器)Kubernetes 叢集。 配置🗄️ ---- 這通常是使用 Kubernetes 時最棘手的部分。為了讓 Kubernetes 執行您的應用程式,您必須建立一個設定檔來告訴 Kubernetes 如何處理您的應用程式。這些文件傳統上是用 YAML 編寫的,並遵循自己的語法和規則。 但好訊息是: **Cyclops 可以讓您完全跳過這個過程。** [Cyclops](https://github.com/cyclops-ui/cyclops)是一個開源工具,它提供了一個用戶友好的介面,用於配置您的應用程式以在 Kubernetes 中執行。 Cyclops 提供的 UI 在透過其模板功能定義配置時是高度可自訂的。它還附帶了一些預先定義的模板,可幫助您開始您的旅程。 Cyclops 的設定很簡單,只需要兩個指令: ``` kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.6.2/install/cyclops-install.yaml && kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.6.2/install/demo-templates.yaml ``` 其次: ``` kubectl port-forward svc/cyclops-ui 3000:3000 -n cyclops ``` 只需在這些命令之間等待幾秒鐘,即可讓 Kubernetes 叢集啟動 Cyclops。 現在,轉到[localhost:3000](http://localhost:3000/modules) ,您應該已準備就緒! ![獨眼巨人模組螢幕](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/iw73cwy4dtd3poqjhpfh.png) 在叢集內執行您的應用程式🏃 ------------- 進入獨眼巨人後,您將看到一個螢幕,上面寫著“未找到模組”。模組是 Cyclops 描述應用程式的方式。下一步是在 Kubernetes 叢集中執行您的應用程式(模組),或者用 Kubernetes 術語來說,「部署您的應用程式」。 首先點擊右上角的**`Add module`**按鈕。這將帶您進入一個新螢幕**,其中將產生最後一步的設定檔。** Cyclops 使用範本產生設定檔([在此處](https://cyclops-ui.com/docs/templates/)查找更多相關資訊)。您可以建立自己的模板,但 Cyclops 附帶了一些非常適合入門的預定義模板。 在螢幕頂部,選擇**`demo-template`** 。您會注意到螢幕發生變化,並且出現新欄位!切換到另一個模板將更改螢幕上的字段,但現在我們繼續使用**`demo-template`** 。 您可以將欄位中的輸入保留原樣或根據您的喜好進行更改,但您必須為模組命名! 如果您有建立的應用程式的 Docker 映像並希望在 Kubernetes 中執行,您也可以這樣做!只需將圖像的名稱放入**`image`**字段,將其版本放入**`version`**字段即可。 ![獨眼巨人配置螢幕](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3r1pxarj3nudollwo742.png) 對這些欄位感到滿意後,點擊底部的**`Save`** ,*瞧,***您的應用程式已部署!** 應用程式剖析 🫀 -------- Kubernetes 面臨的挑戰之一是它使用的資源種類繁多。然而,Cyclops 透過**顯示模組建立的所有資源**使這一切變得容易。這種視覺表示確實可以幫助您了解應用程式的結構。 透過`demo-template`和輸入的內容,我們建立了一個簡單的 Kubernetes 配置,其中包含服務和部署,如螢幕上所示。這是您將遇到的兩個最常見的資源,也是了解整個系統的良好切入點。 ![獨眼巨人模組概述螢幕](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ab6v8o6r3ghx6ehpy9sa.png) Cyclops 介面以清晰、有組織的方式顯示所有這些元件,讓您可以輕鬆了解應用程式的結構以及不同部分如何組合在一起。 例如,您可以看到名為「my-app」的應用程式正在 Minikube 上執行,並帶有 Nginx 容器的副本(版本 1.14.2)。您可以直接從此介面查看日誌或修改設定。 這種視覺化方法有助於彌合開發人員與 Kubernetes 底層基礎架構之間的差距,讓您更輕鬆地管理和理解應用程式。 後續步驟👣 ----- 現在你已經打破了僵局,Kubernetes 感覺不再那麼可怕了。我建議您嘗試 Cyclops 提供的其他模板,看看不同的模板如何建立不同的資源。 掌握 Kubernetes 的旅程漫長且乏味。然而,你不必獨自走這條路!加入我們的[Discord 社群](https://discord.com/invite/8ErnK3qDb3)並與其他人聯繫,如果您感到迷茫,他們可以為您提供幫助! 如果您喜歡這篇文章,請記得在我們的[倉庫](https://github.com/cyclops-ui/cyclops)上給我們一顆星來支持我們⭐ --- 原文出處:https://dev.to/cyclops-ui/the-easiest-way-to-get-started-with-kubernetes-3mg7

Docker 掌握:初學者和專業人士的全面指南

Docker 是一個功能強大的平台,可簡化輕量級、可移植容器中應用程式的建立、部署和管理。它允許開發人員將應用程式及其相依性打包到標準化單元中,以實現無縫開發和部署。 Docker 增強了不同環境之間的效率、可擴展性和協作,使其成為現代軟體開發和 DevOps 實踐的重要工具。 我們將深入研究 Docker 的各個方面,從安裝和配置到掌握映像、儲存、網路和安全性。 安裝與配置 ----- 下面給出了在 CentOS 和 Ubuntu 上安裝 Docker Community Edition (CE) 的基本指南。 **在 CentOS 上安裝 Docker CE** - 安裝所需的軟體包: `sudo yum install -y () device-mapper-persistent-data lvm2` - 新增 Docker CE yum 儲存庫: `sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo` - 安裝 Docker CE 軟體包: `sudo yum install -y docker-ce-18.09.5 docker-ce-cli-18.09.5 containerd.io` - 啟動並啟用 Docker 服務: `sudo systemctl 啟動 docker sudo systemctl 啟用 docker` 將使用者加入Docker群組,授予使用者執行Docker命令的權限。下次登入後它將可以存取 Docker。 `sudo usermod -a -G docker` **在 Ubuntu 上安裝 Docker CE** - 安裝所需的軟體包: `sudo apt-get 更新 sudo apt-get -y install apt-transport-https ca-certificates curl gnupg-agent software-properties-common` - 新增 Docker 儲存庫的 GNU Privacy Guard (GPG) 金鑰: `curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -` - 新增 Docker Ubuntu 儲存庫: `sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable` - 安裝包: `sudo apt-get install -y docker-ce=5:18.09.5~3-0~ubuntu-bionic docker-ce-cli=5:18.09.5~3-0~ubuntu-bionic containerd.io` 將使用者加入Docker群組,授予使用者執行Docker命令的權限。下次登入後它將可以存取 Docker。 `sudo usermod -a -G docker` **選擇儲存驅動程式** 儲存驅動程式是處理容器內部儲存的可插入驅動程式。 CentOS和Ubuntu系統的預設驅動程式是overlay2。 若要確定目前的儲存驅動程式: `docker info | grep "Storage"` 選擇不同儲存驅動程式的一種方法是將`--storage-driver`標誌傳遞給 Docker 守護程式。設定儲存驅動程式的建議方法是使用守護程式設定檔。 - 建立或編輯守護程序設定檔: `sudo vi /etc/docker/daemon.json` - 新增儲存驅動程式值: `"storage-driver": "overlay2"` 請記住在進行任何更改後重新啟動 Docker,然後檢查狀態。 `sudo systemctl 重新啟動 docker sudo systemctl 狀態泊塢窗` **執行容器** `docker run IMAGE[:TAG] [COMMAND] [ARGS]` `IMAGE` :指定執行容器的映像。 `COMMAND and ARGS` :在容器內執行指令。 `TAG` :指定影像標籤或版本 `-d` :以分離模式運作容器。 `--name NAME` :為容器指定一個指定的名稱,而不是通常隨機分配的名稱。 `--restart RESTART` :指定 Docker 何時自動重新啟動容器。 - `no (default)` :從不重新啟動容器。 - `on-failure` :僅當容器失敗時(以非零退出程式碼退出)。 - `always` :無論成功或失敗,始終重新啟動容器。 - `unless-stopped` :無論容器成功或失敗,始終重新啟動容器,並且在守護程序啟動時,除非手動停止容器。 `-p HOST_PORT` : CONTAINER\_PORT:發布容器的連接埠。 HOST\_PORT 是在主機上偵聽的端口,到該端口的流量將映射到容器上的 CONTAINER\_PORT。 `--memory MEMORY` :對記憶體使用設定硬性限制。 `--memory-reservation MEMORY` :設定記憶體使用的軟限制。 `docker run -d --name nginx --restart unless-stopped -p 8080:80 --memory 500M --memory-reservation 256M nginx:latest` 用於管理正在執行的容器的一些命令是: `docker ps` :列出正在執行的容器。 `docker ps -a` :列出所有容器,包括已停止的容器。 `docker container stop [alias: docker stop]` :停止正在運作的容器。 `docker container start [alias: docker start]` :啟動已停止的容器。 `docker container rm [alias: docker rm]` :刪除容器(必須先停止) **升級 Docker 引擎** 停止 Docker 服務: `sudo systemctl stop docker` 安裝所需版本的 docker-ce 和 docker-ce-cli: `sudo apt-get install -y docker-ce=<new version> docker-ce-cli=<new version>` 驗證目前版本 `docker version` 鏡像建立、管理和註冊 ---------- 鏡像是一個可執行包,包含執行容器所需的所有軟體。 使用映像執行容器: `docker run IMAGE` 下載圖片: `docker拉映像 docker鏡像拉取鏡像` 映像和容器使用分層檔案系統。每層僅包含與前一層的差異。 使用以下命令查看影像中的檔案系統層: `docker image history IMAGE` Dockerfile 是一個定義了一系列指令並用於建立映像的檔案。 ``` # Use the official Nginx base image FROM nginx:latest # Set an environment variable ENV MY_VAR=my_value # Copy custom configuration file to container COPY nginx.conf /etc/nginx/nginx.conf # Run some commands during the build process RUN apt-get update && apt-get install -y curl # Expose port 80 for incoming traffic EXPOSE 80 # Start Nginx server when the container starts CMD ["nginx", "-g", "daemon off;"] ``` 建構圖像: `docker build -t TAG_NAME DOCKERFILE_LOCATION` Dockerfile 指令: `FROM` :指定用於正在建置的 Docker 映像的基礎映像。它定義了映像的起點,可以是 Docker Hub 或私有註冊表上可用的任何有效映像。 `ENV` :設定影像內的環境變數。在建置過程和容器執行時可以存取這些變數。 `COPY or ADD` :將檔案和目錄從建置上下文(Dockerfile 所在的目錄)複製到映像中。 COPY 通常更適合簡單的文件複製,而 ADD 支援附加功能,例如解壓縮存檔。 `RUN` :在建置過程中執行指令。您可以使用 RUN 安裝依賴項、執行腳本或執行任何其他必要的任務。 `EXPOSE` :通知 Docker 容器將在執行時間監聽指定的網路連接埠。它不會將連接埠發佈到主機或使容器可以從外部存取。 `CMD or ENTRYPOINT` :指定從映像啟動容器時要執行的指令。 CMD 提供可以覆寫的預設參數,而 ENTRYPOINT 指定不能覆寫的指令。 `WORKDIR` :設定任何後續 RUN、CMD、ENTRYPOINT、COPY 或 ADD 指令的工作目錄。 `STOPSIGNAL` :設定將用於停止容器程序的自訂訊號。 `HEALTHCHECK` :設定 Docker 守護程式將使用的指令來檢查容器是否健康 Dockerfile 中的多階段建置是一種用於建立更有效率、更小的 Docker 映像的技術。它涉及在 Dockerfile 中定義多個階段,每個階段都有自己的一組指令和依賴項。 包含多階段建置定義的範例 Dockerfile 是: ``` # Build stage FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build WORKDIR /app # Copy and restore project dependencies COPY *.csproj . RUN dotnet restore # Copy the entire project and build COPY . . RUN dotnet build -c Release --no-restore # Publish the application RUN dotnet publish -c Release -o /app/publish --no-restore # Runtime stage FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS runtime WORKDIR /app COPY --from=build /app/publish . # Expose the required port EXPOSE 80 # Set the entry point for the application ENTRYPOINT ["dotnet", "YourApplication.dll"] ``` **管理影像** 影像管理的一些關鍵命令是: 列出系統上的影像: `docker image ls` 列出系統上的映像,包括中間映像: `docker image ls -a` 取得有關圖像的詳細資訊: `docker image inspect <IMAGE>` 刪除影像: `docker rmi docker 映像 rm docker 映像 rm -f ` 只有當沒有容器或其他圖像標籤引用圖像時,圖像才會被刪除。尋找並刪除懸空或未使用的圖像: `docker image prune` **Docker 註冊表** Docker 註冊表可作為儲存和共用 Docker 映像的集中儲存庫。 Docker Hub 是由 Docker 管理的預設、公開可用的註冊表。透過利用註冊表鏡像,我們可以免費設定和管理我們自己的私有註冊表。 執行一個簡單的註冊表: `docker run -d -p 5000:5000 --restart=always --name registry registry:2` 將圖像上傳到註冊表: `docker push <IMAGE>:<TAG>` 從註冊表下載映像: `docker pull <IMAGE>:<TAG>` 登入註冊表: `docker login REGISTRY_URL` 有兩種身份驗證方法可用於使用不受信任或自簽名憑證連接到私有註冊表: **安全性**:這涉及將註冊表的公共憑證新增至 /etc/docker/certs.d/ 目錄。 **Insecure** :此方法需要將登錄檔新增至 daemon.json 檔案中的 insecure-registries 清單中,或使用 --insecure-registry 標誌將其傳遞給 dockerd。 **儲存和磁碟區** 儲存驅動程式控制如何在 Docker 主機上儲存和管理映像和容器。 Docker 使用可插拔架構支援多種儲存驅動程式。 **overlay2** :所有 Linux 發行版的首選 **fusion-overlayfs** :僅適用於執行 Rootless Docker(不是 Ubuntu 或 Debian 10) **vfs** :用於測試目的,以及無法使用寫入時複製檔案系統的情況。 **儲存型號** \*\*檔案系統儲存:\*\* - 資料以常規檔案的形式儲存在主機磁碟上 - 有效利用記憶體 - 寫入繁重的工作負載效率低下 - overlay2使用 **區塊儲存:** - 使用特殊的區塊儲存設備將資料儲存在區塊中 - 高效率處理寫入繁重的工作負載 - 由 btrfs 和 zfs 使用 **物件儲存:** - 將資料儲存在外部基於物件的儲存中 - 應用程式必須設計為使用基於物件的儲存。 - 靈活且可擴展。 **配置overlay2儲存驅動** 停止 Docker 服務: `sudo systemctl stop docker` 建立或編輯守護程序設定檔: `sudo vi /etc/docker/daemon.json` 新增/編輯儲存驅動程式值: `"storage-driver": "overlay2"` 請記住在進行任何更改後重新啟動 Docker,然後檢查狀態。 `sudo systemctl 重新啟動 docker sudo systemctl 狀態泊塢窗` **Docker 卷** Docker 上有兩種不同類型的資料掛載: **Bind Mount** :將主機上的特定目錄掛載到容器。它對於在容器和主機之間共用設定檔和其他資料非常有用。 **命名磁碟區**:將目錄掛載到容器,但 Docker 動態控製磁碟區在磁碟上的位置。 在容器中新增綁定掛載或磁碟區有不同的語法: \_-v 語法 \_ 綁定安裝:來源以正斜線“/”開頭,這使其成為綁定安裝。 `docker run -v /opt/data:/tmp nginx` 命名卷:來源只是一個字串,這表示這是一個磁碟區。如果不存在具有所提供名稱的捲,它將自動建立。 `docker run -v my-vol:/tmp nginx` *--掛載語法* 綁定掛載: `docker run --mount source=/opt/data,destination=/tmp nginx` 命名卷: `docker run --mount source=my-vol,destination=/tmp nginx` 我們可以將相同的磁碟區掛載到多個容器,從而允許它們共享資料。我們也可以自己建立和管理卷,而無需執行容器。 一些常見且有用的指令: `docker volume create VOLUME` :建立一個磁碟區。 `docker volume ls` :列出卷。 `docker volume inspect VOLUME` :檢查卷。 `docker volume rm VOLUME` :刪除磁碟區。 **影像清理** 檢查Docker的磁碟使用情況: `docker system df` `docker system df -v` 刪除未使用或懸空的影像: `docker 映像修剪 docker映像修剪-a` Docker 網路 --------- Docker 容器網路模型 (CNM) 是一個概念模型,描述 Docker 網路的元件和概念。 Docker CNM 有多種實作: **沙箱**:一個隔離單元,包含與單一容器關聯的所有網路元件。 **端點**:將一個沙箱連接到一個網路。 **網路**:可以相互通訊的端點的集合。**網路驅動程式**:可插拔驅動程序,提供 CNM 的特定實作。 **IPAM 驅動程式**:提供 IP 位址管理。分配和指派 IP 位址。 **內建網路驅動程式** **Host** :此驅動程式將容器直接連接到主機的網路堆疊。它不提供容器之間或容器與主機之間的隔離。 `docker run --net host nginx` **Bridge** :此驅動程式使用虛擬橋接器介面在同一主機上執行的容器之間建立連線。 `docker 網路建立 --driver 橋 my-bridge-net docker run -d --network my-bridge-net nginx` **Overlay** :此驅動程式使用路由網格來連接多個 Docker 主機(通常在 Docker 群組中)的容器。 `docker 網路建立 --driver 覆蓋 my-overlay-net docker 服務建立 --network my-overlay-net nginx` **MACVLAN** :此驅動程式將容器直接連接到主機的網路接口,但使用特殊配置來提供隔離。 `docker網路建立-d macvlan --subnet 192.168.0.0/24 --gateway 192.168.0.1 -oparent=eth0 my-macvlan-net docker run -d --net my-macvlan-net nginx` **None** :此驅動程式提供沙箱隔離,但它不提供容器之間或容器與主機之間的網路的任何實作。 `docker run --net none -d nginx` **建立 Docker 橋接網絡** 它是預設驅動程式。因此,任何在未指定驅動程式的情況下建立的網路都將是橋接網路。 建立橋接網路。 `docker network create my-net` 在橋接網路上執行容器。 `docker run -d --network my-net nginx` 預設情況下,同一網路上的容器和服務只需使用容器或服務名稱即可相互通訊。 Docker 在網路上提供 DNS 解析,使其能夠正常運作。 提供網路別名以提供存取容器或服務的附加名稱。 `docker run -d --network my-net --network-alias my-nginx-alias nginx` 當必須與 Docker 網路互動時,一些有用的命令是: `docker network ls` :列出網路。 `docker network inspect NETWORK` :檢查網路。 `docker network connect CONTAINER NETWORK` :將容器連接到網路。 `docker network disconnect CONTAINER NETWORK` :斷開容器與網路的連接。 `docker network rm NETWORK` :刪除網路。 **建立 Docker 覆蓋網絡** 建立覆蓋網路: `docker network create --driver overlay NETWORK_NAME` 建立使用網路的服務: `docker service create --network NETWORK_NAME IMAGE` **網路故障排除** 查看容器日誌: `docker logs CONTAINER` 查看服務的所有任務的日誌: `docker service logs SERVICE` 查看Docker守護程序日誌: `sudo jounralctl -u docker` 我們可以使用nicolaka/netshoot鏡像來執行網路故障排除。它附帶了各種有用的網路相關工具。我們可以將一個容器注入另一個容器的網路沙箱中以進行故障排除。 `docker run --network container:CONTAINER_NAME nicolaka/netshoot` **配置 Docker 使用外部 DNS** 在 daemon.json 中為 Docker 容器設定係統範圍的預設 DNS: `{ “DNS”:\[“8.8.8.8”\] }` 為單一容器設定 DNS。 `docker run --dns 8.8.4.4 IMAGE` 安全 -- **簽署映像並啟用 Docker 內容信任** Docker Content Trust (DCT) 是一項功能,可讓我們在執行映像之前對映像進行簽名並驗證簽名。透過設定環境變數啟用 Docker Content Trust: `DOCKER_CONTENT_TRUST=1` 如果映像未簽署或在啟用 Docker Content Trust 的情況下簽章無效,系統將不會運作映像。 使用以下命令簽署並推送映像: `docker trust sign` 當 DOCKER\_CONTENT\_TRUST=1 時,docker push 在推送之前會自動對映像進行簽署。 **預設 Docker 引擎安全性** 基本的 Docker 安全性概念: Docker 使用命名空間將容器程序彼此隔離以及與主機隔離。這可以防止攻擊者在設法獲得對一個容器的控制時影響或獲得對其他容器或主機的控制。 Docker 守護程式必須以 root 存取權限執行。在允許任何人與守護進程互動之前,請注意這一點。它可用於存取整個主機。 Docker 利用 Linux 功能為容器程序分配精細權限。例如,偵聽低埠(低於 1024)通常需要進程以 root 身分執行,但 Docker 使用 Linux 功能允許容器偵聽連接埠 80,而無需以 root 身分執行。 **保護 Docker 守護程式 HTTP 套接字的安全** 為 Docker 伺服器產生憑證授權單位和伺服器憑證。 ``` openssl genrsa -aes256 -out ca-key.pem 4096` `openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem -subj "/C=US/ST=Texas/L=Keller/O=Linux Academy/OU=Content/CN=$HOSTNAME" openssl genrsa -out server-key.pem 4096 ` `openssl req -subj "/CN=$HOSTNAME" -sha256 -new -key server-key.pem -out server.csr \ echo subjectAltName = DNS:$HOSTNAME,IP:,IP:127.0.0.1 >> extfile.cnf ` `echo extendedKeyUsage = serverAuth >> extfile.cnf ` `openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf` Generate client certificates: `openssl genrsa -out key.pem 4096 openssl req -subj '/CN=client' -new -key key.pem -out client.csr echo extendedKeyUsage = clientAuth > extfile-client.cnf openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem \ -CAcreateserial -out cert.pem -extfile extfile-client.cnf ``` 對憑證文件設定適當的權限: `chmod -v 0400 ca-key.pem key.pem server-key.pem chmod -v 0444 ca.pem server-cert.pem cert.pem` 將 Docker 主機配置為使用 tlsverify 模式以及先前建立的憑證: ``` sudo vi /etc/docker/daemon.json { "tlsverify": true, "tlscacert": "/home/user/ca.pem", "tlscert": "/home/user/server-cert.pem", "tlskey": "/home/user/server-key.pem" } ``` 編輯 Docker 服務文件,尋找以 ExecStart 開頭的行並更改 -H。 `sudo vi /lib/systemd/system/docker.service` `ExecStart=/usr/bin/dockerd -H=0.0.0.0:2376 --containerd=/run/containerd/containerd.sock` `sudo systemctl daemon-reload` `sudo systemctl restart docker` 將 CA 憑證和用戶端憑證檔案複製到客戶端電腦。 在用戶端電腦上,設定用戶端以安全地連線到遠端 Docker 守護程式: `mkdir -pv ~/.docker` `cp -v {ca,cert,key}.pem ~/.docker` `export DOCKER_HOST=tcp://:2376 DOCKER_TLS_VERIFY=1` 測試連接: `docker version` 結論 -- 總而言之,掌握 Docker 可以簡化安裝、設定、映像管理、儲存、網路和安全性,從而改變您的開發工作流程。本指南為您提供必要的知識和實務技能,使您能夠有效率地建立、發布和執行應用程式。利用 Docker 的強大功能將您的容器管理提升到一個新的水平。 --- 原文出處:https://dev.to/theyasirr/docker-mastery-a-comprehensive-guide-for-beginners-and-pros-2p18

GraphQL、REST 和 gRPC 之間的區別

*揭露:這篇文章包含附屬連結;如果您透過本文中提供的不同連結購買產品或服務,我可能會獲得補償。* [![GraphQL、REST 和 gRPC 之間的區別](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/j0rpasf3053dewpovmo4.png)](https://bit.ly/3pMiO8g) image\_credit -[設計大師](https://bit.ly/3pMiO8g) 開發者們大家好,如果您正在準備編碼面試以及系統設計和微服務面試,您還應該準備 REST、GraphQL 和 gRPC 等內容,例如**REST、GraphQL 和 gRPC 之間有什麼區別?** ,這也是程式設計面試的熱門議題之一。 之前,我討論了[API 網關與負載平衡器](https://dev.to/somadevtoo/difference-between-api-gateway-and-load-balancer-in-system-design-54dd)、[水平與垂直擴展](https://dev.to/somadevtoo/horizontal-scaling-vs-vertical-scaling-in-system-design-3n09)、 [正向代理與反向代理](https://dev.to/somadevtoo/difference-between-forward-proxy-and-reverse-proxy-in-system-design-54g5)之間的區別以及[**JWT、OAuth 和 SAML 之間的區別**](https://medium.com/javarevisited/difference-between-jwt-oauth-and-saml-for-authentication-and-authorization-in-web-apps-75b412754127),在本文中,我將分享我對REST、 GraphQL 的想法,和 gRPC,這三種用於建立 Web API 的流行通訊協定。 它們用於允許不同的軟體元件透過網路相互通信,例如[微服務可以使用 REST 在它們之間進行同步通訊](https://medium.com/javarevisited/how-microservices-communicates-with-each-other-synchronous-vs-asynchronous-communication-pattern-31ca01027c53)。 這些協議都有自己的優點和缺點,了解它們之間的差異不僅從技術面試的角度很重要,而且對於為您的專案選擇正確的協議也很重要。 在本文中,您將了解**REST、GraphQL 和 gRPC 之間的差異**。您將了解每個協議背後的核心概念、它們的優點和缺點,並提供一些何時使用每個協議的用例。 讀完本文後,您應該更了解哪種協議最適合您的專案要求。 順便說一句,如果您正在準備系統設計面試並想深入學習系統設計,那麼您還可以查看[**ByteByteGo**](https://bit.ly/3P3eqMN) 、 [**Design Guru**](https://bit.ly/3pMiO8g) 、 [**Exponent**](https://bit.ly/3cNF0vw) 、 [**Educative**](https://bit.ly/3Mnh6UR)和[**Udemy**](https://bit.ly/3vFNPid)等網站,它們有許多很棒的系統設計課程 [![如何回答系統設計問題](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fehiytzxrwt4g89ubwfm.jpg)](https://bit.ly/3pMiO8g) 我們將首先進行一些介紹,然後深入研究它們中的每一個,然後再次回顧它們的差異,以便您清楚地了解它們的優點和缺點以及何時使用它們。 [REST](https://en.wikipedia.org/wiki/Representational_state_transfer)代表表述性狀態傳輸,它是一種流行的協議,用於建立透過 HTTP 公開資料和功能的 Web 服務。 它基於 HTTP 協定和一組約束,定義如何辨識和定址資源以及如何對這些資源執行操作。 另一方面, [**GraphQL**](https://graphql.org/)是 Facebook 開發的 API 查詢語言。它允許客戶端準確指定他們需要的資料,並且伺服器僅使用該資料進行回應。 GraphQL 的建立是為了解決 REST 的缺點和限制,因此它提供了一種更靈活、更有效的從伺服器獲取資料的方式,因為客戶端可以在單一請求中請求多個資源。 而且, [gRPC](https://grpc.io/)是一種用於建立 API 的高效能開源協定。它使用**Google 的 Protocol Buffers**作為資料格式,並提供對串流和雙向通訊的支援。 gRPC 由於其效能和對多種程式語言的支援而經常用於[微服務架構](https://javarevisited.substack.com/p/difference-between-microservices)中。 現在我們知道它們是什麼,讓我們深入研究它們。 --- 什麼是 REST?什麼時候使用它? -------------- 正如我所說,REST(表述性狀態傳輸)是一種用於設計分散式應用程式(尤其是基於 Web 的 API)的架構風格。 [RESTful API](https://javarevisited.blogspot.com/2018/02/top-5-restful-web-services-with-spring-courses-for-experienced-java-programmers.html)使用 HTTP 方法(例如 GET、POST、PUT、DELETE)對 URL(統一資源定位器)辨識的資源執行 CRUD(建立、讀取、更新、刪除)操作。 > > 如果您了解 HTTP,那麼您就了解 REST。 REST 還依賴**無狀態的客戶端-伺服器架構**,其中來自客戶端的每個請求都包含伺服器完成請求所需的所有訊息,而無需維護會話狀態。 以下是 REST 是不錯選擇的一些場景: 1. **當您需要透過 API 公開資料和服務時,**因為 REST 是一種流行且完善的協議,用於建立可供其他應用程式和服務輕鬆使用的 API。 2. **當您需要支援多種平台和程式語言時,**因為 REST 依賴標準 HTTP 方法和資料格式,因此它可以被多種程式語言和平台使用。 3. **當您需要支援快取時,**因為REST支援緩存,這可以提高效能並減少網路流量。 4. 當您需要建立簡單、輕量級的 API 時 5. 當您需要支援大量資源時 此外,了解 HTTP 方法對於設計 REST API 非常重要。您可以進一步查看[**REST API 設計、開發和管理**](https://click.linksynergy.com/fs-bin/click?id=JVFxdTr9V80&subid=0&offerid=323058.1&type=10&tmpid=14538&RD_PARM1=https%3A%2F%2Fwww.udemy.com%2Frest-api%2F)課程,以了解 REST API 設計、開發和管理。 [![何時使用 REST API](https://miro.medium.com/v2/resize:fit:609/1*X-VfQ3bf6WL-tcb9C8J7DA.png)](https://click.linksynergy.com/fs-bin/click?id=JVFxdTr9V80&subid=0&offerid=323058.1&type=10&tmpid=14538&RD_PARM1=https%3A%2F%2Fwww.udemy.com%2Frest-api%2F) 總體而言, **REST 是一種靈活且廣泛採用的協議**,對於許多類型的 API 來說都是不錯的選擇。 然而,它可能不是所有場景的最佳選擇,特別是那些需要即時更新或更複雜的查詢和資料操作的場景。 在這些情況下,其他協定(例如 GraphQL 或 gRPC)可能更合適。 --- 什麼是 GraphQL?什麼時候使用它? -------------------- GraphQL 是一種 API 查詢語言,由 Facebook 於 2012 年開發,並於 2015 年作為開源專案發布。 GraphQL 允許客戶端定義他們所需的資料結構,並且伺服器可以準確地回應該資料,而無需任何不必要的資料。 它通常用作 RESTful API 的替代方案,特別是在客戶端需要對傳回的資料進行細微控制的情況下。 以下是 GraphQL 是不錯選擇的一些場景: 1. 當您想要減少網路流量時,GraphQL 允許客戶端準確指定他們需要的資料,這可以減少透過網路傳輸的不必要的資料量。 2. 當您需要支援各種客戶端時,因為 GraphQL 支援強類型查詢,這可用於確保客戶端以他們理解的格式接收正確的資料。 3. **當您需要支援即時更新時**,因為 GraphQL 支援透過訂閱進行即時更新,這允許客戶端在更新可用時立即接收更新。 4. 當您需要支援複雜的查詢和資料操作時:因為GraphQL允許客戶端使用簡單的語法執行複雜的查詢和資料操作操作,例如過濾、排序和聚合。 5. 當您需要支援版本控制時,因為 GraphQL 透過允許客戶端指定他們在請求中使用的架構版本來支援版本控制,這樣隨著架構隨時間的發展,可以更輕鬆地保持向後相容性。 總的來說,GraphQL 是一個強大且靈活的協議,對於資料細粒度控制和即時更新很重要的場景來說,它是一個不錯的選擇。 但是,**它可能比 RESTful API 需要更多的設定和配置,**特別是當您使用多種程式語言或平台時。 您可以進一步查看[**GraphQL by Example**](https://click.linksynergy.com/deeplink?id=CuIbQrBnhiw&mid=39197&murl=https%3A%2F%2Fwww.udemy.com%2Fcourse%2Fgraphql-by-example%2F%3FcouponCode%3DLEADERSALE24A)和[GraphQL with React: The Complete Developers Guide](https://click.linksynergy.com/deeplink?id=CuIbQrBnhiw&mid=39197&murl=https%3A%2F%2Fwww.udemy.com%2Fcourse%2Fgraphql-with-react-course%2F%3FcouponCode%3DLEADERSALE24A)以了解有關 GraphQL 及其使用方法的更多資訊。 這也是一個很好的圖表,突出顯示了**REST 和 GraphQL 查詢之間的差異:** [![何時使用 GraphQL](https://miro.medium.com/v2/resize:fit:609/0*7uX0fDc7ROg3OgjF.png)](https://click.linksynergy.com/deeplink?id=CuIbQrBnhiw&mid=39197&murl=https%3A%2F%2Fwww.udemy.com%2Fcourse%2Fgraphql-by-example%2F%3FcouponCode%3DLEADERSALE24A) --- 什麼是 gRPC?什麼時候使用它? ----------------- 現在讓我們看看什麼是 gRPC 以及它提供什麼? gRPC 是 Google 開發的一個高效能、開源的遠端過程呼叫 (RPC) 框架。 它使用Protocol Buffers作為介面描述語言,支援多種程式語言,可以輕鬆建構跨不同平台和環境的分散式系統。 以下是 gRPC 是不錯選擇的一些場景: 1. **當您需要高效能和高效率時,**因為 gRPC 使用二進位協定並支援串流傳輸,這可以使其比其他協定更快、更有效率,特別是在高延遲或低頻寬連線上。 2. 當您需要支援多種程式語言時,因為 gRPC 支援多種程式語言,包括 Java、C++、Python 和 Go,可以輕鬆建立跨不同平台和環境的分散式系統。 3. 當您需要支援即時更新時,因為 gRPC 支援雙向流,這允許伺服器即時向客戶端發送更新。 4. **當您需要處理大量資料時,**因為 gRPC 使用 Protocol Buffers,它比 JSON 或 XML 等其他資料格式更有效率、更緊湊,使其成為處理大量資料的不錯選擇。 5. 當您需要建立微服務或分散式系統時,因為 gRPC 提供了一個強大且靈活的框架,用於建立可以水平擴展並處理大量流量的微服務和分散式系統。 總體而言,gRPC 是一個強大且高效的協議,對於效能、效率和即時更新很重要的場景來說,它是一個不錯的選擇。 但是,**與 RESTful API 等其他協定相比,它可能需要更多的設定和配置**,特別是當您使用多種程式語言或平台時。 您可以進一步查看[Protocol Buffers 3 完整指南 \[Java、Golang、Python\]](https://click.linksynergy.com/deeplink?id=JVFxdTr9V80&mid=39197&murl=https%3A%2F%2Fwww.udemy.com%2Fcourse%2Fprotocol-buffers%2F)和[gRPC \[Java\] 大師班:建立現代 API 和微服務](https://click.linksynergy.com/deeplink?id=JVFxdTr9V80&mid=39197&murl=https%3A%2F%2Fwww.udemy.com%2Fcourse%2Fgrpc-java%2F),以了解有關 gRPC 和 Google Protocol buffer 的更多資訊。 這是一個很好的圖表,突出顯示了 REST、gRPC 和 GraphQL 請求之間的區別 [![REST 和 GraphQL 之間的區別](https://miro.medium.com/v2/resize:fit:609/1*o4TgSCCvQgyE0OKsVSgQwg.png)](https://click.linksynergy.com/deeplink?id=JVFxdTr9V80&mid=39197&murl=https%3A%2F%2Fwww.udemy.com%2Fcourse%2Fprotocol-buffers%2F) image\_credit --- [https://medium.com/@LadyNoBug/grpc-vs-rest-vs-others-5d8b6eaa61df](https://medium.com/@LadyNoBug/grpc-v-s-rest-v-s-others-5d8b6eaa61df) --- GraphQL、REST 和 gRPC 之間的區別 ------------------------- 現在您已經了解什麼是REST、gRPC 和GraphQL 以及它們的工作原理,以下是REST、GraphQL 和gRPC 之間的主要區別(以點格式表示),記住它們的主要特徵以及何時在專案中使用它們: ### REST: - 代表代表性狀態轉移 - 使用 HTTP 方法(GET、POST、PUT、DELETE)執行 CRUD 操作 - 以結構化格式傳送資料,通常是 JSON 或 XML - 不同資源可以有多個端點 - 客戶端收到回應中指定的所有資料,即使他們不需要全部資料 - 支援緩存,但管理起來可能很複雜 - 完善且廣泛採用,提供大量工具和文件 ### 圖形語言: - 允許客戶準確指定他們需要什麼資料,並僅接收該資料 - 使用單一端點存取多個資源 - 擁有自己的查詢語言,允許複雜的資料取得和操作 - 可以支援透過訂閱即時更新 - 在某些情況下比 REST 更有效率,特別是對於頻寬有限的行動設備 - 與 REST 相比,快取可以更細粒度且更易於管理 - 比 REST 需要更多的設定和配置,並且可能需要更多的專業知識才能有效使用 ### 遠程過程呼叫: - 代表帶有 Google 協定緩衝區的遠端程序呼叫 (RPC) - 使用二進位資料代替 HTTP 進行通信 - 支援串流資料即時更新 - 使用協定緩衝區進行序列化,這比 JSON 或 XML 更有效率 - 可以跨不同的程式語言使用 - 專為微服務之間的高效能、低延遲通訊而設計 - 比 REST 需要更多的設定和配置,並且可能需要更多的專業知識才能有效使用 - 互通性可能不如 REST 或 GraphQL,因為它不是基於 HTTP 這裡還有一個很好的表格,突出顯示了 REST、GraphQL 和 gRPC 之間的區別,您可以使用它來快速複習: [![REST、GraphQL 和 gRPC 之間的區別](https://miro.medium.com/v2/resize:fit:609/1*USJRkl5JS0IT90RqwMEopA.png)](https://javarevisited.blogspot.com/2022/04/difference-between-graphql-and-rest-api.html) 還值得注意的是,**這些協議並不相互排斥,並且可以組合使用它們以利用它們的不同優勢。** 例如,您可能對大多數 API 使用 REST,但對某些資源密集型查詢使用 GraphQL,或使用 gRPC 在微服務之間進行通信,同時對外部 API 用戶端使用 REST 或 GraphQL。 --- ### 系統設計訪談資源: 而且,如果您正在準備系統設計面試,那麼這裡有一些最佳系統設計書籍、線上課程和練習網站的精選列表,您可以查看這些內容,以便更好地準備系統設計面試。 1. [**DesignGuru 的 Grokking 系統設計課程**](https://bit.ly/3pMiO8g):一個互動式學習平台,提供實作練習和真實場景,以增強您的系統設計技能。 2. [**《系統設計面試》作者:Alex Xu**](https://amzn.to/3nU2Mbp) :這本書深入探討了系統設計概念、策略和麵試準備技巧。 3. Martin Kleppmann 的[**「設計資料密集型應用程式」**](https://amzn.to/3nXKaas) :綜合指南,涵蓋了設計可擴展且可靠的系統的原則和實踐。 4. [LeetCode 系統設計 標籤](https://leetcode.com/explore/learn/card/system-design):LeetCode 是一個受歡迎的技術面試準備平台。 LeetCode 上的系統設計標籤包含各種需要練習的問題。 5. GitHub 上的[**「系統設計入門」**](https://bit.ly/3bSaBfC) :精選的資源列表,包括文章、書籍和影片,可幫助您準備系統設計面試。 6. [**Educative 的系統設計課程**](https://bit.ly/3Mnh6UR):一個互動式學習平台,提供實作練習和真實場景,以增強您的系統設計技能。 7. **高可擴展性部落格**:該部落格包含有關高流量網站和可擴展系統架構的文章和案例研究。 8. **[YouTube 頻道](https://medium.com/javarevisited/top-8-youtube-channels-for-system-design-interview-preparation-970d103ea18d)**:請參閱「Gaurav Sen」和「Tech Dummies」等頻道,以取得有關係統設計概念和麵試準備的富有洞察力的影片。 9. [**ByteByteGo**](https://bit.ly/3P3eqMN) :Alex Xu 的一本現場書籍和課程,用於系統設計面試準備。它包含《系統設計訪談》第一捲和第二卷的所有內容,並將隨即將推出的第三卷進行更新。 10. [**Exponent**](https://bit.ly/3cNF0vw) :一個專為面試準備的網站,特別是針對亞馬遜和谷歌等 FAANG 公司,他們還有很棒的系統設計課程和許多其他材料,可以幫助您破解 FAAN 面試。 [![如何為系統設計做準備](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kqv3p46jmw5qc0newuiu.jpg)](https://bit.ly/3P3eqMN) image\_credit - [ByteByteGo](https://bit.ly/3P3eqMN) #### 結論 這就是**REST、GraphQL 和 gRPC 技術之間的差異。**簡而言之,REST 是一種用於建立Web 服務的流行協議,受到HTTP 的啟發並充分利用HTTP 提供的功能,而GraphQL 是一種查詢語言,允許客戶端準確指定他們需要從伺服器獲取哪些資料。 它的建立是為了解決 REST 的缺點,因此如果您正在努力維護 REST API,那麼它絕對是一個可行的選擇。 另一方面, **gRPC**是一種高效能、開源協議,常用於微服務架構。 這些協定中的每一個都有不同的用途,並且它們都可以一起使用,為 Web 應用程式提供全面且高效的通訊系統。 --- 原文出處:https://dev.to/somadevtoo/difference-between-graphql-rest-and-grpc-58bl

TypeScript 專案的自訂實用程式類型

在我們探索 TypeScript 開發的第二部分中,我們引入了另外十種自訂實用程式類型,這些類型可以擴展程式碼的功能,提供更多工具來更有效地管理類型。這些實用程式類型有助於保持您的程式碼庫乾淨、高效和健壯。 第一部分: [TypeScript 專案的 1-10 個自訂實用程式類型](https://dev.to/antonzo/10-sustom-utility-types-for-typescript-projects-48pe) 總有機碳 ---- - [不可空深](#NonNullableDeep) - [合併](#Merge) - [元組到物件](#TupleToObject) - [獨佔元組](#ExclusiveTuple) - [Promise類型](#PromiseType) - [省略方法](#OmitMethods) - [函數參數](#FunctionArguments) - [承諾](#Promisify) - [約束函數](#ConstrainedFunction) - [聯合解析器](#UnionResolver) <a name="NonNullableDeep"></a> `NonNullableDeep` ----------------- `NonNullableDeep`類型是一個實用程序,可從給定類型`T`的所有屬性中深度刪除`null`和`undefined` 。這意味著不僅物件的頂級屬性不可為空,而且所有嵌套屬性也遞歸地標記為不可為空。在必須確保物件的屬性(包括深度嵌套的屬性)不為`null`或`undefined`情況下(例如在處理必須完全填充的資料時),此類型特別有用。 ``` type NonNullableDeep<T> = { [P in keyof T]: NonNullable<T[P]> extends object ? NonNullableDeep<NonNullable<T[P]>> : NonNullable<T[P]>; }; ``` **例子** 以下範例示範如何套用`NonNullableDeep`類型來確保`Person`物件本身及其任何巢狀屬性都無法為`null`或`undefined` ,從而確保整個物件已完全填入。 ``` interface Address { street: string | null; city: string | null; } interface Person { name: string | null; age: number | null; address: Address | null; } const person: NonNullableDeep<Person> = { name: "Anton Zamay", age: 26, address: { street: "Secret Street 123", city: "Berlin", }, }; // Error: Type 'null' is not assignable to type 'string'. person.name = null; // Error: Type 'undefined' is not assignable to type 'number'. person.age = undefined; // Error: Type 'null' is not assignable to type 'Address'. person.address = null; // Error: Type 'null' is not assignable to type 'string'. person.address.city = null; ``` <a name="Merge"></a> `Merge` ------- `Merge<O1, O2>`類型對於透過組合兩個物件類型`O1`和`O2`的屬性來建立新類型非常有用。當屬性重疊時, `O2`中的屬性將覆寫`O1`中的屬性。當您需要擴展或自訂現有類型以確保特定屬性優先時,這特別有用。 ``` type Merge<O1, O2> = O2 & Omit<O1, keyof O2>; ``` **例子** 在此範例中,我們定義了兩種物件類型,分別表示預設設定和使用者設定。使用`Merge`類型,我們組合這些設定來建立最終配置,其中`userSettings`會覆蓋`defaultSettings` 。 ``` type DefaultSettings = { theme: string; notifications: boolean; autoSave: boolean; }; type UserSettings = { theme: string; notifications: string[]; debugMode?: boolean; }; const defaultSettings: DefaultSettings = { theme: "light", notifications: true, autoSave: true, }; const userSettings: UserSettings = { theme: "dark", notifications: ["Warning 1", "Error 1", "Warning 2"], debugMode: true, }; type FinalSettings = Merge<DefaultSettings, UserSettings>; const finalSettings: FinalSettings = { ...defaultSettings, ...userSettings }; ``` <a name="TupleToObject"></a> `TupleToObject` --------------- `TupleToObject`類型是將元組類型轉換為物件類型的實用程序,其中元組的元素成為物件的鍵,並根據這些元素在元組中的位置提取關聯的值。這種類型在需要將元組轉換為更結構化的物件形式的情況下特別有用,允許透過元素的名稱而不是位置更直接地存取元素。 ``` type TupleToObject<T extends [string, any][]> = { [P in T[number][0]]: Extract<T[number], [P, any]>[1]; }; ``` **例子** 考慮這樣一個場景,您正在使用將表架構資訊儲存為元組的資料庫。每個元組包含一個欄位名稱及其對應的資料類型。這種格式通常用於資料庫元資料 API 或架構遷移工具。元組格式緊湊且易於處理,但對於應用程式開發來說,使用物件更方便。 ``` type SchemaTuple = [ ['id', 'number'], ['name', 'string'], ['email', 'string'], ['isActive', 'boolean'] ]; const tableSchema: SchemaTuple = [ ['id', 'number'], ['name', 'string'], ['email', 'string'], ['isActive', 'boolean'], ]; // Define the type of the transformed schema object type TupleToObject<T extends [string, string | number | boolean][]> = { [P in T[number][0]]: Extract< T[number], [P, any] >[1]; }; type SchemaObject = TupleToObject<SchemaTuple>; const schema: SchemaObject = tableSchema.reduce( (obj, [key, value]) => { obj[key] = value; return obj; }, {} as SchemaObject ); // Now you can use the schema object console.log(schema.id); // Output: number console.log(schema.name); // Output: string console.log(schema.email); // Output: string console.log(schema.isActive); // Output: boolean ``` <a name="ExclusiveTuple"></a> `ExclusiveTuple` ---------------- `ExclusiveTuple`類型是一個實用程序,它產生包含來自給定聯合類型`T`的唯一元素的元組。此類型確保聯合的每個元素僅在結果元組中包含一次,從而有效地將聯合類型轉換為具有聯合元素的所有可能的唯一排列的元組類型。這在您需要枚舉聯合成員的所有唯一組合的情況下特別有用。 ``` type ExclusiveTuple<T, U extends any[] = []> = T extends any ? Exclude<T, U[number]> extends infer V ? [V, ...ExclusiveTuple<Exclude<T, V>, [V, ...U]>] : [] : []; ``` **例子** 考慮這樣一個場景:您正在開發一個旅行應用程式的功能,該功能可以為遊覽某個城市的遊客產生獨特的行程。該市有三個主要景點:博物館、公園和劇院。 ``` type Attraction = 'Museum' | 'Park' | 'Theater'; type Itineraries = ExclusiveTuple<Attraction>; // The Itineraries type will be equivalent to: // type Itineraries = // ['Museum', 'Park', 'Theater'] | // ['Museum', 'Theater', 'Park'] | // ['Park', 'Museum', 'Theater'] | // ['Park', 'Theater', 'Museum'] | // ['Theater', 'Museum', 'Park'] | // ['Theater', 'Park', 'Museum']; ``` <a name="PromiseType"></a> `PromiseType` ------------- `PromiseType`類型是一個實用程序,用於提取給定 Promise 解析為的值的類型。這在使用非同步程式碼時非常有用,因為它允許開發人員輕鬆推斷結果的類型,而無需明確指定它。 ``` type PromiseType<T> = T extends Promise<infer U> ? U : never; ``` 此類型使用 TypeScript 的條件類型和`infer`關鍵字來決定`Promise`的解析類型。如果`T`擴展`Promise<U>` ,則表示`T`是解析為類型`U` `Promise` ,而`U`是推斷的類型。如果`T`不是`Promise` ,則型別解析為`never` 。 **例子** 以下範例示範如何使用 PromiseType 類型從 Promise 中提取已解析的類型。透過使用此實用程式類型,您可以推斷 Promise 將解析為的值的類型,這有助於在處理非同步操作時進行類型檢查並避免錯誤。 ``` type PromiseType<T> = T extends Promise<infer U> ? U : never; interface User { id: number; name: string; } interface Post { id: number; title: string; content: string; userId: number; } async function fetchUser(userId: number): Promise<User> { return { id: userId, name: "Anton Zamay" }; } async function fetchPostsByUser(userId: number): Promise<Post[]> { return [ { id: 1, title: "Using the Singleton Pattern in React", content: "Content 1", userId }, { id: 2, title: "Hoisting of Variables, Functions, Classes, Types, " + "Interfaces in JavaScript/TypeScript", content: "Content 2", userId }, ]; } async function getUserWithPosts( userId: number ): Promise<{ user: User; posts: Post[] }> { const user = await fetchUser(userId); const posts = await fetchPostsByUser(userId); return { user, posts }; } // Using PromiseType to infer the resolved types type UserType = PromiseType<ReturnType<typeof fetchUser>>; type PostsType = PromiseType<ReturnType<typeof fetchPostsByUser>>; type UserWithPostsType = PromiseType<ReturnType<typeof getUserWithPosts>>; async function exampleUsage() { const userWithPosts: UserWithPostsType = await getUserWithPosts(1); // The following will be type-checked to ensure correctness const userName: UserType["name"] = userWithPosts.user.name; const firstPostTitle: PostsType[0]["title"] = userWithPosts.posts[0].title; console.log(userName); // Anton Zamay console.log(firstPostTitle); // Using the Singleton Pattern in React } exampleUsage(); ``` **為什麼我們需要`UserType`而不僅僅是使用`User` ?** 這是個好問題!使用`UserType`而不是直接使用`User`主要原因是為了確保從非同步函數的回傳類型準確推斷出類型。這種方法有幾個優點: 1. **類型一致性:**透過使用`UserType` ,您可以確保類型始終與`fetchUser`函數的實際回傳類型一致。如果`fetchUser`的回傳類型發生更改, `UserType`將自動反映該更改,而無需手動更新。 2. **自動類型推斷**:在處理複雜類型和巢狀承諾時,手動確定和追蹤解析的類型可能具有挑戰性。使用 PromiseType 允許 TypeScript 為您推斷這些類型,從而降低錯誤風險。 <a name="OmitMethods"></a> `OmitMethods` ------------- `OmitMethods`型別是個實用程序,可從給定型別`T`中刪除所有方法屬性。這意味著作為函數的類型`T`的任何屬性都將被省略,從而產生僅包含非函數屬性的新類型。 ``` type OmitMethods<T> = Pick<T, { [K in keyof T]: T[K] extends Function ? never : K }[keyof T]>; ``` **例子** 此類型在您想要從物件類型中排除方法的情況下特別有用,例如將物件序列化為 JSON 或透過 API 發送物件時,其中方法不相關且不應包含在內。以下範例示範如何將`OmitMethods`套用至物件類型以刪除所有方法,確保產生的類型僅包含非函數的屬性。 ``` interface User { id: number; name: string; age: number; greet(): void; updateAge(newAge: number): void; } const user: OmitMethods<User> = { id: 1, name: "Alice", age: 30, // greet and updateAge methods are omitted from this type }; function sendUserData(userData: OmitMethods<User>) { // API call to send user data console.log("Sending user data:", JSON.stringify(userData)); } sendUserData(user); ``` <a name="FunctionArguments"></a> `FunctionArguments` ------------------- `FunctionArguments`類型是一個實用程序,用於提取給定函數類型`T`的參數類型。這意味著對於傳遞給它的任何函數類型,該類型將傳回一個表示函數參數類型的元組。此類型在需要捕獲或操作函數的參數類型的情況下特別有用,例如在高階函數中或建立類型安全的事件處理程序時。 ``` type FunctionArguments<T> = T extends (...args: infer A) => any ? A : never; ``` **例子** 假設您有一個高階函數包裝,它接受一個函數及其參數,然後使用這些參數來呼叫該函數。使用 FunctionArguments,您可以確保包裝函數參數的類型安全。 ``` function wrap<T extends (...args: any[]) => any>(fn: T, ...args: FunctionArguments<T>): ReturnType<T> { return fn(...args); } function add(a: number, b: number): number { return a + b; } type AddArgs = FunctionArguments<typeof add>; // AddArgs will be of type [number, number] const result = wrap(add, 5, 10); // result is 15, and types are checked ``` <a name="Promisify"></a> `Promisify` ----------- `Promisify`類型是一個實用程序,它將給定類型`T`的所有屬性轉換為各自類型的 Promise。這意味著結果類型中的每個屬性都將是該屬性的原始類型的`Promise` 。這種類型在處理非同步操作時特別有用,您希望確保整個結構符合基於`Promise`的方法,從而更輕鬆地處理和管理非同步資料。 ``` type Promisify<T> = { [P in keyof T]: Promise<T[P]> }; ``` **例子** 考慮一個顯示使用者個人資料、最近活動和設定的儀表板。這些資訊可能是從不同的服務獲取的。透過承諾單獨的屬性,我們確保使用者資料的每個部分都可以獨立取得、解析和處理,從而在處理非同步操作時提供靈活性和效率。 ``` interface Profile { name: string; age: number; email: string; } interface Activity { lastLogin: Date; recentActions: string[]; } interface Settings { theme: string; notifications: boolean; } interface UserData { profile: Profile; activity: Activity; settings: Settings; } // Promisify Utility Type type Promisify<T> = { [P in keyof T]: Promise<T[P]>; }; // Simulated Fetch Functions const fetchProfile = (): Promise<Profile> => Promise.resolve({ name: "Anton Zamay", age: 26, email: "[email protected]" }); const fetchActivity = (): Promise<Activity> => Promise.resolve({ lastLogin: new Date(), recentActions: ["logged in", "viewed dashboard"], }); const fetchSettings = (): Promise<Settings> => Promise.resolve({ theme: "dark", notifications: true }); // Fetching User Data const fetchUserData = async (): Promise<Promisify<UserData>> => { return { profile: fetchProfile(), activity: fetchActivity(), settings: fetchSettings(), }; }; // Using Promisified User Data const displayUserData = async () => { const user = await fetchUserData(); // Handling promises for each property (might be in different places) const profile = await user.profile; const activity = await user.activity; const settings = await user.settings; console.log(`Name: ${profile.name}`); console.log(`Last Login: ${activity.lastLogin}`); console.log(`Theme: ${settings.theme}`); }; displayUserData(); ``` <a name="ConstrainedFunction"></a> `ConstrainedFunction` --------------------- `ConstrainedFunction`類型是一個實用程序,它約束給定的函數類型 T 以確保保留其參數和傳回類型。它本質上捕獲函數的參數類型和返回類型,並強制結果函數類型必須遵守這些推斷類型。當您需要對高階函數實施嚴格的類型約束或建立必須符合原始函數簽署的包裝函數時,此類型非常有用。 ``` type ConstrainedFunction<T extends (...args: any) => any> = T extends (...args: infer A) => infer R ? (args: A extends any[] ? A : never) => R : never; ``` **例子** 在事先未知函數簽署且必須動態推斷的情況下, `ConstrainedFunction`可確保根據推斷的類型正確應用約束。想像一個實用程序,它包裝任何函數以記憶其結果: ``` function memoize<T extends (...args: any) => any>(fn: T): ConstrainedFunction<T> { const cache = new Map<string, ReturnType<T>>(); return ((...args: Parameters<T>) => { const key = JSON.stringify(args); if (!cache.has(key)) { cache.set(key, fn(...args)); } return cache.get(key)!; }) as ConstrainedFunction<T>; } const greet: Greet = (name, age) => { return `Hello, my name is ${name} and I am ${age} years old.`; }; const memoizedGreet = memoize(greet); const message1 = memoizedGreet("Anton Zamay", 26); // Calculates and caches const message2 = memoizedGreet("Anton Zamay", 26); // Retrieves from cache ``` 在這裡, `memoize`使用`ConstrainedFunction`來確保記憶函數保持與原始函數`fn`相同的簽名,而不需要明確定義函數類型。 <a name="UnionResolver"></a> `UnionResolver` --------------- `UnionResolver`類型是將聯合型別轉換為可區分聯合的實用程式。具體來說,對於給定的聯合類型`T` ,它會產生一個物件陣列,其中每個物件都包含一個屬性類型,該屬性類型保存聯合中的類型之一。在需要明確處理聯合的每個成員的情況下使用聯合類型時,此類型特別有用,例如在類型安全的 Redux 操作或 TypeScript 中的可區分聯合模式中。 ``` type UnionResolver<T> = T extends infer U ? { type: U }[] : never; ``` **例子** 以下範例示範如何應用`UnionResolver`類型將聯合類型轉換為物件陣列,每個物件都具有`type`屬性。這允許對聯合內的每個操作進行類型安全處理,確保考慮到所有情況並降低使用聯合類型時發生錯誤的風險。 ``` type ActionType = "ADD_TODO" | "REMOVE_TODO" | "UPDATE_TODO"; type ResolvedActions = UnionResolver<ActionType>; // The resulting type will be: // { // type: "ADD_TODO"; // }[] | { // type: "REMOVE_TODO"; // }[] | { // type: "UPDATE_TODO"; // }[] const actions: ResolvedActions = [ { type: "ADD_TODO" }, { type: "REMOVE_TODO" }, { type: "UPDATE_TODO" }, ]; // Now you can handle each action type distinctly actions.forEach(action => { switch (action.type) { case "ADD_TODO": console.log("Adding a todo"); break; case "REMOVE_TODO": console.log("Removing a todo"); break; case "UPDATE_TODO": console.log("Updating a todo"); break; } }); ``` --- 原文出處:https://dev.to/antonzo/11-20-sustom-utility-types-for-typescript-projects-2bg5

REST API 設計規則

為什麼編寫乾淨的 REST-API 設計很重要 ----------------------- 在當今互聯的世界中,精心設計的 REST API 是高效且可擴展的應用程式的支柱。 編寫乾淨的 REST API 設計至關重要,原因如下: - **增強的可用性:**精心設計的 API 直覺且易於使用,適合各種技能水平的開發人員使用。這簡化了整合並縮短了學習曲線。 - **提高可維護性:**乾淨的程式碼可以更輕鬆地辨識和修復錯誤、加入功能和擴展 API,從而提高可維護性。這確保了長期穩定性並降低了開發成本。 - **提高安全性:**結構良好的 API 具有適當的身份驗證和授權機制,有助於防止未經授權的存取、資料外洩和其他安全漏洞。 - **增強的效能:**簡潔的設計透過使用高效的資料結構、避免不必要的呼叫並最大限度地減少延遲來優化效能。這提供了無縫的用戶體驗並提高了整體應用程式效能。 - **縮短開發時間:**明確定義的 API 規格和清晰的文件可消除猜測並減少大量測試的需要,從而加快開發速度。這節省了寶貴的開發時間和資源。 - **改進的可擴展性:**簡潔的設計透過提供模組化架構來實現輕鬆的可擴展性,該架構可以輕鬆擴展以處理增加的流量或新功能。這確保了 API 可以隨著應用程式的需求而成長。 - **提高可重複使用性:**設計良好的 API 可以在多個應用程式中重複使用,從而減少重複並提高一致性。這簡化了開發並節省了時間和精力。 - **改進的文件:**簡潔的設計更容易記錄,讓開發人員清楚 API 的工作原理以及如何有效地使用它。這可以減少混亂並提高採用率。 URI規則 ----- **一個url的結構如下** **`scheme :// authority / path [?query][#fragment]`** 例如 `https://soccer.api.org/teams/dortmund/players?name=Rona#2` 有兩種類型的資源 1. 集合資源:包含資源的集合。它可以比喻為資料庫關係 2. 單例資源:包含單一資源。它可以比喻為資料庫記錄。 --- 設計 Rest-Api 時 1 集合資源應該是複數 ``` + soccer.api.org/teams/dortmond - soccer.api.org/team/dortmond ``` 2 Singleton資源應該是單一的,可以用api後面資料庫系統中代表資源的唯一id來代替 ``` +soccer.api.org/teams/dortmond/players/58c1aaae-205a-11ef-aeea-a64c74618950 ``` 3 URI 中沒有**尾隨正斜杠** ``` +soccer.api.org/teams/dortmond/players -soccer.api.org/teams/dortmond/players/ ``` 4 使用**連字號**取代**底線**以提高 API 的可讀性 ``` + api.blog.com/blogs/this-is-my-blog - api.blog.com/blogs/this_is_my_blog ``` 5 URI 路徑**中小寫字母**優先於**大寫字母** ``` + api.example.com/my-api/my-resource - api.example.com/My-Api/My-Resource ``` 6 URI 中沒有**檔案副檔名** ``` + api.example.com/api/resource - api.example.com/api/resource.json ``` 7 CRUD 函數名稱**不應**在 URI 中使用 ``` + DELETE api.example.com/api/resource - GET api.example.com/api.resource/delete ``` 8 URI 的查詢元件只能在集合資源中使用 ``` + GET /users?role=admin ``` 9 URI 的查詢元件應用於對集合結果分頁 ``` + GET /users?pageSize=25&pageStartIndex=50 ``` HTTP 方法規則 --------- | HTTP 方法 |用途 | | ----------- | -------------------------------------------------- -------------------------------------------------- ------------- | |POST |建立新資源。類似於建立 | |GET |獲取資源的表示。類似閱讀 | |PUT|透過替換**整個**資源來更新資源 | |DELETE |刪除資源 | |PATCH|透過更改所需資源的一部分來更新資源,而不取代整個資源。 | |HEAD|僅獲取響應頭而不是響應體 | |OPTION |獲取特定資源的所有可用選項 | > PUT 可用於建立和更新資源。但是,根據最佳實踐,通常建議使用 POST 來建立新資源,並使用 PUT 來完全取代現有資源。 --- 版本控制 ---- 對 api 進行版本控制對於以下方面可能很重要: **保持向後相容性:**版本控制可讓您引入新功能,而不會破壞依賴舊 API 版本的現有整合。使用者可以繼續使用熟悉的端點,而尋求新功能的使用者可以採用版本化的 API。 **確保一致且設計良好的 API:**跨版本的一致命名約定有助於提供使用者友善的體驗。更改端點會破壞這種體驗,而版本控制有助於避免這種情況。 --- 結論 == 現在您已經掌握了這些 REST API 設計規則,是時候將它們付諸實現了!在下面的評論中分享您的 API 創作,讓我們一起建立一個設計良好且對開發人員友好的 API 世界。 --- 原文出處:https://dev.to/ezekiel_77/rest-api-design-rules-2c4j

如何建立基本的 RAG 應用程式

生成式人工智慧的出現使我們建構的應用程式具有新的功能成為可能。法學碩士可以以令人難以置信的技巧回答使用者的問題。那麼,為什麼不將它們用作我們系統的一部分呢?如果用戶需要協助使用該應用程式,我們可以加入聊天功能,法學碩士將回答用戶的所有問題。如果我們的應用程式有解釋重要概念的部落格文章,而不是讓用戶閱讀所有內容來獲取所需的知識,它可以只詢問並立即得到回應。 為什麼是拉格? ------- 我們決定將法學碩士整合到我們的應用程式中,為我們的用戶帶來這些功能。然而,我們很快就發現該模型無法回答使用者的問題。它沒有任何關於我們的應用程式的資訊!如果需要回答的資訊不在LLM的訓練資料中,則無法回答。更糟的是,如果它不知道答案,它可能會產生一個完全錯誤的事實的幻覺!這很糟糕,那麼我們該如何解決這個問題呢?採用 Transformer 架構的法學碩士已展現出優異的情境學習能力。因此,我們只需在提示中傳遞它所需的所有事實以及問題即可!呃哦,每次提示都塞滿所有資料肯定會很貴。那麼,我們該怎麼做呢? 什麼是RAG? ------- RAG 代表**檢索增強產生**。 RAG與變形金剛一起誕生。最初,它被用來用額外的事實來增強法學碩士的預訓練資料。一旦 Transformers 的情境學習能力變得明顯,在推理過程中增強提示也成為一種常見做法。 基本的 RAG 管道由三個步驟組成:索引、檢索和產生。法學碩士需要回答的所有資訊都在向量資料庫中建立了索引。當使用者提出問題時,我們可以從該向量資料庫中檢索資訊的相關部分。最後,結合相關資訊和使用者的問題,我們可以提示法學碩士根據我們作為上下文提供的資訊給出答案。讓我們更詳細地看看如何實現這一目標。 ### 索引 首先,我們從任何地方提取模型所需的資訊。生成模型使用純文字(某些模型也可以使用圖像或其他格式,這些格式也可以被索引,但這是另一個主題)。如果訊息已經是純文字形式,那麼我們很幸運。但它也可能存在於 PDF 文件、Word 文件、Excel、Markdown 等。 ![索引過程](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9rbz60uizoiswi8lng0k.png) 一旦資訊採用文字格式,我們就可以將其儲存在向量資料庫中。向量資料庫將儲存該文字的嵌入表示。這將使我們能夠搜尋與另一個文本具有相似嵌入表示的文本部分,因此它們涉及相似的概念。我們將整個文字分成更小的部分或區塊,計算每個部分的嵌入表示,最後將它們儲存在向量資料庫中。 ### 恢復 當使用者問我們一個問題時,我們可以使用我們用於索引資料的相同嵌入模型將該問題轉換為向量表示。利用該向量表示,我們將計算問題與向量資料庫中儲存的每個區塊之間的相似度因子。我們將選擇與查詢最相似的前 K 個區塊,因此它們的內容與問題的概念相同(因此它們可能包含答案)。 ![檢索流程](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/isms443c1ytjcazo5t17.png) ### 世代 系統會建立一個提示,將使用者的問題和相關上下文放在一起,以幫助 LLM 回答。我們也可能包含用戶和人工智慧助理之間對話的先前訊息。 LLM 根據上下文而不是之前學習的預訓練資料為使用者產生答案。 ![檢索流程](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x9ih4417ubpht7kyskav.png) 例子 -- 對於這個例子,我們將收錄一篇名為「蘭格語言模型的檢索增強生成:調查」的論文。我們將使用本文中包含的資訊查詢LLM,以便它可以回答使用者對其內容的疑問。您可以在[本文提供的 Google Colab 筆記本](https://colab.research.google.com/drive/1mFmPN0GBHpS-kMDMuU8EDrWu1KENy69e?usp=sharing)中遵循此範例。 首先,我們將載入 PDF 文件並使用 LangChain 的 PyPDF 連接器對其進行解析。 ![使用 pypdf 載入文件](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mggsh8vxc1i6aknze50x.png) 一旦我們從文件中獲得文本,我們就必須將其分割成更小的區塊。我們可以使用 LangChain 的可用分割器,例如本例中的 RecursiveCharacterSplitter: ![將文件分割成區塊](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/92h7gf78bv699oup9xfc.png) 我們將使用 BGE-small,一種開源嵌入模型。我們將從 HuggingFace Hub 下載它並在所有區塊上執行它以計算它們的向量表示。 ![計算嵌入](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g9qoe5p4b0t37gooh4ix.png) 一旦我們有了所有區塊的向量表示,我們就可以建立一個記憶體向量資料庫並將所有向量儲存在其中。對於此範例,我們將使用 FAISS 資料庫。 ![將嵌入載入到向量資料庫中](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kvw8o3f9hwtafr3olord.png) 資料庫現已建立。現在,我們將接受用戶對此資訊的查詢。在這種情況下,用戶詢問 Naive RAG 的缺點是什麼。我們使用與先前相同的嵌入模型對該查詢進行編碼。然後,我們檢索與該查詢最相似的前 5 個區塊。 ![從向量資料庫中檢索與查詢類似的文件](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n3euuftp1j1edlvj8oau.png) 檢索相關上下文後,我們使用此資訊和使用者的原始查詢來建立提示。在這個例子中,我們將使用克勞德的俳句作為法學碩士: ![使用上下文和查詢來產生答案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wdl7s7gownp37psg9084.png) 常見問題和陷阱 ------- 正如標題所暗示的,該解決方案是一個基本的或簡單的 RAG 實作。它將幫助您的申請充分利用其所使用的法學碩士和您的資料。但它並不適用於所有情況。這些只是 RAG 最常見的問題: - **檢索不相關的資訊。**如果檢索器從向量資料庫中獲取與問題無關的資料,它將混淆試圖回答問題的模型。這可能會導致不使用上下文來回答問題,或回答與所問內容不同的問題。 - **錯過重要資訊。**也許回答問題所需的資訊不在資料庫中。也許檢索機制無法找到相關的區塊。我們必須找到方法來幫助檢索器輕鬆、更可靠地找到所需的資訊。 - **產生上下文不支援的回應。**如果上下文有模型需要的訊息,但它不使用它而是依賴自己的預訓練資料,那麼這一切都是徒勞的。預訓練資料中的資訊可能已過時或錯誤。我們必須支持模型始終使用上下文來回答,或者如果它無法從上下文中回答,則回答「我不知道」。 - **對查詢的回應不相關。** LLM 可能會使用您提供的所有資訊來產生回應,但這並不意味著它回答了使用者的問題。重要的是,模型必須堅持使用者的原始問題,而不是迷失在大量資訊中。 - **相似上下文導致的冗餘響應。**當我們攝取具有相似資訊的多個文件時,檢索器有可能會獲得多個幾乎相同的資訊區塊。這可能會導致法學碩士在其回復中多次重複相同的訊息。 如何避免這些問題呢? ---------- 為了避免這些問題,簡單的 RAG 管道可能還不夠。我們需要建立一個更先進、更複雜的RAG系統。存在經過測試的技術來解決我們提出的問題。我們可以將它們合併到 RAG 管道中,以提高 RAG 應用程式的效能。 另一個需要解決的重要問題是,為了改進您的 RAG 應用程式,您需要能夠測量和評估整個過程。你無法改進你無法衡量的東西。另外,當您進行評估時,您可能會發現基本的 RAG 設定足以滿足您的用例,並且不需要使其過於複雜。畢竟,即使是非常基本的 RAG 實施也可以極大地改進您的 LLM 支援的應用程式。 在以後的文章中,我將更詳細地解釋先進的 RAG 技術,這將幫助我們避免常見問題並將我們的 RAG 應用程式提升到新的水平。 --- 原文出處:https://dev.to/rogiia/how-to-build-a-basic-rag-app-h9p

編寫 SOLID React Hooks

SOLID 是較常用的設計模式之一。它在許多語言和框架中都很常用,也有一些文章介紹如何在 React 中使用它。 每篇關於 SOLID 的 React 文章都以稍微不同的方式介紹該模型,有些將其應用於元件,有些將其應用於 TypeScript,但很少有人將這些原理應用於鉤子。 由於 hooks 是 React 基礎的一部分,我們將在這裡看看 SOLID 原則如何應用於這些。 單一職責原則(SRP) ----------- Solid 中的第一個字母 S 是最容易理解的。本質上,它的意思是,讓一個鉤子/元件做一件事。 ``` // Single Responsibility Principle ``` ``` A module should be responsible to one, and only one, actor ``` 例如,看看下面的 useUser 鉤子,它會取得使用者和待辦事項,並將任務合併到使用者物件中。 ``` import { useState } from 'react' import { getUser, getTodoTasks } from 'somewhere' const useUser = () => { const [user, setUser] = useState() const [todoTasks, setTodoTasks] = useState() useEffect(() => { const userInfo = getUser() setUser(userInfo) }, []) useEffect(() => { const tasks = getTodoTasks() setTodoTasks(tasks) }, []) return { ...user, todoTasks } } ``` 這個鉤子並不牢固,它不遵守單一責任原則。這是因為它有責任獲取用戶資料和待辦任務,這是兩件事。 相反,上面的程式碼應該分為兩個不同的鉤子,一個用於獲取有關用戶的資料,另一個用於獲取任務。 ``` import { useState } from 'react' import { getUser, getTodoTasks } from 'somewhere' // useUser hook is no longer responsible for the todo tasks. const useUser = () => { const [user, setUser] = useState() useEffect(() => { const userInfo = getUser() setUser(userInfo) }, []) return { user } } // Todo tasks do now have their own hook. // The hook should actually be in its own file as well. Only one hook per file! const useTodoTasks = () => { const [todoTasks, setTodoTasks] = useState() useEffect(() => { const tasks = getTodoTasks() setTodoTasks(tasks) }, []) return { todoTasks } } ``` 這個原則適用於所有的鉤子和元件,它們都應該只做一件事。要問自己的事情是: 1. 這是一個應該顯示 UI(演示性)或處理資料(邏輯性)的元件嗎? 1. 這個鉤子應該處理什麼單一類型的資料? 1. 這個鉤子/元件屬於哪一層?它是處理資料儲存還是 UI 的一部分? 如果您發現自己建造的鉤子對上述每個問題都沒有單一答案,那麼您就違反了單一責任原則。 這裡值得注意的一件有趣的事情是第一個問題。這實際上意味著渲染 UI 的元件不應該處理資料。這意味著,要真正嚴格遵循這項原則,每個顯示資料的 React 元件都應該有一個鉤子來處理其邏輯和資料。換句話說,不應在顯示資料的相同元件中取得資料。 ### 為什麼在 React 中使用 SRP? 這種單一責任原則其實非常適合 React。 React 遵循基於元件的架構,這意味著它由組合在一起的小元件組成,因此它們一起可以建構並形成一個應用程式。元件越小,可重複使用的可能性就越大。這適用於元件和鉤子。 因此,React 或多或少是建立在單一職責原則上的。如果你不遵循它,你會發現自己總是在編寫新的鉤子和元件,並且很少重複使用它們中的任何一個。 違反單一責任原則將使您的程式碼難以測試。如果不遵循這個原則,您經常會發現您的測試文件有數百行,甚至可能多達 1000 行程式碼。 {% 嵌入 https://dev.to/perssondennis/how-to-use-mvvm-in-react-using-hooks-and-typescript-3o4m %} 開閉原理 (OCP) ---------- 讓我們繼續遵循開閉原則,畢竟這是 SOLID 中的下一個字母。 OCP 和 SRP 一樣是較容易理解的原則之一,至少其定義是如此。 ``` // Open/Closed Principle ``` ``` Software entities (classes, modules, functions, etc.) should ``` ``` be open for extension, but closed for modification ``` 對於最近開始使用 React 的傻瓜來說,這句話可以翻譯為: ``` Write hooks/component which you never will have a reason to ``` ``` touch again, only re-use them in other hooks/components ``` 回想一下本文前面所說的單一責任原則;在 React 中,您需要編寫小元件並將它們組合在一起。讓我們看看為什麼這有幫助。 ``` import { useState } from 'react' import { getUser, updateUser } from 'somewhere' const useUser = ({ userType }) => { const [user, setUser] = useState() useEffect(() => { const userInfo = getUser() setUser(userInfo) }, []) const updateEmail = (newEmail) => { if (user && userType === 'admin') { updateUser({ ...user, email: newEmail }) } else { console.error('Cannot update email') } } return { user, updateEmail } } ``` 上面的鉤子獲取用戶並返回它。如果使用者的類型是管理員,則允許該使用者更新其電子郵件。普通使用者不允許更新其電子郵件。 上面的程式碼絕對不會讓你被解僱。但這會惹惱你團隊中的後端人員,他會為他的孩子閱讀設計模式書籍作為睡前故事。我們就叫他皮特吧。 皮特會抱怨什麼?他會要求你重寫該元件,如下所示。將管理功能提升到它自己的 useAdmin 掛鉤,並讓 useUser 掛鉤除了那些應該可供普通用戶使用的功能之外沒有其他功能。 ``` import { useState } from 'react' import { getUser, updateUser } from 'somewhere' // useUser does now only return the user, // without any function to update its email. const useUser = () => { const [user, setUser] = useState() useEffect(() => { const userInfo = getUser() setUser(userInfo) }, []) return { user } } // A new hook, useAdmin, extends useUser hook, // with the additional feature to update its email. const useAdmin = () => { const { user } = useUser() const updateEmail = (newEmail) => { if (user) { updateUser({ ...user, email: newEmail }) } else { console.error('Cannot update email') } } return { user, updateEmail } } ``` 皮特為什麼要求更新?因為那個無禮挑剔的混蛋皮特寧願希望你現在花時間重寫那個鉤子,然後明天回來進行新的程式碼審查,而不是將來可能需要用一個微小的新 if 語句更新程式碼,如果有的話成為另一種類型的使用者。 好吧,這是消極的說法...樂觀的說法是,使用這個新的useAdmin 掛鉤,當您打算實現僅影響管理員用戶的功能時,或者當您打算實現僅影響管理員用戶的功能時,您不必更改useUser 掛鉤中的任何內容。 當新增新的使用者類型或更新 useAdmin 掛鉤時,無需弄亂 useUser 掛鉤或更新其任何測試。這意味著,當您新增的使用者類型(例如假使用者)時,您不必意外地將錯誤傳送給普通使用者。相反,您只需加入一個新的 userFakeUser 鉤子,您的老闆就不會在周五晚上 9 點給您打電話,因為客戶在發薪週末會遇到銀行帳戶顯示虛假資料的問題。 ![床下的前端開發人員](https://www.perssondennis.com/images/articles/write-solid-react-hooks/frontend-developer-under-the-bed.webp) *皮特的兒子知道要小心義大利麵式程式碼開發人員* ### 為什麼在 React 中使用 OCP? 一個 React 專案應該有多少個 hooks 和元件是有爭議的。每一個都需要渲染效果圖的代價。 React 不是 Java,其中 22 種設計模式導致 422 個類別用於簡單的 TODO 清單實作。這就是狂野西部網絡 (www) 的魅力所在。 然而,開放/封閉原則顯然也是在 React 中使用的少數模式。上面的鉤子範例是最小的,鉤子沒有做太多事情。隨著更多實質的掛鉤和更大的專案,這項原則變得非常重要。 這可能會花費您一些額外的鉤子,並且需要稍長的時間來實現,但是您的鉤子將變得更加可擴展,這意味著您可以更頻繁地重複使用它們。您將不必經常重寫測試,從而使掛鉤更加牢固。最重要的是,如果您從不接觸舊程式碼,則不會在舊程式碼中產生錯誤。 ![沒有破損的東西不要碰](https://www.perssondennis.com/images/articles/write-solid-react-hooks/dont-touch-what-is-not-broken.webp) *天知道不要碰沒有破損的東西* {% 嵌入 https://dev.to/perssondennis/react-anti-patterns-and-best-practices-dos-and-donts-3c2g %} 里氏替換原理 (LSP) ------------ 啊啊,這個名字……誰是利斯科夫?而誰來代替她呢?而這個定義,難道就沒有意義嗎? ``` If S subtypes T, what holds for T holds for S ``` 這個原則顯然是關於繼承的,在 React 或 JavaScript 中,繼承的實踐並不像大多數後端語言中那麼多。 JavaScript 在 ES6 之前甚至沒有類,ES6 是[在 2015/2016 年左右引入的,](https://caniuse.com/?search=class)作為基於原型的繼承的語法糖。 考慮到這一點,該原則的用例實際上取決於您的程式碼的外觀。類似 Liskov 的原則在 React 中有意義,可能是: ``` If a hook/component accepts some props, all hooks and components ``` ``` which extends that hook/component must accept all the props the ``` ``` hook/component it extends accepts. The same goes for return values. ``` 為了說明這一點,我們可以看一下兩個儲存鉤子:useLocalStorage 和 useLocalAndRemoteStorage。 ``` import { useState } from 'react' import { getFromLocalStorage, saveToLocalStorage, getFromRemoteStorage } from 'somewhere' // useLocalStorage gets data from local storage. // When new data is stored, it calls saveToStorage callback. const useLocalStorage = ({ onDataSaved }) => { const [data, setData] = useState() useEffect(() => { const storageData = getFromLocalStorage() setData(storageData) }, []) const saveToStorage = (newData) => { saveToLocalStorage(newData) onDataSaved(newData) } return { data, saveToStorage } } // useLocalAndRemoteStorage gets data from local and remote storage. // I doesn't have callback to trigger when data is stored. const useLocalAndRemoteStorage = () => { const [localData, setLocalData] = useState() const [remoteData, setRemoteData] = useState() useEffect(() => { const storageData = getFromLocalStorage() setLocalData(storageData) }, []) useEffect(() => { const storageData = getFromRemoteStorage() setRemoteData(storageData) }, []) const saveToStorage = (newData) => { saveToLocalStorage(newData) } return { localData, remoteData, saveToStorage } } ``` 透過上面的鉤子,useLocalAndRemoteStorage 可以被視為 useLocalStorage 的子類型,因為它與 useLocalStorage 執行相同的操作(保存到本地存儲),而且還通過將資料保存到其他位置來擴展 useLocalStorage 的功能。 這兩個鉤子有一些共享的屬性和回傳值,但是 useLocalAndRemoteStorage 缺少 useLocalStorage 接受的 onDataSaved 回呼屬性。傳回屬性的名稱也有不同的命名,本地資料在useLocalStorage中命名為data,而在useLocalAndRemoteStorage中命名為localData。 如果你問利斯科夫,這就違背了她的原則。實際上,當她嘗試更新Web 應用程式以在伺服器端保留資料時,她會非常憤怒,只是意識到她不能簡單地用useLocalAndRemoteStorage 鉤子替換useLocalStorage,只是因為一些懶惰的開發人員從未為useLocalAndRemoteStorage 鉤子實現onDataSaved回調。 利斯科夫會痛苦地更新鉤子來支持這一點。同時,她也會更新 useLocalStorage 掛鉤中的本地資料名稱,以符合 useLocalAndRemoteStorage 中的本地資料名稱。 ``` import { useState } from 'react' import { getFromLocalStorage, saveToLocalStorage, getFromRemoteStorage } from 'somewhere' // Liskov has renamed data state variable to localData // to match the interface (variable name) of useLocalAndRemoteStorage. const useLocalStorage = ({ onDataSaved }) => { const [localData, setLocalData] = useState() useEffect(() => { const storageData = getFromLocalStorage() setLocalData(storageData) }, []) const saveToStorage = (newData) => { saveToLocalStorage(newData) onDataSaved(newData) } // This hook does now return "localData" instead of "data". return { localData, saveToStorage } } // Liskov also added onDataSaved callback to this hook, // to match the props interface of useLocalStorage. const useLocalAndRemoteStorage = ({ onDataSaved }) => { const [localData, setLocalData] = useState() const [remoteData, setRemoteData] = useState() useEffect(() => { const storageData = getFromLocalStorage() setLocalData(storageData) }, []) useEffect(() => { const storageData = getFromRemoteStorage() setRemoteData(storageData) }, []) const saveToStorage = (newData) => { saveToLocalStorage(newData) onDataSaved(newData) } return { localData, remoteData, saveToStorage } } ``` 透過為鉤子提供通用介面(傳入的 props、傳出的返回值),它們可以變得非常容易交換。如果我們遵循里氏替換原則,繼承另一個鉤子/元件的鉤子和元件應該可以用它繼承的鉤子或元件替換。 ![擔心的利斯科夫](https://www.perssondennis.com/images/articles/write-solid-react-hooks/worried-liskov.webp) *當開發人員不遵循她的原則時,利斯科夫感到失望* ### 為什麼在 React 中使用 LSP? 儘管繼承在 React 中並不是很突出,但它肯定在幕後使用。 Web 應用程式通常可以有幾個外觀相似的元件。文字、標題、連結、圖示連結等都是類似類型的元件,可以從繼承中受益。 IconLink 元件可能會也可能不會包裝 Link 元件。無論哪種方式,它們都會受益於使用相同的介面(使用相同的 props)實作。這樣,您可以隨時在應用程式中的任何位置將 Link 元件替換為 IconLink 元件,而無需編輯任何其他程式碼。 鉤子也是如此。 Web 應用程式從伺服器取得資料。他們也可能使用本地儲存或狀態管理系統。這些最好可以共享道具以使它們可以互換。 應用程式可能會從後端伺服器取得使用者、任務、產品或任何其他資料。類似的函數也可以共享接口,從而更容易重複使用程式碼和測試。 {% 嵌入 https://dev.to/perssondennis/the-20-most-common-use-cases-for-javascript-arrays-2j8j %} 介面隔離原則(ISP) ----------- 另一個更明確的原則是介面隔離原則。定義很短。 ``` No code should be forced to depend on methods it does not use ``` 顧名思義,它與介面有關,基本上意味著函數和類別應該只實現它明確使用的介面。最容易實現這一點的方法是保持介面整潔,讓類別選擇其中的一些來實現,而不是被迫用它不關心的幾種方法來實現一個大介面。 例如,代表擁有網站的人的類別應該實現兩個接口,一個稱為 Person 的接口,描述有關此人的詳細訊息,另一個用於網站的接口,其中包含有關其擁有的網站的元資料。 ``` interface Person { firstname: string familyName: string age: number } interface Website { domain: string type: string } ``` 如果相反,建立一個單一介面網站,包括有關所有者和網站的訊息,則將違反介面隔離原則。 ``` interface Website { ownerFirstname: string ownerFamilyName: number domain: string type: string } ``` 你可能會想,上面的介面有什麼問題嗎?它的問題是它使介面不太可用。想想看,如果公司不是人,而是公司,你會怎麼做?公司其實沒有姓氏。然後您會修改介面以使其對人類和公司都可用嗎?或者您會建立一個新介面 CompanyOwnedWebsite 嗎? 然後,您最終會得到一個具有許多可選屬性的接口,或分別稱為 PersonWebsite 和 CompanyWebsite 的兩個接口。這些解決方案都不是最佳的。 ``` // Alternative 1 // This interface has the problem that it includes // optional attributes, even though the attributes // are mandatory for some consumers of the interface. interface Website { companyName?: string ownerFirstname?: string ownerFamilyName?: number domain: string type: string } // Alternative 2 // This is the original Website interface renamed for a person. // Which means, we had to update old code and tests and // potentially introduce some bugs. interface PersonWebsite { ownerFirstname: string ownerFamilyName: number domain: string type: string } // This is a new interface to work for a company. interface CompanyOwnedWebsite { companyName: string domain: string type: string } ``` ISP 遵循的解決方案如下所示。 ``` interface Person { firstname: string familyName: string age: number } interface Company { companyName: string } interface Website { domain: string type: string } ``` 透過上述適當的接口,代表公司網站的類別可以實現接口 Company 和 Website,但不需要考慮 Person 接口中的 firstname 和 familyName 屬性。 ### React 中使用 ISP 嗎? 所以,這個原則顯然適用於接口,這意味著它只應該在您使用 TypeScript 編寫 React 程式碼時才有意義,不是嗎? 當然不是!不輸入介面並不意味著它們不存在。到處都有,只是你沒有明確地輸入它們。 在 React 中,每個元件和鉤子都有兩個主要接口,輸入和輸出。 ``` // The input interface to a hook is its props. const useMyHook = ({ prop1, prop2 }) => { // ... // The output interface of a hook is its return values. return { value1, value2, callback1 } } ``` 使用 TypeScript,您通常會鍵入輸入接口,但輸出接口通常會被跳過,因為它是可選的。 ``` // Input interface. interface MyHookProps { prop1: string prop2: number } // Output interface. interface MyHookOutput { value1: string value2: number callback1: () => void } const useMyHook = ({ prop1, prop2 }: MyHookProps): MyHookOutput => { // ... return { value1, value2, callback1 } } ``` 如果鉤子不會將 prop2 用於任何用途,那麼它不應該成為其 props 的一部分。對於單一道具,可以輕鬆地將其從道具清單和介面中刪除。但是,如果 prop2 是物件類型,例如上一章不正確的 Website 介面範例,該怎麼辦? ``` interface Website { companyName?: string ownerFirstname?: string ownerFamilyName?: number domain: string type: string } interface MyHookProps { prop1: string website: Website } const useMyCompanyWebsite = ({ prop1, website }: MyHookProps) => { // This hook uses domain, type and companyName, // but not ownerFirstname or ownerFamilyName. return { value1, value2, callback1 } } ``` 現在我們有一個 useMyCompanyWebsite 鉤子,它有一個 website 屬性。如果鉤子中使用了網站介面的部分內容,我們不能簡單地刪除整個網站道具。我們必須保留 website 屬性,因此也保留ownerFirstname 和ownerFamiliyName 的介面屬性。這也意味著,該針對公司的掛鉤可以由人類擁有的網站所有者使用,即使該掛鉤可能不適用於該用途。 ### 為什麼在 React 中使用 ISP? 我們現在已經了解了 ISP 的含義,以及它如何應用於 React,即使不使用 TypeScript。透過查看上面的小例子,我們也看到了一些不遵循 ISP 的問題。 在更複雜的專案中,可讀性是最重要的。介面隔離原則的目的之一是避免混亂,避免不必要的程式碼的存在,這些程式碼只會破壞可讀性。不要忘記可測試性。您是否應該關心您實際未使用的道具的測試覆蓋率? 實現大型介面也迫使您將 props 設定為可選。導致更多的 if 語句來檢查函數的存在和潛在的誤用,因為在介面上顯示該函數將處理此類屬性。 {% 嵌入 https://dev.to/perssondennis/answers-to-common-nextjs-questions-1oki %} 依賴倒置原則(DIP) ----------- 最後一個原則,即 DIP,包括一些被廣泛誤解的術語。令人困惑的地方在於依賴反轉、依賴注入和控制反轉之間的差異。所以我們先聲明一下。 **依賴倒置** 依賴倒置原則(DIP)表示高階模組不應該從低階模組導入任何內容,兩者都應該依賴抽象。這意味著任何高階模組自然可能依賴它所使用的模組的實作細節,但不應該具有這種依賴性。 高級模組和低階模組的編寫方式應使它們都可以在不了解其他模組內部實現的任何細節的情況下使用。只要介面保持不變,每個模組都應該可以用它的替代實作來替換。 **控制反轉** 控制反轉(IoC)是用來解決依賴反轉問題的原理。它指出模組的依賴關係應由外部實體或框架提供。這樣,模組本身只需使用依賴項,而不必建立依賴項或以任何方式管理它。 **依賴注入** 依賴注入(DI)是實現 IoC 的常見方法。它透過建構函數或 setter 方法注入模組來提供對模組的依賴關係。這樣,模組就可以使用依賴項而無需負責建立它,這符合 IoC 原則。值得一提的是,依賴注入並不是實現控制反轉的唯一方法。 ### React 中使用 DIP 嗎? 澄清了這些術語,並知道 DIP 原則是關於依賴倒置的,我們可以再次看看這個定義是怎樣的。 ``` High-level modules should not import anything from low-level modules. ``` ``` Both should depend on abstractions ``` 這如何適用於 React? React 不是一個通常與依賴注入相關的函式庫,那我們該如何解決依賴倒置的問題呢? 這個問題最常見的解決方案是鉤子。鉤子不能算作依賴注入,因為它們被硬編碼到元件中,並且不可能在不更改元件實現的情況下用另一個鉤子替換鉤子。相同的鉤子將在那裡,使用相同的鉤子實例,直到開發人員更新程式碼。 但請記住,依賴注入並不是實現依賴倒置的唯一方法。 Hooks 可以被視為 React 元件的外部依賴,它有一個介面(它的 props),可以抽像出 hook 中的程式碼。這樣,鉤子就實現了依賴倒置的原則,因為元件依賴抽象接口,而不需要知道有關鉤子的任何細節。 React 中 DIP 的另一個更直觀的實作(實際上使用依賴注入)是 HOC 和上下文的使用。請參閱下面的 withAuth HOC。 ``` const withAuth = (Component) => { return (props) => { const { user } = useContext(AuthContext) if (!user) { return <LoginComponent> } return <Component {...props} user={user} /> } } const Profile = () => { // Profile component... } // Use the withAuth HOC to inject user to Profile component. const ProfileWithAuth = withAuth(Profile) ``` 上面顯示的 withAuth HOC 使用依賴項注入為使用者提供 Profile 元件。這個範例的有趣之處在於,它不僅顯示了依賴注入的一種用法,而且實際上包含了兩個依賴注入。 將使用者註入到設定檔元件並不是此範例中的唯一注入。 withAuth 鉤子實際上也透過 useContext 鉤子透過依賴注入來獲取使用者。在程式碼中的某個地方,有人聲明了一個將使用者註入上下文的提供者。該用戶實例甚至可以在執行時透過更新上下文中的用戶來更改。 ### 為什麼在 React 中使用 DIP? 儘管依賴注入不是與 React 相關的常見模式,但它實際上與 HOC 和上下文相關。鉤子從 HOC 和上下文中佔據了大量市場份額,也很好地證實了依賴倒置原則。 因此,DIP 已經內建到 React 庫本身中,當然應該使用。它既易於使用,又具有模組之間的鬆散耦合、鉤子和元件的可重複使用性和可測試性等優點。它也使得實現其他設計模式(例如單一職責原則)變得更加容易。 我不鼓勵的是,當確實有更簡單的解決方案可用時,請嘗試實施智慧解決方案並過度使用該模式。我在網路和書籍中看到了使用 React 上下文的建議,其唯一目的是實現依賴注入。像下面這樣的東西。 ``` const User = () => { const { role } = useContext(RoleContext) return <div>{`User has role ${role}`}</div> } const AdminUser = ({ children }) => { return ( <RoleContext.Provider value={{ role: 'admin' }}> {children} </RoleContext.Provider> ) } const NormalUser = ({ children }) => { return ( <RoleContext.Provider value={{ role: 'normal' }}> {children} </RoleContext.Provider> ) } ``` 儘管上面的範例確實將角色注入到 User 元件中,但為其使用上下文純粹是矯枉過正。當上下文本身有其用途時,應該在適當的時候使用 React 上下文。在這種情況下,一個簡單的道具可能是更好的解決方案。 ``` const User = ({ role }) => { return <div>{`User has role ${role}`}</div> } const AdminUser = () => <User role='admin' /> const NormalUser = () => <User role='normal' /> ``` {% cta https://2e015922.sibforms.com/serve/MUIFAGF3ypa0p6D6nTWI0MHVOIAC7q4TIJd0yXAhiBC9CswkNPnOlQBzeqSbR2XFM95gUn2G1IxWwCpDpDjkjk aaG9tz9UYhn\_O\_dWg1PPGS8kRM5ROREaJsslnGD8WEHszzZr0geJ9-g7lGsbn\_hTT-wZSKWa1C8ay4Ok85ozro %}訂閱我的文章{% endcta %} {% 嵌入 https://dev.to/perssondennis %} --- 原文出處:https://dev.to/perssondennis/write-solid-react-hooks-436o

Kubernetes 編譯失敗:然後正式機掛掉的情況!

我從來都不是一個大賭徒。過去我可能會下一個小賭注來為超級盃增添趣味,但我並沒有那麼投入,但這並不是什麼瘋狂的事情。真正投入資金需要一定程度的確定性,而我在任何體育賽事、選舉結果或未來預測中都很少有這種確定性。科技領域的確定性非常少。工作保障並不是既定的,產業趨勢潮起潮落,你每天使用的[工具](https://glasskube.dev/guides/kubectl/)和技術堆疊很可能會隨著時間的推移而不斷發展。儘管充滿了不確定性,但還是有一些東西你可以安全地押注,但在某些時候,**你會遭遇中斷。** ![賭場](https://media1.giphy.com/media/26tneF8wxg0H4NrC8/200.webp?cid=ecf05e4725b5vpix4vj3x0ajz06gb8rehvx96kjva729y9nu&ep=v1_gifs_search&rid=200.webp&ct=g) 從事任何時間的 Kubernetes 工程師都可以證明這個現實。在這種情況下,害怕失敗或執行艱鉅的任務來確保[100% 可用性](https://andrewmatveychuk.com/why-99-99-uptime-or-sla-is-bad/)是沒有意義的,如果有任何[錯誤](https://www.amazon.com/Black-Box-Thinking-People-Mistakes-But/dp/1591848229)和中斷應該被視為學習機會,這對於任何渴望成熟並提供高品質的環境來說都是必要的邪惡以可靠的方式提供服務。 有效處理和消化中斷的最佳方法是系統地進行[事後分析](https://www.atlassian.com/incident-management/postmortem/reports)。事實證明,這些是我們尋找模式並綜合中斷所提供的經驗教訓的最敏銳的工具。關於 Kubernetes 叢集故障中常見的模式主題,出現了一些模式。 ![reddit-1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xml8lmgs8g9e36624td5.png) DNS、網路和預設資源分配是一些關鍵的罪魁禍首。 ![reddit-2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4ijimseogd4nn43k5sni.png) 在這篇文章中,我們將分析其中的一些事後分析,並盡力吸收其他人經過艱苦的努力才學到的東西。 故障嚴重程度等級 -------- 並非每次中斷都會產生相同的影響,因此我建立了一個非常科學的分類系統來了解每次 Kubernetes 中斷的影響: **🤷 - 有點糟糕:**微不足道的 Kubernetes 故障 **😅 - 非正式機,但仍然令人煩惱:**我們沒有影響任何客戶,但我們學到了教訓 **🤬 - 休士頓,我們在生產中遇到了問題:**客戶受到影響,職業選擇受到質疑。 ![你被開除了](https://media1.giphy.com/media/xT4uQ7N8UNsoeFAjVS/200.webp?cid=790b76115lk6lg7hzua5e4qexoocj2f0sltdsw5l4ggfcsln&ep=v1_gifs_search&rid=200.webp&ct=g) --- 在我忘記之前,讓我感謝[Glasskube](https://github.com/glasskube/glasskube)讓我花時間建立這樣的內容。如果這是您第一次聽說我們,我們正在努力`Package Manager for Kubernetes` 。 如果您願意支持我們完成這項任務,我們將不勝感激 [⭐️ GitHub 上的 Star Glasskube 🙏](https://github.com/glasskube/glasskube) [![感謝您的支持](https://media1.giphy.com/media/v1.Y2lkPTc5MGI3NjExOHZxc3Nxbjdyem9kY24xd3k5M3EwY2Q1dmQ3OTA0aTh4c3cycmpkdyZlcD12MV9naWZzX3NlYXJjaCZjdD1n/l3q2wJsC23ikJg9xe/200.webp)](https://github.com/glasskube/glasskube) --- 有點糟糕🤷 ----- 如果你不能笑自己,你還能笑誰? ### 叢集和節點群組 第一個故事來自您謙虛的記者,他最近使用 AWS 控制台啟動了一個測試 Kubernetes 集群,以快速驗證概念。我已經有一段時間沒有使用 EKSCTL 或某種形式的基礎設施即程式碼定義檔來建立叢集了。 因此,我登入並存取 EKS 控制台,命名我的 Kubernetes 集群,然後點擊「建立」。然後,我按照 CLI 說明配置 kubeconfig 檔案並透過終端連接到我新建立的叢集。 由於渴望測試最新版本的 Glasskube,我將其安裝在叢集中。然而,令我驚訝的是 Pod 的安排時間如此之長。現在回想起來,我很尷尬地承認我花了多長時間才意識到我沒有配置節點組,難怪 Pod 沒有被調度。 ![不為所動](https://media4.giphy.com/media/v1.Y2lkPTc5MGI3NjExNm9mdzVweWc1cDljdjM3MWpmeTRqcm1sejltZXhzZmZlYzFtMmNtMSZlcD12MV9naWZzX3NlYXJjaCZjdD1n/c5FhF1waAJ5wk/giphy.webp) ### 打電話給消防隊,我忘了加入資源限制。 另一個真實的故事來自另一位Glasskube 成員,由於在本地Minikube 集群中安裝了許多元件(GitLab),他的本地筆記型電腦超載了,筆記型電腦幾乎在他的辦公桌上燒了一個洞,這是一個很好的提醒,要使用資源限制和請求 ![筆記型電腦起火](https://media0.giphy.com/media/dbtDDSvWErdf2/200.webp?cid=ecf05e4775sy7d66ores8c10w1hrw77311mm7m323lkkkqym&ep=v1_gifs_search&rid=200.webp&ct=g) 非正式機,但仍然很煩人😅 ----------- 轉向一些真實的事件,幸運的是這些事件僅限於不會影響付費客戶的叢集。 ### 事件#1:Venafi 的 Webhooks 無回應 [Venafi](https://venafi.com/)是機器身分的控制平面,最近被[Cyberark](https://www.cyberark.com/)收購,Cyberark 在 OPA 方面存在一些問題。完整的屍檢[在這裡](https://venafi.com/blog/gke-webhook-outage/)。 ![快點](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5mnqgz5998ynmk3rpipg.png) > **影響:**間歇性 API 伺服器逾時導致節點不健康。 > **涉及:**開放策略代理、節點準備 **逐場比賽** 在計劃的叢集升級期間,儘管有警告並且之前升級成功,但主升級失敗,導致 API 伺服器逾時和節點不穩定。**根本原因是 ConfigMap 更新期間逾時**,由無回應的[OPA](https://www.openpolicyagent.org/) Webhook 觸發。刪除 webhook 恢復了服務,此後他們將其限制在特定的命名空間,加入了 OPA 的活性探針,並更新了文件。 他們強調需要 API 回應時間警報、工作負載探測,並可能使用 Helm 圖表進行部署,以避免將來出現類似問題。他們繼續監控功能的改進並透過 Flightdeck 服務提供見解。 **學習內容:** - 需要對 API 伺服器回應時間發出警報。 - 增加所有工作負載所需的`livenessProbes` 。 - 使用套件管理進行更精細的配置。 > 💡 這事件凸顯了[Glasskube](https://github.com/glasskube/glasskube)旨在解決的用例之一。雖然 Glasskube 尚不支援 OPA 運算符,但我們相信透過強大的 Kubernetes 套件管理器可以避免這個問題。 Glasskube 可輕鬆配置關鍵功能,協助升級,並將 GitOps 方法應用於套件操作員管理,包括回溯和特定命名空間分配。[在這裡](https://github.com/glasskube/glasskube)嘗試一下。 ### 事件#2:當加密貨幣礦工潛入時 [JW Player](https://jwplayer.com/)成為比特幣挖礦惡意軟體的目標,請[在此處](https://medium.com/jw-player-engineering/how-a-cryptocurrency-miner-made-its-way-onto-our-internal-kubernetes-clusters-9b09c4704205)查看完整的事後分析。 ![JW-玩家](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/do39mgvqt5e01ndnk9aw.png) > **影響:**非生產集群被比特幣礦工滲透 > **涉及:** Root存取利用 **逐場比賽** 在 Datadog 向 JW Player 的 DevOps 團隊發出其臨時和開發環境中的平均負載較高的警報後,JW Player 的 DevOps 團隊在其 Kubernetes 叢集上發現了一個加密貨幣挖礦程式。**初步調查發現,有一個gcc進程佔用了100%的CPU,經檢查發現該進程是監控工具Weave Scope發起的礦機**。該礦工利用了面向公眾的 Weave Scope 負載平衡器,允許在容器中執行命令。 立即採取的行動包括停止 Weave Scope、隔離受影響的節點並將其輪換出去。該事件導致 CPU 使用率較高,但沒有服務中斷或資料外洩。該團隊將 Kubernetes 覆蓋的手動安全群組編輯確定為關鍵問題,並強調需要採取適當的配置實踐來防止此類漏洞。 **學習內容:** - 監控負載並不是檢測叢集問題的最佳方法。 - 可能需要`falcon`或`sysdig`等工具 - 需要更強大的 Docker 映像和容器掃描。 - 架構的某些區域需要重新檢視。 - 需要更多的跨團隊資料共享和溝通。 ### 事件 #3:GKE 耗盡 IP 位址 ![愛情假期](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2e5fh4u5u8hxwse1az0s.png) > **影響:**高節點數叢集耗盡了 IP 位址,無法調度新的 Pod。 > **涉及:**子網路、每個節點的預設 IP 分配 **逐場比賽** 當一名團隊成員報告其應用程式的部署時間異常長時,就發生了一起事件。他們很快就發現,雖然一些新部署的 Pod 正在提供流量,但其餘的 Pod 仍處於`pending`狀態。**分析顯示`FailedScheduling`警告顯示資源不足。**儘管部署了叢集自動縮放器,但問題仍然存在,因為他們看到了令人震驚的**「0/256 個節點可用」**訊息。進一步檢查發現,GKE為每個節點預先分配了110個IP,導致IP消耗意外高。了解這一點後,他們調整了每個節點的 Pod 分配,將整體 IP 使用量減少了 30%。此外,他們還探索了子網擴展和增加節點大小等選項以緩解 IP 耗盡,最終優化節點池實例大小以更好地利用資源。 **學習內容:** - 了解 GKE 設定的預設值的重要性。 - [子網路擴充功能](https://cloud.google.com/vpc/docs/create-modify-vpc-networks#expand-subnet)是一個可供您使用的實用工具(儘管關於次要範圍的文件不多)。 - 增加節點池執行個體大小也可以完成這項工作(每個節點執行更多 Pod,然後需要更少的節點)。 休士頓,我們的生產遇到問題了🤬 --------------- 這些類型的中斷**會讓 SRE 徹夜難眠**,當客戶受到影響並且業務價值岌岌可危時,這些都是最重要的經驗教訓和英雄的誕生地。 ### 事件 #1 Skyscanner 只需要幾個字元就可以關閉他們的網站 在這裡我們看到,針對彈性進行了最佳化的架構仍然容易因為一行程式碼而故障。完整的屍檢[在這裡](https://medium.com/@SkyscannerEng/how-a-couple-of-characters-brought-down-our-site-356ccaf1fbc3)。 ![天巡](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zma05ic4v2m88e05y797.png) > **影響:**全球 Skyscanner 網站和行動應用程式無法存取 > **涉及:** IaC清單 **逐場比賽** 2021 年 8 月,由於無意中更改了基礎設施配置系統中的根文件,Skyscanner 面臨持續四個多小時的全球中斷。**由於缺少`{{ }}` ,這項變更意外地觸發了全球範圍內關鍵微服務的刪除**,導致網站和行動應用程式無法存取。 ![致命線](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3ohytkjb4v3p1c0ekvno.png) 他們迅速解決了這個問題,利用 GitOps 恢復配置並確定關鍵服務的優先順序。 **學習內容:** - 不要進行全域配置部署。 - 需要更徹底的「最壞情況」規劃。 - 驗證備份/復原過程。 - 保持操作手冊最新。 - 超越自動化的潛力。 ### 事件#2 Monzo Bank 的 linkerd 慘敗 英國數位[銀行](https://monzo.com/)艱難地發現了 Kubernetes 的一個嚴重錯誤。完整的屍檢[在這裡](https://community.monzo.com/t/resolved-current-account-payments-may-fail-major-outage-27-10-2017/26296/95)。 ![蒙佐銀行](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8tjblle4py5mifmv1s1e.png) > **影響:**預付卡和新活期帳戶下降約1.5小時 > **涉及:** Linkerd、kube-apiserver、etcd **逐場比賽:** 此事件始於例行部署導致支付處理失敗。嘗試回滾變更未成功,導致內部中斷聲明。工程師發現並重新啟動了不健康的`linkerd`實例,但`kube-apiserver`的配置問題導致新的`linkerd`實例無法啟動,從而將中斷升級為整個平台故障。**根本原因可追溯到 Kubernetes 和 etcd 中的錯誤,該錯誤是由最近的叢集重新配置觸發的。**這導致`linkerd`無法接收網路更新,再加上 Kubernetes 和 linkerd 之間的相容性問題。該事件已透過更新 linkerd 並刪除空的 Kubernetes 服務得到解決。 **學習內容:** - 需要新版本的 Linkerd。 - k8s bug 需要修復(現已[修復](https://github.com/kubernetes/kubernetes/issues/47131))。 - 改進執行狀況檢查、儀表板和警報。 - 改進程序以改善停電期間的內部溝通。 ### 事件 #3 Redis 操作員丟了一個曲線球 Palark 是一家 DevOps 服務供應商,曾試圖保護其 Redis 集群,但最終卻後悔了。[這](https://blog.palark.com/failure-with-redis-operator-and-redis-data-analysis-tools/)是完整的移植剖析 ![帕拉克](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/09fk9z0exq8006orscwm.png) > **影響:**加入副本後的生產 Redis 資料 > **涉及:** Redis算子 **逐場比賽** 他們遇到了一個涉及眾所周知的記憶體鍵值儲存 Redis 的事件,他們透過[Redis Operator](https://github.com/spotahome/redis-operator)安裝該儲存來執行 Redis 故障轉移。最初部署了一個 Redis 副本,後來擴展到兩個副本以增強資料庫可靠性。**然而,這個看似微小的變化在部署過程中被證明是災難性的,導致資料遺失。**該事件揭露了 Redis Operator 中的缺陷,主要是其`readiness probe` ,引發了意外的主升級和隨後的資料破壞。使用`Redis-memory-analyzer`等工具進行進一步分析,揭示了對資料庫大小和元素的洞察,從而幫助開發人員優化資料庫和應用程式程式碼,以防止未來發生事件。 **學習內容:** - 使用 Kubernetes Operator 時要非常小心(確保它們成熟且經過充分測試)。 - 他們發現了與 Redis Operators 就緒性探測相關的關鍵錯誤,該錯誤使副本橫向擴展容易導致資料遺失(已[修復](https://github.com/spotahome/redis-operator/releases/tag/v1.0.0-rc.3))。 - `Redis-memory-analyzer`是Redis資料庫故障排除的最佳工具。 事件 #4 Datadog 的多區域噩夢 -------------------- 多個[Datadog](https://www.datadoghq.com/)區域宕機`systemd-networkd`強制刪除了容器網路介面 (CNI) 插件管理的路由。完整的屍檢 [在這裡](https://www.datadoghq.com/blog/2023-03-08-multiregion-infrastructure-connectivity-issue/)。 ![資料狗](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pcobaticca62tpuk7nwq.png) > **影響:**多個地區的使用者無法存取 API 和平台。 > **涉及:** systemd更新、Cilium **逐場比賽** 從 2023 年 3 月 8 日開始,Datadog 經歷了一次影響多個區域的重大中斷,導致用戶無法存取平台、API 和監視器,並影響資料提取。這個問題是由眾多虛擬機器上的 systemd 自動安全性更新觸發的,導致網路中斷,導致數萬個節點離線。恢復涉及恢復運算能力、解決特定於服務的問題以及為客戶提供持續更新。**根本原因被確定為允許自動更新的錯誤配置,該更新已停用。** **學習內容:** - 更強大的混沌測試。 - 需要在停電期間改善與客戶的溝通 - 停電期間狀態頁面不充分。 - 自動更新本身就有風險,應謹慎使用。 ### 事件#5 Reddit 的圓周率日中斷 Reddit 遭受了快速有機成長的後果,他們面臨著殘酷的現實,即許多關鍵的 Kubernetes 叢集不標準化,很容易出現中斷,[這裡是](https://www.reddit.com/r/RedditEng/comments/11xx5o0/you_broke_reddit_the_piday_outage/)完整的 Pi-Day 中斷事後分析。 ![紅迪網](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5s1vi0fdjwzps01hgnpj.png) > **影響:**嚴重的跨平台中斷持續 314 分鐘 > **涉及:** Calico、Kubernetes版本更新 **逐場比賽** 2023 年 3 月,Reddit 經歷了一次持續 314 分鐘的嚴重中斷,巧合的是,這發生在圓周率日。嘗試存取網站的用戶要么遇到不堪重負的 Snoo 吉祥物、錯誤訊息,要么看到空的主頁。這次中斷是由 Kubernetes 1.23 升級到 1.24 引發的,這引入了一個以前從未見過的微妙問題。工程團隊近年來一直強調可用性的改進,但發現自己處於一個充滿挑戰的境地,回滾雖然有風險,但卻成為了最佳選擇。 在復原過程中,由於 TLS 憑證和 AWS 容量限制不匹配,因此出現了一些複雜情況,但團隊設法克服了這些挑戰並重新建立了高可用性控制平面。 **進一步調查顯示,根本原因與 Calico 過時的路由反射器配置有關**,由於刪除了「master」節點標籤,此配置與 Kubernetes 1.24 不相容。 **學習內容:** - 出於測試目的改進預生產集群的重要性。 - 需要改進 Kubernetes 元件生命週期管理工具。 - 需要更同質的環境。 - 此外,還需要增加他們的 IaC 和內部技術文件。 結論 -- 正如您所看到的,熵定律很容易適用於 Kubernetes 叢集——破壞它們比讓它們滿意要容易得多。升級、部署、擴展和部署等變更通常會引發中斷,因此您可能傾向於盡量減少中斷。但對於那些努力引領細分市場並滿足不斷變化的客戶需求的組織來說,這不是一個選擇。我們所能期望的最好的結果就是從實踐中學習,並從失敗中學習。從好的方面來說,科技業普遍樂於學習,並能坦然面對失敗( [在大多數情況下](https://apnews.com/article/cellular-att-verizon-tmobile-outage-02d8dfd93019e79e5e2edbeed08ee450))。事實上,許多大型企業公開分享事後總結供更大的社區學習,這是一種最佳實踐,其基礎是這樣的假設:故障和中斷是「何時」而不是「是否」的問題。保護我們自己的最好方法就是在他們過去後向他們學習。 > 🫵 那你呢?您是否經歷過任何特別困難的停電並從另一邊講述了這個故事?如果是這樣,請在下面的評論中分享您的經驗。我相信我們很多人都想聽聽這個。 --- 幫助我們製作更多這樣的內容! -------------- 在[Glasskube,](https://github.com/glasskube/glasskube)我們在此類內容上投入了大量精力,並`next generation package manager for Kubernetes` 。 如果您從我們所做的工作中獲得價值,我們將不勝感激 [⭐️ GitHub 上的 Star Glasskube 🙏](https://github.com/glasskube/glasskube) [![github 上的明星](https://media2.giphy.com/media/v1.Y2lkPTc5MGI3NjExdnhibjU3MnRqeDVydm83ZXNiMHF1YXQ3NW9iMTEwcjFuZmhqcG8ydSZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/XaFhFM2lVRoVa/giphy.gif)](https://github.com/glasskube/glasskube) --- 原文出處:https://dev.to/glasskube/kubernetes-fail-compilation-but-they-keep-getting-worse-12n2

10 個工程博客,免費成為系統設計英雄

簡介: ------- 系統設計基本上是您想要建造的系統的藍圖。它是定義系統架構、元件和介面以滿足某些特定需求的過程。系統設計是軟體開發行業的熱門話題之一,在技術面試中被廣泛詢問,學習這項技能將保證你的加薪。 ![唐納川普說系統設計就是金錢](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/26gmdveo1ak1y0r752cn.gif) 在這篇文章中,我將分享十大系統設計工程博客,這些博客將幫助您免費成為系統設計大師 [字節字節 Go 博客](https://blog.bytebytego.com/) ------------------------------------------ Byte Byte Go 是一家教育科技新創公司,專注於提供系統設計主題的培訓和課程,幫助您像專業人士一樣在系統設計面試中取得好成績。 Byte Byte go 可以認為是學習和掌握系統設計技能最好的學校之一。 他們使用互動式動畫影片、心智圖、備忘錄等分解了複雜的系統設計主題,這將幫助您輕鬆掌握系統設計。無論您是系統設計新手還是想跟上當前行業標準,Byte Byte Go 都是您的必去之選 ![位元組GO博客](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ffpgu7maxrhb2jbejve5.png) [谷歌研究](https://research.google/blog/?page=1&) --------------------------------------------- 谷歌是世界上最受歡迎、最高效的搜尋引擎之一。他們每天在其平台上處理數十億用戶和請求。 Angular、Flutter、Android、Google Cloud、Firebase 等 Google 產品是幾乎每個開發人員都使用的一些關鍵技術。谷歌研究平台擁有廣泛的軟體開發主題,包括機器學習、軟體系統、硬體和架構、分散式和平行系統,這個平台是軟體開發人員學習和研究各種主題的隱藏寶石 ![谷歌研究](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3jwp16grrttt33g44eg1.png) [Dropbox 技術博客](https://dropbox.tech/) ------------------------------------- Dropbox 是一家美國科技公司,為各種用例提供儲存解決方案和其他軟體產品。他們每天也處理數百萬個請求,然後管理和擴展大型軟體基礎設施。在這裡您可以探索各種主題,例如基礎設施、前端開發、安全性、行動應用程式開發等。 ![投遞箱技術博客](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gdp43crv099kww6yl8ls.png) [Netflix 科技部落格](https://netflixtechblog.com/) --------------------------------------------- Netflix 是全球最受歡迎、最成功的 Ott 巨頭之一,每天處理數百萬用戶和請求。您可以關注 Netflix 工程博客,了解從視訊串流、微服務到機器學習和人工智慧等各種主題。如果您在 Ott 行業工作或計劃在視訊串流技術之上建立一些東西,您必須關注 Netflix 技術部落格以供參考。 ![Netflix 科技部落格](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2trw7unayy4uett3cri0.png) [優步工程博客](https://eng.uber.com/) ------------------------------- 優步是世界上最受歡迎、也有望成為最大的線上計程車服務提供者之一。優步也涉足線上食品配送領域。我將 Uber 工程部落格放入此列表的原因是因為您會在他們的部落格中找到一些最重要的主題,例如使用地圖和位置來提供服務。使用地理位置資料是軟體工程中最重要的主題之一,電子商務和物流等最常見的工業部門非常依賴這些訊息,以便他們能夠盡快交付產品或服務。如果您是軟體產業中從事地理位置或導航技術工作或計劃使用這些技術建立某些東西的人,那麼 Uber 工程部落格是您必須查看的內容 ![優步工程博客](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m1kwwqi4orz3cunyeo9p.png) [元工程博客](https://engineering.fb.com/) ------------------------------------ Meta(原 Facebook)是世界上最大的社群媒體巨頭,也是最受歡迎的用於建立使用者介面的 JavaScript 函式庫(即 React.js)的創辦人和維護者。除此之外,幾乎所有流行的社交媒體應用程式(包括 facebook、instagram、whatsapp、threads 等)都歸他們所有。元工程博客包含廣泛的軟體工程主題,如網絡和移動開發、基礎設施系統、影片技術、AR 和 VR 技術等。 VR 科技 ![元工程](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d8mba756nkk0q9fnsy4t.png) [Stripe 工程博客](https://stripe.com/blog/engineering) -------------------------------------------------- Stripe 是最受歡迎的提供支付相關解決方案的公司之一。大多數線上企業和電子商務網站都使用 stripe 來處理付款、訂閱和發票,即使我也使用 stripe 來存取客戶的付款。 Stripe Engineering 部落格涵蓋了廣泛的主題,您可以探索這些主題,例如使用機器學習進行詐欺偵測、用於響應式和互動式支付介面的 UI 和 UX 相關主題、應用程式安全性等等。因此,如果您正在從事支付工作或計劃建立與處理支付相關的東西,您一定要查看 Stripe 工程部落格作為參考。 ![Stripe 工程博客](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5g8eoq6f2puv2nkekfxy.png) [亞馬遜工程博客](https://aws.amazon.com/blogs) --------------------------------------- 亞馬遜工程博客 亞馬遜是世界上最大的電子商務巨頭,不僅如此,它還擁有亞馬遜網路服務(最大的雲端服務供應商)、亞馬遜Prime(最受歡迎的OTT巨頭之一)、有聲故事平台亞馬遜音樂等等。多的。 Amazon Engineering 部落格涵蓋了廣泛的主題,包括容器和 Kubernetes、雲端模式和架構、機器學習和 Amazon 人工智慧技術,以解決複雜的業務挑戰。因此,如果您打算使用 AWS 建立下一個應用程式或整合 Alexa 等亞馬遜技術,那麼亞馬遜工程部落格是您必須查看的地方。 ![亞馬遜工程博客](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a07bwfp2rsebvi180cnl.png) [微軟開發部落格](https://devblogs.microsoft.com/) ------------------------------------------ 微軟是美國最受歡迎的科技巨頭之一,擁有最常用的作業系統 Windows、用於建立極快企業應用程式的點網框架、Bing 搜尋引擎、copilot(最高效的人工智慧工具之一)、最大的程式碼共享、託管和版本控制平台GitHub、Azure雲端平台(最大的雲端服務提供者之一)。 Microsoft 工程部落格包含廣泛的主題和教程,還包括 Windows、azure、機器學習和人工智慧、dot net 框架。如果您打算使用 Microsoft 技術建立下一個應用程式或軟體,那麼您必須關注它 ![微軟開發部落格](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y10tc92q65czuks6cidk.png) [蘋果開發者新聞](https://developer.apple.com/news/) -------------------------------------------- 蘋果是世界上最大的科技巨頭之一,也擁有最受歡迎的Mac作業系統和IOS(iPhone作業系統)。 MacBook 和 iPhone 擁有非常龐大的用戶群,因此大多數新創公司和企業也為 Mac 和 IOS 用戶打造產品。 Apple 開發者新聞主要包含與IOS、Swift(建立本機IOS 和Mac OS 應用程式的唯一語言)、Swift UI(Apple UI)相關的主題,以及一些與C++、Kubernetes 等主題相關的主題。正在計劃的人要為 iOS 或 Mac OS 用戶建立軟體,開發者新聞是您必須參考的。 ![蘋果開發者新聞](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8ewo1tt4046wgom5d8hy.png) 結論 -- 在本文中,我討論了 10 個您必須查看的工程博客,以提高您的系統設計技能。如果您關注每個博客,那很好,但我建議您必須僅根據您將使用的堆疊或您正在處理的行業類型來查看那些博客 --- 原文出處:https://dev.to/kumarkalyan/10-engineering-blogs-to-become-a-system-design-hero-for-free-20ee

簡短概述:微前端 🧩

當人們談論**微前端**時,他們首先提到的就是其驚人的擴展能力。他們透過將服務分成更小的部分並無縫協作來實現這一目標。 微前端的優勢👍 ------- - **微前端**支援團隊可以實現後續前端功能,從而顯著加快迭代速度。 - 微前端的**水平可擴展性**旨在使組織能夠透過水平擴展來擴展其前端架構。 📈 微前端的缺點👎 ------- - 微前端會使網站的開發、維護和建置**變得複雜**。然而,可以透過使用智慧設計、有助於自動部署和測試的工具以及確保團隊之間的清晰溝通來緩解這些挑戰。 📉 - 如果團隊之間不進行溝通,**依賴管理**可能會成為問題。但可以透過在團隊之間建立清晰的溝通管道來討論更新來解決! 👌 單體應用程式經常遇到有效擴展的挑戰。透過將前端分解為微前端,可以更有效地實現延遲載入和**服務工作者**等高階邏輯結構。 **JavaScript 的**靈活性允許團隊加入各種框架和程式庫,從而促進微前端之間的無縫整合和互通性。豐富的 JavaScript 工俱生態系統為開發人員提供了強大的資源來建立動態和響應式的使用者介面。 - 受到以下書的啟發: [***建立微前端、擴展團隊和專案、為開發人員提供支援***。](https://www.amazon.com/Building-Micro-Frontends-Projects-Empowering-Developers/dp/1492082996/ref=sr_1_2?crid=RCBAUE4OKJ0J&dib=eyJ2IjoiMSJ9.0ZJp2IXMP9BkahJYaiHl9ez2Wm6vlnMHRLwunki8JYstYZfM_ukCSBNN1JAldlIqkOUuSa70q6nEYv5Rle1a2vzND0PJ_BEBt_kCHgnNjO9tg-Kp9V1tGAtMW7QtLmY53ZAuOFX4lfXTM2DTu5KCUiwIHGHiERCZ9ehXTueraXmWd4AAl5aP6VkEgs56_BamuYAo7pHw1nb6ceTIouGXkdImZ4fB-y81_da06oyWRY8.601H27Rq2LULtNXKVir3Z3QOGJlbx6ovOrmk3Iny2Bg&dib_tag=se&keywords=micro+frontend&qid=1717013751&sprefix=microfronten,aps,223&sr=8-2)作者:*盧卡‧梅札里拉 (Luca Mezzalira) 尼爾‧福特 (Neal Ford) 作序* 加入我們! ----- 那麼...您喜歡 Javascript 並想為開源專案做出貢獻嗎?**你在等什麼?** 😁 前往[Webcrumbs](https://www.webcrumbs.org/)並加入一個致力於為開源愛好者提供 JavaScript 生態系統的社群! --- 原文出處:https://dev.to/buildwebcrumbs/short-overview-micro-frontends-2f5i

系統設計面試的 10 個微服務架構挑戰

*揭露:這篇文章包含附屬連結;如果您透過本文中提供的不同連結購買產品或服務,我可能會獲得補償。* [![微服務架構最佳實踐](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rkibz6xn6xqibepgu9cz.png)](https://bit.ly/3P3eqMN) image\_credit - [ByteByteGo](https://bit.ly/3P3eqMN) 朋友們大家好,如果您正在準備系統設計面試,那麼您也必須準備微服務架構。這是許多面試官最喜歡的架構,它提供了大量的材料來拷問你。 毫無疑問,微服務架構透過將單體應用程式分解為更小的、鬆散耦合的服務,徹底改變了軟體開發。 過去,我分享過幾篇系統設計面試文章,例如[API 網關與負載平衡器](https://medium.com/javarevisited/difference-between-api-gateway-and-load-balancer-in-microservices-8c8b552a024)、 [正向代理與反向代理](https://medium.com/javarevisited/difference-between-forward-proxy-and-reverse-proxy-in-system-design-da05c1f5f6ad)以及[常見的系統設計問題](https://medium.com/javarevisited/7-system-design-problems-to-crack-software-engineering-interviews-in-2023-13a518467c3e),在本文中我們將討論微服務架構的挑戰。 它也是程式設計師必須了解的[基本系統設計主題或概念](https://medium.com/javarevisited/top-10-system-design-concepts-every-programmer-should-learn-54375d8557a6)之一。 雖然微服務方法承諾提高可擴展性、靈活性和更快的開發週期,但它也帶來了一系列挑戰,這對開發人員來說非常重要,不僅要了解這些挑戰,還要有效地解決這些挑戰。 雖然有很多文章討論微服務最佳實踐,但很少有文章闡述它們提供的好處以及它們解決的挑戰。 在本文中,我們將探討開發人員在使用微服務時所面臨的十大主要挑戰,並學習克服這些挑戰的有效策略。 順便說一句,如果您正在準備系統設計面試並想深入學習系統設計,那麼您還可以查看[ByteByteGo](https://bit.ly/3P3eqMN) 、 [Design Guru](https://bit.ly/3pMiO8g) 、 [Exponent](https://bit.ly/3cNF0vw) 、 [Educative](https://bit.ly/3Mnh6UR)和[Udemy](https://bit.ly/3vFNPid)等網站,它們有許多很棒的系統設計課程 此外,對各種微服務模式(例如服務發現、CQRS 和 Saga)的紮實了解對於解決我們將在本文中討論的許多挑戰大有幫助,就此而言,這裡有一個來自[DesignGuru.io](https://designgurus.org/link/84Y9hP)的漂亮圖表,說明如何微服務中的服務發現工作,我們將在本文後面使用此模式 [![微服務中的服務發現](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e0ke14if9uyunsszj0lu.png)](https://www.designgurus.io/course/grokking-microservices-design-patterns?aff=84Y9hP) --- 微服務開發的10大挑戰及解決方案 ---------------- 以下列出了使用微服務架構建立應用程式時可能面臨的主要挑戰 ### 1. 服務溝通挑戰 如果您在現實世界的微服務架構中工作過,那麼您可能知道微服務嚴重依賴服務間通信,隨著服務數量的增長,這可能會成為一個挑戰。 由於每個服務都有自己的 API 和協議,管理通訊變得複雜。 為了解決這個問題,請採用 REST、訊息佇列和事件驅動架構等通訊模式。此外,請考慮使用[**API 閘道**](https://medium.com/javarevisited/difference-between-api-gateway-and-load-balancer-in-microservices-8c8b552a024)來集中通訊邏輯並處理橫切問題。 ![微服務架構挑戰](https://miro.medium.com/v2/resize:fit:609/1*I4tv-pLx4ccaaBTFzquzsA.png) --- ### 2. 資料管理挑戰 由於架構的分散性,跨微服務的資料管理可能會很複雜。不一致的資料模型和維護資料一致性帶來了困難。 為了解決這個問題,您可以實施多語言持久性策略,使用適合每個服務特定需求的資料庫。 您還應該利用事件來源和[**CQRS(命令查詢職責分離)**](https://javarevisited.substack.com/p/how-cqrs-pattern-works-in-microservices)等技術來維護資料完整性以及讀寫操作的分離。 [![微服務的資料管理挑戰](https://miro.medium.com/v2/resize:fit:609/1*XKdhM77EN6isbz5eeH2K9A.jpeg)](https://medium.com/javarevisited/what-is-cqrs-command-and-query-responsibility-segregation-pattern-7b1b38514edd) --- ### 3. 分散式追蹤與監控挑戰 由於請求跨越多個服務,監控和除錯微服務應用程式變得非常具有挑戰性。傳統的監控工具可能無法提供所需的可見度。 為了解決這個問題,您應該整合 Jaeger 或 Zipkin 等分散式追蹤系統來追蹤跨服務的請求。 您還可以使用集中式日誌記錄和監控解決方案來聚合和分析來自各種服務的日誌和指標,有助於早期發現問題。 對於開發人員來說,微服務中的偵錯問題是處理和了解 Zipkin 等追蹤系統真正運作的最大挑戰之一。 ![微服務架構中的分散式追蹤與監控挑戰](https://miro.medium.com/v2/resize:fit:609/1*MRyM0qiMBljjsfnoemCAeg.png) --- ### 4. 服務編排與編排挑戰 微服務可以集中編排,也可以以分散的方式編排。這兩種方法都有其挑戰。 編排服務可能會導致單點故障,而編排可能會導致追蹤流程的複雜性和難度增加。 在這種情況下,您應該努力尋求平衡,對關鍵工作流程採用編排,並對可以獨立運作的服務進行編排。 ![微服務中的服務編排與編排挑戰](https://miro.medium.com/v2/resize:fit:609/1*O_AFZvulWl5ZZYE1BG7hYQ.png) --- ### 5. 部署與 DevOps 挑戰 微服務的部署涉及管理多個服務實例並確保不同環境之間的相容性。使用傳統方式部署微服務幾乎是不可能的。 使用 Docker 等工具的容器化和使用[Kubernetes 的](https://medium.com/javarevisited/top-15-online-courses-to-learn-docker-kubernetes-and-aws-for-fullstack-developers-and-devops-d8cc4f16e773)編排可以幫助標準化部署流程,事實上,如果您想要穩健的話,它們是必須的。 您還應該採用**DevOps 實踐**並自動化部署管道,以確保微服務的一致性和快速部署。 ![微服務中的部署與 DevOps 挑戰](https://miro.medium.com/v2/resize:fit:609/1*Bxoxd1eCCtPyJzMtLeFVYw.jpeg) --- ### 6. 跨服務挑戰的測試 測試微服務一點也不容易,由於其互動的複雜性,它需要一個全面的策略。 傳統的單元測試可能還不夠。 為了解決這個問題,您可以結合整合測試、合約測試和端到端測試來驗證服務互動和資料流。 您還應該實施一個強大的[CI/CD 管道](https://javarevisited.blogspot.com/2018/09/top-5-jenkins-courses-for-java-and-DevOps-Programmers.html),以在整個微服務生態系統中自動進行測試。 ![應對微服務中的服務挑戰](https://miro.medium.com/v2/resize:fit:609/1*fKlBw13XQ5RyazLXl2MIIQ.png) --- ### 7. 安全和存取控制挑戰 微服務可能會暴露大量端點,從而增加潛在的攻擊面。大多數時候,您甚至不會意識到這一點,但不用擔心,幾乎所有大型組織都有龐大的安全團隊,高薪來騷擾您。 就您而言,您應該確保跨服務的安全性,管理身分驗證和授權以及保護傳輸中的資料會帶來重大挑戰。 採用零信任安全模型,實作[OAuth2](https://medium.com/javarevisited/5-best-online-courses-to-learn-oauth-2-0-and-jwt-in-2023-719fd63c834)和[JWT(JSON Web Tokens)](https://medium.com/javarevisited/difference-between-jwt-oauth-and-saml-for-authentication-and-authorization-in-web-apps-75b412754127)等 API 安全標準,並採用具有強大存取控制機制的 API 閘道。 ![微服務中的安全性和存取控制挑戰](https://miro.medium.com/v2/resize:fit:609/1*GP0lglBapQS929e3Paf1ng.png) 積分 --- superTokens --- ### 8. 可擴展性和資源分配 可擴展性是微服務的核心承諾,也是許多公司放棄單體應用而轉向微服務的主要驅動力之一,但它需要仔細規劃。 某些服務可能會遇到比其他服務更重的負載,導致資源分配挑戰。 您應該利用容器**編排平台**和工具(例如 K8)根據需求動態分配資源。 您也可以根據 CPU 使用率或請求率等指標實施自動擴展,以確保最佳的資源使用率。 [![微服務中的可擴展性和資源分配挑戰](https://miro.medium.com/v2/resize:fit:609/1*JH4N7C199Gl3dhc2sh3xHQ.png)](https://medium.com/javarevisited/difference-between-horizontal-scalability-vs-vertical-scalability-67455efc91c) --- ### 9. 版本控制和相容性挑戰 隨著微服務的獨立發展,保持向後和向前相容性變得至關重要。 不相容的更改可能會破壞整個系統。 作為經驗豐富的開發人員或技術主管,您應該在程式碼層級和通訊協定中實作 API 的版本控制。 您也可以利用語意版本控制來清楚傳達相容性期望。逐步淘汰舊版本,同時為遷移提供足夠的支援和文件。 ![微服務中的版本控制和相容性挑戰](https://miro.medium.com/v2/resize:fit:609/1*xezI58bd7nSSjW35u2XfGQ.jpeg) --- ### 10.組織複雜性和溝通挑戰 微服務架構可以反映組織的結構,從而導致溝通和協作方面的挑戰,例如不同的團隊管理不同的微服務。 從事不同服務的跨職能團隊需要協調他們的工作,這一點很重要。 作為經驗豐富的專家,您應該透過定期會議、分享文件和促進資訊交換的工具來培養溝通和協作的文化。 ![組織複雜性與溝通挑戰](https://miro.medium.com/v2/resize:fit:609/1*6-rMCG_PZDnt1Z1RWvPWyg.jpeg) --- ### 系統設計訪談資源: 而且,這裡列出了最佳系統設計書籍、線上課程和練習網站,您可以查看這些內容,以便更好地為系統設計面試做好準備。這些課程中的大多數也回答了我在這裡分享的問題。 1. [**DesignGuru 的 Grokking 系統設計課程**](https://bit.ly/3pMiO8g):一個互動式學習平台,提供實作練習和真實場景,以增強您的系統設計技能。 2. [**《系統設計面試》作者:Alex Xu**](https://amzn.to/3nU2Mbp) :這本書深入探討了系統設計概念、策略和麵試準備技巧。 3. Martin Kleppmann 的[**「設計資料密集型應用程式」**](https://amzn.to/3nXKaas) :綜合指南,涵蓋了設計可擴展且可靠的系統的原則和實踐。 4. [LeetCode 系統設計 標籤](https://leetcode.com/explore/learn/card/system-design):LeetCode 是一個受歡迎的技術面試準備平台。 LeetCode 上的系統設計標籤包含各種練習問題。 5. GitHub 上的[**「系統設計入門」**](https://bit.ly/3bSaBfC) :精選的資源列表,包括文章、書籍和影片,可幫助您準備系統設計面試。 6. [**Educative 的系統設計課程**](https://bit.ly/3Mnh6UR):一個互動式學習平台,提供實作練習和真實場景,以增強您的系統設計技能。 7. **高可擴展性部落格**:該部落格包含有關高流量網站和可擴展系統架構的文章和案例研究。 8. **[YouTube 頻道](https://medium.com/javarevisited/top-8-youtube-channels-for-system-design-interview-preparation-970d103ea18d)**:請參閱「Gaurav Sen」和「Tech Dummies」等頻道,以取得有關係統設計概念和麵試準備的富有洞察力的影片。 9. [**ByteByteGo**](https://bit.ly/3P3eqMN) :Alex Xu 的一本現場書籍和課程,用於系統設計面試準備。它包含《系統設計訪談》第一捲和第二卷的所有內容,並將隨即將推出的第三卷進行更新。 10. [**Exponent**](https://bit.ly/3cNF0vw) :一個專為面試準備的網站,特別是針對亞馬遜和谷歌等 FAANG 公司,他們還有很棒的系統設計課程和許多其他材料,可以幫助您破解 FAANG 面試。 而且,這是一個很好的系統設計面試備忘錄,可以快速修改基本的系統設計概念: [![系統設計面試備忘錄](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1ooidxg5v3bopt7a6uf4.png)](https://bit.ly/3cNF0vw) image\_credit - [tryExponent](https://bit.ly/3cNF0vw) ### 結論 這就是關於微服務架構挑戰以及如何應對這些挑戰的全部內容。微服務架構在可擴展性、靈活性和更快的開發方面提供了顯著的優勢。 然而,這些優勢也伴隨著開發人員必須有效應對的一系列獨特挑戰。 透過在服務通訊、資料管理、監控、測試、安全性等方面採用最佳實踐,團隊可以克服這些挑戰並釋放微服務的全部潛力。 隨著軟體開發環境的不斷發展,解決這些挑戰對於成功實施微服務仍然至關重要 雖然我寫這篇文章是為了準備系統設計面試,但對於使用微服務並希望獲得更多控制和更好組織的經驗豐富的開發人員來說,它同樣有價值。 微服務開發一切順利! **獎金**\\ 正如承諾的,這是給你的獎金,一本免費的書。我剛剛找到一本新的免費書籍來學習分散式系統設計,您也可以在 Microsoft 上閱讀它 --- [https://info.microsoft.com/rs/157-GQE-382/images/EN-CNTNT -eBook-設計分散式系統.pdf](https://info.microsoft.com/rs/157-GQE-382/images/EN-CNTNT-eBook-DesigningDistributedSystems.pdf) [![關於分散式系統的免費書籍](https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fso5r1wv8x95i74nz6p89.png)](https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fso5r1wv8x95i74nz6p89.png) --- 原文出處:https://dev.to/somadevtoo/10-microservices-architecture-challenges-for-system-design-interviews-6g0

您把 Git commit 訊息寫對了嗎?

當涉及版本控制時,Git 是一個非常有效的工具。然而,像任何其他工具一樣,您必須以正確的方式使用它才能充分利用它。您需要考慮不同的方面。本文重點介紹如何按照常規提交規範編寫有效的 Git 提交訊息。它概述了幫助您建立清晰、資訊豐富且標準化的提交訊息的基礎知識。 好的提交訊息是什麼樣的? ------------ 發送訊息的目的是為了溝通。為了使溝通有效,接收者必須清楚地了解訊息發送者試圖告訴他們什麼。因此,您需要提供上下文和足夠的資訊。基於此,一個好的提交訊息應該傳達以下內容: **1. 類型(必填)** - `fix:` – 適用於修復錯誤的操作。 - `feat:` – 當您新增功能時適用。 - `BREAKING CHANGE:` - 當您引入以下變更時適用 可能需要更新程式的某些方面或 升級以避免中斷。例如,替換已棄用的 如果有的話,新資源可能會破壞功能 沒有向後相容性。您也可以指示中斷 使用符號“!”進行更改緊接在類型(或範圍,如果 可用的)。 例子; '壯舉(身份驗證)! - `docs:` – 適用於文件。 其他包括*test:、chore:、refactor:、build:、style:*等。因此,提前了解詳細資訊很重要。 **2.範圍(可選)** 儘管提供範圍是可選的,但為了清晰起見,最好將其包含在內。範圍指定了受變更影響的程式碼庫部分,從而幫助讀者了解變更的上下文。這對於有許多貢獻者的大型專案尤其有用。它使協作變得更加容易。 **3. 說明(必填)** 這是您描述您所做的事情的部分。保持簡潔、開門見山。確保以命令式形式編寫。例如,不應編寫“新增身份驗證機制”,而應編寫“新增身份驗證機制”。這將提高自動產生的變更日誌和發行說明的可讀性。 **4. 本體(可選)** 您可以在此處提供有關您已實施的內容的更多資訊。使用空白行將正文與描述分開。 **5.頁尾(可選)** 如果您想在頁腳中包含任何元資料,請執行此操作。例如,如果您所做的變更解決了先前提出的問題,您可以透過引用參考號在此指出。例子; '**修復#003** ' 您也可以在頁腳中包含審閱者的姓名。 請記住,在給出描述之前,範圍後面應該跟有冒號和空格。您還應該記住,BREAKING CHANGE 在包含在頁腳中時區分大小寫,因此應以大寫形式書寫。 例子 -- - Chore(Art\_func):將變數“Empty”更改為“empty” 將變數名稱從“Empty”更改為“empty”以保持一致 命名約定。 - 修復(資料庫)! 修改架構以僅容納結構化資料。關閉所有 其他類型的資料。 - 壯舉:增加對黑暗模式的支援。 對於長訊息,請使用文字編輯器執行 ``` git commit ``` 沒有 -m 標誌。這將打開一個編輯器,您可以在其中編寫詳細的提交訊息。對於較短的訊息,您可以僅包含 -m 標誌並使用終端機而不是編輯器。 ``` git commit -m "subject" -m "body" ``` 使用多個 -m 標誌可以透過分隔主題、正文和頁腳來幫助您正確格式化訊息。 結論 -- 編寫提交訊息應該達到預期目的。為了使其清晰且資訊豐富,建議您至少包含所做更改的類型和描述。按照傳統方法維護一個良好的程式碼庫,可以支援各種流程的協作和自動化。有關詳細訊息,請務必閱讀[常規提交](https://www.conventionalcommits.org/en/v1.0.0/)指南。 --- 原文出處:https://dev.to/otienorabin/are-you-writing-your-git-commit-messages-properly-54cl