隨著網際網路及5G的持續不斷發展，許多的資訊系統在網際網路的應用也將愈來愈多。當應用的需求隨著企業成長的要求改變時，能夠採用新式的資訊來開發系統之外，也需要考量到後續維運的方法。所以在建構新式的資訊架構時，要由前段的作業需求，到開發設計以及完成後上線的維運管理， 應該要有完整的考量才能符合現階段所請 DevOp的要求。本文先就開發及維運上的架構及設計上的要求來設計，在執行上可以就實際面將服務變成微服務的容器微服務。
在企業的實際要務要求上，除了系統功能外在這樣的資訊系統必需符合以下的必要要求:
- 必需能夠即時接收大量的回報資料，
- 必需能夠接收後台及第三台系統的要求或命令，
- 要求命令必需即時下達給接收端
- 監控系統的效能及服務
- 長期記錄回報的資料及命令資訊
- 依業務需求成長可以彈性調整系統架構
- 可以依作業的實務需求針對訊息需要要版本管理
- 系統依開發、稽核及維運部門需要必需區分為”測試區”、”驗證區”及”正式區”
- 系統的Down Time 必需達到99.9以上,
- 成本及維運費用
以系統架構而言:
採用雲端架構最能符合以上的企業要求，在雲端架構中可以考量二種方式: “公有雲”或是”私有雲”。在以”作業架構”及部門需求分區來評估需要的”主機”數量及頻寛需求(對內及對外)後，採用”私有雲”的方式。”私有雲”以三台主機做為開始架構。架構如下圖
- Ceph : 底層儲存系統運用 Ceph 將所有主機上的磁碟機虛擬化成一個大的磁碟空間, 並同時保有三份的資料，
- OpenStack : 中間層以 OpenStack 來管理虛擬主機和網路層，
- 敦緯 PrivateCloud Manager : 再加上客製的管理層來協助系統管理員來管理及設定這些資源的設定及管制作業。
以作業架構而言:
設計一個以訊息佇列為中心的訊息平台。在多工的資訊系統中不應該存在長時間單一執行緒的設計方法，所以我們採用以 Message Queue 為主的訊息架構，在這樣的架構之下，每一個訊息都能在接收或是發送後即完成控制及連線，而不需要佔用連線的資源。這樣的訊息處理方式很適合多工多主機和微服務的作業，若是能再搭配REST API的方法那麼就更為彈性。以下是各伺服器元件的角色說明:
- HAProxy : 流量分配及負載平衡
- RabbitMQ server : 訊息佇列服務
- Prometheus + Grafana : 監控所有伺服器的負載、服務及告警通知
- InfluxDB : 儲存即時的回報訊息。
- 伺服器:
- Register, database server : 連線認證主機
- Portal server : 後台命令、報表及控制管理主機
- Message server : 建立雲端平台與終端之間的連線及接收/發送資料
擴充架構
當測試階段的系統佈署完成後，可以使用開發時的測試程式或是使用JMeter 來模擬終端點送出批量式的訊息，以便用來找出系統元件的設定值調整、網路的配置或是主機資源的分配等以做為上線前的評估。
營運說明
以上的作業主機共需要三套包含所有的伺服器元件之相類似的主機系統，以分別做為”正式營運”、”系統驗證”以及”系統測試”之獨立系統。一般而言, 還需要加上”開發測試”的一套系統。為因應以上實務作業，我們利用 OpenStack & Ceph 以三台x86主機建置一套”私有雲”，在這個雲上以配給的規格之可用資源為 48 vCore / 384GB RAM / 7TB disks (3 copies)。對每一個分別的獨立系統我們單獨配發分別的資源配額，讓各個獨立系統依特性及要求可以獨立但分享整體資源。
不論是在那一區的作業主機都可以納入系統監控的監控之中，在實際之中因為”開發測試”和”系統測試”二個系統比較不需要即時監控所以我們的監控主機就不含這二個系統中的作業主機系統資源, 但需要監控這些主機中的服務狀態。