分類
About Mike

回顧 2019 工作上的新學習

故事要先從防火牆說起,防火牆的設定說穿了就是一堆欄位去對應實體的機器,舉凡SDWAN、Data lose prevention 、Symmetric Routing等相關的網路功能都可以在實體機器上設定。

農曆新年剛過,祝福大家鼠年鈔票鼠不完(完全硬搭),近日剛好有些空檔回顧一下去年在工作上新的學習,雖然常抱怨大公司做事效率很差,但仔細回顧發現其實在技術上仍然有所精進,以此篇文章作為未來回首的索引。

畢業後開始做網站工程師做了將近8年,從小型官方形象網站到中型資料庫網站甚至是幾萬人在線的售票網;從後端撈資料的工程師到開API進而到網站部署、做快取、自然擴充(Auto scaling)到前端頁面美化特效(CSS, SCSS, JAVASCRIPT)、SPA(Single page application);從菜鳥工程師到人稱所謂資深工程師;網站開發相關的問題大大小小即便沒做過,大概也知道要怎麼解。

2019年7月從高速成長的新創公司換到了上市公司,每週要處理的bugs與features從數十個變成個位數個,數字上看起來好像很閒,其實也不然,因為大公司產品的規模大,不管是使用者人數、同時在線人數或者是程式碼(code base)本身都在一個相當高的量級,架構與組織的複雜度無法與新創比擬,同樣解一個bug的effort可能比新創高出許多,自然能解決的數量看起來就不那麼壯觀。

回到正題,目前服務的公司是做資安的,公司主力產品是一個防火牆,我們組負責的是防火牆的設定網站(portal)。聽到這裡應該覺得很無聊對吧!?不要懷疑,我跟我們組老闆(manager)聊過架構之前我也是這樣覺得,但加以理解後,才知道要處理的問題其實很有深度,甚至其他公司可能無法碰到這樣類似的問題。

工作職務上,我負責的部分除了前端UI外還包含了nodejs的middleware,某種程度來說也算是在做Full stack。

故事要先從防火牆說起,防火牆的設定說穿了就是一堆欄位去對應實體的機器,舉凡SDWAN、Data lose prevention 、Symmetric Routing等相關的網路功能都可以在實體機器上設定。那這樣的欄位一個防火墻有幾個?公司身為新一代的防火牆領先者,功能自然多到難以計算,相關能設定的欄位在數千的量級,那至於開發此portal網站的目標是什麼呢?是做出一個不管防火牆端新增了什麼欄位功能,網站端都可以自然生成對應的欄位介面。

認識schema

Schema基本上就是一個檔案紀錄了一台實體機器上的所有欄位。用網站工程師比較好了解的語言來說的話,可以把schema檔案想像成一個xml檔案,內容記載了所有欄位的屬性(attribute)與階層子母關係(parent child relationship)。每一次防火牆的更新都會有新的schema產生,可能多了欄位或是少了欄位或者是有什麼欄位做了更動。

舉例來說:(schema範例)

<?xml version=”1.0"?>
<sequence name=”config” forward-compatible=”no”>
  <sequence name=”demo-config” optional=”yes” xpath=”/config”>
  </sequence>
  <array name="users" optional="yes">
    <sequence name="entry" tlo="yes">
       <validate expr="not(@name='root')" err="'root' is a reserved name"/>
       <validate expr="not(@name='machine')" err="'machine' is a reserved name"/>
       <validate validator="not-system-user" err="it is a system user name"/>
       <attr-req name="name" type="string" regex="^[a-zA-Z0-9_.-]+$" maxlen="31" help-string="alphanumeric value">
         <validate uniquein="#users/entry/@name"/>
       </attr-req>
       <element name="phash" type="string" maxlen="63" optional="yes"/>
    </sequence>
  </array>
</sequence>

每次部署上線的流程如下:

雲端資料庫更新 (驅動)-> 防火牆機器schema更新 ->(客戶手動 可不更新)網站portal更新升級新版 ->Web UI 響應客戶安裝之版本

如上所述,我們的目標是要建立一個隨著schema響應的UI,所以和一般網站開發的邏輯稍微不同,市面上當然也沒有類似的框架可以拿來使用;當然我們也盡量避免自己造輪子,所以舊版的網站我們用Ext.js(如果有人聽過的話…)作為基底,新版網站我們用React.js做為基底,在此基底上自建我們的框架。

而資料流方面,由於公司客戶的使用人數都在極高的規格下,在整體網站效能上也需要特別留意,我們使用了Rx.js,此框架可以取消已發送的Ajax,此功能對於減少API loading幫助相當大,非常推薦給大型網站的開發者使用,一旦完全理解它能提供的功能與用途,大概就回不去了。

資料流:

DB data -> Global Redux store (dispatch action to make ajax call in rxjs to update state)-> local context component level data -> local fields data

UI:

Own UI library includes:

Widgets -> Builders -> Viewers

React router for routes -> page, component with schema and customized fields plus business logic -> import UI from own library to render

由於UI都是延伸自內部開發的library,所以整體的視覺表現也相同沒有問題,而關於全公司共用的元件像是header, sidebar之類的UI元件則是有microservices architecture 概念在裡頭,統一有別的部門開發而我們就像是安裝一個npm package一樣,按照文件檔撰寫程式。

架構大概敘述完成,非相關領域的應該很難咀嚼其中的硬道理,不過原則上就是記載一下新的學習。

希望年年都能新的學習,持續進步,COVID-19病毒早點結束。

作者: matrixki

Software Engineer / Entrepreneur / Dreamer

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *