關於服務化,以及軟件系統的服務化,是一個大的概念。我經過一些以服務化爲主題的文章輸出,總結下來服務化是一種思想,是一種軟件過程,並無嚴格的非此及彼的標準化定義,可是有必定的量化指標能夠參考。前端
話又說回來,軟件開發是一項工程行爲,按照軟件開發的定義,是有一套理論基礎做爲支撐的,在大學教育裏有專門的軟件工程專業。服務器
本文試圖在軟件開發理論與中小型軟件項目的最佳實踐的基礎之上,探尋最大程度的軟件系統服務化。網絡
服務化系統首先應該是分佈式的系統。
分佈式系統是由一組經過網絡進行通訊、爲了完成共同的任務而協調工做的計算機節點組成的系統。分佈式系統有如下幾個特徵:分佈式
副本(Replica)是分佈式系統最多見的概念之一,指分佈式系統對數據和服務提供的一種冗餘方式。在常見的分佈式系統中,爲了對外提供高可用的服務,咱們每每會對數據和服務進行副本處理。有副本的概念,就會關聯到副本數據一致性問題。spa
不要擔憂故障,故障在分佈式系統中總會發生,咱們要作的是預防故障,處理故障。設計
分佈式系統的核心就是處理各類各樣的異常狀況。
服務交互的三種狀態,能夠理解爲網絡請求的三種狀態,「成功」、「失敗」、「超時」,blog
尤爲注意失敗和超時是不同的,失敗表明着明確的處理結果,而超時是一種不肯定的狀態。事務
這三種狀態的區分對於跨系統之間定義通信協議時很重要。開發
分佈式系統須要區別對待 RPC 的「成功」、「失敗」、「超時」三種狀態。當出現「超時」時,能夠經過發起讀取數據的操做以驗證 RPC 是否成功(例如銀行系統的作法)。rem
或者設計分佈式協議時將執行步驟設計爲可重試的,即具備所謂的「冪等性」。
失敗的操做在必定場景下能夠重試至成功。
【有些執行步驟是可重試的,而有些是不能重試的。冪等性的重點是其任意屢次執行所產生的影響均與一次執行的影響相同,在事務型設計中 保持冪等性是尤其重要的】
本文對冪等性不作過多介紹。
這裏回顧下,網絡通信中兩種通信模式 C/S模式和P2P模式,C/S模式強調的是客戶端發起和服務器端之間的角色定位,P2P模式認爲沒有嚴格的客戶端和服務端。
P2P模式下,在一組服務化的系統中,每個節點都是調用鏈中的一環,除了用戶最前端和數據持久化的最末端,幾乎每個節點都在向上遊獲取服務,向下遊提供服務。
顯然分佈式系統中,使用的通信模式都是P2P模式。
基於以上內容的理解,本文對服務化作一個簡單的定義
服務化是軟件服務的一個過程,是不斷更迭和完善的。有以下幾個可量化的屬性
共享性
1 服務化的系統最終功能交付物被多個下游系統依賴調用,調用方>=2。也就是一個服務是能夠被多個服務消費方共享使用的。服務須要獨立部署,不須要與其餘項目深度耦合。
有功能邊界
2 服務化的系統具備必定的抽象功能,抓大放小,解決系統核心功能及主要矛盾。
咱們須要定義系統的核心模塊及數量,也就是服務化的粒度
穩定性
3 服務化的系統要穩定,可靠,可控
健壯性
4 服務化的系統具備必定的健壯性,彈性。對於異常能夠進行平行過分,擁有降級等容錯機制。
彈性是服務化系統的一個特色,要求系統在遇到異常和外部破外時,可以保持原有最小化的功能輸出,不至於被壓倒。設計者在設計服務系統時,須要創建彈性思惟。
本文從分佈式的特色,服務交互狀態,以及網絡通信模型幾部分着手,基於理論,實踐,可複製性,覆盤開發經驗和理解的原則,對軟件服務化進行了4個緯度的定義。以後我會梳理一些開發案例進行分解。