[閒聊] 公司內部非GUI類型的AP

[architk (ㄜ)]

   進入這行已經八個年頭

   呆過四間公司 Vendor Side & User Side都有

   開發維護過系統非常多元


   我們知道大型企業裡的資訊系統 除了一些給人操作的 GUI類型系統外

   還有一大部分是默默的躲在背後定期被執行或常駐型的AP

   我習慣稱他們為 scheduling job或daemon

   這類job的行為不外乎也是CRUD 外加call call其他系統提供的API

   來達成企業營運上的特定需求

   //這類API的interface如ejb/webservices/rpc/rmi/corba/rest/DCOM/socket daemon


   例如 製造業MES/CIM會有一些automation job來取代人為操作

        電信業/金融業會有一些cycle job負責出帳

        ERP薪資系統負責算錢的job 等等.....


   這類job的execution frequency 短到每五分鐘或長到每一個月才執行一次的都有

   然而這些job的可靠度是很重要的，因為一但job發生run time fail或是

   該起來的時機沒起來，都會讓相關使用者單位遭受到很大的impact，所以一般都會在

   implement一些monitor或是defense機制來確保其可靠性



  小弟過去所遇過這類的critical job實作技術大部分都是用下列技術

  1 用java/c/c++/寫成 batch job 部署到unix/linux上設crontab執行

  2 有效能考量且不用跨multi db source也無跨系統間API呼叫的需求

    就可以寫成oracle procedure 在用unix shell script去定期invoke之類的

  3 花俏一點會用一些 3-party scheduling framework或自己implement framework

    來控制這些job的排程



  最近來到一個新環境，部門這類的job的在整體系統裡扮演的重要性是很高的

  也就是job fail都會對公司營運造成很大的impact


  但是卻發現開其發技術卻是用舊VB/Delphi寫成windows exe檔

  然後跑再windows 2000上，使用的scheduling tool是system scheduler，

  整個可靠度就很低。

  job常常莫名的crash就跳出memory violation address之類視窗的，或是莫名奇妙

  連跑都沒跑，不然就是windows server動不動當機要重開


  最近被assign一個任務

  要弄一個defense平台來確保這些job執行的可靠度，真是頭很大

  總不能請所有owner翻掉重寫全搬到unix上吧(有1000多隻..XD)


  想到的低級的方法是用table來記錄每個job的執行status，在去monitor這些status

  進一步實作alarm和recovery機制



  拋出這個有趣的問題來跟大家討論(純討論)，板上有經驗的人

  有無其他更好的solution，或現成好用的job monitor tool (for windows platform)

  可以介紹給小弟


  另外閒聊話，那些入行10 ~ 20年的前輩，在90年代這類job都是什麼樣的技術實作呀

  DOS上跑Basic ? 還是傳統的Unix + C 最流行 ?


  牢騷話...我離開java/unix環境就整個不對勁 Orz..

  另外.NET上有無可靠度高的scheduling framework可用 ?


  軟體版來討論一些solution腦力激盪一下吧 ...


















--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 111.255.178.76
推 koller:你可以全部寫英文嗎 看得很痛苦耶 =.=
推 OriginStar:我同事寫個Java的Process Monitor，主要是因為客戶要求
→ OriginStar:若被監控的ap掛了，可以自動重啟，供原PO參考
推 joy830:推1F
→ jej:噓1F..懶得看可以不用寫..請提供意見..其實我也有相同的困擾..
→ andymai:語言夾雜也還好吧~我很好奇在看像"小孩不笨"之類的新加坡
→ andymai:電影~會不會更痛苦???
推 slalala:oracle all_jobs
→ kenzou:一樓可以去阿六的論壇呀，他們都中文化的很徹底呢。
推 bobju:讀起來蠻順的呀, 1F會感到痛苦?
→ bobju:90年代大約還是用unix shell script較多.
→ remmurds:在windows上可以考慮改寫成windows service
→ remmurds:.net framework對這方面有支援
推 Maisky:Real Time Java JSR1
推 Label:我覺得 服務+事件檢視器 是還不錯的Solution
→ Label:但Service要非常注意記憶體裡  而且Service也不太容易Debug
推 breakingball:十年前mainframe上的cronjob不是shell就是perl
推 DeathTemp:我比較想知道為什麼job會crash...
推 epola:為何會感到痛苦 ? 一般的用語啊
推 wancd:job會crash的情況不多  但遇到不執行時就很頭疼
推 TroyLee:我覺得考靠度低有一半問題在程式設計師...
→ TroyLee:不能說你看他用VB/Delphi在win2k上跑就一定低
→ TroyLee:如果程式本身沒有做完善的考慮 就不應該歸咎到語言及平台