一、什么是SOA
SOA即面向服務的架構。分為三層結構：表示層（服務層）、中間業務邏輯層、數據訪問層。
SOA是一種粗粒度、松耦合服務架構，服務之間通過簡單、精確定義接口進行通訊，不涉及底層編程接口和通訊模型。SOA可以看作是B/S模型、XML（標准通用標記語言的子集）/Web Service技術之后的自然延伸。
它提供了構建系統的標准和方法，可以通過建立組合、復用等服務方法減少業務冗余並通過服務協同合作來加快項目開發的速度。
我們通過網絡上的幾個小例子來解釋一下SOA：
第一個：
假設我要做幾道菜：
1.麻婆豆腐
2.素炒小青菜
3.西紅柿炒蛋
以前我的做法：
我要做麻婆豆腐，先洗豆腐，然后找到豆瓣醬，把豆瓣醬炸出香味，然后我想到還需要辣椒，我就去切辣椒，切完辣椒放進去后，我發現還需要姜蒜，我去切了姜蒜，然后和燒好的豆瓣醬一起煎出香味，倒入豆腐翻兩圈開始燜。
燜好麻婆豆腐之后，我要素炒小青菜。
我立即去洗小青菜，然后燒好油后發現還少了姜蒜，我就去切姜蒜，一陣手忙腳亂，小青菜炒好了。
如此重復進行炒西紅柿炒蛋。
有了SOA之后：
先剁好一小碗姜末；再剁好一小碗蒜末；切好青菜，找好豆瓣醬，洗好豆腐，切好西紅柿
然后，我想要什么服務，直接取。（這里來說是一個人的SOA）
后來，我為了想提高效率，叫其他人來一起幫忙准備這些材料,后面，有10個朋友來我家，要做的菜式更多了，然后我叫幾個朋友一起幫忙准備各種材料。
這里面的思想還可以發散。
我想了一下，再補充一下
對於第一種情況，假設我每種菜要做10份，那么再叫來9個人和我一起重復上面的事情（多個服務器部署同一套系統）
而后面有了SOA,我每一個人就只關注自己的具體邏輯，比如切青菜的專門切青菜，洗青菜的專門洗青菜等等，對於廚師（用戶），想要做一份西紅柿炒蛋，那他就去拿西紅柿和打好的蛋就好了，分工明確，各司其職。
第二個：
統一文字，在秦始皇統一六國之前，各國的文字是不統一的，據說許多常用的文字有十幾種寫法和讀音，妨礙了各國之間的文化交流，就象SOA之前，各種軟件平台、各種開發工具和各種接口的組件之間，沒有統一的標准，對軟件系統之間的整合造成巨大的困難。
因此，偉大的始皇帝統一了六國文字，“書同文、車同軌”就是通過標准解決“復用”和“互操作”等問題。這也為大規模的印刷和文明發展提供了一個良好的基礎，這種“統一封裝”的文字，對文化交流起到了一個“互操作”的標准作用
二、為什么需要SOA三層架構
SOA的實施具有幾個鮮明的基本特征：
粗粒度的服務接口分級，松散耦合，可重用的服務，服務接口設計管理，標准化的服務接口，支持各種消息模式，精確定義的服務契約等。
SOA可以使每個模塊獨立出來，用什么取什么。即使模塊出現問題，也可以用備份模塊代替即可。不影響系統的整個運行。每個人的分工也非常明確，各司其職。
三、SOA案例分析
蘇寧易購商品詳情設計：
商品詳情系統介紹
基本介紹
商品詳情系統是一個展示商品基本信息、參數等詳情的系統，是商品購買的入口。它是電商平台中訪問量最大的系統之一，蘇寧易購大促期間PV量和UV量很大，這么大的訪問量對系統的並發能力要求高。在業務上它與周邊系統的關系是高耦合。依賴商品詳情系統的的系統特別多，比如：促銷系統、推薦系統、大聚惠、等眾多營銷系統、還有主數據系統、購物車、收藏夾等，業務復雜度高對系統設計提出更多的要求。
業務特點
重點在於數據展示
頁面信息豐富，如：商品詳情、商家列表、推薦、排行榜等
部分數據時效要求高，如：價格、庫存等
業務上依賴的系統多
商品詳情系統三要素
1. 展示
產品上需要設計好頁面區分展示的內容
技術上主要是頁面緩存設計、前端頁面模版和JAVA程序的解耦
2. 數據處理
數據全部來源於其它系統，在數據上分為：
基本數據，外部系統傳過來直接就可以使用的數據
聚合數據，需要加工才能使用的數據
3. 服務依賴
通過MQ解耦，異構數據
解決好以上三個問題就解決了此系統核心問題。
系統邏輯架構
商品詳情系統在設計上分成前、中、后三層結構
前台負責展示，做為VIEW層不處理業務邏輯，負責渲染。
中台負責業務邏輯處理，提供數據給前台，同時還會對外部系統提供服務
后台負責主數據管理，做為數據管理層處理商品主數據、參數、品牌、供應商等，同時部分內容開放給運營進行維護、管理和異常處理等。
前台設計
頁面設計：
1. 動靜分離
JavaScript、CSS統一放到公共的靜態服務器上，完全獨立的子域名，防止臟Cookie問題和動態域名中無用Cookie問題，通過文件版本號解決系統新版和舊版本之間沖突問題。
所有圖片由獨立的分布式圖片系統管理，對原圖進行不同規格的無損裁減和壓縮。
2. 異步加載和懶加載
商品價格、營銷活動信息、庫存等動態數據通過異步加載
非首屏數據做懶加載處理，提高首屏加載時間，比如評價、商品詳情等內容
3. 多級緩存策略
a. 瀏覽器本地緩存
協商緩存，對於某些時效要求較高的資源通過Last-modified控制數據。做到StatusCode=304
強緩存，JS、CSS等靜態資源或者一些頁面碎片偽靜態數據通過Expires、Cache-Control(http1.1支持)設置做到強緩存，在不強制刷新的情況下可以做到200(from cache)
b. CDN緩存
CDN分兩條線有自營CDN和合作商的CDN，圖片、靜態資源與偽靜態數據分
別放在不到的CDN上
c. Varnish緩存
Varnish在設計上負載使用輪詢方式，不使用URL HASH策略，用空間換時間的策略， 從而避免熱數據問題，也支持橫向擴展。
Varnish 緩存和CDN緩存在失效時間錯開，從而避免同時失效回源壓力過大。
d. 精准緩存
精准緩存失效用於促銷活動准時展示的場景，基於Varnish緩存，通過精准控制緩存有效期實現緩存精准失效保證促銷活動准時切換。
組件邏輯設計：
商品詳情系統中的購買按鈕和加入購物車會因商品不同走不同的流程。如：大聚惠商品、定金團商品、預售商品等因促銷方式不同，走不同的業務處理流程。促銷模式變化多端，可能每個月都會有變化，通常的面向接口編程和加上工廠方法或者依賴管理框架Spring也很難做到真正的解耦，雖然這樣做已經符合開閉原則。我們通過觀察者模式很好的解決了這個問題。讓前端的頁面模版和JAVA應用程序之間真正的解耦。
后台設計
商品數據統一處理設計
商品詳情系統商品主數據通過MQ消息來源於外部系統，比如：商品基本信息、參數、參數模版、品牌、品類等。我們設計時把共性抽出來分成三部分：
接受MQ消息並持久化通過Listener
解析報文
業務處理上簡化為add、update、delete三個動作
異常組件以觀察者模式實現，記錄處理失敗的MQ消息並對消息進行截取，並供下次再反向執行(一條MQ消息中會有一到多條參數、品牌，所以這里用截取)