微服務框架學習一：架構介紹

需求說明書

目的

構建一個穩定，高效，容錯，易維護，可監控的服務調用框架，以便推進公司業務系統朝着SOA架構演進，從而使總體業務架構更加清晰，可控和可度量，最終實現業務產品的健康，敏捷發展。

項目背景

目前匯付各業務系統各自獨立，存在重複業務邏輯，經過數據庫共享數據等問題。項目粗放式生長，缺少清晰的脈絡和獨立的職責。
不少相同數據在不一樣的系統中存在冗餘，給變動和維護帶來很大的難度，也沒有系統負責維護這些數據，基本靠人工重複維護的方式。
系統職責的不獨立，必然帶來人員職責的劃分不清，致使生產率的低下和產品演進速度的緩慢。 

可行性分析

構建這樣一套框架須要從底層通訊，編碼/解碼，序列化，異步處理，線程池等幾個大的方面入手，具體可行性分析以下：
底層通訊：依賴於第三方包netty
編碼/解碼：自定義二進制編碼協議
序列化：依賴於第三方協議，如hessian, protobuf, thrift，以實際狀況權衡使用
異步處理：基於Future Pattern實現
線程池：使用JDK concurrent包自帶的線程池，如有效率問題，後期再作優化

功能需求

穩定：不會由於系統請求併發量的陡增而出現性能大幅度降低的狀況，而且持續可用
高效：性能及吞吐量應比開源的rpc框架高，如hessian, xfire等
容錯：應具有底層網絡通訊容錯及部分只讀業務容錯的能力
負載均衡：經過客戶端負載均衡的方式，摒棄額外的軟/硬負載設備，具有更好的性能和可靠性
簡單監控：V1.0.0版本中僅實現簡單的監控統計功能(log/jmx/telnet方式)
配置服務提供者：V1.0.0版本中僅支持客戶端手工配置服務提供者地址和權重的方式，後續版本改由註冊中心提供

項目計劃

1. 項目信息

項目編號	251
項目名稱	Pegasus
項目經理	劉健
項目簡述	Pegasus爲分佈式服務框架，推動公司業務架構朝着SOA方向發展 V1.0.0版僅構建服務調用框架模塊

2. 目的與範圍 

請參照"服務通訊框架"文檔

3. 參考文獻

名稱	版本	連接

4. 項目計劃

4.1 歷史項目參考

無

4.2 項目估算

FP	624.00
生產率基線	3.01
工做量估算	207.3089701

#	模塊	子模塊	功能	EI			EO			EQ
				S	M	C	S	M	C	S	M	C
1	通訊客戶端	service stub				2			2
2		invoke filter chain				5			5
3		client route				4			4
4		client load balance				4			4
5		heart beat task				3			3
6		reconnect task				2			2
7		communicate protocol				5			5
8	通訊服務端	service registry				4			4
9		communicate protocol				5			5
10		service processor				2			2
11		process filter chain				4			4
12	客戶端服務端集成					3			3
13	http通訊支持	design & coding				5			5

影響因子列表	級別(0-5)	緣由
數據通訊	5
分佈式數據處理	5
性能	5
大業務量配置	5
複雜處理	5
可複用性	5
支持變動	5
級別總數	35

4.3 項目資源

4.3.1 人力資源

角色	人數	姓名	備註
項目經理	1	劉健
架構工程師	1	劉健	初期1人，後續加入其餘開發工程師
開發工程師	3	劉健，劉成業，待定
測試工程師	2	待定	須要與測試部門協調

4.3.2 基礎設施

硬件環境	線下3臺虛擬機用於測試
軟件環境	linux系統(centos), 局域網千兆網絡

4.3.3 工具和技術

用途	工具名稱	版本	生產廠商
開發	Eclipse/IDEA	任意	/
測試	EasyMock	任意	/
設計	Microsoft Visio	2007	Microsoft
壓測	JMeter	任意	Apache
構建	Maven	2	Apache
持續集成	Jenkins	任意	/

4.4 項目排期及流程

4.4.1 項目排期

任務	負責人員	參與人員	開始日期	完成日期	估算工時	實際完成日期	備註
需求分析	劉健	各業務項目責任人	2013-05-22	2013-05-28	12h	2013-05-28
FP估算	劉健	項目開發成員	2013-05-30	2013-05-30	4h	2013-05-30
概要設計	劉健	項目開發成員	2013-06-03	2013-06-03	8h	todo
源代碼編寫	劉健	項目開發成員	2013-06-04	2013-08-12	500h	todo
單元測試及報告	劉成業	項目開發成員	2013-06-04	2013-08-12	100h	todo
源代碼審覈	劉健	項目開發成員	2013-06-04	2013-08-12	50h	todo
開發模擬上線	劉健	項目開發成員	2013-08-15	2013-08-16	2d	todo
質量測試	QA	QA，項目開發	2013-08-14	2013-08-19	4d	todo
性能測試	QA	QA，項目開發	2013-08-20	2013-08-21	2d	todo
QA模擬上線	QA	QA，項目開發	2013-08-22	2013-08-27	4d	todo
生產上線(含準備)	劉健	小白鼠項目人員，項目開發，QA	2013-08-22	2013-08-29	6d	todo
生產測試	劉健	小白鼠項目人員，項目開發，QA	2013-08-29	2013-08-30	2d	todo

 

4.4.2 項目文檔

項目文檔列表

4.4.3 上線計劃

PegasusV1.0.0上線計劃

4.5 項目培訓

培訓需求	參加人員	培訓師	計劃日期
項目目標及整體概要設計	開發人員，QA	劉健	2013.06.05 ~ 06.07中一天
How to test pegasus	開發人員，QA	待定	待定

5 項目跟蹤計劃

5.1 溝通計劃

#	會議名稱	頻率/日期	參與人員
1	項目每日例會	daily	項目成員，QA
2	項目週會	weekly	項目成員，上級管理，QA
3

5.2 風險管理

風險類型	風險描述	風險規避措施	負責人
項目管理	規避項目進度，人力方面的風險	每日例會上跟進	劉健
開發	模塊設計，實現，接口契約方面的風險	每日實時跟進	劉成業
測試	測試進度，問題反饋，及時跟進修復等風險	每日例會跟進	待定
其餘	線下測試環境可靠性及持續集成等支撐平臺狀態跟進	每日實時跟進	劉成業

 

 

項目文檔

1. 目的與範圍

2. 參考文獻

名稱	版本	連接
Netty Doc	3.2.1-Final	http://netty.io/3.6/guide
Hessian Doc	3.1.5	http://hessian.caucho.com/doc/

3. 縮寫或名詞

RPC	Remote Procedure Call
Sync	同步調用，客戶端調用遠程服務接口時，業務線程Block，直到服務返回結果
Callback	回調調用，客戶端調用遠程服務接口時，業務線程不Block，而且無結果返回，結果會在後續返回，並觸發註冊的Callback接口執行
Future	異步調用，客戶端調用遠程服務接口時，業務線程不Block，無結果返回，但能夠獲取到此次調用的句柄Future實例，後續能夠經過 該句柄獲取服務的結果，該方式在優化性能時極爲有用，一些與此次服務調用不相干的操做能夠在服務未返回時執行，後續再經過 Future句柄獲取服務結果，即不少事情是並行交叉的。多個互不相關的服務調用，也能夠經過這種方式並行處理，縮短處理總時間。
Oneway	單向調用，客戶端調用遠程服務接口時，業務線程不Block，無結果返回，而且服務端無響應消息寫回，客戶端不關心服務端是否正 確處理請求，僅關心消息是否發送出去。對於應用發送Trace/Log之類的消息很是有用，性能最快，吞吐最大，資源最節約。

4. 總體流程圖

5. 類圖

注：簡要繪製，實際編碼時進行豐富和調整 

6. 子模塊設計

6.1 序列化方式

序列化	優勢	缺點
XML	描述能力強，跨語言	佔用空間大，marshall/unmarshall效率極低
JSON	描述能力強，跨語言，比XML節省空間	佔用空間較大，jackson引擎尚不熟悉
Java	對Java的各種對象支持完善，使用方便	速度慢，佔空間
Hessian	字節碼方式，跨語言，性能較快，空間較小	各種語言的實現支持不夠
Protobuf	跨語言，佔用空間極小，性能極快	須要編寫中間代碼並生成最終代碼，每次更新代碼很是麻煩
Thrift	性能，空間俱佳，功能較protobuf完善	須要中間代碼生成最終代碼，跟新代碼很是麻煩

綜合以上各種序列化方式的優缺點，從性能和使用性方便綜合權衡，選擇較中庸的Hessian序列化方式做爲Pegasus的默認序列化方式。後續考慮將其餘方式做爲可選的實現，使用者自由進行選擇。
跨語言方面經過提供http + json的方式實現。

6.2 插件化

暫不考慮，做爲v2版本實現，由於目前不須要考慮註冊/訂閱和監控模塊。

6.3 負載均衡

目前包含兩類實現：隨機路由(random)，依據服務提供者負載進行均衡路由(load-autoaware)

Random:

Load Autoaware:

1. 具體服務的每一個provider在調用端都會維護一個水桶，桶中的水量即爲從該客戶端發往該provider的，且還沒有返回響應的請求量，請求發往該provider時，桶中增長水量，該請求的響應返回時，從桶中減小水量
2. 某個服務的請求，發往該服務的全部provider中，對應桶中水量最少的那個provider，由於水量最少，代表當前其處理能力最強---負載最低) 

6.4 異常處理

將異常與正常返回區別對待，正常返回使用object::response.return，異常使用throwable::response.error返回，以便服務端異常序列化後傳遞到客戶端，客戶端沒有該異常的完整結構信息時，可以反序列化爲throwable對象，而非沒法反序列化或反序列化爲map。

序列化或反序列化過程當中出現異常，須要模擬爲error response返回給調用端，以便調用端知曉具體的異常信息。

業務異常須要enrich上相關的遠程調用信息，如請求派發的地址，請求類型，請求sequence，請求超時時間等，以便快速定位異常。

6.5 傳輸協議設計

+----------------+----------------------+-------------------+----------------------+------------------------+----------------------+------------------+
| magic (2 bytes)|  serialize (1 byte)  | sequence(8 bytes) | message type(1 byte) | expand region(8 bytes) | body length(4 bytes) |   message body   |
+----------------+----------------------+-------------------+----------------------+------------------------+----------------------+------------------+

magic: magic number
serialize: 標記使用的是什麼序列化協議(目前支持hessian, java)
sequence: 該次請求的序列號
message type: 消息類型(業務調用/心跳/業務異常/框架異常)
expand region: 預留擴展區
body length: body區的長度
message body: 消息body區 

6.6 線程規範

使用統一的threadfactory和threadpool，以便對線程規範命名，統一監控定位，以及後續的統一優化。

6.7 上下文傳遞

須要區分爲session context與transient context，區別以下：
session context：在每次rpc調用時，從client端一直傳遞到server端，並從server端返回到client端。
transient context: 僅在client端或server端傳遞，如client端的invoke chain，server端的process chain上傳遞，不會傳遞到相對的另外一端。
使用tracker context(session context)進行分佈式調用的調用信息跟蹤。

6.8 關於超時

因爲對目前公司各業務項目的性能控制狀況不瞭解，而且支付交易系統對數據完整性有極高的要求，因此謹慎起見，將框架的默認RPC超時時間設置爲15s，若超過15s仍不返回，則視做超時，且現階段不對超時作傳遞計算的優化處理。

6.9 http接口

開發排期較緊，開發完畢後，再一次性補充設計文檔內容！！！

 

測試文檔

測試範圍

1.    同步應答接口功能，http協議，測試該接口的各類調用方法以及成功率

2.    異步應答接口功能，binary協議，4個接口爲：sync，oneway，future，callback

3.    註冊中心控臺功能測試，包含：權重配比功能，動態增減server服務，配置生效的實時性以及心跳帶來的容錯處理機制

4.    性能測試，主要包含穩定性測試和容量測試的評估，模擬異常狀況下系統運行狀況以及容錯效率的提高

測試計劃

• 各測試階段資源要求

測試任務	人員	方法或工具
測試計劃以及測試策略	張林	文檔描述
功能測試	張林、龔建林	調用接口，工具ecplise junit
性能測試	張林、馬莉莉	執行工具jmeter或loadrunner
其餘任務

•  時間計劃

里程碑任務	工做量	計劃開始日期	計劃結束日期	人員安排
制訂測試計劃	1d	2013-7-29	2013-7-29	張林
設計測試用例	3d	2013-7-30	2013-8-1	張林、龔建林
執行功能測試	3d	2013-8-2	2013-8-6	張林、馬莉莉、龔建林
執行性能測試	3d	2013-8-7	2013-8-9	張林、馬莉莉
實際應用測試	3d	2013-8-12	2013-8-14	功能測試組（錢管家）

測試策略

• 測試需求

功能：

註冊中心控臺功能測試，該功能有2個

1. 權重能夠自由設置配比，從而達到各類配比功能
2. 自由動態的擴展server服務

性能：

這次性能測試，主要測試該系統在正常運行時，其穩定性和容錯性，在正常運行狀況下，該系統的內存消耗以及對於服務器的cpu消耗狀況，在發生錯誤或者異常的狀況下，該系統是否可以無錯誤的繼續運行，從而構建一個穩定，高效，容錯，易維護，可監控的服務調用框架。

接口：

本次測試的接口有5個，分別以下：

1. 同步應答接口，http協議
2. 4個異步應答接口，binary協議，分別爲：sync，oneway，future，callback
   
   

• 測試類型及方法

測試方法：

本次測試，將通訊中間件基礎服務提供的jar包，以應用的形式，部署在本地，提供接口供客戶端訪問及調用。

1.    根據不一樣的接口，採起不一樣的調用方式，模擬各類類型如String,int,long等的調用，檢驗接口返回是否正確。

2.    根據不一樣的接口，模擬報異常的狀況傳送給客戶端及服務端，檢驗服務端或者客戶端對於異常處理的狀況是否知足需求。

註冊中心權重配比功能測試：

Case 1

測試目標	檢驗server權重分爲0表示服務中止工做
測試方法	將2臺機器的權重配比更改，如：server1權重改成0，server2改成1
完成標準	當server1改成0，server2改成1以後，server1中止工做，檢查系統運行狀態或者觀察日誌去判斷

Case 2

測試目標	權重分配後，其是否實時生效
測試方法	將server服務權重同時設置爲0或者同時設置爲1-10不等，檢驗系統是否可以實時暫停服務或者運行服務
完成標準	同時設置爲0時，系統暫停工做，客戶端響應報錯 同時開啓權重1-10不等，檢驗系統是否可以當即工做

Case 3

測試目標	檢測權重分配比例是否生效
測試方法	初始狀態：server權重都爲5 將server的權重配置，一個改成1，另一個改成9，檢驗其發送的請求是否按照1比9的比例，流向server服務
完成標準	經過觀察cpu的消耗來模糊的觀察壓力分佈，經過日誌的計數，來觀察精細的壓力分佈

Case 4

測試目標	心跳異常測試
測試方法	大量的發送請求至server端，忽然將某臺server權重設置爲0
完成標準	客戶端不報超時錯誤，但該請求的響應時間要長與其餘請求的時間 計算髮送請求的總數是否和server端處理的總數一致（觀察日誌能夠檢驗）

Case 5

測試目標	找不一樣配置的機器做爲server端，檢驗配比效果是否與預期一致
測試方法	找配置比例差距較大的server服務（2C和4C和32C）
完成標準	完成各類配比檢測（在機器不出現任何異常的狀況下），按照實際配比進行請求流向分配，經過日誌能夠查詢

註冊中心增減server功能測試

Case 1

測試目標	增長一臺server服務後，該服務可以正常接受請求
測試方法	手動配置一臺新的server服務，查看後臺日誌是否接收到請求
完成標準	添加完server服務，該應用可以正常運行起到分流減壓做用

Case 2

測試目標	減小一臺server服務，系統不受影響，可以正常運行
測試方法	將權重設置爲0再刪除該應用
完成標準	可以成功刪除該server並經過日誌查看該應用再也不接受到請求

Case 3

測試目標	增長或刪除server服務過程當中，不對其餘server形成任何功能上的影響
測試方法	增長或者server服務
完成標準	在增長或減小過程當中，其餘server正常運行，無任何異常狀況出現

性能測試：

測試目標	檢驗系統的所能承受的最大請求數（TPS）
測試方法	模擬用戶發送請求，觀察測試指標
完成標準	容量測試，主要測出最大值，結果待定（需評審）