1架構總覽
此架構支撐的業務是 一天10G的日誌處理,100個左右的QPS
##業務流
業務訂單表設計
CREATE TABLE `biz_order` (
`tid` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主鍵',
`biz_id` varchar(100) NOT NULL DEFAULT '' COMMENT '業務訂單編號',
`type_no` varchar(50) NOT NULL COMMENT '業務類型',
`user_id` bigint(20) NOT NULL COMMENT '用戶userId',
`object_id` int(11) NOT NULL COMMENT '業務對象ID',
`request_status` tinyint(4) DEFAULT NULL COMMENT '存管通狀態1.待發起指令 2.發起指令 3.委託成功 4.不需要調用存管通 5.處理成功 6.處理失敗 ',
`biz_is_success` tinyint(4) NOT NULL DEFAULT '1' COMMENT '業務處理結果 1.等待處理 2.處理中 3.處理成功 4.處理失敗 5.已取消',
`in_json` text NOT NULL COMMENT '傳入參數json傳',
`out_json` text COMMENT '輸出參數json傳',
`version_no` tinyint(4) NOT NULL DEFAULT '1' COMMENT '版本號',
`biz_level` tinyint(4) NOT NULL COMMENT '業務級別',
`sort_no` tinyint(4) NOT NULL COMMENT '驟編號,頂級爲-1',
`parent_tid` bigint(20) DEFAULT NULL COMMENT '父級業務ID',
`request_id` varchar(100) DEFAULT NULL COMMENT '存管接口訂單號',
`date_seriano` int(11) NOT NULL COMMENT '日期字符串',
`redirect_url` varchar(100) NOT NULL COMMENT '回調地址',
`create_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' ON UPDATE CURRENT_TIMESTAMP COMMENT '創建時間',
`update_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '最後更新時間',
PRIMARY KEY (`tid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='業務訂單表';
存管訂單表設計
CREATE TABLE `cgt_request_order` (
`tid` bigint(20) NOT NULL DEFAULT '0' COMMENT '主鍵',
`request_id` varchar(100) NOT NULL COMMENT '存管接口訂單號',
`biz_id` int(11) NOT NULL COMMENT '業務對象ID',
`type_no` varchar(50) NOT NULL COMMENT '業務類型',
`request_is_success` tinyint(4) NOT NULL DEFAULT '1' COMMENT '存管通狀態 1.發起指令 2.委託成功 3.處理成功 4.處理失敗 5.已取消',
`key_value` text NOT NULL COMMENT '輸入參數json傳',
`return_value` text COMMENT '輸出參數json傳',
`version_no` tinyint(4) NOT NULL DEFAULT '1' COMMENT '版本號',
`bank_no` tinyint(4) NOT NULL COMMENT '存管銀行1.廈門銀行',
`date_seriano` tinyint(4) NOT NULL COMMENT '日期字符串',
`row_num_sum` int(11) DEFAULT NULL COMMENT '數據行數',
`redirect_url` varchar(100) NOT NULL COMMENT '回調地址',
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '創建時間',
`update_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '最後更新時間',
PRIMARY KEY (`biz_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='存管訂單表';
2 日誌紀錄
Flume+elastic-search-----
3 密鑰管理
放入DB中,緩存redis----ok
4 外部api接口管理
切換銀行,接口升級-----ok
放入db中,緩存redis。
5 數據一致性保證
異步補償,定時補償,增加事務紀錄表
6 異步通知接口需保持冪等
接收外部的異步通知接口必須支持冪等
通過數據庫唯一性約束保證。
7 定時對賬-業務補償
走任務調度中心
一般來說是實時,如果業務處理速度跟不上,業務量大的功能10分鐘補一次單,業務量小的1分鐘補一次單
7 外部接口監控
定時探針測試。-----測試環節
架構演進
單體架構
SOA
微服務
單體架構
一個歸檔包包含了應用所有功能的應用程序, 我們通常稱之爲單體應用。
架構單體應用的架構風格, 我們稱之爲單體架構, 這是一種比較傳統的架構風格。
單體架構的缺點
複雜性逐漸變高
技術債務逐漸上升
部署速度逐漸變慢
阻礙技術創新
無法按需伸縮
SOA
面向服務的架構(SOA)是一個組件模型,它將應用程序的不同功能單元(稱爲服務)通過這些服務之間定義良好的接口和契約聯繫起來。接口是採用中立的方式進行定義的,它應該獨立於實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行交互。
SOA是一種粗粒度、鬆耦合服務架構,服務之間通過簡單、精確定義接口進行通訊,不涉及底層編程接口和通訊模型。
##分佈式系統優點
- 1:把模塊拆分,使用接口通信,降低模塊之間的耦合度.
- 2:把項目拆分成若干個子項目,不同的團隊負責不同的子項目.
- 3:增加功能時只需要再增加一個子項目,調用其他系統的接口就可以。
- 4:可以靈活的進行分佈式部署.
- 5:提高代碼的複用性,比如service層,如果不採用分佈式rest服務方式架構就會在手機wap商城,微信商城,pc,android,ios每個端都要寫一個service層邏輯,開發量大,難以維護一起升級,這時候就可以採用分佈式rest服務方式,公用一個service層。
##分佈式系統缺點
系統之間的交互要使用遠程通信,接口開發增大工作量
微服務
微服務架構風格這種開發方法,是以開發一組小型服務的方式來開發一個獨立的應用系統的。
其中每個小型服務都運行在自己的進程中,並經常採用HTTP資源API這樣輕量的機制來相互通信。
這些服務圍繞業務功能進行構建,並能通過全自動的部署機制來進行獨立部署。
這些微服務可以使用不同的語言來編寫,並且可以使用不同的數據存儲技術。
對這些微服務我們僅做最低限度的集中管理
微服務特點:
1. 每個微服務可獨立運行在自己的進程裏;
2. 一系列獨立運行的微服務共同構建起了整個系統;
3. 每個服務爲獨立的業務開發,一個微服務一般完成某個特定的功能,比如:訂單管理、用戶管理等;
4. 微服務之間通過一些輕量的通信機制進行通信,例如通過REST API或者RPC的方式進行調用。
微服務優點:
易於開發和維護
啓動較快
局部修改容易部署
技術棧不受限
按需伸縮
DevOps
微服務挑戰
運維要求較高
分佈式的複雜性
接口調整成本高
重複勞動
微服務設計原則
單一職責原則
服務自治原則
輕量級通信原則
接口明確原則