剛開始並沒有預期是使用微服務。
在不斷調整的過程, 以及閱讀他人的想法後, 瞭解自己所處的位置。
推敲起來, 像是在一個只有筷子的用餐環境下, 自然會去使用。雖然不是刻意, 終究殊途同歸的結果。
主題是替某個研究單位打造內部資訊系統, 將目標和資源透明化的專案管理工具。
開始打工, 指定 M 社的 CMS 方案
團隊成立, 有不少角色, 大家都在熟悉中。
照傳統的方式進行訪談, 分析, 設計, 實作, …
光是資料表就討論大半年, 畢竟這是全部的人都認識, 總能談上兩句。
在 M 社工具(SD/IP/SM/VS四樣)加持, 歷經一番波折後完成。
工具多, 卻有各自的假設。在預給情境下, 拖拉點貼就解決。
然而, 經常面對的是一堵堵高牆, 愉快的滑鼠生涯了結, 開始耕碼長征之路。
在 API 叢林穿梭; 也在系統間徘徊。
幸好有許多第三方元件支持, 第一版得以面世。
棘手的問題在於, 冗長的開發到結果, 是一大包(monolith)。
縱使 M 社兵多將廣, 面對複雜的環境, 提供更多工具, 卻更令人左支右絀, 疲於奔命。即使變更一小處字樣, 從修改到配置, 不僅耗工夫, 也費時間。
如果偏好階級化流程, 有一大撮團隊, 絕對可讓大家都很忙, 每個人都有事情做。
因地制宜, 替系統加一層殼(Shell)
當時領域探索的人多, 需求也多; 然而隨時間推衍, 變化也多。
按官方手法實作, 必定成為瓶頸。
為了將 需求 到 實作 的距離拉近, 借鏡 Unix, 在應用系統上加一層 Shell。作業系統的 Shell 通常是一個互動環境, 但在應用系統有不同呈現方式。例如要修改已有的網頁, 用 jQuery 一般比手工刻 JaveScript 好。存取複雜的資料, 透過 ORM 常不如 SQL 直接。而以框架為底、API/程式庫為輔、使用工具打造的應用, 也的敵不過腳本(Script)靈活。
這個案例是有工具負責資料綱目, 流程/表單, 並用 C# 做擴充。
最後維持資料綱目, 保留表單, 改為事件驅動(Event driven), 基本上利用 Powershell Script 在表單變化時更新資料庫, 同時擔任流程處理與擴充功能的任務。 對使用者的結果不變, 但流程的反應較好(原本頓頓的); 擺脫工具大包的束縛, 更快滿足需求。
從結果來看, 這個技巧是讓需求到方案的流動, 透過新搭建的 Shell, 約 80% 可快速流過; 縱使還有 20% 得經傳統工具, 由於毋需經常打交道, 阻礙自然較低。
持續開發, 逐步擴展, 遞加服務
完成第二階段, 系統表現稱職, 跑出新題目 … 建立 TLD 服務。兩個子系統 bind/whois 包含 server 和 DB 在 Linux, 使用者介面被期望繼續在 M 社的 SP 上。一般性應用的開發, 會將 DB 連線拉到 SP, 解決跨系統、跨設備的問題。但我們以系統安全的角度, 選擇用訊息傳遞(messaging)來解決, 順勢引入 python 的網路服務引擎 twisted。
隨著系統擴展, 在 2014 的某個階段, 決定後端服務皆用 twisted。
這個決定點在於, 綜使之前做了簡化, 但開發的元件散落在各子系統上。加上原廠的方案, 檔案幾乎都是 binary 或是一大串, 版本控管有麻煩, 再在使變更困難或成本驟增。
所以把在各子系統做的, 除 UI, 權限管理外, 將通訊處理(protocol)、編組/解組(marshalling / unmarshalling)、資料存取、子系統溝通(REST 或 Web Services) … 分層(layered)後做成 twisted 的服務, 全部處理都訊息化, 包含檔案上/下傳。
這些順勢做的改變, 後來對照 microserivces 的要件, 很多地方相似, 甚至一致。
最明顯的好處是在面對人力多樣化, 經歷過: 原班的開發人員, 甲方組織的員工, 以及最後加入的外包單位。自己組員問題少, 甲方組織要投入前, 備妥環境著實不易, 後來用簡化的虛擬機器(做成 VM), 讓人入手。 到了外包單位加入, 已經有新的架構, 只要把 python 環境建立(難度大概只有 1/20 吧?), 加上源碼儲存庫, 按著符合情境腳本(Scenario)的 nose 測試碼, 就可開拓新的道路。不論開源工具帶來的好處, 新的方式讓開發者在特定區塊(Bounded context)就可完工, 是差異所在。
按照目前狀況, 應用系統想組合/分散功能, 更換子系統, 包含資料庫與文件管理(DMS), 甚至作業系統(docker?), 都變成策略面的考量, 不會因為技術造成障礙, 或讓開發好的應用鎖在某個地方。嗯, 是鎖在 python 上沒錯, 不過還有幾個選擇 …。
(待續)
