SOA（Service-Oriented Architecture），中文全稱：面向服務的架構。
怎麼理解呢？
簡單來說就是把系統分解成一個個功能，然後用接口的方式進行交互
為什麼這麼搞？
來來看看網上
SOA對需要使用信息技術解決關鍵業務問題的企業（包括希望減少冗餘架構、創建跨客戶和員工系統的公共業務接口的企業；需要基於角色和工作流對用戶提供個性化信息的業務的企業；希望通過Internet實現跨區銷售、升級銷售和經由移動設備的訪問來提升客戶服務的組織）很有價值。
面向服務架構的業務好處
效率：將業務流程從"煙囪"狀的、重複的流程向維護成本較低的高度利用、共享服務應用轉變。
響應：迅速適應和傳送關鍵業務服務來滿足市場需求，為客戶、僱員和合作夥伴更高水準的服務。
適應性：更高效地轉入轉出讓整個業務變得複雜性和難度更小，達到節約時間和資金的目的。
面向服務架構的IT好處
複雜性降低：基於標準的兼容性，與點到點的集成相比降低了複雜性。
重用增加：通過重用以前開發和部署的共享服務，實現了更有效的應用程序/項目開發和交付。
遺留集成：用作可重用服務的遺留應用程序降低了維護和集成的成本。
來看看一個例子
很多開發人員，做系統的時候是這樣合作的：
小明負責【考勤】，小王負責【薪資】。
小王說： 小明，我要用【考勤】數據，你做好了沒？
小明說： 早做好了，表名叫Attenance, 字段A代表員工ID，字段B代表....自己去數據庫查。
相信很多人看到這種情景很熟悉， 數據交互完全通過數據庫，模塊件沒有完全分離，錯綜複雜！用不了多久，你的系統就成了一碗美味的“意大利麵”
這種開發方式不符合SOA的理念，那麼SOA是如何處理的呢？
1.考勤作為單獨模塊，成為一個考勤服務，發佈了一個考勤數據接口（WebServices）
2.小王需要使用考勤數據，調用考勤服務的接口即可
SOA是模塊分離，模塊間要進行數據交互，通過接口來完成！
很多程序員看了估計會不屑一顧，我們從不SOA，也過了這麼多年，並沒有什麼問題！看起來SOA並沒有什麼卵用！
在看看老闆活著需求放提出的問題
1. 平臺越來越龐大，有10幾個開發人員都要用你負責模塊的數據。
如果沒有統一接口，你要同所有人講你的數據庫結構。一旦變更，你還要通知所有人
2. 系統運行越來越慢，老闆說分離【考勤】和【薪資】使用不同的數據庫和服務器
由於功能間沒有嚴格分離，數據交互也是直接通過數據庫。分拆系統基本不可能，所以也就無從談論分開部署
3. 客戶的其他系統需要調用平臺的數據進行計算，你還要開放數據庫結構嗎？
功能沒有嚴格分離，當系統發展到一定層次，開發就會感覺越來越吃力，往往牽一髮而動全身，也不符合軟件設計原則！
但是如果你的系統本身就很小，一週就搞定了！要實行SOA，搭建個架構花費了一個月，這就得不償失了！
是否實行SOA，是要根據平臺的定位去調整的！如果你的平臺定位不高，強制實行SOA，就好比高射炮打蚊子，不僅浪費炮，還TMD打不到蚊子！所以不要“過度設計”，“恰如其分”很重要。
閱讀更多 程序員一代碼搬運工 的文章
