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

微服務挑戰

  運維要求較高
  分散式的複雜性
  介面調整成本高
  重複勞動

微服務設計原則

  單一職責原則
  服務自治原則
  輕量級通訊原則
  介面明確原則