跳到主要內容

文章

館長的網站技術瓶頸,小弟弟來解答 - notorious-2019.com

館長的網站技術瓶頸,小弟弟來解答 - notorious-2019.com昨天看到館長的網站倒了,也看到館長說一個月花費大概一百萬左右的月費在支持這個架設的電商網站,也對外發布出來訊息,希望求救,直接講結論建議解法,1. 首先要做的事情是讓整個網站可以橫向擴展 (Load Balancer + n 台伺服器),對,相信我,IIS 也是可以做 Scale out, 這是對於 Application layer 服務的解法。2. 資料的部分 SQL 吞吐量,建議改成 GCP Cloud SQL, 或者就直接轉到 Azure SQL Server 環境上會相對容易解決 SQL 的問題。上述 2 個步驟都處理完,其實 100 萬的費用,應該 20000 concurrent user 是沒有問題的,但前提是要設定『對』!額外需要花較長期時間要處理的,建議就是在 Queue 的處理,購物車的狀態都可以進入到 Queue 再來處理 SQL insert 的問題,減少不斷的 insert / update 的狀態,後文會提到 ...底下詳細的會再說明如何後後續還有哪些處理的細節。這兩天剛好有個小空擋,就來分析一下狀況,可以從外部讀取得到的服務大致上如下,ASP.Net: 4.0IIS 10 + Windows (廢話)SQL Server (推測)OP Service: PleskWinHost: Google CloudDNS: Cloudflare前端服務內容架構Server-side render, jQuery base, 推測有可能採用現成購物車來進行,看起來不太像是用 wooCommerce 比較像是 Cart Functionality 這類的項目直接搭建而成(當然這純屬猜測)功能拆解因為網站是透過 Server site render 所有頁面都需要重新透過伺服器進行載入,這樣的狀況,如果在頻繁忙碌的 eCommerce 網站架構下會是一個致命傷,簡單來說,數量的查詢,特惠價,優惠碼等等資訊的處理,使用者每做一步都需要重新跳轉頁面,或者整頁面重新讀取,只是為了部分的資料更新,這些都可以抽取出來成為 API ,透過 AJAX 的方式進行讀取。讀寫分離在不了解目前資料庫複雜狀態下,首先要讓所有人都可以讀取到資料,頁面可以跑出來,建議至少將讀取資料庫,和寫入資料庫的…
最近的文章

LINE Ads Platform 演進史,魔鬼藏在細節中

LINE Developer Day 2019 有一場 Session 讓自己一定要參加一下,LINE Ads platform revolution。 https://speakerdeck.com/line_devday2019/how-line-ads-platform-is-constantly-evolving Ads Platform 對於大部分的人來說,這可能是一個最熟悉的陌生人,對於電商平台以及眾多需要曝光的使用者來說, Ads 的來臨讓各位迎來曙光。 最直接的例子莫過於 Facebook 廣告投遞,簡單來說, 投標 -> 快曝光 (給錢) -> 轉換 -> 達到目標 但是,最重要的就是這個 BUT , 投標與曝光之間有許多事情需要進行。 數位廣告已經脫離一刊 100 元的年代許久(雖然許多公司還是用這樣的概念在做事情),但實際上的概念是, 投標 -> 達到標地 -> 投遞 -> 投遞總量 * 投標金額 / 目標轉換 當此數字出來時,才會是大家所期待看到 100 元 / Click (或者任何轉換) 的計算金額。 聰明的各位肯定有想到了,這樣最簡單的方式,其實並不是告訴大家要投標多少,而是從使用者希望的轉換的預期金額,來進行回推投標金額。 因此還是一樣的概念,投標數字越高,就可以越快達到標,簡單來說就是, 如果有 100 元達不到的事情,那就 200 元,如果再不行就 ...

新鮮人的迷惘不只你有,我也有之Web GangKu 網站甘苦談 02 活動紀錄

Web GangKu 網站甘苦談 02 活動紀錄 參與者:
Ted, Wake, 振壹, Chris and Me 地點:
桃園 Ice Honey 帕米亞甜點 原本預期是一場不會有人,到當天從 22:00 - 直到 02:00 才結束的一場活動,人數雖然少,卻因為這樣小巧的場合讓大家可以暢所欲言,了解業界動態,還有互相交流一些不同的心得。 感觸最多的在於轉職和求職的迷惑過程,自己其實在早期也是這樣迷惘的過程中,不知道自己要的是什麼,雖然說知道自己對於寫程式有些小小興趣,但是對於實際上要往哪條道路走其實還是充滿了疑惑。 看到這些小朋友,彷彿看到十年前的自己,在求職的十字路口徘徊,這些過程沒有一定的步驟,也沒有最佳的解答,充滿的就是一路的探索與衝撞。 在十年前也沒有人知道前端工程師接下來的 Career path 會是什麼,甚至沒有人知道 mobile web, desktop ui, TV 都會是可以讓 Web front end developer 進攻的天下,甚至當時也沒有人預測到 Node.js 的崛起可以讓前端工程師瞬間成為全端工程師,有太多太多的未知與不確定性。 但有件事情是肯定的,找到自己所喜愛,把握當下自己的所愛,這樣的生活才會讓自己的人生更精彩, 希望我們的 Web GangKu 網站甘苦談 ,也是號稱深夜大人咖啡館的深夜小聚會,能夠有一些小小分享。 如果喜歡的話,歡迎透過底下追蹤消息,Web GangKu 網站甘苦談 活動 將會繼續推出(畢竟 Ted 大大都先放酒在這邊了), Caesar Chi (@clonncd) | Twitter熱血老漢仔 - 首頁 | FacebookCaesar Chi | Facebook

2016 - 2019 LINE DEV DAY 技術發展

從 2016 年 LINE 開始舉辦 DEV Day 活動至今,已經進入到第四個年頭,每一年都有不同的重頭戲,也讓我們第一次看到了 LINE 這樣亞洲公司在亞洲地區打造出屬於亞太地區專屬於自己品牌的技術形象。 簡易年度記錄 2016 年,LINE 發表了 Chatbot 以及 Open 技術的策略,從那時候開始發表了 armeria 開源技術框架,持續發展至今。 同時當年每個會眾可以拿到一組 LINE Beacon 官方版本,開始了初步 IoT 的佈局。 2017 年,發表了 Clova 項目,以及更多關於 Iot 相關的展示,關於物的連結上,以及對於 Data 上架構的展示,也算是開始進如 Messenge API 調整的一年。 2018 年,建立 LAE 制度,深度開始與開發者進行合作,進行 DevRel 相關,這年 FinTech 大戰開始,同時發表對於 AI 實現於應用上的展示,更值得一提的是 LIFF 的開發與發表。 2019 年,可以說是 AI 年,基本上所有的項目圍繞於 AI 打轉,秉持著原有架構,服務,產品多樣性之餘,已經在這幾年默默的深入到台灣的生活中,大家默默的用著 Chat, 看著 Line News, 用著 Line pay付款買貼圖等。 關於 LINE Dev Day 2019 有更多深入討論。 轉變 2019 年,對於自己來說,是個感覺很深的一年,彷彿經過了再次世代的更替。 從 2012 時所討論的 Cloud System, 當時的討論更多的是在於當地自建機房,還是直接使用雲端服務,從 AWS 服務獨大,到 GCP 深入開發者心中,Azure 當初最不被看好,居然真的擁抱 Open source 在 dotNet core 組合下打下一片天。 2015 年開始,雲端不再是口號,Data 才是王道,到處喊著使用 hadoop ,衝著分散式運算大資料量儲存分析,每個新創都是喊著 Cloud x Data 廝殺著。 2017 年進入 Iot 年代,物物都要聯網,事事都要上網,當時看似傻傻的連冰箱都要上網,到現在似乎已經變成顯學,甚至當年喊著

npm i fail - 查不出原因的處理方式

npm i fail - 查不出原因的處理方式經歷許多次的 npm 安裝問題,目前有幾種不同的解法。npm cache issue可能因為 npm 下載的時候,或者因為連線問題導致模組並沒有完整被安裝,但是 npm 的檢查機制就是只要存在就會跳過安裝步驟,因此當遇到安裝完成,但是執行卻無法的時候,可以嘗試著rm -rf node_modules # install again npm i 如果是在中間就遇到 fail 的狀態,有可能是因為之前連線問題,並沒有將模組安裝成功,但是資料已經存在 npm cache 資料夾裡面,以往都需要找出這個環境設定,環境路徑才能進行移除,不過現在透過 npm cache 可以簡單做到這件事情npm cache clean rm -rf node_modules npm i npm version issue另外一種會再安裝的時候跳出錯誤,會顯示為 npm 版本不符合,或者是 node 版本不符合,這個時候就需要進行安裝更新,最簡單方式就是升級 npm.npm i -g npm 缺少套件通常最常見的就是有些模組需要透過 gcc, g++ 這是最常見的缺少模組問題,以 mac 環境來說直接透過 brew 就可以安裝完成。brew install gcc brew install g++ # install again npm i 記憶體不足最後一種就是屬於記憶體不足的狀態,這通常會很難檢查,實際上 npm 也會跳出錯誤,現在的錯誤資訊都已經比較明顯,npm ERR! node v4.4.1 npm ERR! npm v3.8.6 npm ERR! code ENOMEM npm ERR! errno ENOMEM npm ERR! syscall spawn npm ERR! spawn ENOMEM 如果遇到這種狀況,請重新調整記憶體分配,如果是採用 vps, 就看能不能夠 scale up ,讓機器的記憶體提升,就可以解決問題。後記以上都是踩過的雷,以及在嘗試許多 node.js 專案時會遇到的問題,我們也經常在摸索中,不過從摸索以及找到答案的過程都繞了許多遠路,希望透過分享可以讓大家更瞭解 npm 錯誤時可以怎麼處理。

JavaScript 物件中快速檢查屬性

JavaScript 物件中快速檢查屬性在我們一般使用 function 或者呼叫某些 api 的時候特別需要去驗證,某些值是否已經存在,或者使用者有沒有忘記傳入哪些數值進來。為了要做這件事情,通常我們會寫一堆 if 去判斷每個值有沒有出現問題。if(!formData.name){ return reject("Parameter 'name' is required"); } if(!formData.size){ return reject("Parameter 'size' is required"); } if(!formData.sizeUnit){ return reject("Parameter 'sizeUnit' is required"); } if(!formData.width){ return reject("Parameter 'width' is required"); } 實際上透過 lodash 可以讓這件事情非常快速完成。let _ = import 'lodash'; let result = _.has(object, ['name', 'size', 'sizeUnit', 'width']); if (result) return reject("Parameter is not correct"); 後記雖然說並不是太困難的程式,但是透過套件真的可以讓程式碼短少一點,讓我們程式透過 import / require 將模組載入,讓程式碼更短。short code is best code