軟件設計要素初探：應用模型

在 「軟件設計要素初探」 一文，嘗試從軟件設計的總體角度，綜合討論了軟件設計的各類要素。本文討論構建軟件可採用的應用模型。

應用模型涉及到數據處理與響應的全局流程和交互方式。 我所接觸過的，主要有「請求-響應模型」、「流處理模型」、「分佈式模型」、「人機交互模型」。

請求-響應模型

Web應用一般採用「客戶端請求-服務端響應」模型。主要有「同步」和「異步」兩種方式。

同步是服務端將請求處理完成後直接將結果返回給客戶端，一般適用於很是快速完成的任務；異步是服務端先返回給客戶端一個響應，而後在後臺啓動任務來處理請求。處理完請求後將結果存儲到指定位置，或者通知客戶端。異步適用於耗時長的批處理任務。

不管是同步仍是異步，處理請求時均可以採用併發的方式來提高性能和可擴展性。併發會帶來不肯定性、死鎖、理解、調試以及測試的複雜性等，須要仔細權衡。一般耗時長的批量任務須要採用併發異步的模式，大多數服務請求可採用「順序-同步」模式。

「同步-異步」是請求的接收與返回形式，「順序-併發」是請求的處理形式。兩兩組合，可衍生出請求的四種「接收-處理-響應」方式。擇善而行之。

流處理模型

海量數據的(準)實時計算應用可採用流處理模型。好比Storm應用預先構建一個用於數據流處理的拓撲結構，運行時將進入拓撲的數據流「發射」到拓撲中的並行工做的工做節點，而每一個工做節點亦能發射處理過的數據流到相鄰的工做節點，依次處理直到在拓撲的終節點獲得最終結果。訂單同步採用了Storm技術，從消息中間件中獲取消息數據，並同步到Hbase中。

使用storm框架開發分佈式實時應用時，主要包括三部分：

• 任務拆分和拓撲構建
• 消息設計/分組/併發處理/ACK
• 同步延遲監控與告警。

對於涉及金額的敏感的消息處理，(準)實時同步應用尤爲要注意添加延遲監控報警。

人機交互模型

人機交互模型，經過人與計算設備的持續而緊密的交互活動來完成應用服務與功能。

流處理模型和分佈式模型，一般是客戶端感知不到的後臺基礎服務；請求-響應模型，一般是人與互聯網的間歇性交互；而人機交互模型，一般着重於視覺和交互設計的友好性、易用性和吸引力，是軟件之形之觀。設計優秀的人機交互在某種程度上會彌補內在功能的不完善，讓已有功能服務發揮的更加出色。

分佈式模型

分佈式模型更可能是一種部署的結構，將部署在不一樣機器上的大量普通服務器應用經過聯網的分佈式的結構組織起來，共同協做來完成高性能計算和高可用服務目標。熟知的互聯網便是一種超大規模的分佈式系統。阿里雲ECS控制系統架構，也採用分佈式模型。以下圖所示：

分佈式體如今以下兩點：

(1) 控制系統與部署在Linux集羣上的上千個NC(每一個NC上運行着若干VM)之間的交互。控制系統訪問RegionDB，根據必定的算法，識別VM所在NC，而後向指定物理機發送虛擬化、存儲、網絡命令，NC接收到命令後，控制指定VM做出正確變動，並向可靠消息組件RMS推送消息，控制系統接收到消息後更新RegionDB信息。集羣上的NC/VM還必須經過可靠心跳服務組件RHS上報心跳，及時識別和修復故障VM。 NC 是物理機上實現的邏輯控制器(NodeController)，每一個NC都是集羣的一個節點。分佈式系統一般是以集羣爲單位部署。

(2) 從總體看來，多臺部署的ECSOpenAPI、部署於全部Region的ECS業務系統，部署於全部Region的控制系統，部署於全部Region的Linux集羣、分佈式緩存組件 Tair、消息組件 RMS、消息心跳 RHS ，構成了一個大型分佈式服務系統， 即：ECS彈性計算服務。

部署結構在必定程度上會影響設計決策。爲了能經過添加更多機器來水平擴展集羣的服務能力，設計上要求請求無狀態。分佈式模型適用於搭建大型計算基礎能力與服務。