• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            Fork me on GitHub
            隨筆 - 215  文章 - 13  trackbacks - 0
            <2017年5月>
            30123456
            78910111213
            14151617181920
            21222324252627
            28293031123
            45678910


            專注即時通訊及網游服務端編程
            ------------------------------------
            Openresty 官方模塊
            Openresty 標準模塊(Opm)
            Openresty 三方模塊
            ------------------------------------
            本博收藏大部分文章為轉載,并在文章開頭給出了原文出處,如有再轉,敬請保留相關信息,這是大家對原創作者勞動成果的自覺尊重!!如為您帶來不便,請于本博下留言,謝謝配合。

            常用鏈接

            留言簿(1)

            隨筆分類

            隨筆檔案

            相冊

            Awesome

            Blog

            Book

            GitHub

            Link

            搜索

            •  

            積分與排名

            • 積分 - 219201
            • 排名 - 117

            最新評論

            閱讀排行榜

             http://arksea.iteye.com/blog/2154673
                   08年開始接觸Erlang,組里正好來了一位Erlang專家--余峰同學(現在淘寶擔任核心系統資深技術專家,花名褚霸),在霸爺的大力傳教下,我立即就被Erlang的強大與優美迷住了。當時我正在為實現一個分布式語音服務集群頭痛,開發語言是C++,在需要跨界研究語音處理、語音傳輸的情況下,實在沒有精力去搞高性能高可靠的分布式網絡服務。
                    在霸爺的推薦下,我花了2周業余時間熟悉Erlang語言,就開始嘗試用她實現語音服務的通信層,三周時間,一個比原來花了2個月時間的C++版本性能更好、更可靠、真正分布式、可擴展,而且代碼量只有一半的服務端就完成了,經過一個月測試,再一個月完善就上線提供服務了,而那個粗糙的C++版本服務要實現相同的功能,沒個半年是不行的,而且還不一定穩定可靠。
                    同樣的場景,在為我廠開發分布式服務框架時(后面簡稱DSF),再次重現。DSF要為應用服務的高性能與高可靠提供可配置的路由策略與失敗處理策略,客戶端驅動的開發是重點中的重點,即使在我們將Thrift作為框架的RPC解決方案的前提下,仍然需要投入極大的精力與時間,更何況,還要求我們的驅動設計必須用Java和C#都能較容易的實現。
                    這時候,作為分布式服務系統中必不可少的應用注冊服務器,同時要進行開發,對于孤軍奮戰的我就顯得力不從心了。在我們的設計中,應用注冊服務器必須提供實時的服務狀態通知與分發能力,盡量讓不健康的服務的切除更加及時,而且,應用注冊服務器作為所有應用服務的基礎服務,其可靠性的重要也是毋庸置疑的。在這種情景下,Erlang再次成為我的救星與堅實的靠山,讓我敢于同時在DSF框架與與應用注冊服務的開發中雙線開戰。
                    應該說在整個的開發過程中,應用注冊服務器并沒有花費我太多時間,三周,一個真正的分布式無中心節點的高可靠服務雛形就此成型,其后只是零星的bug修改與功能補充了,這種力量來自哪里?還是Erlang!
                    經常有人問我,Erlang到底好在哪里?因為能力有限,對Erlang的了解僅限皮毛,專業的分析可以到霸爺的“Erlang非業余研究”找相關普及貼看看,我這里僅根據這幾年實踐說說自己的感受。
                    從技術上說,Erlang是一個平臺,她提供了一套完整的高性能、高可靠網絡服務開發所需要的基礎設施,并提供了原語給開發人員使用,她降低了開發類似系統的難度與門檻。有一個說法,Erlang讓一個中高級程序員,用一半的時間,一半的代碼量,就能提供頂尖C程序員開發的網絡服務80%性能的類似系統,并且可靠性不輸于甚至超過前者。我的實踐讓我確信,這是真的。
                    另一方面,Erlang也給了開發人員強大的自信,就如同前面開發DSF時的場景所述。有開發維護過線上系統的人應該可以深刻的感受到,開發一個高可靠的網絡服務有多困難,維護一個線上系統有多勞心,當一個服務上線時,我們的運維與程序員即使睡覺都恨不得睜著一只眼睛。
                    根據我的經驗,采用Erlang開發的系統,其出現的bug量與用常規語言開發的絕對不是一個數量級;Erlang的監控樹機制,更是讓我們的服務,天生就具備了高可靠的基因,只要稍花精力,仔細規劃我們的監控樹與重啟策略,就可以讓本來就少了很多的bug及一些無法預料的外部故障,在即使出現時也有很大的幾率迅速恢復,給你修復bug排除故障一個緩沖的時間,更何況,Erlang可是具備熱更新能力的,那真的可以讓你延壽啊!延壽!
                    如果你的老板問你,為什么要用Erlang,Erlang好在哪里,你可以這樣總結:省錢吶!你想想,一個資深的、頂尖的程序員與中高級普通程序員之間的成本差,普通的系統就只要普通的程序員就好啦,那不僅僅是省錢,是省很多很多的錢,這個回答,一定可以讓你的老板眼睛像手電筒一樣閃閃發光!
            posted on 2017-01-10 17:27 思月行云 閱讀(356) 評論(0)  編輯 收藏 引用 所屬分類: Erlang
            免费观看久久精彩视频| 亚洲Av无码国产情品久久| 婷婷久久香蕉五月综合加勒比 | 欧美喷潮久久久XXXXx| 精品久久一区二区三区| 亚洲国产成人久久精品99| 久久精品人人做人人爽97| 国产真实乱对白精彩久久| 无码日韩人妻精品久久蜜桃| 久久香蕉综合色一综合色88| 伊人久久大香线蕉AV一区二区| 国产国产成人精品久久| 国产午夜福利精品久久2021| 香蕉久久夜色精品升级完成| 久久99精品久久久久久水蜜桃 | 久久成人永久免费播放| 狠狠色综合网站久久久久久久高清| a高清免费毛片久久| 亚洲色婷婷综合久久| 人人狠狠综合久久亚洲高清| 伊人色综合久久| 久久久久国产日韩精品网站| 99久久精品免费| 69SEX久久精品国产麻豆| 久久午夜无码鲁丝片| 久久人人爽人人爽人人片av麻烦 | 99久久免费国产精品热| 久久久久亚洲精品天堂| 亚洲精品白浆高清久久久久久| 亚洲午夜久久久| 亚洲午夜福利精品久久| 婷婷久久综合| 偷窥少妇久久久久久久久| 久久精品亚洲日本波多野结衣| 久久99热这里只有精品66| 亚洲另类欧美综合久久图片区| 久久综合久久性久99毛片| 无码超乳爆乳中文字幕久久| 亚洲午夜久久久影院伊人| 久久久久亚洲AV片无码下载蜜桃| 日韩AV无码久久一区二区|