從縱向到橫向

　　傳統業務系統的構建更多的是豎井式的縱向思想，這個主要是從單個業務系統孤立來看都是垂直應用。那么SOA架構的視角是從整個企業應用架構環境來看，思想的核心轉變就是從傳統的縱向獨立構建模式轉變為橫向從底朝上逐層構建模式，在這個構建模式中首先是底層的資源層（獨立的業務組件），然后是服務層，再上面才是應用層和門戶展現層。這種橫向思維模式的驅動力本身在端到端的流程支撐和分析，沒有這種橫向思考模式的轉變很難構建出來真正企業全局意義上的SOA架構風格。

　　從交換到共享

　　為何很多企業做了多年的SOA最后仍然僅僅是一個接口平臺或者數據交換平臺，其核心的原因還是集成關注的是接口和數據交換，其本質思維還是點對點的思維模式。而共享則關注的是組件本身的可重用服務識別和能力開放，首先思考的是可重用的服務能力的開放而不是點對點的數據集成和交換。同時在轉換到共享能力開放的時候，將從原來數據集成的時候數據多點落地，轉化為新服務共享模式下的僅僅能力按需調用。業務間的協同和交互各個組件之間關注更多的是能力的消費和調用，而不是一定要底層同步和傳遞數據。這個思考的轉變才能從大量的數據服務為主的集成模式，轉化為數據服務+業務服務能力提供的服務共享模式。

　　從系統到組件

　　對于一個企業完整的應用架構來說，前面已經寫過很多文章再強調整個企業就是一個大的業務系統，而不是孤立建設了多個業務系統。對于原來的業務系統本身已經轉變為業務組件下層到資源層和服務層，而上層的應用本身僅僅是服務的組合，流程的編排。只有這種構建模式上層的應用才可能真正靈活的根據需求進行組合和組裝，當業務流程和需求發生變化的時候僅僅是組件或服務的重新組合。

　　對于一個新業務需求的產生，我們要看到有可能會產生新的業務組件，也有可能僅僅是底層服務的組合就能夠實現新的業務需求或流程。這個的核心區別就在于，新增加的業務需求是否存在自己為Owner的核心業務對象產生，如果有這些核心業務對象產生很可能新需求本身會規劃為一個新的業務組件。但是當一個業務需求本身不產生核心業務對象的時候，那么這個需求的滿足很可能通過已有業務組件的提供的能力即可。例如我們在規劃電商客戶服務模塊的時候，這個模塊可能僅僅是已有的客戶關系管理，訂單管理，物流管理，財務管理等各個業務組件能力的進一步組合即可完成客戶服務。從這個意義上說客戶自服務本身不是業務組件，而是已有業務組件的服務組合和編排，形成的一個新的應用能力單元。

　　從集成到集中

　　可以講這個思想是SOA和云思想的一個重要集成點，即對于遺留系統的集成和重構我們考慮的更多的是集成和已有的遺留系統服務能力的抽取。但是如果是全新的構建企業內部的完整應用架構，那么就必須要考慮很多共性的技術組件和基礎數據本身就不屬于任何一個上層業務系統，而是屬于公共平臺層的內容。既然屬于平臺層的內容就應該集中化的模式進行構建，然后再將能力開放和暴露出去。集中化的構建是云和平臺的思想，而服務最終的開放和暴露是SOA的思想，兩者得到很好的融合演進。

　　從系統外轉到系統內

　　如果一個企業的SOA架構僅僅應用在業務系統間，那么就很難叫做完整的SOA化。只有將SOA的架構思想應用到業務系統內部的時候，才可能形成完整的組件化和服務化構建模式。即業務系統本身也是多個松耦合的業務組件構成的，業務組件本身才是最小的可以獨立管理，獨立進行設計，開發，測試，部署和運維的管理單元。組件之間本身交互需要通過粗粒度的服務進行以保證組件本身的高內聚性，由于組件本身松耦合并可以靈活的組合，那么原來規劃的業務系統邊界逐漸就沒有存在的意義。只有這樣從企業全局思考角度才能夠形成一個完整的SOA參考架構模式。對于遺留系統集成這點比較難，但是對于全新的IT系統規劃和建設就必須一開始采用這種模式和思考方法進行，否則即使應用了SOA中間件還是煙囪式的系統架構。

　　從同步到異步

　　單獨將這點拿出來談逐漸該點的重要性。其原因就是一個SOA架構我們更希望的是各個組件和模塊之間的完全松耦合，任何一個模塊出現故障不至于馬上影響到其它模塊，從這個意義上來看如果全部是同步服務模式則很容易出現問題，提供服務的模塊宕機各個消費模塊馬上受到影響。而基于消息中間件的異步消息和服務模式可以較好的解決這個問題，即通過消息中間件的異步和重試機制真正實現了服務消費方和提供方之間的解耦，對于業務應用來說只需要保證最終的一致性即可。包括現在談到的EDA時間驅動架構，CEP復雜事件處理很多都是異步消息模式思想的應用。即在定義服務的時候能夠用異步模式盡量用異步模式以實現真正的解耦。

　　在引入了異步模式后會出現一個新的問題，即需要我們異常日志的分析和記錄清晰和全面，并提供后臺異常信息的實時預警能力，否則將出現很多時候出現了服務消費和調用異常而沒有及時發現的問題。