恆生O32系統的前世今生

恆生O32系統的發展歷程

O32系統即基金投資管理系統，其實從名字不難看出最開始是為基金公司開發的系統，到後來逐步涉及到券商、券商資管、保險、信託、期貨，所以說O32系統的發展歷程幾乎伴隨著整個基金行業的發展。

首先為什麼叫O32呢？其實主要是以底層資料庫使用什麼作為命名依據的，在2003年之前，由於使用的是SqlServer資料庫，當時還叫做S1.0、S2.0；2003年3月恆生推出O3系統，開始引入Oracle資料庫（系統所有的資料都存在裡面），在S2.0系統基礎上升級，所以改叫O3（"O"取用"Oracle"首字母，3代表升級了，不再是之前的S2.0了）；2007年恆生將O3系統多個業務模組重新開發升級，推出O3升級版O32系統，意思是我比之前的O3要強很多了。

這十幾年中，恆生從O32衍生出很多系統，下面這些系統就和O32有著千絲萬縷的關係，足見O32系統的龐大、複雜。

順應行業發展的O45系統

前幾年大家使用O32系統體驗還是不錯滴，但是隨著業務量的不斷提升，大家明顯感受到現在O32系統在交易速度方面存在很大的效能瓶頸，這主要原因還是十幾年前的系統架構已經無法支撐現在的業務量了，所以2015年起恆生考慮通過記憶體化交易從而提高交易速度，向市場推出了O4系統(也叫UFT, Ultra Fast Trade，極速交易)。但O4系統(O32版本的極速交易，在O32系統基礎上增加的子系統)的同業使用率並不高，我司也沒有使用該子系統，一是因為O32涉及業務範圍太廣，極速交易子系統無法快速滿足所有業務場景；二也是因為恆生後續主要想向市場直接推廣O45系統。所以今天主要為大家介紹O45系統：

No.1 行業為什麼需要O45

No.2 我司目前面臨的問題

No.3 O45系統架構總覽

O45是統一主系統 + 子系統模式，各個子系統單獨部署、單獨升級，鬆耦合，比如只是改造創業板，那麼只需要升級權益子系統即可，進行ETF相關改造，也不會涉及到固收子系統什麼事。總體來說，把系統分為多個子系統，改哪兒就升級哪套子系統，只針對該子系統進行測試驗證，無需腳摔傷了，把整個身體都檢查一遍。

O32與O45的巔峰對決

O32系統

目前採用基於外掛的CRES架構，CRES理解為：C++、Reused（可複用）、Easy (易用)、 Solution（一個解決方案），主要靠各類外掛支撐系統。

其中介軟體是C++語言開發、後臺主應用服務大部分是C語言、前臺程式是比較老的Delphi6開發，只能編譯出32位程式，這就是為什麼有時候恆生O32系統會彈出來帶有out of memory關鍵字的報錯，因為32位程式執行在我們在64位作業系統，最大定址空間是2G，其中作業系統佔用0.5G，我們的O32系統就只剩下了1.5G左右，超過1.5G就會報錯，這個時候需要關閉O32客戶端重啟即可，所以若非必須，不建議同時開啟很多選單，因為每個選單都會佔用一定記憶體。

O45系統

所採用的JRES3.0技術平臺基於原生SpringBoot開發，是一個符合網際網路分散式系統開發的JAVA開發技術平臺，具備可複用（Resume）、可擴充套件（Extend）、高安全（Security）的特性，降低業務開發人員技術要求，提升開發效率以及系統穩定性。

其中介軟體是Java語言開發、後臺主應用服務是Java和C++語言、前臺不再單純是之前CS架構了(即通過客戶端登入)，增加了BS架構(即通過web瀏覽器的形式直接登入)，既可以通過客戶端形式登陸，也可以通過瀏覽器登陸了。資料庫也拋去了Oracle，引入了Mysql，準確說不能叫O45了，但是O32已經深入人心了（前面講到之前的"O"就是指"Oracle"），所以也就延用這個名字。

以上這些變化主要是由於系統整體架構變化導致的，這也是整個網際網路金融發展的趨勢帶來的變化，通過這些後臺的改造，帶給我們前端使用者最直觀的感受就是交易速度變快了，系統更加靈活、擴充套件性更強。如果說之前的O32是一頭龐大的大象，有力而笨重，那麼O45可以說是一隻勇猛的獅子，強壯而靈活。

JRES3.0架構幾大特性

• 元件化
  採用微服務技術架構，基於服務和元件，按最小業務單元劃分，可根據使用者需求對元件進行組裝。
• 鬆耦合
  業務層微服務架構鬆耦合。
• 可擴充套件性
  採用小核心、大外延的設計思想，降低模組間耦合，具有高度的可擴充套件性和靈活性，適應未來的業務發展變化。
• 開放介面
  通過介面互動，只要保證介面不變，核心系統再怎麼修改和演進也不會對外圍功能產生影響，實現投資系統與外圍功能的鬆耦合。
• 記憶體極速交易
• 資料走記憶體（很快喲），先報單，再落庫。