SOA架構設計概要

主要內容也是來自《stevey對amazon和google平台的長篇大論》

我們理解的soa必然是通過介面的方式將資料與功能開放出來的，但要想要往平台方向發展，必須保證用且僅用服務介面的形式提供資料和服務：

團隊間的程式模組的資訊通訊，都要通過這些介面；

除此之外沒有其它的通訊方式。其他形式一概不允許：不能直接讀取其他團隊的資料庫、不能使用共享記憶體模式、不能使用別人模組的後門；

所有的程式都必須從骨子裡到表面都要設計成能對外界開放的。也就是說，團隊必須做好規劃與設計，以便把介面開放給全世界的程式設計師，沒有例外。

作為soa服務中的開發者，既不能相信為自己提供服務的應用（server），也不能相信訪問服務的應用（client）。

基本算老調重彈，因為沒有無故障的軟體，也沒有無故障的硬體，再加上千奇百怪的網路條件和完全料想不到的客戶，所以要處理異常（容錯）才是正常邏輯；而每乙個和你相關的團隊突然間都可能成為乙個潛在性的dos攻擊者。必須要為每乙個service設定配額（quota）與節流閥（throttling）的保護機制。

僅有乙個確定主程序不死的響應不是監控。如果測試覆蓋到能驗證所有業務邏輯的程度，當然是最好的。但我迄今為止，沒見過太多的團隊（僅有乙個團隊）完成了如此縝密細緻的測試用例。

我覺得比較理想的監控系統要讓業務人員「看到」業務在系統中的流轉。實現這樣的監控系統需要從以下幾方面著手：

把乙個服務拆解成1~3個關鍵的業務流程，每個流程有2~4個重要環節。

然後描畫出業務的時序圖，在圖上標出業務資料取樣點。

由兩種匹配模式，最佳模式是尋找乙個流程從上游到下游的資料關聯性，打個比方來說，乙個訂購流程，在一段時間內使用者發起的訂購請求是x，下游訂購成功的梳理是y，在一定範圍的業務週期內，應該能觀察得出y=f（x）的關係函式；

另外一種模式是無法獲得可以直接關聯的x和y。這種情況下只能通過對比環比資料來判斷是否異常了，對於依賴使用者行為的業務，準確性較低。

可以看出來，這個監控系統也是個分布式的。soa服務要拆解自己的業務，尋找取樣點，按照統一業務日誌格式進行記錄；

監控程式要能把資料進行彙總，按照預置匹配函式進行判斷，對超出閾值的情況進行告警。