講在前面的話： 若企業缺乏對服務變更的控制和規則，那麼一個服務在經過幾個專案之後，就很有可能被隨意更改成多個版本，將來變成什麼樣更是無法預測。久而久之，降低了服務重用的可能性，提高了服務利用的成本。 服務治理在SOA實施之初的作用不明顯，甚至在一定程度上影響到專案的進展，但隨著SOA實施深入開展和服務數量的增加，其作用會越來越明顯。正如SOA架構通過引入了多個層級，在一定程度上犧牲單筆服務呼叫的效率卻換來架構的靈活性一樣。 什麼是SOA 面向服務的體系結構（SOA）是一個元件模型，它將應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的介面和契約（規範）聯絡起來。 SOA的定義 面向服務架構，它可以根據需求通過網路對鬆散耦合的粗粒度應用元件進行分散式部署、組合和使用。服務層是SOA的基礎，可以直接被應用呼叫，從而有效控制系統中與軟體代理互動的人為依賴性。 SOA的優勢 對 SOA 的需要來源於需要使業務，讓服務變得更加靈活，以適應業務中的改變。更好的實現業務驅動。 SOA具有低耦合性特點，業務夥伴對整個業務系統的影響較低。 SOA的特性 暴露API，可從企業外部訪問 隨時可用 鬆散耦合 可重用的服務（與重組服務） 標準化的服務介面 精確定義的服務契約 ... SOA四大支柱 團隊合作 理念共識 紀律規範 範圍邊界 SOA八個原則 標準化服務合同原則 服務鬆散耦合原則 服務的抽象原則 服務可重用性原則 服務自治原則（服務合同定義良好功能邊界，避免服務重疊） 服務無狀態原則？ 服務可發現原則 服務可組合原則 服務治理的重要性 服務是SOA的核心。按其願景，在新專案設計實施過程中，專案團隊通常會面臨如下問題： 1.企業有無服務目錄，服務目錄在哪裡？ 2.哪些服務可在新專案實施中重用？ 3.需要新開發哪些功能，這些功能是否要封裝成服務，供其他應用使用？ 4.當新系統所需要的某一功能已經存在於某一現有系統之中，但是並非以服務形式出現時，是否要對它進行封裝，如何封裝？ 5.服務的呼叫是否必須經過企業服務匯流排（ESB、dubbo_zk），何種情況下必須經過ESB，何種情況下不需要？ 6.當某個現有服務功能部門滿足某項需求時，如何對服務進行改造和版本控制？ 7.待開發的新系統是對某個舊系統的升級，那麼舊系統提供的服務何時中止，用新系統中的服務替換，還是將服務升級成另一種形式？ 8.服務來自於哪個系統，被哪些系統所用？ 9.服務由誰負責管理和維護？ 10.服務可被哪些人或角色有許可權訪問？ 如何服務治理 1、建立服務倉庫 2、制定治理規範   服務定義（服務的範圍、介面和邊界）   服務部署生命週期（各個生命週期階段）   服務版本治理（包括相容性）   服務變更（啟用和退役）   服務註冊中心（依賴關係）   服務監視（進行問題確定）   服務所有權（企業組織）   服務測試（重複測試）   服務安全（包括可接受的保護範圍）