2015/06/01

打造微服務

剛開始並沒有預期是使用微服務。

在不斷調整的過程, 以及閱讀他人的想法後, 瞭解自己所處的位置。

推敲起來, 像是在一個只有筷子的用餐環境下, 自然會去使用。雖然不是刻意, 終究殊途同歸的結果。

主題是替某個研究單位打造內部資訊系統, 將目標和資源透明化的專案管理工具。

開始打工, 指定 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 上沒錯, 不過還有幾個選擇 …。

(待續)

2012/12/09

PDF Forms

近來關注著表單的相關方案, 除了 Web(眾多框架, backbone-forms), XML(XForms, InfoPath, XUL) … 前陣子逛軟體商店, 才發現有處理 PDF 表單這類 App。

搜尋相關資源, 整理一下 …

雖然系出 Adobe, 卻也不一定需要 Adobe 官方指定工具, 就能從頭到尾、從建立到處理, 完成所有工作。

特點

和 Web, XML 方案要一整個系統最大的差別, 在於 PDF 的表單只要單檔就可運作。

1. 方便移動

PDF 表單除了只要單檔, 和 PDF 一樣, 不論行動設備或各種常見的作業系統都通行。

在 OS X 上的 Preview 可直接填寫。

另一個觀點是能離線作業 … 得以各別填妥表單再傳送處理。

2. 容易讀取

不論對人與電腦都方便。

PDF 可輸出的樣式彈性很大, 幾乎是報表方案的代名詞。好讀自然不再話下, 只要有適當的設計規劃。再加上一些欄位就成為 PDF Forms, 立即讓人填寫。

讀取表單內容, 可利用 pdftk 直接讀出資料, 毋須寫程式也可使用 … 在下一段介紹用法。

實作

很多介紹, 是以寫程式來產生 PDF 表單, 後續處理表單資料也要額外程式 … 其實不一定需要, 這些工作不寫程式也能達成。

1. 建立表單 PDF Forms

在 OS X 有 PDFpenPro, PDFClerk Pro, PDF Nomad 可替 PDF 加上表單欄位。

開放源碼 OpenOffice(使用版本 3.4.1), 則可在各平台直接建立 PDF 表單。步驟大致如下:

a. 新增 XML 表單

11 New XML Form

b. 建立表單項目

在下面的範例, 塞一張圖檔、加一些欄位, 額外使用淡紅色標示欄位名稱

12 Construct Form

建妥表單, 再到下一步。

c. 輸出 PDF 表單

13 Export PDF

d. PDF 表單選項

14 Export PDF Options

e. PDF 表單檔名

15 Export PDF Filename

完成以上步驟, 應該能順利產生 PDF 表單: fruit_order.pdf 檔案。

下載: fruit_order.odt(無法預覽, 請選擇下載), fruit_order.pdf(線上看有點怪, 下載後 ok)。

2. 取出資料

a. 填寫表單資料

使用 Preview 按上面 PDF 表單給定欄位, 填入各項資料。

21 Fill PDF

填入的資料會存入該 pdf 檔案中。

b. 讀取表單資料

使用 pdftk, 如果檔案放在 ~/Desktop/fruit_order.pdf, 執行如下指令:

$ pdftk ~/Desktop/fruit_order.pdf dump_data_fields_utf8 output -

就可將表單資料輸出到 stdout, 或把 - 改為檔名, 選擇輸出到特定檔案。

22 Use pdftk

和先前 b. 建立表單項目 步驟比較, 可看出 欄位名稱 (FieldName) 和 填寫資料 (FieldValue) … 很容易對上。

3. 佈置 PDF 表單

從上面的介紹, 瞭解 PDF 表單 建立, 填寫, 讀取 方式, 接下來看看怎麼安置這些 PDF 表單檔案。

a. 電子郵件

PDF 放在網站上提供下載, 或以電子郵件傳給需要填表單的人。

在 PDF 表單裡頭標注, 填寫完寄給 foo@jia-side.org … 即可完成表單發送、接收的程序。

只是收到 PDF 檔案後會怎樣被處理, 全取決於經辦人員。

b. 檔案分享

適合組織內區域網路中檔案共享, 或使用網際網路檔案服務的方式 … 也就是特定群組內的檔案分享。

在檔案相關系統中, 安排 PDF 表格處理方式的各種目錄。例如: 所有表單的 樣板目錄, 處理中目錄, 完成目錄, 以及最後流入按年份分門別類的 庫存目錄, …

使用大部份人都熟悉的方式, 不同工作在不同目錄間流動, 即可完成許多原先紙本的工作。

c. 內容管理 + 流程系統

基本上, 是前個項目 b. 檔案分享 的進階版 … 概念相同, 但所有動作自動化。

  • 樣板目錄 中, 各表單的版本由內容管理區分。
  • 新填表單送入 收件目錄, 由流程系統分派給經辦人員。
  • 表單處理的特定過程, 皆由流程系統安排。(可考慮資料檢核)
  • 處理完成, 按流程安排的步驟放入 完成目錄 中, 供相關人員瀏覽。
  • 老舊檔案的時間屆存檔年份, 內容管理負責移到 庫存目錄 備查。

用途

表單是許多組織行動的基礎, 單純表單的角色, 卻常被使用系統人力資源所左右。

複雜的系統, 其本身往往就需要很多專業人士來維持。

從頭打造的應用系統, 建立/維護也是個問題, 總不成每每來個衝刺。

使用 PDF 表單, 有機會突破這些罩門。

  • 能操作文書軟體, 就能建立/維護表單。
  • 不需 Web 專業, 也可在表單中盡量放入必要訊息。(參考高鐵轉乘服務的PDF檔)
  • 讀取表單內輸入項目的資料, 只要工具, 不用寫程式。

使用方面 PDF 表單也近似紙本表單, 能高亮(Highlight)標示、張貼備忘(Note) …

31 Preview PDF Note

再者, 若打通檔案的流通, 透過智慧手機、平板設備處理 PDF 表單, 會更接近真實填寫表單, 包括簽名