2023年6月28日

金融自動系統

 前言:

2014年時,曾以Java為基礎開發了股市自動交易系統 - JavaATS,後來不了了之。
最近以先前的架構為基礎重新開發,系統改以Python語言為基礎,以PostgreSQL和MQTT通訊協定為核心,重新設計成開發式架構。
因為系統無法達成自動交易的目標,因此命名為金融自動排程系統。
這篇會描述系統架構。

系統架構:

系統延續JavaATS的排程器核心,以Python重新實做。
因為科技的進步,原先Configure Manager使用的XML現在直接改用ini + PostgreSQL,原本定義在XML內的Task,都改定義到SQL中。
原先各元件之間,透過一個Socket Server交換資訊,同樣因為科技的進步,現在直接透過MQTT就能達成,Socket Server交換資訊時的資料格式問題,現在透過json能夠方便的進行資料交換。

TimerServer:

這是整個系統的核心,它以Crontab語法為基礎,在SQL中定義多個Task,TimerServer會以while loop方式每15秒撈取一次SQL內的Task List,並比對當下時間和Task Crontab時間,符合就執行。
執行時,透過Python的os.system(),以及定義在SQL內的Task欄位,能夠指定直譯器以及程式參數,例如:
python3 Downloader.py
ts-node-script stock_invest_downloader.ts
python3 dir_scanner.py /tmp/data/

Crontab格式定義如下:

延續JavaATS的TimerServer,Crontab的語法基本上能做到特定日期時間執行、週期執行、每星期特定天執行。

多機跨網路系統:

TimerServer啟動時包括一個config.ini檔案,裡面定義了SQL的帳號、密碼、DB,一個稱為MY_RUNNER_NAME的名稱定義。
而在資料庫的Task List中,每個Task都包含一個runner的欄位,同樣的,TimerServer在檢查Task List時,會比對Task的runner和自己的MY_RUNNER_NAME是否一致,或者runner是否為空,如果為空或者一致,則進一步比對時間是否符合,符合則執行。
上述的runner設計,讓TimerServer變成了多機跨網路的系統,可在多台PC甚至樹莓派上執行,每台電腦都透過SQL撈取Task List,比對後判斷是否是相對應的機器和相對應的時間,符合就會執行,達到多機器跨網路運作。

圖形化管理元件:

Python支援Qt,在Blog以前的文章中寫過多次Qt文章,這裡緬懷良葛格,以前開發Qt程式時,良葛格是少數中文的Qt教學,而且不同於書籍和官方教材,他的文章內容精準,看得出是學過寫過得人,才寫得出的教學文章,可惜他竟然走了。
透過PySide2,能夠方便的新增、修改、刪除Task List的Task。


模組化元件:

只有TimerServer定時執行顯然不夠,要能建構出金融自動系統,至少還需要歷史資料、證券公司API行情程式、證券公司API下單程式。

以歷史資料而言,現在能夠過Yahoo Finance API的Python Package,直接撈取歷史資料,後續透過Python PostreSQL Package就能將資料寫入SQL中。
加密貨幣?
加密貨幣交易所也是有提供API的,NodeJS?
前面提到,TimerServer可透過指定直譯器執行,不一定是Python,當然也可以是NodeJS,如前面範例提到的,ts-node-script就蠻方便的。

證券API串接:

我使用的證券提供c#的API,原則上是PC的下單應用程式將Component拆出來,透過c#呼叫的,因此,Windows是必要的。
目前我開了一個Windows VM,用Visual Studio 2015的c#開發2隻程式,一隻為即時價格註冊和擷取程式,一隻為下單程式,證券公司的API中,即時價格擷取是一個API,下單是一個API。
因為以前的經驗,為了縮短開發時間,方便未來證券公司API程式改版。
我是以證券公司提供的範例程式直接修改,將視窗Dialog隱藏,增加右下角System Notify,然後加上config.ini、MQTT的相關程式碼。
作用,
即時價格擷取:
能透過config.ini、SQL撈取要註冊取得即時價格的Symbol,當取得即時價格後,透過MQTT發送。

即時下單程式:
透過MQTT取得下單指令,進行下單,並透過MQTT、LineBot回報委託情況。

上述2隻程式開發後,連同API一起放在一個Windows VM,並排程開機、關機。


資料分析與技術分析:

嗯~這是個大哉問,如果有答案就不會寫這篇了~啊~不是。
這個以TimerServer為基礎的系統,能夠方便的加上各種分析模塊,我們以典型的技術分析當作例子:
寫一隻Python程式,內容是
每日從SQL中撈取歷史資料,透過Python的TALib計算均線(Simple MA),然後根據是否Cross,從MQTT或SQL上發出或寫入觸發信號。
當然,也可以是透過觸發信號直接透過MQTT發出下單指令。

來點更複雜的吧。
OK......

結論:

透過新版的金融自動(排程)系統,能夠透過開發各個模塊疊加,形成一個多功能跨網路的金融系統,因為以模塊化設計,各種功能都能實做,小到下載歷史資料,大到結合AI測試都能開展,而且透過SQL和MQTT,能夠讓各模塊交互作用。
TimerServer排程器是系統核心中的核心,所有的元件執行都透過TimerServer,透過runner欄位,能讓TimerServer做到多主機跨網路的能力。


2023年2月20日

BladeX(SpringCloud)介紹

前言

這一兩年因為工作需要接觸了基於BladeX的Spring Cloud,深刻體會到Spring Cloud的博大精深,因為這是中國公司以Spring Cloud集成的微服務架構系統,台灣知道的人比較少,這邊就介紹下這個大傢伙。
另外,前一篇介紹了我對JavaScript和NodeJS的看法,這篇也會帶入,既然NodeJS這麼好,BladeX適用情境在哪?

BladeX介紹
BladeX是由上海布雷德科技有限公司集成的Spring Cloud解決方案,產品稱為BladeX
BladeX包括開源版和商業版,不用懷疑,大家都用商業版,開源版基本上只用做入門,事實上以商業版而言,它的價格不算貴,商業版授權大概台幣30,000左右,無使用限制、無授權期限制、無升級版本限制,基本上就是買一次,無限使用。
BladeX有2個版本,BladeX和BladeX Boot,兩個版本分別對應Spring Cloud和Spring Boot。
使用上,大部分使用者都使用BladeX,BladeX Boot版本用的人很少很少。

BladeX系統需求
BladeX的架構是所謂的微服務2.0。
BladeX要佈署和運行,至少需要 MySQL、Nacos、Redis,其系統需求,除去MySQL、Redis、Nacos這3台伺服器外,通常還需要3台每台至少8GB(建議16GB)記憶體的伺服器。

上述意思是,BladeX的運作環境,伺服器需求6台起跳。

Spring Cloud與BladeX架構介紹
以Web Service觀點看Spring Cloud,Spring Cloud是目前Web後端微服務2.0架構的主流。
以前以SOAP Protocol為基礎的Java 2 Enterprise Edition (J2EE),目前都改以Spring架構實做。
單從Protocol觀點而言,J2EE使用SOAP為基礎,SOAP以RPC + HTTP + XML組成,Spring則以(WebSocket) + REST API + HTTP + json組成。
既然對比的是J2EE,Spring Cloud的特點是在高穩定、模塊化、大架構、分散式的企業級應用情境。
Spring Cloud由許多輕量級組件組合而成,我們從下面這個架構圖看起:











這張架構圖算是比較簡潔的圖,先以這張圖描述服務註冊(Service Register)和服務發現(Service Discovery)。

Spring Cloud的架構中,以服務註冊(Service Register)和服務發現(Service Discovery)為基礎,在Spring Cloud中,一般用Eureka (BladeX中是Nacos)。
所謂的服務註冊(Service Register),是系統中所有要運行的微服務,在加入系統時,都要先透過Eureka進行註冊(Service Register),服務註冊後,系統內要呼叫和使用服務時,都可以透過Eureka的服務發現(Service Discovery),自動的找出相對應服務的微服務。
例如:
上圖中右側有個Auth Service,是使用者認證用的,要在上圖系統中使用Auth Service
首先,要先在Eureka (BladeX是Nacos)中先註冊Auth Service
使用時,要使用的程式要先詢問Eureka (BladeX是Nacos),Auth Service是誰?Eureka (BladeX是Nacos)會將Auth Service的IP和Port回傳給要使用的程式。
這個註冊和使用過程看起來有點複雜,在Spring Cloud中,呼叫、查詢和使用封裝在Feign Client API當中,透過呼叫和使用Feign Client API,它底層直接將上述行為處理完成。

在寫程式時,我們會需要全域變數紀錄和處理環境變數,並讓系統內所有程式都能存取,同樣的,Spring Cloud的微服務也需要存取共用的變數資料,在Spring Cloud中,並不將它稱為變數,而將它稱為Config或設置參數。
因為這些Config需要能夠共用,因此這些Config需要特定一個服務儲存和管理,它就是上述架構途中的Spring Cloud Config(BladeX中是Nacos)。
系統內所有的微服務,都能夠透過存取Spring Cloud Config(BladeX是Nacos),儲存和讀取Config。
例如:
微服務要能存取MySQL,通常會將MySQL的JDBC URL存放在Spring Cloud Config(BladeX是Nacos),使用時取出。

前面提到過,BladeX是Spring Cloud集成的解決方案,在BladeX當中,上述的服務註冊(Service Register)、服務發現(Service Discovery)和Config參數管理,都是透過Nacos管理的,而Nacos是阿里巴巴針對Spring Cloud開發的輕量級服務。

Spring Cloud中包含很多微服務,實際使用時,Client端通常不會直接存取微服務,Client端一般會透過Spring Cloud的API Gateway存取,在Spring Cloud中是ZUUL,而在BladeX中,它包含了一個稱為bladex gateway的微服務。
架構圖如下:

BladeX的bladex gateway和ZUUL作用相同。
所有Client都存取API Gateway,ZUUL和其他微服務的需求,則透過Feign Client API互相存取,中間存取的API,都是REST API,資料格式都是json。

BladeX(Spring Cloud)與php/express/django比較
典型的Web應用,通常由SQL(常見MySQL)、Apache、Web Backend、Web Frontend組成。
通常SQL一台,Apache和Web Backend一台,其他Client端都在系統外部。
這樣的應用,一般使用php/nodejs express/python django都能方便開發,經典的CRUD這類都足夠並方便使用,我自己估計,大概9成的應用都屬於此。
BladeX與Spring Cloud適用在企業的大型Web應用,它最基本需要穩定,還需要模組化,能夠以模組形式開發新服務,還需要具備分散式系統的橫向擴充性。
例如:
當希望有多個Client入口分散系統負載時,直接開多個API Gateway即可,只要確定Nacos內API Gateway有多個Instance,就能橫向擴展服務。

上述這些需求,會讓系統架構的複雜度變高,比較不適合直接用php/express/django開發,底層需要的API和SDK太多太雜。
舉個例子:
Nacos有NodeJS的API,透過呼叫Nacos API,NodeJS也能做到服務發現、服務註冊、Config存取,但這個只是Nacos API,並不是Feign Client API,實際在開發微服務時,需要大量使用Feign Client API存取其他微服務,光是要把NodeJS Nacos API包裝成Feign Client API,就要花費很多時間成本,而在BladeX中,Feign Client API只是其中一組常用的API,其他像是資料庫ORM的MyBatis API、加解密API...等,大概有10幾組API,不大可能全部用NodeJS重造輪子。

結論
BladeX是博大精深的微服務Web Framework,它集成了認證、會員管理、後台管理界面...等功能,它的系統集成了以Nacos為基礎的許多輕量級Spring Cloud組件服務,且能夠擴展支援包括Prometheus...等監控系統服務,承襲Spring Cloud的架構、模組化設計、橫向擴充能力、服務管理...等特點,讓大型Web應用的開發變得容易。
同時,BladeX與Spring Cloud這類Web Framework的設計目標,並不是使用在常見的小型Web應用,如果開發的目標項目是一般會員網站或功能網站,系統需求鎖定在2台以下的Web Server時,以express/django開發可能更為簡單方便。
(圖與排版後續補上)

JavaScript/NodeJS Web前端之我見

前言

這一兩年因為工作需要接觸了JavaScript/NodeJS與Web前端,也因此對所謂的Web前端有了更深刻的體會和理解。

這篇文章雖然標題寫的是JavaScript介紹,但後面會描述JavaScript和Web前端的不可替代性。

Web前後端概念

早期的Web並沒有區分前後端,典型的開發方式是先做個Web版型,然後Web內容替換asp/php/jsp寫的function和變數,瀏覽器載入時,Server會執行這些function,並將執行結果放入Web中提供給瀏覽器。

目前的Web開發,則多半會建議前後端分離,所謂的前後端分離,指的是後端一樣是asp/php/jsp,現在甚至可以是NodeJS Express/Python Django。

後端開發後,提供的是所謂的RESTFul API,一般簡稱REST API或API。

前端開發,則幾乎都是以JavaScript/TypeScript為主的Web App。

為什麼分成前後端?有沒有必要?能不能不學JavaScript/TypeScript而用Java/Python/C++開發?

這是我在接觸Web前端時的一系列疑問,而後得到了答案。

1. 為什麼分成前後端?有沒有必要?

Google多半會查到,現在的趨勢如此,專業分工,前後端架構...等,但WordPress沒有前後端分離,一樣有很大的使用群,那需求和原因在哪?

其實最關鍵的需求和原因,是多平台支援。

現在這個時代,手機佔了很大的使用群,手機又區分了Apple和Android,Apple要使用ObjectC/Swift開發,Android要使用Java/Kotlin開發,而傳統的PC和Web要支援嗎?PC可能要用c#開發,Web要使用JS開發。

為了能夠滿足多平台開發,典型前後端一體的開發方式,無法適用在這樣的情境中,因此,將後端改為REST API,前端各自使用HTTP API串接成了解決方案,而這點,才是前後端分離開發的真正原因。

換句話說,假設今天明確的需求是,我們只使用Web瀏覽器,並且不打算支援手機,那麼是否要前後端分離其實沒這麼重要。

2. 能不能不學JavaScript/TypeScript而用Java/Python/C++開發?

這個問題,很多後端想跨入前端開發的都會問,我一開始也是如此,事實上這有好處。

想想看,團隊成員都會Java,直接用Java開發前後端,人力能自由調配,這是很大的優勢。

但實際上呢?答案是不太行,原因很簡單。

目前所有的Web瀏覽器,核心都是JavaScript Engine,而目前Web瀏覽器,尤其是Chrome,基本上跨所有作業系統平台,Chrome地位等同以前的IE,幾乎是Web瀏覽器的代名詞,因為它原生支援的是JavaScript Engine,學習JavaScript這件事就避免不了。

那TypeScript和其他語言又如何呢?

目前TypeScript和其他語言,都是透過轉譯器的方式,將程式碼轉譯成JS後,在提供給Web瀏覽器執行的。

Web前端優勢

我們先帶個比較無關的東西,看一看Google AI的TensorFlow SDK"主要"支援哪些語言?

TensorFlow API Document

TensorFlow SDK支援4種語言,包括:

Python/JavaScript/C++/Java

其中有趣的是,Java點進去會發現,它都寫這個支援未來可能移除。

Python因為簡單易學,是目前的顯學,學校教的程式語言,都開始改教Python,以AI主軸在類神經網路設計/訓練/推論這幾個開發點,程式語言帶出的系統架構不是重點,程式執行速度也不是重點,簡單實做和修改類神經網路才是重點,因此以Python為主要語言是合理的。

C++的優勢除了程式執行速度快,上至伺服器服務和Web後端,下至MCU都能支援,最重要的是,C++編譯後,Binary反組譯比較難,原始程式碼隱蔽性好,是主要語言合理。

Java在程式語言開發中,仍舊有非常高的使用率,因此支援Java不意外,但它的開發便利性不如Python,程式碼沒有隱蔽性,不如C++,因此有支援但可能移除就不意外了。

那JavaScript為什麼變成主要支援的語言?

簡單的說,目前所有Web瀏覽器都只支援JavaScript,而目前所有作業系統平台都有Web瀏覽器,支援JavaScript,等於能讓AI應用從PC到手機全部支援。

意思是,JavaScript與Web瀏覽器,原生就具備跨平台能力,儘管在不同平台上的整合度沒有各平台原生語言強,但套用Java以前的標語:One language run anywhere 完全沒問題。

JavaScript與分散式特性

傳統系統開發時,為了最大化系統效能,通常會測試系統可支持的最大負載量,然後將最大負載量設為80%左右。

一般而言,不論是PC/IPC/開發板,效能越強單價越高,通常都希望盡可能的降低程式CPU和記憶體的使用量,拉高系統可負載量。

當我們代入Web前後端開發後,上述的最大負載量能直覺反應,它是屬於Web後端的服務,那前端呢?

Web前端通常運作在Web瀏覽器中,因此JavaScript和Web瀏覽器執行在Client端。

一個極端的說法,對於Web前端而言,後端只需要有個Web Server提供儲存空間,能讓Web瀏覽器下載HTML和JS,後續就能在Client端的瀏覽器中執行。

從這個觀點看JavaScript和Web前端,它是完美的分散式架構,所有程式都分散運行在全部的Client當中,不會佔用後端Server服務資源。

白話的說,如果盡可能在Web前端用JS開發和執行,能最大程度降低後端服務器的負載量,增加整個系統的使用效率。

而目前Web瀏覽器和JS SDK能夠支援的運算越來越多,已不是傳統的JS function只處理頁面顯示,像是TensorFlow能夠直接用Web瀏覽器在本地執行Ai程式,WebGL能夠直接在Web瀏覽器繪圖,瀏覽器內嵌的影片播放器能夠直接播放影片並進行H264/H265...等影像格式解碼,以往這些負載較大的程式,現在都能轉到Web前端運行,以分散式觀點而言,能很大程度的降低後端負載,增加系統負載量。

Web3.0與區塊鍊

區塊鍊細節這裡不提,一方面熟悉度沒這麼高,一方面是要描述Web3.0與分散式發展的觀點。

前面提到,從Web前後端觀點看JavaScript和Web瀏覽器的應用,JavaScript和Web形成了完美的分散式架構,有沒有一種可能,讓全部的Web瀏覽器之間互相連線,運行同一支JavaScript程式,變成一個全分散的執行環境和系統?

我認為,Web3.0提出的區塊鍊就是答案。

我們把記憶回到以前的P2P,包括eDonkey和BT,並以eDonkey設計思考。

eDonkey這類P2P的典型設計如下:

所有P2P Client都有檔案清單,所有資源都在P2P Client,eDonkey Server處理的,是紀錄和提供P2P Client的IP列表。

P2P Client啟動後,先連上eDonkey Server詢問最新的P2P Client列表,再跟自己的P2P Client列表比對,接著根據上傳或下載提供檔案(資源)清單,接著進行檔案(資源)上傳和下載。

Server主要服務是維護P2P Client清單。

BT則進一步透過DHT,讓P2P Client之間能夠互相連線取得這份清單,進一步降低Server的依賴性。

那麼,有沒有可能這樣的設計用JavaScript開發在Web瀏覽器上面執行?

我認為區塊鍊是這樣設計的變形。

典型的區塊鍊,每個Client(錢包)都以token形式表示,Client(錢包)中每個代幣(資源)也都以token表示,每個所謂的主鍊(P2P Network),所有的代幣(資源)都以linklist的形式串接,新的代幣(資源)要加入到主鍊(P2P Network),需要主鍊上超過一半以上的Client認可後,串入其中。

會發現,Server在其中的角色和傳統P2P網路的Server有一點相似,Server所謂的交易處理,可看做傳統P2P網路中,新增檔案(資源)時,通知各個P2P Client,進行資源清單同步的動作。

當然,在區塊鍊下,區塊鍊的Server的服務更多,區塊鍊錢包的功能是以錢包為主,沒有所謂的資源,但如果以P2P和Web瀏覽器的分散性思考,比較能夠體會坊間將區塊鍊介紹為Web3.0的原因。


結論

JavaScript從一開始就是Web瀏覽器主要的執行引擎,在目前的Web開發中,具有Web瀏覽器執行的不可取代性。

因為Web的普及,Web瀏覽器是很重要的跨平台環境,這讓JavaScript具有特殊性。

又因為Web瀏覽器是在Client端作業系統中運行,讓JavaScript具有分散性。

以前Java所謂的One language run anywhere,現在的作業系統中,Windows Linux PC預設都沒有Java,Apple iOS也沒有Java,只有Android還以JavaVM為基礎。

但看看現在的Web瀏覽器,PC/Android/Apple iOS,每個平台都有,JavaScript在這個時代成為了One language run anywhere的代表。

以此為基礎,NodeJS可單獨執行,並且有Express這樣的Framework,這讓JavaScript從Web瀏覽器前端跨入伺服器後端服務程式,回想一開始期望的,假如團隊中都是Java開發者,前端到後端都使用Java開發,人力調配的便利性,如果Java改成JavaScript和NodeJS呢?

(圖和排版後續補上)