[筆記]高階IT架構師座談會(3)

Session 3 如何設計以服務為導向的企業資訊架構

3.1 DB的相關處理 : 全部都用stored procedure 切開 千萬別直接操作DB

3.2 Data Layer Service : 建議call sp 的東西做成元件
進而做成服務

3.3 SOA常見的錯誤開發方式

        (1) 開發習慣改不過來
程式間仍bind太緊

   (2) 僅僅將元件變成Service並不是SOA的精神

   (3) 常做出只滿足前端某一需求的服務 (不夠自由)

   (4) Service要跨平台時Message不要使用該語言的特性

      建議回歸基本的型別 or 按照wsdl規定

      顧問們一致推薦JSON

      ps. 若資料量太大
可使用Google Protocol Buffer 來處理

   (5) Framework的Base寫超大是浪費 很多人只是用到其中一小塊功能

      建議透過不同的Interface去控制版本 好處是當Base擴充新功能 舊版仍讀舊的Interface就不會影響到

3.4  SOA應該是以服務為導向的架構

(1) 一定要鬆
才能重複使用

(2) 單一窗口對外
然後再導向其他Service

    (3) Service是給系統使用
而不是人

    (4) 設計Service時 建議倒過來想 從最前端開始設計

    (5) 必須要有一組專門的團隊來開發Service 不然開發者很容易因為其他案子而分心 效果不佳 (開發Framework也是)

3.5 SOA的表面好處與實際問題

   3.5.1
提升投資效益

        但實際上效益無法保證

   3.5.2
提升組織敏捷性

        但實際上有時會面臨以下問題 :

(1)
Interface會設計的過於複雜

(2) 平台與技術上的限制

   3.5.3
減輕IT負擔

        因為Service要對外服務 所以必須確保高可靠性及高獲得性

        反而需要更多心力去維護

3.6 服務導向原則 :

  ps. 描述 from wiki

  http://en.wikipedia.org/wiki/Service-oriented_architecture

(1) 標準化合約

   (2) 鬆散耦合

   (3) 抽象化

          除了服務契約中所描述的內容，服務將對外部隱藏邏輯

   (4) 重複使用

      將邏輯分佈在不同的服務中，以提高服務的重用性

   (5) 自主性

      服務對所封裝的邏輯具有控制權

   (6) 無狀態性

      服務將一個活動所需保存的資訊最小化

   (7) 可被探索性

服務需要對外部提供描述資訊，這樣可以通過現有的發現機制發現並訪問這些服務

   (8) 可組合性

一組服務可以協調工作並組合起來形成一個組合服務

3.7 訂閱者模式的架構能使用SOA嗎?

    座談中 我有請教一下顧問們 如果是 訂閱者模式的架構

    該如何引進SOA? 適合用SOA來處理嗎?

    胡顧問的回答是 雙向都能當作服務 但要避免依賴性的問題

    張顧問的回答是 可以切成兩塊 一塊realtime 一塊用batch來處理

    當下我沒想懂他們在說什麼 後來思考了一下 或許可用以下模式進行

    1. Service1 接收Client端需求者 要記錄Client位置

    2. Service2 主動發送端 => 一旦有新資料 就呼叫Service1

        讓Service1決定送什麼資料給誰