在半個月前，Microsoft Connect 2015 大會上正式宣布 .NET Core / ASP.NET 5 正式推出 RC1. RC 代表開發已經到了準備 release 的階段 (RC: release candidate), 功能都已完備 (FF: feature freeze), 品質也到一定的階段，RC 推出後若沒碰到重大問題，那接下來應該就是 RTM 了。 若你擔心 Beta 跟最終的版本落差太大，而不願意太早投入了解 .NET Core 的話，那現在是個適合的時間點了! 這次除了版本進展到 RC1 之外，Microsoft 除了在 Docker Hub 釋出了新版的 image 之外，也推出了另一個新的命令列工具集: DOTNET CLI, 同樣也提供 Docker Container 的 Image 可以使用。 原本開始研究… Read more »
網站架構調整後有感: 要學習另一個陣營的技術，還真是條不歸路，越挖越覺得要摸索的東西越多 @@ 照例前面先來點碎碎念，正題後面再來。這年頭，大型的佈署是少不了 Linux + OpenSource Solution 的，再加上我吃飯的傢伙 ASP.NET 的下一版 (vNext, .NET Core) 也要正式跨各種平台了，不熟悉一下 Linux 以後怎麼會有能力把寫出來的 code 搬到 Linux 上面執行? 不過，要跨到完全另一個生態體系的環境，還真要下點決心才跨得過去… 所幸，我挑對了切入點 (把自己的 BLOG 從 BlogEngine 轉移到 WordPress, 架設在 NAS + DOCKER 環境)，這幾個月下來，也算累積了不少的心得 😀 要在 Linux 的世界裡打滾，最痛苦的就是安裝各種軟體了，只能說那真是地獄… @@，尤其是對於不熟 Linux 的人來說更是如此。現在有各種套件安裝的工具，向是 APT-GET 之類的，其實已經簡化很多了，但是難的在後頭，各種的 configuration 都要自己編 conf 檔，而每套系統用的語法都不一樣… 我不論是在 Coding 或是… Read more »
![Wordpress-start-image[1]](http://columns.chicken-house.net/wp-content/uploads/2015/11/Wordpress-start-image1-176x176.jpg)
前情提要: 起因很簡單，上個月才把我的 BLOG 從 BlogEngine 轉移到 WordPress… 這種轉換系統一定會碰到的問題，就是新舊系統的 URL 格式一定不一樣的，不過好不容易累積起一些文章連結 (別人連到我的文章) 不處理的話，這些連結就失效了。算算文章數量，約 400 篇.. 統計一下每篇文章可能連到的格式，有 6 種，若不放掉每個連結，則有 400 x 6 = 2400 個連結要轉換.. 究竟，在 Apache 做這麼多網址轉換的動作，怎樣才是最理想的方法? 這就是這篇文章想探討的… 讓我們繼續看下去 😀 到底有多少舊網址要轉換? 人家說做事要講究事實，開始動工前，先來了解一下到底有哪些情況需要轉址? 我之前用的 Blog 系統是 ASP.NET 寫的 BlogEngine 1.6, 算是老字號的 .NET 部落格了，先從我知道的開始: 預設的格式: 最基本的格式，按照日期 (年/月/日) 後面加上編碼過的文章標題。用我最常被引用的這篇當例子，像這樣: http://columns.chicken-house.net/post/2008/07/10/GoodProgrammer1.aspx (這是第一類) 不過，不知哪個版本開始，多了… Read more »
繼上一篇講完我落落長的研究過程後，這篇補上昨天想寫最後卻沒加進去的內容，就是一樣的動作改用我自己的 NAS 所提供的 Docker 環境來做 (官網)。試過之後只有一個感想… 果然買現成的實在輕鬆太多了 XD，如果不是很在意效能，只是想有個環境驗證看看，想避開整套 Linux 從無到有的 setup 過程的人可以試看看! 廢話上一篇都講過了，直接進入主題.. 這步驟跟昨天的比起來，實在是簡單太多了，這篇改一改就變成葉佩雯了，以後寫 ASPNET5 的人應該都去買台 NAS 才對… 不知以後會不會有 Visual Studio + NAS 同捆包? XD 以下是 step by step 的步驟: 開發環境準備: Core CLR 版 “Hello World !” 開啟 Visual Studio 2015, 新增專案。這邊要留意的是專案類型，不知 RTM 後會不會改.. 我是找 Visual C# / Web /… Read more »
Microsoft 官方宣布能在 Linux 上面運行 .NET (v5) 應用程式.. 其實這已經不是什麼新聞了，去年 Microsoft TechEd 2014 North America 就正式的發布這個消息了，不過因為種種原因，去年看到這新聞的時候，只停留在 “看看” 的階段而已，直到現在時機成熟了才開始動手研究。一來是因為官方的開發工具 Visual Studio 2015 已經 RTM 了 (這麼大的軟體，實在不大想安裝 preview 版本).. 二來 Docker 用的很高興，NAS / Ubuntu Server 也都已經準備好，執行環境我也上手了.. 萬事俱備只欠東風，於是今天就趁周末，把 .NET Core 版的 “Hello World” 丟到 Docker 裡面執行的任務給搞定了 😀 Microsoft 自從新任 CEO Satya Nadella 上任後，宣布了一連串改變，我覺得對未來影響最大的就是 .NET Open… Read more »
原本只是想在 NAS 上簡單玩玩 Docker, 為了接下來的 ASP.NET 5 做準備.. 不過實在太好用，還沒開始做正事 (ASP.NET 5), 就先把原本的 BLOG 從 GoDaddy 的 hosting 搬回來放 NAS 了，順手也架了 reverse proxy … 現在 NAS Docker 有正式用途了, 而 NAS 的運算能力又很有限 (我的是 DS-412+, CPU 只是 atom d2700, 雙核而已, 1GB RAM), 裝沒幾個就跑開始擔心了，於是就開始想另外搞一個可以隨便玩得 docker engine 環境.. 其實 PC 上弄個 VM 是很容易啦，windows 10 內建的… Read more »
前言: 先讓我講一點前情提要 XD，想看安裝步驟的請自己跳到後面… 在買這台 NAS 之前 (Synology DS-412+), 我是自己在家裡弄了台 PC, 裝了一堆硬碟充當個人用 file server, 同時順便在裡面架了自己常用的網站，包含這部落格的前身 (BlogEngine)，還有自己用的 Visual SVN, 另外也架了 Linux VM 裝 Redmine 等等其他的東西.. 後來 PC 開始不聽話了，開始三不五時當機，心一橫，兩年多前就買了台 4Bays NAS 把 Server 換掉，頓時輕鬆許多… 只是 NAS 不比 Server, 慣用 Windows Server 的我一時找不到替代品，這些服務就一個一個搬家了。其中最重要的 BLOG，就搬到 GoDaddy 的免費 web hosting (有 IIS)，繼續在上面掛著.. 用過 Synology NAS 的大概都知道，它的特色就是… Read more »
原本只是很單純的把大型檔案 (100mb 左右的 video) 放到 Azure Storage 的 BLOB 而已，結果效能一直不如預期般的理想。才又把過去的 thread 技巧搬出來用，結果又花了點時間改寫，用 async / await 的效果還更漂亮一點，於是就多了這篇文章 😀 其實這次要處理的問題很單純，就是 WEB 要從 Azure Storage Blob 讀取大型檔案，處理前端的認證授權之後，將檔案做編碼處理後直接從 Response 輸出。主要要解決的問題是效能過於糟糕… 透過層層的處理，效能 (3.5 Mbps) 跟直接從 Azure Storage 取得檔案 (7.3 Mbps) 相比只剩一半左右.. 過程中監控過 SERVER 的 CPU，頻寬等等，看來這些都不是效能的瓶頸。 為了簡化問題，我另外寫了個簡單的 Sample Code, 來呈現這問題。最後找出來的原因是，程式碼就是單純的跑 while loop, 不斷的把檔案內容讀進 buffer… Read more »
上篇花了一堆口水，說明各種 data layer 的設計方式，這回不噴口水了，直接來實作…。開始前先說明一下我的期望，我先假設各位都用過 Entity Framework 或是這類的 solution, 我希望在 data context 這層，就能處理掉所有隔離 tenancy data 的問題，也就是我可以用一般 application 的開發概念來開發 multi-tenancy 的 application。換另一個說法，我希望在一個 storage 內，模擬出讓每個 tenancy 都有獨立的 storage 可運用的介面。 Web 的這部份也是一樣的概念，我希望在網址這層，邏輯上就讓每個 tenancy 有獨立的 URL (虛擬目錄)。有這種網址上自行客製的需求，當然是非 MVC 不可，因此這次會在 MVC 的 Routing 上動手腳，除了 controller 及 action 之外，能夠再切出一層 client 出來，讓 application 也像是能夠虛擬化一樣，每個用戶可擁有自己的 partition。 最後當然也希望 WEB… Read more »
其實上一篇設計概念還沒寫完，只不過很晚了想睡覺就先貼了，本篇繼續.. 之前介紹 MSDN 的那篇文章，作者很精確的分析了資料層面的三種設計方式。不過仔細研究之後，真正能搬上台面的，也只有最後一種 “Shared Schema” 而已。我從系統實際運作的角度，來分別考量這三種方式的可行性，各位就知道我為何這樣說了..。上篇介紹了各種可行的方案，這篇則會說明我認為的最佳方案。 我的看法很簡單，除非你的 Multi-Tenancy 的 “Tenancy” 規模只有幾十個的數量，否則 Separated DB / Separated Schema 都不適用，因為這兩種方式都是依賴把資料放在不同的 DB 或是 TABLE，來達到隔離的目的。並不是說這樣不好，而是這些都是 “過渡” 的作法，讓傳統的 application 不需要大符修改就能化身變為 Multi-Tenancy 的應用系統。而且 database / table 的數量都是有限制的，無法無限制的擴張。同時，以系統設計的角度來看，在系統執行的過程中，動態去建立 DB 或是建立 TABLE 也不是個很好的作法，在我眼裡都會覺的這是禁忌 XD。 當你辛辛苦苦建立了 SaaS 服務，總不可能只服務兩三隻小貓吧? 因此下列的分析會用使用量及 DB 各種功能的理論上限來做簡單的評估。Multi-Tenancy 的用戶數量，就抓個 50000 好了，至於每個用戶的 profile 我也依過去的經驗大致預估看看。依這些假設，就可以來評估各種資料層的處理方式，會有啥問題。 以下是一般的應用，每個用戶需要的資料規模 (假設):… Read more »