<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ??碼云GVP開源項目 12k star Uniapp+ElementUI 功能強大 支持多語言、二開方便! 廣告
                # Google+是使用您也可以使用的工具構建的:閉包,Java Servlet,JavaScript,BigTable,Colossus,快速周轉 > 原文: [http://highscalability.com/blog/2011/7/12/google-is-built-using-tools-you-can-use-too-closure-java-ser.html](http://highscalability.com/blog/2011/7/12/google-is-built-using-tools-you-can-use-too-closure-java-ser.html) ![](https://img.kancloud.cn/00/2e/002ed5110f5bca591ed39e2a1421dc20_150x150.png) Plaxo 的前首席技術官 Joseph Smarr(解釋了我認出他的照片的原因)在[中,我是 Google+團隊的技術負責人。 問我什么](http://anyasq.com/79-im-a-technical-lead-on-the-google+-team),揭示用于構建 Google+的堆棧: > 如今,我們的協議棧是 Google 應用程序的標準價格:我們將 Java servlet 用于服務器代碼,將 JavaScript 用于 UI 的瀏覽器端,很大程度上是由(開源)Closure 框架構建的,其中包括 Closure 的 JavaScript 編譯器和模板系統 。 我們采取了一些巧妙的技巧:即使使用的是 AJAX 應用程序,我們也使用 HTML5 歷史記錄 API 來維護漂亮的 URL(對于較舊的瀏覽器,它采用哈希碎片); 并且我們經常在服務器端渲染 Closure 模板,以便在加載任何 JavaScript 之前先渲染頁面,然后 JavaScript 找到正確的 DOM 節點并掛接事件處理程序等,以使其具有響應能力(因此,如果您在 緩慢的連接,您很快就會點擊內容,您可能會注意到它在執行任何操作之前都存在滯后,但幸運的是,大多數人實際上并沒有遇到這種情況)。 我們的后端主要建立在 BigTable 和 Colossus / GFS 之上,并且我們使用了許多其他常見的 Google 技術,例如 MapReduce(同樣,與許多其他 Google 應用程序一樣)。 起初,我讀了 Clojure,這真是一個真正的驚喜,但是它是 Closure,這是一套 JavaScript 工具,由[庫](http://code.google.com/closure/library/),[編譯器](http://code.google.com/closure/compiler/)和[模板](http://code.google.com/closure/templates/)組成 。 該編譯器是用于 JavaScript 的真正編譯器,可加快 JavaScript 下載和運行速度。 該庫是模塊化和跨瀏覽器的 JavaScript 庫。 模板是服務器端模板系統,可幫助您動態構建可重用的 HTML 和 UI 元素。 它都是開源的,因此您也可以使用它。 雖然您沒有可用的 Google 堆棧,但確實有一些開源選項。 [HBase](http://wiki.apache.org/hadoop/Hbase) 替代了 BigTable。 然后是 [Hadoop MapReduce](http://hadoop.apache.org/mapreduce/) 。 [Colossus](http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) 是 Google 的[下一代文件系統](http://highscalability.com/blog/2010/9/11/googles-colossus-makes-search-real-time-by-dumping-mapreduce.html),是 GFS 的替代品。 由于我們對 Colossus 知之甚少,因此很難說出合適的替代品。 有 Hadoop 分布式文件系統 [HDFS](http://hadoop.apache.org/hdfs/) 。 如果您正在尋找一些像基礎架構膠之類的云,則可以使用 [OpenStack](http://www.openstack.org/) (它也具有存儲系統)。 Google 可能使用了自定義的 [Java servlet](http://en.wikipedia.org/wiki/Java_Servlet) 容器,但是此處的選擇并不重要。 大部分工作將以并行方式產生,并在以 [C ++,Java 或 Python](http://www.quora.com/Which-programming-languages-does-Google-use-internally) 實現的其他服務器上執行。 盡管幾乎沒有與 Google 的交流,但 Google+開發團隊的響應速度明顯加快,可以快速,一致地實現明顯的改進。 約瑟夫告訴我們原因:*我們特別強調工程速度/敏捷性-我們嘗試每天發布代碼更新,同時仍保持質量/穩定性/延遲與您對 google 的期望一樣高。 這有助于我們快速行動并快速響應用戶反饋。 我們嘗試(幾乎)每天都進行一次完全推送,有時,如果需要,有時我們也會潛入補丁程序發行版中。 但是有很多人參與其中,這不是“如果所有測試都通過都會自動推動”的情況或類似的情況。* 對于 Google+最具創新性的功能,即環聊視頻會議,GigaOM 在該堆棧上有一篇[不錯的文章,該文章基于由技術負責人 Justin Uberti 撰寫的](http://gigaom.com/video/google-hangouts-technology/)[宣布 Google+ Hangouts](http://juberti.blogspot.com/2011/06/announcing-google-hangouts.html) 。 與以經濟高效的 P2P 模式運行的 Skype 不同,環聊完全由 Google 托管。 這必須花費驚人的金錢。 你自己一個人在這里。 沒有人可以取代 Google 童話捐贈的帶寬。 那就是 Google。 再一次,一位前 Google 員工認為[您可以使用 MessagePack,JSON,Hadoop,jQuery 和 MongoDB 更好地完成](http://rethrick.com/#waving-goodbye)。 如果您可以為全球十億用戶群做得更好,那將是另一個完全不同的問題。 ## 相關文章 * [封閉庫](http://code.google.com/closure/library/) / [封閉模板](http://code.google.com/closure/templates/) / [封閉編譯器](http://code.google.com/closure/compiler/) * [VMware 公開了計劃成為云操作系統](http://gigaom.com/cloud/vmware-exposes-its-plans-to-be-the-os-for-the-cloud)-另一種基礎架構選項。 * [羅得島巨像](http://en.wikipedia.org/wiki/Colossus_of_Rhodes)-世界奇觀。 * [Colossus Computer](http://en.wikipedia.org/wiki/Colossus_computer) -英國密碼破解者使用的電子計算設備,用于在第二次世界大戰期間幫助讀取加密的德語消息。 他們使用真空管(熱電子閥)進行計算。 * [巨像:Forbin 項目](http://en.wikipedia.org/wiki/Colossus:_The_Forbin_Project)-一部名為 Colossus 的大型美國防御計算機的科幻電影,引起了人們的注意并決定接管世界。 * 這篇文章[關于黑客新聞](http://news.ycombinator.com/item?id=2758177) * 這篇文章[在 Reddit 上](http://www.reddit.com/r/programming/comments/iod09/google_is_built_using_tools_you_can_use_too/) * [OpenGSE 發布](http://google-opensource.blogspot.com/2009/01/opengse-released.html)-*開放源代碼愛好者可能感興趣的是最近發布的 Open Google Servlet Engine(OpenGSE)。 以前,Google 內的工程師開發了自己的快速,輕量級的 servlet 引擎,我們在 Google 內部將其簡稱為“ Google Servlet 引擎”或 GSE。* * 在 Quora 上: *[谷歌的軟件基礎設施是否已過時?](http://www.quora.com/Google/Is-Googles-software-infrastructure-obsolete)* TLDR:不。 Hector Yee 有一個很好的總結:*與開放源代碼變體相比,Google 基礎結構要穩定得多,而且文檔也要好得多。 他們作為一個整體工作在一起。 在 Google 框架中構建穩定,可大規模擴展的系統要比使用等效的開源工具容易得多。* 另一方面,采用定義的做事方式很容易對大公司施加的限制感到不滿。 這兩個觀點都是正確的。 * [jQuery vs 閉包](http://news.ycombinator.com/item?id=2758317)上的 nostrademons:基本上每個 Google 產品都使用閉包。 *沒有可比性-就網頁瀏覽量,邊緣情況和一般現實情況而言,Closure 比其他所有 JS 庫都得到更廣泛的使用。 我實際上認為他們填補了非常不同的領域。 JQuery 適用于主要是 HTML 但需要通過漸進增強而分層的其他交互功能的網站。 閉包適用于 JavaScript 應用,其中整個客戶端基本上都是用 JavaScript 編寫的。* * RyanDScott 在[上解釋了為什么 Google 內部沒有使用 GWT](http://news.ycombinator.com/item?id=2760822) :*閉包只是 JavaScript。 無需等待 GWT 團隊構建所需的功能,也無需自己構建這些功能。 以我的經驗,當我需要使用 GWT 進行最前沿的開發時,我最終為 JavaScript 函數編寫了一堆包裝程序,這使我想知道為什么我不使用 JavaScript 編寫所有內容。 (就像我說的那樣,GWT 庫非常引人注目,并且在計劃大型項目時,Java 對于某些人通常感覺更舒服。)* ## Related Articles * [從 Google+實驗中學習:Stowe Boyd 的操作系統,平臺,應用](http://www.stoweboyd.com/post/8129714757/learning-from-the-google-experiment-operating-system)。 *但是,我們正在邁向一個世界,在這個世界上,Google +的大多數基本元素將成為下一代 Android 版本的一部分,并且感覺像 Google+上的應用的東西實際上將是在未來的社交網站上運行的應用 操作系統。* 整個“前 Googler 認為您可以做得更好”的事情是如此虛假。 我在其他地方對此進行了評論,但是粗略地瀏覽一下他的主要批評就可以清楚地看出他對這些技術只有膚淺的知識: “與 MessagePack,JSON 和 Hadoop 相比,協議緩沖區,BigTable 和 MapReduce 都是古老的,吱吱作響的恐龍。與快速而優雅的工具(如 jQuery 和 mongoDB)相比,GWT,Closure 和 MegaStore 之類的新項目速度慢,設計過度,Leviathans” 真? 實際上,這幾乎都不是真的。 協議緩沖區和消息包在大小和效率方面幾乎相同,協議緩沖區的文檔更好,周圍有更強大的社區。 您不一定會知道,如果只是在 MessagePack 網站上做一個表象(無疑是作者所做的),但是如果您實際更深入地使用這些技術,他們的主張是完全虛假的。 JSON 與協議緩沖區? 好的,比較奇怪,但是首先 Google 到處都使用 J??SON-他們可能是世界上最大的 JSON 用戶。 協議緩沖區也比 JSON 小得多并且快得多。 Hadoop 與 BigTable? 真的,你要去那里嗎? Hadoop 的整個歷史是試圖在性能方面趕上 BigTable 并盡可能地復制 BigTable 功能以獲得功能之一。 Hadoop 的發展速度很快,但是我所看到的一切都表明 BigTable 的發展速度仍然更快。 它會一直持續下去。 閉包的壓縮比 JQuery 好得多。 最新版本的 JQuery 是否更快? 可能,但這與新的快速,優雅的工具相比,這簡直不是“ Leviathan”。 GWT 還執行*瀏覽器特定的構建*,這是 JQuery 無法觸及的,并使它的 JavaScript 變得更小,更快。 MongoDB 當然很酷,但是您真的要把它與 BigTable 相提并論,這是唯一有意義的比較? 真? 這甚至不是一條值得走的路。 無論如何,僅僅因為有人在 Google 工作過并不意味著您應該堅持自己的每一個字。 這也不意味著他們對 Google 的每個項目都有深入的了解。 在那兒找到工作要容易得多。 還存在編寫熱門文章的問題。 這家伙的文章提出了一些瘋狂的主張,旨在做到他們所做的一切:獲取鏈接。 這是總的 BS,你們應該對 High Scalability 有更好的了解。 認真地說,你們這里有一些殺手 articles,但您不應該鏈接到這樣的虛假信息。 請注意,我在這場戰斗中沒有狗。 我不在 Google 工作,但我直接使用了其中大多數技術,包括通過大量使用 App Engine 間接地使用了 BigTable。 亞當(Adam),很難想象有人在 Google 交付了一個重要的項目,但不值得他們對自己的經驗發表意見。 我們必須對此表示不同意見,但是我非常感謝您和您對這兩個堆棧的比較,非常有見地,謝謝。 真的很不錯,感謝您發布! 前端沒有 GWT 嗎? 是的,我已經在自己的 Google+上工作了。 我不會邀請任何人! 穆哈哈哈... 托德(Todd):作為“最早”出現在前五名站點中的人和作為仍在其市場中處于領先地位的類別站點的唯一啟動者,我建議您不要在您從中看到的“前-”觀點中投入過多的股票 我認為這些“觀點”沒有任何值得注意的見解。 *創造*改變游戲規則的技術和從稀薄空氣中獲得的技術之間的區別很大,而僅僅是在非常引人注目的平臺上展示和發布某些東西。 上面對“前 Google 員工”的反駁表明,事實勝過權威,而您現在可能已經發現,并不是每個“老朋友”都是天才 基于權威的論點,提議不聽某人大規模交付了復雜且極富創新性的產品,因為它與公認的權威沖突,這是一種令人愉快的策略。 做得好。 對不起,托德,但由于您已經形成了意見而拒絕接受這樣精心撰寫的批評/評論,同樣令人愉快(使用您的術語)。 從您對亞當評論的回應中,我認為您甚至都沒有讀過它。 我每天都使用 GWT,將 jQuery 與之比較是可笑的……只是舉一個例子。 我了解猛烈抨擊 Google 會產生網頁點擊量(IMO,這就是為什么這位前 Googler 的帖子得到博客作者如此廣泛的報道),并且批判性地分析優勢/劣勢始終是一件好事,但請保持客觀。 Sekhar,所以您認為我什至不應該鏈接到它? 如果您注意到我在帖子的內容上什么也沒說,只是質疑那些技術是否可以擴展。 批評甚至涉及到該職位。 那是你的錯嗎?
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看