EZTABLE IDEAS 是 EZTABLE 成員揮灑熱情和大家分享專業及創意的網誌。 EZTABLE 讓消費者 24 小時都可以在網路訂位全台灣最優質的餐廳,同時提供餐廳經營者 e 化的訂位管理系統 (雲端、iPad、智慧型手機)

【Workshop】EZTABLE System Architecture/EZTABLE系統架構

七月 24 2014 Published by under Engineering, 經營兩三事

 【Workshop@140718】

Topic: EZTABLE System Architecture/EZTABLE系統架構
Speaker: Hao-Kang 
slideshare: EZTABLE System Architecture

 

 

EZTABLE 2008創立至今,系統上經過許多的轉換與修改,
今天請到Hao-Kang 來和大家分享EZTABLE 至今的系統架構以及未來的一些方向。

 2-2-CAM03004

  

 

EZTABLE System Architecture

 

Long long Ago

以前的EZTABLE 是以PHP技術起家的。
當時,肥大的Kernel是PHP,和Database和worker,而web以PHP和JavaScript撰寫。

 

 

投影片3

Status Quo

現在這個階段多了許多不同層級的app,這些app會去跟PHP要Data,但是目前發現這樣copy來copy去實在太麻煩了,每個APP要的資料結構不一樣,要的欄位不一樣,這將會導致Kernel整個肥大,可稱作一坨"hairball"的狀況,意思是每個資料格式不一樣,同時又並需包括完全部的可能性。

 

 

 投影片4

巨人」──就是肥大的Kernel,累積了每個人不同的要求。

 

 

 投影片5
 

The future

想法: 我們稍為把它切開來。
若我們可以針對每個application、每個team,讓它去做小小的 node.js service時,這時候當你需要做新的API,只要自己開即可。

 

優點: 我們將不用管你是用node.js寫、go寫、Lua寫、PHP寫,寫的語言依照你們自己的team決定。

 

切出來後你會感覺到你和Kernel的溝通是透過Server 溝通,APP不用直接去找Kernel, reformatting要怎麼build 是你家的事(當然還是要做 local ache)。你會覺得 Kernel被切成像是第三方的service (backed service, message service, 訂位service等等),你可以選擇自己想要做什麼東西,只要你記得把小小的server 和小小的APP一起傳上來就行。

 
 
 
 
 投影片6
這便是 MV* 系列的概念(MVC or MVVM等)
不論是哪一種,所有的值都長一樣,Model和View,中間是transformation。
(Model是Kernel, View是mobile/web)
 
 
 

transformation

transformation概念很簡單
我們server kernel會吐一個小小的data給各位的server,當server transform 各位的APP要的資料的時候,就跟小叮噹一樣一個Data走進去一個transformation變成另外一個樣子。

5-5-CAM03014投影片7

所以Data經過一個function變成另一個Data。
Data → (transformation) → Data*
y = f(x)

 7-7-CAM03016 投影片8

transformation能做的可分成四個部分: Combine, Filter, Split, Recorder.

 

  • Combine
    舉例來說:
    我不只要拿一間餐廳,還要餐廳相關的評論,以前的做法就是去找channel說: 欸channel,我要餐廳資訊然後順便把評論一起給我,通常這樣的方法要等一個月!
    而現在你小小的server可以去抓你的APP和你餐廳的IP,以及自己去拉餐廳的資料(A),自己去複製write’s API去拿相關的評論(B)  ,最後再把兩個Combine起來(C)推出去,這樣的方法大約需要一天的時間,而且不需要DEMO
  • Split
    反之,如果你覺得太大包傳輸很慢,便把它分成你所需要的幾包即可。
  • Filter
    當你要做特別的Filter,像是Filter by餐廳、Filter  by菜單、Filter  by地區,
    只需在自己Channel裡的server自己做。
  • Recorder
    要照什麼樣的排序,依自己的需求決定。

  

 

Rule of Thumb

  • event-driven : 盡量可能用event算。
  • autonomy: 每一個小小的service盡量去保持它的autonomy(自治),不要直接去讀SQL、讀人家的DB,而是透過API等方法溝通。
  • clear boundary: 有非常非常清楚的界限劃分,做屬於自己的事情,不和其他不相干的攪和在一起。
  • local cache:  不要每次一個小小的server 都去做 Kernel Combine,你可以直接一個local端把cache寫好,便可以大量使用local cache 節省時間。
 
 

Summary

因為經過這樣一系列的切割,
各種的view不再需要直接與Kernel溝通,而是保有獨立自主可自行運用修改的空間,
同時view彼此間將不用擔心互相干擾而引申出的許多問題,
也因為有了local cache,減少了從Kernel挖資料時的等待時間,更迅速的取得需求,
瘦身成功的Kernel,跟以往肥大的時候相比,負擔變小,變得更輕便,更專業,更有效率!

 

 

 


 

如果您喜歡這篇文章可以點擊「讚」&「分享」
並歡迎訂閱EZTABLE IDEAS!  😀 

如果你是學習力強,而且經驗值高的人才,
歡迎一起加入我們 EZTABLE!! 

EZTABLE at Linkedin-Senior Mobile Software Engineer


Related Posts Plugin for WordPress, Blogger...

No responses yet

發表迴響