今天再整理和分享下我最近出版的《SOA與大資料實戰-企業私有云平臺規劃和建設》裡面的部分內容。前面談中臺，微服務和雲原生比較多，最近自己的思考重點也在傳統企業IT架構如何進行微服務改造，如何基於雲原生解決方案思路平滑上雲。

而越是深入思考，越能得到如下結論。

即對於傳統企業完全按照網際網路的思路構建中臺或微服務基本都是死路一條，而對於公有云廠商同樣不能真正理解企業傳統架構和業務複雜性，理想化的推動雲原生也是死路。

我自己上面這本書本身在14年左右完成初稿，一直拖到今年在出版，但是在13年就提出了私有云PaaS平臺，平臺+應用，業務能力元件化和元件能力服務化等思路絕對是具備足夠的前瞻性。雖然很多傳統的技術已經被新技術所取代，類似傳統的PaaS平臺已經逐步被容器雲平臺驅動，ESB匯流排逐步被API閘道器或ServiceMesh取代。但是當時整個的規劃架構思想仍然值得當前大部分企業在實施微服務，構建自己雲原生演進實踐的時候思考。

私有云PaaS-建設背景

結合企業在資訊化規劃和建設中遇到的實際問題來分析企業私有云PaaS平臺建設的背景和原因。假設一個企業已經完成了初步的私有云IaaS資源池建設，然後各個業務系統仍然按傳統的獨立規劃建設模型進行，具體如下：

結合該圖可以看到，在業務系統建設中遇到的問題主要包括：

煙囪式的系統建設模式

這個是企業資訊化建設中經常遇到的問題，即各個業務系統孤立建設，越建越多，系統之間大量複雜的蜘蛛網式互動和資料傳遞。由於業務系統間本身的互動困難導致了端到端流程存在斷點，多個系統間基礎資料不一致等一系列問題。

雖然很多大型企業在IT系統構建中已經引入了基於SOA理念的整合平臺，但是平臺本身的作用仍然停留在資料整合和系統間介面管理。即整合平臺雖然解決了傳統的點對點整合到匯流排式整合和統一管控的轉變，但是業務系統本身孤立和豎井式建設的本質並沒有改變。

業務系統中大量可複用的能力沒有提取並抽象到平臺層統一建設，業務系統本身沒有基於SOA參考架構的思想進行靈活構建，這些都導致了整個IT系統和環境日趨複雜。

資料交換和能力共享

傳統的企業資訊化建設過程中往往會實施資料交換平臺等實現業務系統間的資料交換和協同，這不可避免導致的問題就是通用的共享業務資料在多個業務系統中多點落地，由於資料交換平臺本身的可靠性或資料管控能力差距，都導致了在某一個時點同樣的資料在多個系統中不一致。

為了解決這個問題，有些企業開始逐步實施了MDM主資料管理系統，雖然實現了資料的統一流程管理和質量管理，但是如果MDM系統仍然是採用傳統的資料收集和分發機制，仍然不可避免帶來資料多點落地和不一致性的問題。導致這種結果的核心原因還是沒有從傳統的資料交換和整合轉化為服務能力開放和共享思路上。

這裡需要強調的是：SOA服務共享的思路重點是業務能力透過服務的方式進行開放和暴露，這種服務是粗粒度的服務，透過底層的資料規則和計算來完成，外圍業務系統往往只需要消費服務能力而不是同步底層資料。

IaaS層能力無法完全發揮

當前已經有不少企業進行了虛擬化資源池建設和實施，也初步搭建了自己的IaaS層管理平臺，但是要注意到如果只實施了IaaS平臺，對於應用來講雖然物理資源不可見，但是邏輯資源仍然可見，往往IaaS層在資源分配中仍然會將邏輯資源固定的分配給業務應用。那麼對於各個業務系統在業務忙閒不同的時候，就很難真正的去動態排程底層的邏輯資源能力，而無法真實實現資源的最大化利用。

而引入私有云PaaS平臺真正實現了應用託管和自動部署後，才可能透過PaaS平臺的排程規則和效能分析監控，去動態排程底層的IaaS資源池中的資源。即透過引入PaaS層後不僅僅是物理資源對業務系統透明，包括邏輯資源也對業務系統透明，對於最終的業務系統而言只關心服務能力的使用，而無須關係提供服務能力的資源。

雲計算包括當前雲原生核心發展趨勢即不斷的從最底層的IaaS朝上層發展，而在過渡到PaaS層一個核心就是從對資源的的需求變化為對服務的需求，底層虛擬機器和容器對你不可見。

業務系統建設規範和標準

在企業資訊化建設過程中，不同的開發商往往都使用自己的開發框架和語言、技術架構、資料庫和應用中介軟體等。這不可避免的導致了企業IT規劃建設部門面臨一個複雜的軟硬體環境，這不僅僅導致了後期運維管控的困難，還造成了各個業務系統間的適配和協同困難，這也是業界經常提到IT建設部門逐步被開發廠商所綁架的一個原因。

系統本身架構可擴充套件性

隨著企業業務的高速發展，海量資料，高併發業務場景下的高可用性和一致性問題，傳統資料架構已經無法解決，即使藉助小機，商用資料庫也存在無法伸縮擴充套件的問題，因此需要考慮全新的架構模式。這種架構模式核心一方面是SOA元件化架構思想的應用，一方面是分散式和平行計算技術、大資料處理和分析技術的使用等。

所以引入私有云PaaS平臺不是簡單地實現公有云的資源排程和應用託管能力，更多的是要形成一套基於PaaS平臺的上層應用開發框架、開發標準、開發流程、技術規範體系等，將企業內各個業務系統的開發都準備的標準化為統一的業務構件和能力單元。

私有云PaaS-建設目標

企業私有云PaaS平臺的建設目標仍然基於企業總體戰略目標出發，根據戰略目標分解為具體的業務目標和技術目標，同時技術目標又為具體業務目標的實現服務。

對於企業私有云PaaS平臺建設的業務目標，主體仍然包括了企業資訊化建設成本降低和業務敏捷性增強兩個方面的內容。PaaS平臺的建設核心不僅僅是雲計算等各種技術的使用，更加重要的是將傳統業務系統孤立煙囪式的建設模式，轉化為平臺+應用的建設模式，打破原有的業務系統邊界形成業務元件化開發和協同的架構模式，真正實現業務模組的快速構建，對業務需求和流程變化的快速響應。具體的業務目標主要包括：

降低IT建設的投資和成本

透過私有云PaaS平臺能力開放和複用的思想，將原有的重複開發的功能元件轉換為平臺層開放能力以降低重複成本。透過PaaS平臺的應用託管和資源動態排程，最大化的實現原有的IaaS基礎設施資源池資源的最大化利用。透過私有云的集中化建設模式實現分散多套系統建設投資和後期運維成本等。

對於當前PaaS平臺建設中的微服務和雲原生方式，要意識到一開始本身不是降低成本，而是增加了成本，特別是學習成本，整合成本，人員成本等。但是當整個平臺+應用的模式構建完成後，一定是降低後續持續交付成本，運維成本。

提升業務敏捷性

對於業務敏捷性的提升包括兩個方面的內容，一個是對於新建設的業務系統或應用，可以基於PaaS平臺層已有的技術和業務複用能力快速地訂購使用，而不需要業務系統全新重頭開發；另外一方面是當出現業務需求和流程變更的時候，基於SOA面向服務架構思想，可以靈活地對服務進行重新組裝和編排，以滿足新的業務和流程需要。

透過私有云PaaS平臺的建設，將逐步弱化原有的業務系統概念和邊界，對於企業端到端業務的支撐將變為多個底層的核心業務能力元件的協同，這些業務元件基於私有云PaaS平臺統一的規範和架構體系，透過標準的服務方式進行協同，基於同樣的底層基礎資料和技術能力，在這種模式下將徹底轉變原有的業務系統隔離和資訊孤島，真正實現業務的端到端流程整合和管控。

提升業務敏捷性是當前傳統企業IT架構轉型，構建中臺或逐步微服務架構改造，實現內部私有云和公有云的混合雲架構，並在此基礎上實現持續整合和交付的核心目標。

私有云建設的技術目標，主要是作為企業IT建設部門和技術層面出發，考慮透過私有云平臺建設後在技術層面的收益。

建設靈活可擴充套件的架構體系

對於雲計算本身即具備彈性伸縮擴充套件能力，而對於私有云PaaS平臺建設，透過平臺+應用的服務化構建模式，透過各種分散式技術的使用，真正形成一套完全可以靈活水平擴充套件的彈性架構體系，這種架構體系能夠滿足IT系統在業務高速發展下5到10年，甚至更長時間段的靈活支撐和水平擴充套件，而不是類似傳統架構體系在擴充套件性方面受到諸多約束。

建設高可用的私有云生態環境

業務系統的高可用性始終是企業資訊化建設和後期運維管控的一個重要內容，透過私有云平臺的建設，期望的是形成一個高可用、高可靠、安全一致的IT生態環境。透過分散式叢集技術，冗餘、異地容災備份，雙中心等多種措施真正形成一個高可用的環境。

形成企業可複用的IT資產庫

傳統的業務系統開發模式往往很難真正的抽取各個業務系統的共效能力並服務化，而私有云PaaS平臺建設在基於SOA的思想指導下，透過可複用服務能力的識別和開發，形成可複用的企業IT資產庫和服務目錄。對於單純的私有云PaaS技術平臺而言不是資產，但是對於提供了可共享的業務，資料和技術服務能力後的PaaS平臺則是企業重要的IT核心資產。

形成標準化的IT治理和管控體系

透過私有云平臺的建設，可以進一步的規劃企業內部業務系統的建設標準和流程，業務系統的開發流程和技術架構，所有的業務系統基於同樣一套技術標準體系，開發流程進行需求分析，設計和開發，過程管理等。真正提升企業內部資訊化部門對IT系統的管控能力。

降低對單一廠家硬體或軟體的依賴

對於中國網際網路領域前幾年開始推行的去IOE運動的重要性，已經逐步被大型企業所接受，隨著國家相關資訊化發展規劃和安全政策，開源和國產化將逐步成為趨勢。因此在當前私有云建設規劃中重點可以考慮去IOE和開源軟體的使用。

私有云PaaS-建設原則

結合傳統的IT系統規劃和建設原則，私有云PaaS平臺的規劃和建設原則如下：

標準化原則

雖然當前私有云PaaS平臺的建設標準還不完善，但是可以看到類似Gartner等已經逐步推出有相應的參考架構可以參考，同時對於雲計算技術本身已經有相應的國家標準出臺。因此在私有云建設過程中需要遵循這些標準體系進行規劃、設計和實施。

先進性原則

在系統的總體設計上，需要借鑑國內外大型IT服務和整合廠商的成功經驗，同時要關注同類平臺的建設教訓。在技術上，要採用國際上先進的且成熟的技術，採用國際標準體系架構，使得設計更加合理、更為先進。充分考慮企業資訊化本身的現狀和特點，在注重平臺的實用性的前提下，儘可能採用先進的軟、硬體環境；在軟體的開發思想上，嚴格按照軟體工程的標準和麵向物件的理論來設計，保證系統的先進性。

安全性原則

系統在設計時將遵循安全性的原則，採用高可靠性的產品和技術，充分考慮整個系統執行的安全策略和機制，具有較強的容錯能力和良好的恢復能力，保障系統安全、穩定、高效的執行。在安全設計中要全面考慮網路安全、資料安全和使用者安全。

可擴充套件性原則

對於私有云PaaS平臺的建設，系統的軟硬體環境都必須能夠根據業務的發展靈活的水平擴充套件，也能夠透過SOA架構和服務化思想靈活的滿足業務變化需求。在水平擴充套件過程中至少需要做到不對已有的硬體投資或軟體體系架構造成修改和變更，而是透過可配置或熱切換的方式進行能力擴充套件，同時在能力擴充套件過程中基本保證線性擴充套件能力。

穩定性原則

一般穩定性是指系統的正確性、健壯性兩個方面，系統是在網路環境下執行的，並且系統管理的資料量大，資料的使用併發性強等，這些特點對系統的設計提出了更高的要求。因此，一方面系統在提交之前應該反覆測試，把錯誤減少到最小程度，保證系統的正常的運轉；另一方面，系統必須有足夠的健壯性，在發生意外情況下，能夠很好的處理並給出錯誤提示，並且能夠得到及時的恢復，減少不必要的損失。

開放性原則

為適應將來業務和技術發展的需求，系統建設必須具有較強的開放性，平臺和應用的建設應基於面向服務（SOA）的理念構建，需底層的接入與業務的處理分離，實現服務的封裝、重用，在增加新業務時不需要更改系統的軟體結構和網路結構。除具有標準的開放式技術介面外，還能夠完成與現有系統具有標準介面的系統完全對接，能夠充分利用已有服務。

投資保護原則

滿足系統整體效能的前提下，充分利用已有的裝置、軟體和資料資源，新添置的裝置以滿足使用為原則。

私有云PaaS建設方法論

對於企業私有云平臺建設主要還是圍繞透過私有云建設後最大化資源利用率，降低能耗和硬體採購成本，實現資料中心的集中管控和運維，促進企業內部資訊化部門的服務化轉型等。雲計算本身具備的技術特點和優勢，由於企業對資訊化資產和安全的管控需求，企業資訊化應用本身業務規則，邏輯和一致性的高要求等，往往很難真正遷移到當前的公有云平臺，這也是諸多大型企業都開始獨立建立自己的私有云資料中心和雲平臺的原因。

目前，很多企業的內部私有云平臺建設僅僅還是在解決IaaS層和虛擬化資源池的問題，而這遠遠沒有達到私有云建設的核心業務目標和核心價值所在。因此在啟動企業內部私有云PaaS平臺建設時，需要進一步明確平臺建設的核心指導思想。

集中和系統化

既然私有云談集中化，那麼大系統觀就顯得更加重要，在大系統觀下企業內部的IT建設和業務系統最終就是一個大系統，其他的僅僅是業務模組和元件單元。在企業私有云PaaS平臺建設下將徹底打破原有的企業資訊化建設中業務系統豎井式的建設模式，真正轉變為基於SOA服務化思想下的平臺+應用構建模式。

在業務系統元件化後，原有的業務系統邊界將被徹底打破，整個企業的資訊化系統將轉變成為一個平臺能力支撐下的多個業務元件構成的大系統。在大系統建設模式下涉及到兩個方面的整合，一個是向底層的資源池整合和平臺化，一個是最頂層的雲門戶化整合，而大系統中剩餘的就是各個業務元件單元。大系統建設要解決的核心問題就是資源的複用問題和資源的水平排程和擴充套件問題。

傳統的企業資訊化建設模式很難真正地按大系統觀的思想來規劃和建設，大系統建設模式首先要解決企業架構中的業務架構和資料架構問題，然後才是應用架構和技術架構問題。只有按企業架構業務驅動IT思想，分層和元件化的思想才可能真正的理解大系統的概念，分層和分模組地進行建設。

如果引入了企業私有云，我們的資訊化建設還是傳統的各個業務系統獨立建設，後續再考慮協同的模式，那麼私有云本身還是停留在技術優勢上面，很難真正的體現業務價值。

平臺和分層化

當我們在談PaaS（平臺即服務）的時候，但是很多時候我們的理解卻是它是一個可託管的雲端執行平臺，可能也包括了線上開發平臺，測試平臺。但是我們一定要注意到私有云裡面的平臺不僅僅是解決平臺的雲化問題，更加重要的是需要解決業務元件本身基於SOA元件化思想設計、基於平臺搭建和整合問題。

技術平臺真正的是可以做到標準化開發方法和開發模式，提升開發效率，將私有云PaaS平臺對應用的約束完全固化到開發框架和平臺中。平臺化一方面解決標準化問題，同時解決可複用問題，還進一步解決前端應用和產品的可配置問題。

在引入了私有云和雲本身的分層架構概念後，結合傳統的企業應用架構，特別是服務化的分層架構，需要重新對企業私有云下的分層架構進行整合。即在整個私有云PaaS平臺體系下分為資源，服務和應用三個層面。其中資源層既包括了IaaS層物理基礎設施，也包括了私有云PaaS技術平臺，而應用則包括了各個松耦合的業務元件模組和頂層雲門戶整合。在平臺和應用層之間是服務層構建，透過標準化的SOA參考架構體系，真正實現了平臺層服務能力和應用層功能構建之間的解耦。

整合和協同化

這個是大型企業資訊化規劃建設的一個核心內容，不管是否引入企業私有云都需要考慮整合方面的問題。在引入私有云後傳統的企業業務系統間的整合轉換為業務元件或模組間的整合，同時在進一步強化分層架構思想後，引入了多層之間的縱向服務整合。對於整合主要包括兩個方面的內容：

首先是資料的整合和資料的融合，這裡面涉及到主資料和共享資料中心的建設問題，核心目標就是解決共享資料只有一套，有唯一的源頭的建立更新機制，資料以共享資料服務的方式將能力釋出出去，供其它業務元件使用。這個和傳統資料交換和整合有很大的區別，即在於資料本身不會落地到各個業務系統形成多份資料複製，而是按需實時訪問和使用。

其次是業務的整合和協同，要完成一個端到端的業務流程和業務協同，最終將轉換為業務元件間的服務互動和協同問題，那麼核心問題就轉變為了業務元件如何劃分最合理，最能夠保證業務元件之間的內聚性，真正能夠實現業務元件的徹底解耦問題。

私有云建設完成後，元件化資源池裡面有大量的業務元件，這些業務元件提供業務服務，如果這些業務元件不能很好的透過業務服務協同起來完成最終的業務目標，那麼資源池化和共享的價值發揮不出來。

演進和平衡觀

要明白企業私有云的建設一定不是一步到位和一蹴而就的，這個有點類似傳統的軟體工程思想都沒有理解透徹一下就過渡到敏捷方法往往栽跟頭。私有云建設有成熟度模型，有參考架構，但是一定要結合企業資訊化實際情況制定切實可行的演進思路和發展路線。目標架構可以有，但是一定要逐步演進和發展。

我們說的平衡包括了建設期和運維期的平衡，業務可行性和技術先進性的平衡，CAP三個方面的平衡，開發難度週期和可擴充套件性的平衡，成本和收益的平衡等多個方面的內容。要知道在引入私有云架構後，雖然可以更好的實現可擴充套件性和容錯性，但是必然犧牲一致性方面的需求，而對於企業資訊化應用來說，往往事務完整性和資料一致性才是最最重要的。

分散式架構有分散式的好處，但是分散式架構卻帶來事務一致性方面的問題，帶來了開發難度的問題，帶來了後續運維難度的問題，這些都必須要去考慮。目標架構雖然理想，但是當前階段的成熟度下是否適用就必須要去評估。再完美的技術如果最終無法落地，也僅僅是空中樓閣而已。

企業私有云PaaS平臺建設中涉及到IPaaS整合平臺，BPaaS流程平臺和APaaS應用排程平臺，還涉及分散式資料庫和資料庫資源池化。而到現在來看比較成熟的仍然是整合共享服務平臺，統一流程管理平臺，資料平臺等。其它內容往往並不成熟，特別是對於完全動態的資源排程和水平擴充套件能力，在實施性和穩定性上仍然沒有答案，在完全基於開源的方式來構建企業內部的私有云PaaS的時候更是風險重重。

結合企業架構和IT規劃的思想，參考SOA服務化架構，基於企業私有云建設的目標和原則要求，私有云平臺的總體規劃可以理解為傳統IT規劃和企業架構在平臺和服務化思想下的進一步細化和展開，具體總體規劃方法如下：

結合上圖，對企業私有云PaaS規劃的核心方法和步驟進行簡要說明如下：

首先仍然是以傳統的IT規劃和企業架構規劃為匯入，體現業務驅動IT，在進行企業架構分析的時候要充分考慮平臺化和SOA的思想，不論是在業務架構，資料架構還是應用架構的規劃和設計中都需要進行共享業務和技術能力的識別，考慮服務能力的共享而非簡單的資料整合和介面。

在企業架構規劃的基礎上，根據共享能力的識別開始進行平臺層功能架構和技術架構的規劃，在規劃過程中可以參考業界PaaS標準架構體系和企業自身的平臺化需求。充分識別可行的共享技術服務和平臺服務能力。

在平臺層能力基本規劃清楚後，考慮企業架構整合架構的規劃成功，從服務共享需求和業務整合需求兩個層面來考慮服務層的規劃，包括功能規劃和技術規劃，形成可共享的SOA服務目錄集和服務檢視，作為可複用的服務資產。

基於平臺層和服務層規劃的輸出，結合SOA和CBM元件化業務模型的思想，開始進行應用層規劃，包括了業務元件規劃，功能架構規劃和基於元件的應用整合規劃等。

在平臺層，服務層和應用層基於私有云總體架構體系指導下規劃完成後，開始考慮結合企業資訊化現狀和成熟度，給出企業私有云演進路線和實施策略規劃。對於本章所涉及到的企業私有云建設規劃，基本也是圍繞該總體規劃方法論展開進行論述。

參考私有云和SOA參考架構體系，結合私有云建設平臺+應用的構建思想，可以得出上圖所示的私有云PaaS平臺總體架構體系。在該架構體現中PaaS平臺層分為PaaS技術平臺，SOA共享服務平臺和PaaS管理平臺三方面的內容。PaaS技術平臺提供的技術能力都透過SOA服務匯流排向外開放和暴露。具體說明如下：

平臺層-技術能力平臺

該層在傳統公有云PaaS平臺提供的中介軟體和資料庫資源池和服務能力，訊息快取等技術服務能力的基礎上，結合私有云PaaS平臺的特點增加了平臺層技術能力。其中主要包括了主資料平臺，4A平臺和流程平臺三部分的核心能力。

服務層-SOA服務匯流排

對於PaaS技術平臺提供的技術服務和資料服務能力，對於業務系統中業務元件提供的業務服務能力，流程平臺提供的流程服務能力統一接入到SOA服務匯流排。SOA服務匯流排實現統一的服務目錄管理，服務全生命週期管理功能。透過SOA服務層，可以真正實現應用層和PaaS技術能力平臺的功能解耦。

PaaS管理平臺

實現PaaS平臺的基於資源和服務的全生命週期管控，包括資源和服務的申請，開通，控制和鑑權，資源和服務的回收，效能分析和監控，應用託管和自動部署等核心功能。

應用層

基於PaaS平臺構建的應用層，重心將轉化為松耦合的業務元件的構建，業務元件的重點是提供可協同的業務服務能力，提供本業務元件需要的服務組裝和介面展現能力。透過業務元件化將逐步打破傳統的業務系統邊界，而松耦合的業務元件最終又透過統一的雲應用門戶進行整合和整合。

平臺層功能規劃

對於PaaS平臺層的功能規劃主要還是從業務系統建設採用平臺+應用構建思想後，可以下沉到平臺層的技術和業務服務能力進行分析，以確定具體可以規劃的功能點。平臺層功能的核心是支撐上層的業務系統或業務元件，和傳統的公有云PaaS功能規劃不同的是，對於私有云PaaS功能既涉及到純技術能力，也包括了可複用的公共基礎能力和業務能力的下沉。對於傳統的煙囪式業務系統構建向平臺+應用方式構建轉換，具體可以參考下圖：

平臺層功能規劃的核心基本圍繞該圖展開，具體說明如下：

資料庫和中介軟體

傳統的IaaS層僅僅實現了物理設施的資源池化，而沒有實現資料庫和中介軟體的資源池，在PaaS平臺建設過程中可以將資料庫和中介軟體以服務的方式對應用提供和開放。使用者將不再關心資料庫和中介軟體的安裝和配置，而僅僅需要訂購資料庫和應用中介軟體容器的服務能力。這既是傳統的公有云APaaS部分的標準內容，也包括了DaaS資料庫即服務層的內容。

注：上雲原生，不是簡單的容器雲部分，更加重要的是中介軟體服務和技術服務部分，特別是資料庫服務，即由傳統的申請虛擬機器轉變到直接申請雲服務廠商的資料庫服務能力。

技術服務平臺

對於任何一個業務系統的構建可以看到，業務系統內部本身也有一個公有的技術元件滿足業務系統上層多個業務模組的需要。其中包括了系統管理，共性的各種技術能力（訊息、日誌、安全、異常、快取、檔案、通知、任務）等多個方面的內容，對於這些公有的技術元件能力需要根據私有云建設過程中的實際情況來考慮是否規劃到平臺層統一建設和實現。

資料層

資料層的一個核心就是共享資料，其中包括了共享動態資料和主資料，對於這些資料往往被上層多個業務系統使用和消費。而傳統的業務系統建設模式往往這些資料在多個系統中建立和維護，資料在多個系統中同步和落地，這些都導致了資料的不一致性等問題。

在PaaS平臺建設過程中需要考慮進行集中化規劃和建設，如建設MDM主資料管理平臺，SID共享資料庫中心等。這樣這些共享資料可以實現集中化的資料儲存並透過資料服務的方式朝外提供標準統一的服務能力。

業務規則

業務規則往往隨著業務系統的不同差異很大，也是很難真正集中平臺化模式建設的。而當前規則引擎可以解決該問題。即業務規則抽取到規則引擎中統一配置和管理，然後規則引擎以規則服務的方式將最終的能力暴露給業務系統使用。對於規則引擎平臺可以在當前的BPaaS業務流程平臺即服務中統一規劃和考慮。

流程層

流程層包括了HWF人工工作流和BPEL自動化業務工作流，不論是哪種類似在PaaS平臺建設中都需要考慮集中化建設。流程層的集中化建設對應到標準的PaaS參考架構中BPaaS部分的內容，對於各個業務系統都使用同一個流程引擎進行流程建模，流程執行和流程監控。同時在規劃的時候要注意到4A平臺的集中化建設是流程平臺規劃的基礎和前提。

SOA服務匯流排

主要是實現平臺層可共享的能力以服務的方式統一註冊和暴露給上層業務應用使用。同時對於上層業務元件之間的資料整合和應用整合也需要由服務匯流排來完成。SOA服務匯流排屬於PaaS參考架構中iPaaS整合平臺即服務的重要內容。

在實現完全的微服務架構化後可以採用API閘道器來實現介面整合和能力對外開放，但是存在遺留系統的情況下，傳統的類似ESB服務匯流排仍然需要存在相當長一段時間。

介面展現層

介面展現層重點是強調可複用的介面UI元件，也包括了在平臺化建設後對於各個拆分後的業務元件透過統一應用框架進行整合。

在這裡的介面展現層也可以理解為前後端分離開發後的前端開發，但是前端不僅僅是單純的介面展現，也包括了服務組合和編排等能力。

平臺層技術規劃

對於平臺技術規劃，結合前面的平臺功能規劃需求，主要從資料庫和儲存、應用託管和資源排程、ESB整合中介軟體、底層建模幾個方面進行展開說明。

資料庫和儲存

首先談下資料庫，要意識到資料庫的集中包括了兩個方面的內容，一個是資料庫伺服器硬體的集中化，一個是資料本身的集中化。對於類似Oracle RAC叢集資料庫實現的是資料庫硬體，軟體和資料的全部集中，但是資料庫叢集算不上真正的分散式資料庫。mysql cluster叢集可以算作分散式資料庫，可以實現資料的水平shading功能，但是cluster叢集本身在大資料量和大併發下，對於複雜業務邏輯操作存在效能瓶頸，這是不可迴避的事實，在cluster叢集配合讀寫分離叢集共同使用的時候又出現了資料儲存分佈的問題。資料物理儲存的分佈又導致了底層資料庫資料日誌同步，分散式資料庫事務一系列衍生問題。

可以說，在大型的企業內，具有高度一致性和複雜業務邏輯規則處理的業務系統，現有mysql自身的能力是存在差距的，其原因就是為了儘量的保證資料庫的分散式和水平可擴充套件性帶來了諸多新問題，這些新問題將急劇的加大應用層開發的複雜度，也帶來傳統架構下沒有的一致性難以處理的問題。

在雲架構下的資料庫集中化要意識到，其本質是邏輯集中，即整個資料庫透過DaaS層實現了公共的資料服務提供，而實際物理資料庫仍然是分離的。那麼在這種情況下對於DaaS層的要求相對高。包括我們說的SQL解析，異構資料庫的語法層遮蔽，底層分散式事務的事務協調，都是新問題，解決不好整個資料庫雖然可擴充套件了，但是效能、一致性、開發複雜度各方面都帶來巨大挑戰。很多時候我們在談去IOP好像很簡單，其實去任何一個內容都是需要進行各方面的權衡，最終做一個決策。

對於資料庫層面，還有就是NoSQL資料庫的使用問題，至少現在看來，企業內的業務系統本身能夠遷移到完全的NoSQL資料庫是不顯示的。主要原因還是複雜的業務規則和一致性要求，開發的複雜度和成本，效能問題等。現在來看可以用NoSQL資料庫的場景往往並不多，只有少量的業務功能和場景可以轉換為Key-Value模式進行儲存和解析，比如類似日誌，檔案等技術服務和元件，可以先開始考慮使用NoSQL資料庫。對於簡單的業務物件，包括物件本身簡單，物件關係也簡單，事務也簡單場景可以超NoSQL資料庫進行遷移。

再到儲存層面，可以將基於HDFS分散式檔案系統架構的分散式儲存相當來說已經相當成熟，企業內的非結構化檔案儲存，檔案的讀取和訪問完全可以統一到分散式檔案儲存架構上。基於Hadoop開源框架來構建分散式儲存服務是完全可行的技術方案，但是要注意到對於分散式儲存服務構建中仍然存在結構化的元資料，這些元資料的儲存可以採用傳統的結構化資料庫，也可以採用NoSQL資料庫。

綜上所述，對於資料庫和儲存方面涉及到的技術主要包括如下方面內容：

 分散式或偽分散式的資料庫叢集技術。

 資料庫的水平拆分和垂直拆分，分散式事務處理技術

 DaaS資料庫即服務層（包括連線池管理，分片路由，SQL解析等）

 NoSQL資料庫和HDFS分散式檔案系統

 應用託管和資源排程

對於中介軟體資源池的構建，可以說是企業私有云中APaaS的核心內容。具體的功能前面文章已經談到過包括了自動部署、應用託管、應用虛擬化的中介軟體資源池，資源根據應用符合的動態排程等方面的內容。

對分散式排程有兩種方案：

一種是基於傳統虛擬機器+高層負載均衡的排程模式，在該模式下需要解決的問題是負載均衡裝置API的完全開放，能夠透過程式來實現計算單元的掛接和解除安裝，而對於虛擬化本身的動態建立，安裝，啟動啟用則屬於傳統的IaaS層需要考慮的問題。

第二種排程方案即基於容器技術實現的資源排程，類似當前主流的K8s+Docker來實現的中介軟體容器雲。要明白排程單元越輕量則排程效率越高，但是各個排程單元之間的隔離性會很差。在這種排程策略下要解決的問題主要是各個排程單元的隔離，已有的CPU和記憶體資源在各個排程單元之間的分配而不出現資源搶佔情況，中介軟體例項的自動建立，啟動，程式部署包的自動部署等一系列問題。

不論是哪種排程策略和方案，APaaS裡面都涉及到另外兩個方面的內容，即管控平臺和各個排程單元之間的訊息通訊機制，現在各家的方案都需要依賴高效的訊息中介軟體技術，一個是實現訊息事件的快速傳遞，一個是實現各個單元之間的徹底解耦。第二個方面技術是對於各個排程單元的健康資訊採集，這個採集透過SSH或其它底層API技術來實現不難，但是難的地方卻是採集的高效性和效能。要實現高效排程，資料的採集頻率會很高，如何保證採集程式本身效能和低能耗就必須考慮。

如果我們把資料庫和中介軟體都實現了分散式部署，那麼整個應用可以算得上是完全的分散式架構系統。

對於應用託管和資源排程主要涉及到的技術包括

 高效能訊息中介軟體技術

 高可靠和準實時的效能資料採集和分析

 排程規則和排程引擎技術

 邏輯資源應用容器技術，資源隔離技術

 負載均衡和軟叢集技術等

 ESB和整合中介軟體

在私有云架構下面，ESB整合中介軟體的作用更加重要，這裡面要注意既包括了傳統的訊息中介軟體，也包括了資料整合中介軟體和服務整合中介軟體。ESB服務匯流排是整個私有云架構中的整合樞紐，是共享服務的提供中心。特別是在PaaS架構下強調資料庫和中介軟體本身的集中化後，更加強調集中化後的共享資料服務和業務服務的提供，強調基於PaaS平臺搭建的各個業務系統或業務元件間的及時訊息傳遞等。

對於ESB核心包括了訊息協議轉換，路由，服務目錄中心，服務監控，服務鑑權，訊息釋出訂閱等一系列內容。基於元件化架構的思想，PaaS平臺下要實現的是業務元件間的業務整合和協同，是實現集中化後資料的共享服務，而不是傳統意義上的資料交換平臺。

談到ESB必須提到元件化架構思想，很多時候我們談業務應用基於SOA架構思想，但實際上往往並沒有按照SOA架構思想來構建應用。業務元件化，元件服務化，業務元件之間透過業務服務進行互動，服務可以組合，組裝和編排來構建和實現完整的業務邏輯，這些就是最基本的SOA架構思想。

迴歸技術層面，ESB平臺本身也需要考慮在大資料量和大併發量下的效能問題，也就是說作為PaaS基礎能力元件的ESB平臺本身也需要水平擴充套件和基於分散式架構。ESB架構下應用伺服器可以在叢集架構下完全水平擴充套件，而服務本身的無狀態特性，又可以很方便的實現資料庫的水平擴充套件和垂直切分。

還有業務整合和傳統資料整合是完全兩個層面的內容，ESB應用整合不是替代傳統的基於ETL資料整合，而是兩者相互結合。而在PaaS雲架構下，如果真正可以實現資料庫的集中化，往往已經沒有再進行ETL資料轉換和清洗的必要，至少ODS這層是當前大資料庫就可以完全勝任的。而真正引入了分散式資料庫和NoSQL資料庫之後往往導致了ETL過程的複雜化，簡單的ETL操作變化為了分散式的ETL操作。

對於ESB整合中介軟體涉及到技術包括：

 ESB企業服務匯流排（路由，適配，協議轉換，鑑權，服務代理等）

 大資料和大檔案整合技術

 EDA事件驅動架構和CEP複雜事件處理

 BPEL和BPM業務流程管理

 分散式事務和事務一致性

 底層建模技術

由於在談PaaS的時候我們一直強調的就是能夠集中考慮和建設的東西都儘量下沉和集中化。那麼在集中化建設的過程中自然涉及到對原有元件模組的進一步抽象和封裝整合。而這裡最重要的還是許可權模型、組織模型、工作流引擎模型等核心技術模型和抽象。也涉及到對於業務應用中的核心元資料模型的抽象。

對於業務系統資料建模的時候，可以看到需要進一步按面向物件的思想來進行建模，多借鑑MDA和領域驅動設計中領域模型的概念，只有做好了基礎物件層的抽象和封裝，才能給更好地提供領域層的物件服務。要明白上層應用更好的構建方式就是更加地關注物件和物件服務，而不是關注底層的資料庫。而且由於傳統的業務系統切分為多個業務元件後，更加需要一個公共的領域服務層，遮蔽底層細節。

對於底層建模涉及到的方法和技術包括：

 面向物件的分析和設計方法

 MDA模型驅動架構和DDD領域驅動設計

 SOA參考架構和技術規範標準

 基於SOA的元件化架構設計方法和技術

 快取、訊息、日誌、安全、規則引擎等相關技術