【科技新聞】我的 Youtube 收入

這透明度真是太棒了；大尊重。有趣的是，這些信息被悄悄地發佈到他們的低流量博客上，幾乎沒有引起注意，同時所包含的信息實際上非常有價值（而且它本身可能會製作一個非常有價值的 youtube 視頻，擁有數千萬的瀏覽量）。

我想知道網絡上還有多少其他信息非常有價值但未被注意

最令人印象深刻的部分是，創作者可以從有機增長的頻道中過上舒適的生活，但仍然 100% 取決於 youtube 的算法。

我關注這個頻道很多年了，不熟悉的人應該看看 [0]。它不是帶有瘋狂面部縮略圖的“病毒式”目標視頻、邊緣點擊誘餌標題、經過一周的 AB 測試，也不是“我必須遵守時間表”的每週視頻等。

這些視頻非常直截了當，重點突出，所有的娛樂都來自觀眾的好奇心和創作者閃耀的幽默。當我看到每個視頻的平均時長為 100 小時時，看起來他們真的確定了真正重要的事情，而忽略了其餘部分。

在我看來，很少有頻道在享受舒適的成功的同時保持非常基本和忠實於他們的形式，我認為這可能是 Youtube 最想鼓勵的類型，並希望更多的頻道在我從未聽說過的地方蓬勃發展。

[0] https://www.youtube.com/BrickExperimentChannel

只是對 YouTube 本身的個人讚美。我從開始就在 YouTube 上觀看視頻，但直到過去幾年我才開始欣賞它已經成為一個多麼偉大的媒體。通過允許人們分享各種小眾主題的內容並可能從中賺錢，YouTube 已成為教育和娛樂的絕佳資源。對於像我這樣只能接觸電視、廣播、報紙和其他大眾媒體的人來說，這是一個巨大的進步。

也就是說，我希望 YouTube 有多個規模相似的競爭對手，包括商業和去中心化的。讓我感到緊張的是，訪問如此多的精彩內容最終由谷歌控制。

作者在這裡。

哇！這有點爆炸，非常感謝你的客氣話！

最近，我正在嘗試為我的帖子添加更多交互性。主要靈感來自 Bartosz Ciechanowski [1] 的驚人作品。

幾年前我開始用代碼繪圖，並完全愛上了它。像這樣的問題讓我對創造性編程產生了渴望。

我希望我的一些帖子會激發人們嘗試使用代碼製作圖片，只是為了它。編程應該很有趣 🙂

[1] https://ciechanow.ski/

編輯：錯別字

值得花一些時間探索該博客的其餘部分 – 那裡有很多很棒的內容。我特別喜歡這個關於使用 Voronoi 圖的生成藝術的作品： https ://muffinman.io/blog/breaking-down-krypton/

這一切都令人驚嘆和難以置信。它是那些本身就是藝術的網頁之一。如此美麗的演講。看到有人解決這類問題也很令人驚訝。它完全逃脫了我，但你最終讓它看起來如此明顯！

微服務雖然經常作為解決技術問題進行銷售，但實際上通常解決的是擴大組織規模時的人為問題。

微服務旨在解決兩個技術問題：模塊化（關注點分離、隱藏實現、文檔接口和所有這些好東西）和可擴展性（能夠為需要它的特定模塊增加計算、內存和 IO 的數量） .

第一個問題，模塊，可以在語言層面解決。模塊可以完成這項工作，這就是這篇博文的重點。

第二個問題，即可伸縮性，對於大多數設計為在分佈式環境中運行的語言之外的語言，很難在語言級別上解決。但大多數人比他們想像的要少得多。通常數據庫是你的瓶頸，如果你讓你的應用服務器保持無狀態，你可以運行很多它們；數據庫最終可能成為瓶頸，但您可以大量擴展數據庫。

微服務可能有意義的真正原因是它們讓人們在模塊邊界周圍保持誠實。它們使得保留對持久內存狀態的訪問變得更加困難，更難以導航對像圖以依賴於他們不應該依賴的東西，更難以在模塊邊界的任一側創建具有復雜變化的 PRs 而沒有關於設計的對話變化和未來的證明。團隊的代碼所有權是隨著組織規模的擴大而需要的，如果只是為了減少開發人員在被視為完全可替代的情況下需要進行的上下文切換的數量；擁有一項服務比擁有一個模塊更具防禦性，因為團隊將擁有發佈時間表和質量控制。

我對每個維護自己的狀態副本的微服務都不太樂觀，可能有自己獨立的數據存儲。我認為這通常會增加同步的持續複雜性，而不是通過隔離模式來節省。更好的規則是一個服務擁有對一個表的寫入，而其他服務只能讀取該表，甚至可能不是所有列或所有非擁有的表。狀態同步問題是分佈式應用程序中最常見的故障模式之一，其中隊列得到備份，“壞”事件的重試導致阻塞等等。

我正在從事一個項目，該項目使用微服務架構來使各個組件可擴展並分離關注點。然而，一個意想不到的後果是，我們現在在這些微服務之間進行了大量的網絡調用，這實際上已經成為我們程序的主要速度瓶頸，特別是因為其中一些服務甚至不在同一個數據中心。我們現在正嘗試通過緩存和批處理請求來解決這個問題，但是所有這些都會產生額外的開銷，而這些開銷本可以通過不使用微服務來避免。

這段經歷極大地影響了我對微服務的看法，對於我將來開發的所有個人項目，我將堅持使用單體，直到很久以後，而不是從微服務開始。

我真的很喜歡模塊化設計，但這篇文章遺漏了單體應用程序的一些關鍵限制，如果它們真的很好地模塊化（這主要是從 Java 開發人員的角度寫的）：

* 他們強制對齊一種語言或至少運行時

* 它們強制對齊依賴項及其版本（是的，你可以有不同的版本，例如通過 Java 類加載器，但這很快就會變得棘手，你不能跨模塊邊界共享它們，等等）

* 如果你有很多模塊和很多類，它們可能需要大量 RAM（半相關的有趣事實：我記得我們達到了一個 JAR 可以讓你加載到 WebLogic 中的類文件的最大數量的情況）

* 它們啟動起來可能很慢（同樣，類加載需要時間）

* 它們可能在技術選擇方面受到限制（您可能不希望在一個進程中連接到 RDBMS、Neo4j 和 MongoDB）

* 它們不提供組件之間的資源隔離：一個模塊中的繁忙循環會佔用大量 CPU？其他模塊運氣不好。

* 重建重新部署需要很長時間，除非您應用大量紀律和工程卓越來僅重建更改的模塊，同時確保沒有 API 合同被破壞

* 它們可能很難測試（另一個團隊的組件的數據庫設置如何再次工作？）

我並不是說這些問題中的大多數都無法克服。相反，我希望看到以不存在這些問題的方式構建單體。我曾研究過模塊化程度非常高的大型單體。上述這些實際問題是在這些情況下扼殺生產力和開發人員樂趣的原因。

我們不要假裝大型單體不會帶來具體挑戰，人們在過去 15 年沒有充分理由就轉向微服務。