開端
隨著公司層面對產(chǎn)品方向的調(diào)整，最近團隊進入了一個找方向的階段，雖然大家都清楚我們最終要達到的目標是什么，但怎么到達那里卻不是一件顯而易見的事情，于是開了幾天頭腦風暴的會，列出了我們近期，短期，中長期要做的事情。其中一項內(nèi)容是在近期要做一個 SAAS 平臺，而這個平臺的構(gòu)架設計工作就是我這兩天的工作內(nèi)容。
設計思考
架構(gòu)是面向問題，而滿足需求的。所以第一步的工作是識別問題。我們要做一個 IOT 領域的 SAAS 服務，那么主要的問題有以下三點：
- 大量的鏈接
- 超大的數(shù)據(jù)量
- 多租戶之間的數(shù)據(jù)隔離
識別問題之后，就是尋找方案來解決問題，目前業(yè)界并沒有一個針對 IOT 領域的 SAAS 服務的參考架構(gòu)，但針對大并發(fā)，大數(shù)據(jù)的問題，我們一般采用分布式集群來解決。
- 按連接數(shù)調(diào)整應用的實例
根據(jù)每個租戶的設備連接數(shù)，為租戶啟動1～n 份應用實例。
但這樣的架構(gòu)有一個問題，有些租戶的設備很多，但數(shù)據(jù)上報的頻率低，而有些租戶設備不是很多，數(shù)據(jù)上報的頻率很高。對一個應用來說，計算量是跟數(shù)據(jù)量相關(guān)的，而連接數(shù)不能完全體現(xiàn)數(shù)據(jù)量，所以不能根據(jù)設備連接數(shù)來決定應用實例數(shù)量。
- 使用網(wǎng)關(guān)來管理連接和收發(fā)數(shù)據(jù)
統(tǒng)一使用網(wǎng)關(guān)來管理連接和收發(fā)數(shù)據(jù)，連接與應用實例解偶。雖然每條連接上傳輸?shù)臄?shù)據(jù)量有差別，但網(wǎng)關(guān)集群中每個網(wǎng)關(guān)上的連接是隨機分配的，所以每個網(wǎng)關(guān)上收發(fā)的數(shù)據(jù)是比較平均的。
這個架構(gòu)的問題是所有的應用實例和所有的網(wǎng)關(guān)都要保持連接，網(wǎng)關(guān)在收到數(shù)據(jù)時，需要選擇轉(zhuǎn)給哪一個應用實例，這樣的多對多關(guān)系，限制了系統(tǒng)的伸縮性。
- 使用消息中間件解偶網(wǎng)關(guān)與應用程序
網(wǎng)關(guān)在收到數(shù)據(jù)之后，把數(shù)據(jù)扔到消息中間件中相應租戶的消息隊列里，應用實例啟動之后，訂閱相應租戶的消息隊列。
到這里這個簡單的架構(gòu)基本就出來了，使用分布式集群網(wǎng)關(guān)解決大量連接和海量數(shù)據(jù)傳輸?shù)膯栴}，使用分布式集群的應用實例來解決海量數(shù)據(jù)的處理問題，使用消息的訂閱發(fā)布的不同主題來解決租戶間數(shù)據(jù)隔離的問題。
但這里遺留了兩個問題沒有解決：
- 租戶對應的設備數(shù)據(jù)量和用戶請求數(shù)不匹配
- 租戶的設備可能所屬不同的租戶的用戶
對于第一個問題，系統(tǒng)應該分離設備數(shù)據(jù)處理邏輯和用戶請求處理邏輯。而第二個問題應用可以根據(jù)數(shù)據(jù)歸屬設備來自行處理。但考慮到我們的 SAAS 服務針對的是工廠或者企業(yè)，不面向消費品市場，所以可以不考慮用戶訪問量大和設備歸屬不同用戶的問題。
架構(gòu)師的格局
第二天當我把這份設計拿給我們的首席架構(gòu)師時，他問了我一個問題：為什么要做一個 SAAS 服務。其實在我們的方向和規(guī)劃里，我們最后會是一個 IOT 領域里的 PAAS ，而 SAAS 只是我們在這個方向上的第一步，起到技術(shù)積累的作用。我們的 PAAS 也可以通過多個 SAAS 間相同功能模塊下沉而不斷豐滿起來。
首席架構(gòu)師說道：路線沒什么問題，但做為架構(gòu)師，眼界不能只放在眼前。既然你們決定要做一個 PAAS 平臺，那么一開始你就要劃清楚 PAAS 的范圍，哪些是 PAAS 的職責，哪些是 SAAS 的職責。所以你應該先出一個 PAAS 平臺的架構(gòu)圖。
PAAS 平臺架構(gòu)設計
根據(jù) Gartner 的定義， PAAS 分為 aPAAS 和 iPAAS 兩類。對于 aPAAS，開源世界現(xiàn)在已經(jīng)有比較成熟的解決方案了。基于 kubernetes 和 deis 完全可以定制出一個滿足以下需求的 aPAAS 。
- 應用的隔離，每個應用獨立的運行環(huán)境（基于容器技術(shù)： docker）
- 易于更新應用程序，部署友好（基于 deis）
- 應用的高可用，應用故障后自動重啟（基于 kubernetes）
- 應用的在線伸縮性，不停機下增加或減少應用的實例（基于 kubernetes）
- 應用的監(jiān)控，報警 （基于 Heapster）
接下來是 iPAAS 的部分了。做為 IOT 領域，首先要解決的就是應用與設備的通訊問題。這個部分在前面 SAAS 部分已經(jīng)說過了，接下來要思考的是還有哪些服務是 PAAS 應該包含的。
- 會員服務
- 鑒權(quán)服務
- 存儲服務
- 消息中間件
- 消息推送服務
以上五種服務是一個通用應用程序會需要用到的服務，而跟 IOT 關(guān)系的體現(xiàn)則是在具體設計這些服務時要重點考慮的問題。
領悟
產(chǎn)品或者項目可以按照敏捷的思路推進，程序也可以按照 TDD 實踐來開發(fā)，然而做為架構(gòu)師，則需要在一開始就劃清系統(tǒng)的范圍，知道邊界在哪里，系統(tǒng)間的關(guān)系是怎么樣的。范圍清晰了，才能識別全系統(tǒng)的問題集，才能談概念完整性問題。
