恆生O32系統的前世此生
2020-06-29信息技術部
前端
恆生O32系統的發展歷程web
OH~~O32啊~咱們每天使用的O32系統怎麼來的？經歷了哪些發展歷程勒？您瞭解嗎？
O32系統即基金投資管理系統，其實從名字不難看出最開始是爲基金公司開發的系統，到後來逐步涉及到券商、券商資管、保險、信託、期貨，因此說O32系統的發展歷程幾乎伴隨着整個基金行業的發展。
sql
首先爲何叫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分佈式
我司目前面臨的問題
微服務
01
下單速度慢
好比在上午10點或下午銀行間交易集中的時候基金經理在下達指令時會等待數秒才能下達成功，這是因爲這個時段同時下單的基金經理或交易員不少，形成了相對較高的併發，且系統內須要計算的風控條例較多，十幾年前的架構對於高併發、計算量大的場景只能表示無奈。
02
接口開放性不高
對於O32而言，外圍與核心系統經過數據表進行交互，好比咱們如今場外系統和O32的對接主要就是經過抽取後臺數據表數據進行交互，致使的結果就是核心系統與外圍功能深度耦合在一塊兒。若是恆生O32的表結構變化了，場外系統也須要同步改造；O32系統處理了某筆業務，須要等到場外再次經過調度任務抽數回去，才能知道這筆業務已經處理了，實時性很低。
03
O32內部技術架構深度耦合
系統牽一髮而動全身：咱們常常向恆生提交需求，他們總說須要評估，這但是真評估，並且是須要時間的，越涉及基礎底層的東西，越難評估，一個修改就要涉及多個業務功能，須要多個開發組進行評估，若是評估不到位，就會產生缺陷引起生產交易事故，這麼一個龐大的系統對於任何一個改動都須要慎之又慎，因此沒法快速響應需求；
04
投資品種不斷增長
好比QD\QF等業務發展；
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架構幾大特性
●組件化
採用微服務技術架構，基於服務和組件，按最小業務單元劃分，可根據用戶需求對組件進行組裝。
●鬆耦合
業務層微服務架構鬆耦合。
●可擴展性
採用小核心、大外延的設計思想，下降模塊間耦合，具備高度的可擴展性和靈活性，適應將來的業務發展變化。
●開放接口
經過接口交互，只要保證接口不變，核心系統再怎麼修改和演進也不會對外圍功能產生影響，實現投資系統與外圍功能的鬆耦合。
●內存極速交易
數據走內存（很快喲），先報單，再落庫。