雲時代下的數據集成

要說雲，不能忘記傳統的三層劃分方法：IaaS、PaaS和SaaS。在企業級，大多談的是IaaS層。當年AWS搞雲計算的時候，無人喝彩。沒想到幾年以後，居然成了趨勢。微軟、IBM等公司都在進入。中國的阿里、騰訊前後進入這個市場，增加迅速。

不過大多數軟文寫的都是概念和宣傳，若是站在Siebel的小船上看過去，咱們就拋開噱頭和炒做，只且看技術和內容。

 

1、雲的概念

如今的雲計算市場很火，先了解下雲計算領域的幾個的概念：IaaS,PaaS,SaaS 

 

 

IaaS: Infrastructure-as-a-Service（基礎設施即服務）

　　第一層叫作IaaS，有時候也叫作Hardware-as-a-Service，幾年前若是你想在辦公室或者公司的網站上運行一些企業應用，你須要去買服務器，讓你的業務運行起來。

　　可是如今有IaaS，你能夠將硬件外包到別的地方去。IaaS公司會提供場外服務器，存儲和網絡硬件，你能夠租用。傳統一點的主要是電信的IDC機房，託管機房或服務器租賃。

　　而如今一些新的IaaS公司包括阿里雲，Amazon, Microsoft 也開始作這塊業務。這些大公司玩轉IaaS通常都是因爲本身自己的系統規模太大，已經有了PaaS、SaaS的分層雛形，而在這些大公司裏，核心的資源就是IaaS ，在這塊已經擁有成熟的技術能力，也是最適合變成計算能力租售給各行各業。正是在這批大公司的競爭中，逐漸孵化出了雲計算目前的幾個領域分類的概念。

 

PaaS: Platform-as-a-Service（平臺即服務）

有兩種含義：

（1） 可定製化的集成開發環境，通常會有如下幾種特性：

    1. 界面UI、字段、可定製，可擴展。好比不一樣角色界面顯示及字段邏輯不一樣

    2. 對象模型及基於對象的事件控制。例如對象CURD時執行某個腳本

    3. 流程可定製。好比定製可圖形化設計的業務流程，審批工做流。

    4. 數據庫對象模型的非SQL語法查詢,例如Salesforce中 SOQL語法

    5. 解釋型語言動態編程擴展。例如SalesCloud中的Groovy，Salesforce中的ApexCode

    6. WebService或Rest API集成框架。全部對象及字段可自動映射到API接口訪問。

（2）平臺生態效應

PaaS將做爲一個平臺，給功能開發者提供了集成開發環境和展現產品的場所（Market Place）。開發人員使用平臺開發出具備特定功能的插件產品，發佈到MarketPlace上，平臺使用方在平臺上自由購買，組裝各個產品插件，以構建符合本身特定需求的總體解決方案。在這樣的PaaS生態環境中，平臺利用雙邊效應讓甲方和乙方造成自由市場，整個平臺最後達到合做雙贏。

目前市場上這塊作的比較完善的PaaS平臺主要仍是大公司，例如Oracle 的Marketplace 和Salesforce的AppExchange。Salesforce 和Oracle, 其實也能夠這麼看

 

 

　SaaS: Software-as-a-Service（軟件即服務）

　　有了上圖其實第三層也能夠理解了，就是各類App Store裏的App。只是這裏的App 賣的都是API，API即服務。而這些服務都是企業來買單，舉個例子，好比如今某土豪老闆要作個CRM，記錄客戶信息，客戶分級，按級別按期給客戶推銷產品文章，按期作客戶回訪，查看文章閱讀量統計報表，客戶活躍度報表，回訪統計報表等。

        若是是傳統的作法：需求評估，買服務器，買操做系統，買套裝軟件，找公司來實施，上線完成招專職運維一枚。週期長成本高風險大，後期升級擴展成本不可估。在雲時代的作法，買個微信企業號（包含客戶分組，可分組圖文羣發，支持報表統計），買個問卷星（支持微信集成，報表查看），客戶數據可下載，整體按API調用次數收費，成本和業務成正比，支持試用，一鍵開通無需等待。若是你是老闆你選哪一種方案？

 

2、雲的發展

    雲產品會愈來愈多，可是和傳統產品不同，雲時代下的SaaS產品會逐漸往細分領域垂直髮展。而大公司會逐漸往這兩個方面發展：

    1. 產品逐漸按行業領域或功能領域垂直細分，單個雲產品功能有限但體驗很好。原先大而全的產品如EBS，SIEBEL,SAP的概念會逐漸弱化，取而代之的場景多是這樣的

 

    2. 強化PaaS平臺，產品分的細了，組織和擴展起來才能更靈活。而PaaS工具強大了，合做夥伴才能利用其開發更好的產品

    3. 對於實施公司來講，其實只是換了個產品，而這個產品並無比大而全的傳統軟件功能強大，反而功能更零碎，系統間的關聯性更復雜。實施公司要實現相同的需求可能會比之前作的更多，但時代老是進步的，產品功能的開發工具先進了，如今能夠用PaaS去完成全部的客製化需求，SaaS先天具備接口集成標準化的優點，接口集成的成本更小了。

 

3、雲的集成

若是說將來都是雲的天下，那麼將來可能有一種職業會很是搶手，就是數據集成架構師。將來系統間的數據鏈路會比較長，數據間的業務依賴會也會影響接口設計的複雜度。那麼站在技術的角度，根據以前的項目經驗，簡單總結目前雲產品下系統集成常見的幾種場景及注意事項

 

（1）身份認證& 組織架構

    雲產品多了以後，每一個系統都要登陸，這裏面就有兩個問題

    1. 人員信息每一個系統如何統一登陸。 作SSO？ 那麼須要一個獨立的SSO 身份認證服務器，好比能登陸Oracle Sales Cloud後，也能夠直接登陸Siebel或Eloqua 。Oracle 提供了 Identity Management Cloud 解決方案，支持SSO，LDAP 等協議。

     2. 組織架構角色如何統一。即便用了SSO拿到訪問令牌Token後，對於數據的查看權限，各個雲系統權限結構不必定一致，而可以基於上下級進行的數據訪問控制就須要系統中預先擁有組織架構數據。這裏就須要用系統集成將組織架構數據和各個雲產品進行同步。 Oracle Identity Management Cloud 中也提供相關解決方案。

 

（2）接口方式

    傳統的接口通常都採用WebService的方式，但這種方式通常都是帶Session會話模式，Login-Process-Logout , 大型軟件通常都會在Session層面初始化不少內容，批處理接口還好點，可是遇到實時接口，效率相對比較低下，更別提採用負載均衡面對大數據量時的實時併發同步處理。如今的雲產品都支持了Rest API模式，包括Oracle Sales Cloud ,Eloqua, RightNow 等產品，均提供了完整的接口方案。

Rest 接口的優點主要在於能夠Stateless 無狀態會話處理，系統只要每次經過Auth2的Token驗證方式驗證經過，就不用初始化Session了，不少場景下甚至把Token的驗證搬到了Redis裏，效率更高。無會話狀態的另外一個好處就是能夠作負載均衡集羣，而不用考慮Session複製，作N個節點處理數據只在意過程，不注重是誰發起的，固然併發處理數據時須要考慮共享數據的寫入鎖。

 

（3）接口認證 

目前雲產品中比較流行的是Auth2.0 和 Basic 認證，在Oracle和salesforce中都有提供。要注意的是雲產品對於數據傳輸加密很是重視，因此全部OutBound 和InBound 的接口都須要SSL 安全性要求，因此外部服務器接入雲產品時，注意都需配置WebServer的HTTPS 訪問。

Basic認證自己是不安全的，由於接近於明文傳輸密碼，雖然已作MD5(Base64(Password))， 但一旦加密傳被網絡層捕獲，也是能夠用HTTP工具模擬身份直接向服務器發起請求的。 因此通常來講採用Basic認證的接口都會要求必須使用HTTPS加密。

OAuth2.0 已是行業內比較成熟通用的認證解決方案了，詳細就不說了，主要是你要有個地方存着Token。 示意過程以下：

 

（3）公有云和本地產品的數據同步 

    不少傳統企業其實剛開始嘗試使用雲產品，過程當中不免遇到和本地系統的數據同步問題

    1. 本地系統因爲企業安全性要求，不容許你外部公網系統直接訪問本地系統的接口。

    2. 本地系統不必定有支持基於Http協議的API接口暴露給外系統，說不定只是個數據庫

    3. 本地系統不必定能直接訪問外部公共網絡

    以上三種狀況咱們常常遇到

    通常來講問題1 和3 是內外網安全性訪問問題，能夠看是否有DMZ區域或堡壘機。在DMZ區中架設Web代理服務器（Apache 或 Nginx便可）經過NAT映射或反向代理轉發到目標主機。

    問題2 ，不能直接要求客戶開放數據庫端口給你, 你能夠辛苦點在你的DMZ區域中本身搭個輕量級的代理應用(能連數據庫就行）發佈一下。不過相似DMZ區非實時性數據同步，大型企業數據量大時能夠考慮用Informatica 或 Kettle 開源工具進行批量搬數工做。Kettle 支持Rest、WebService、FTP CSV等輸入，輸出到表，也支持Job做業，很是方便。