soa實施要點：
1、soa
的構建次序。是從上到下還是從下到上？我個人傾向於從大局進行把握，因為
soa中重要的不是技術，而是對業務的定位。如果從下往上去設計服務的話可能會做很多重複勞動工作，或者在真正去用的時候返工。應該在設計的時候進行足夠的需求調研，挖掘出業務的核心並對外提供。但是設計時候肯定會有很多沒考慮到的東西，或者說想的過於粗，那麼在開發的時候也可以進一步去討論需要公開的服務，補充上粒度比較細的那一部分。也就是說先把握大局從上到下，然後抓住細節從下到上。 2、
soa的測試過程。作為客戶端程式，在需要的服務尚未建立的時候，需要自己建立基於介面的
fake
服務進行測試，等服務在網路端點上部署之後使用服務**進行替換（當然，理想的方式是由客戶端**自動生成
fake
服務和測試資料）。作為服務的主辦者，需要在服務發布之前對服務的邊界、邏輯和效能進行嚴格的測試，作為服務端是不知道我的客戶是什麼的，我要處理所有可能的情況。 3、
soa的持續建設。雖然說契約是不變的，但不代表服務不變。服務的業務邏輯是需要不斷完善的。服務也是可以擴充的。沒有什麼事情是在一開始的時候就完美的，如果服務沒有持續建設作為保障的話，可能花費很大時間做出來的服務並沒有多少人願意來使用，導致整個服務層越來越孤立越來越偏離
soa，最終導致
soa實施的失敗。我們不要去怕服務做的不好，不好的地方就去不斷修正，如果服務沒有客戶來消費的話那就很危險了。 4、
soa的基礎結構。不管是叫
esb或者其他什麼名詞，基礎結構總是需要的，而且應該在實施前進行這個基礎結構的建設。其中有一些東西是非常重要的。一是可靠性的保證服務，比如如何去做服務的負載均衡，如何去做事務，如何去做服務的流量控制，如何實現訊息的加密和安全。第二是服務的監控和管理，比如服務呼叫的異常記錄，系統的狀態，系統的配置，系統的部署。第三是服務的中介，比如服務的路由、非同步佇列、訊息轉換。第四點是服務的管理平台的平台，比如流程管理、契約管理、部署管理。從技術上說這個基礎結構應該是盡量對開發人員透明的，並且也是也是需要不多的人為的參與，以**生成工具、
aop、管理工具等方式實現。這一套框架是
soa開發前期需要完成的，也是技術難度最大的。在完成後對開發人員進行技術上的培訓和流程上的培訓。
soa概念誤解：
1、soa
不是技術（當然也不是
web服務）、不是產品、不是新概念、不是一塵不變的。
soa是so的
a，也就是說是符合面向服務思想的架構（可能需要
web服務作為某項技術來參與，但不能說它就是
web服務）。
soa的成功需要一套產品的支援，但本身不是產品。
soa為什麼不是新概念？我們生活中需要用到各種服務，我們只需要按照要求，寫一些**（契約），對方就會給我們結果，這不是
soa是什麼，計算機硬體中很多地方也是
soa的思想（其實我一直覺得軟體工程走在硬體工程的後面，很多開發上的思想在硬體設計中都能找到原型）。
soa沒有實施結束的那一天，一定是不斷變化不斷改進的。 2、
soa可大可小，可以是企業內部的，也可以是企業與企業間的，可以是同構平台也可以是異構平台，因此，
soa很難套用，甚至沒有哪個公司對
soa的實施是一模一樣的。
soa可能會很簡單也可能會很複雜，複雜不是說技術上的複雜，很多時候在於管理上的複雜性，因為裡面融合了業務，業務是會變化的。複雜性還體現在可能是基於老系統進行實施，需要考慮到資料相容問題以及資料集中的問題。 3、
soa不一定是一層的。沒有規定服務的消費者一定是客戶端，服務的消費者可以是服務，也就是服務的組合，多層的服務能進一步提高重用。
文章 實施SOA治理
todd biske是一位在世界500強企業任職的企業架構師。在這篇文章中，他為成功實施soa治理提供了指導。他建議採取注重策略的定義與貫徹的三個步驟 todd建議設立乙個soa卓越中心 最常見的做法是設立乙個卓越中心 center of excellence，簡稱coe 卓越中心由多個部門的領導組...
實施SOA，就是「殺人遊戲」
剛剛玩過殺人遊戲，剛有點體會，看到這篇文章覺得很有道理，轉過來分享。實施soa，就是 殺人遊戲 想必很多人都玩過 殺人遊戲 在乙個中立的法官的主持下，根據其他人的分析和判斷，盡快找到 贏得勝利，反之則失敗。殺人遊戲中有這樣一些角色 法官 警察 平民 殺手。法官保持中立，其中殺手可以殺警察和平民，勝利...
Soa設計概念
快取，訊息，rpc，檔案，日誌，配置，資料流，監控，通知，服務發現 服務的註冊與發現 zookeeper 中儲存的資訊，如下圖 關於controller與action的資訊，在服務啟動的時候就已經註冊到服務中心去，儲存到資料庫中 系統名稱 controller action zk 上則保留 系統名稱...