企業級PAAS平臺-關鍵問題

　　數據庫即服務

　　對于daas首先考慮的是做的厚還是薄，如果做的足夠薄，那么daas的核心將重點只關注數據庫層實例ID的路由功能。所有sql都進行透傳，不做任何的sql解析工作。對于路由規則應該做到可配置。數據庫層對應用半透明而非完全透明，通過daas層來實現數據庫的軟負載均衡。daas層含了數據庫即服務，也含了數據即服務。對于數據庫持久化層可以下沉到daas層里面，即對hibernate等做進一步的封裝。

　　對于mysql集群需要考慮的問題包括。對于master-slave集群，需要考慮的是集群本身的擴展和演進路線。對于讀寫分離后，第二個層面考慮master庫本身的分庫，在企業級應用中可以考慮按業務組件進行分庫。在分庫后需要進一步考慮對于表的水平或垂直shading，這是第二個層面。

　　對于雙向復制的mysql集群，需要考慮的是進行shading后的復雜關聯查詢操作的性能問題。NDB存儲引擎性能本身是比innoDB引擎性能弱的。對于NDB引擎下共享內存模式，需要考慮內存本身是否能夠足夠大支持大數據和大并發的查詢操作。

　　中間件即服務

　　這里面有太多的技術點。比較難的包括資源本身的隔離問題，特別是應用虛擬化模式下的資源隔離問題。其次是數據采集模塊的性能問題，內部的消息總線的可靠性問題。

　　在動態調度實現過程中，一種模式是基于虛擬機+硬件負載均衡設備的集群模式;一種是應用虛擬化+軟集群的實現模式。在大訪問大并發的情況下，如果采用軟集群需要考慮軟集群本身的router節點的性能問題。要知道通過軟集群來實現和硬件設備相同的性能和可靠性是很困難的事情。包括負載均衡算法，會話狀態的保存，對高并發下的TPS訪問量的支持。

　　數據采集模塊需要有足夠好的實時性，同時又需要對資源本身的消耗最低，這里一般都需要通過較為底層的協議和代碼來實現高可靠性和高性能。動態調度雖然有一定的延遲，但是仍然需要一定的實時性保證。強調資源隔離的核心仍然是只有資源隔離的清楚，實時采集到的CPU和內存信息才是可靠和準確的。

　　開發框架和環境

　　企業內私有云的paas平臺對開發框架和環境的要求和公有有有較大的區別。但是我們仍然可以看到開發框架需要集成本身的應用系統技術架構，支撐基于SOA模式的組件化開發，對于可復用的組件能夠全部嵌入進來方便的使用。對于在線開發和離線開發要同時支撐。

　　開發框架本身是一個實現了底層技術平臺和服務兩方面集成的內容。對于開發框架和環境的難點還是本身是否能夠很好的集成各種組件，設計規范和約束進來。保證各個應用系統遵循相同的開發規范，paas應用接入規范進行開發。支撐一個業務組件很快捷的和外部的技術組件，外部的業務組件進行服務層面的集成和交互。開發框架可輕可重，但是核心能力仍然是組件本身遵循某種技術架構，組件本身遵循標準的服務集成方式和外部交互。

　　應用框架和環境

　　我一直期望做到的就是有一個完全外面的app應用容器，這個應用容器已經包括了登錄，認證，統一的權限管理，菜單，系統管理，工作流引擎這些內容在里面。這個應用容器也可以看做是一個沒有任何業務功能的空應用。那么這個應用容器本身的難點在于。

　　其一是應用容器本身完全和統一認證，權限，組織人員，用戶，工作流引擎進行集成。這些集成不需要各個業務系統或業務組件操心。其二是應用容器如何裝載業務組件進來，如何保持業務組件之間的協同和交互。如何管理狀態和管理資源的使用等。

　　組織引擎，權限引擎，流程引擎，底層技術組件和平臺，4A一系列的事情都應該融合到應用框架和環境里面。因此要開發出這樣一個空應用本身就不是一件簡單的事情。

　　ESB企業級服務總線

　　在IBM的基于SOA組件化思想里面已經談到其實一個企業級PAAS應用存在多條總線，包括企業級總線，業務組件間的內部總線，業務組件內部的軟總線等。

　　ESB提供統一的服務目錄，服務接入和注冊，服務鑒權，服務運行，服務監控，服務路由，消息協議轉換等功能。不論是soap web service還是restful webservice都需要考慮實現這些內容。在這里問題主要是兩種不同serivce模式的采用。按初步理解技術服務適合采用面向資源設計，即rest方式。而對于業務服務，由于對安全性和事務，服務編排都有要求，更加適合soap web service模式。

　　對于業務組件內部的軟總線其實是另外一個難點，包括osgi的采用，osgi是否適合大型企業級應用場景，是否存在不穩定的地方，osgi軟總線調用模式對性能會構成多大的消耗等。

　　基于SOA的組件化架構

　　組件化架構強調的重點前面已經都談到過。在基于soa的組件化架構，一方面是強調業務組件間，一方面是強調業務組件內部的類總線osgi模式。業務組件是可以獨立進行需求分析，設計，開發，部署和運維的模塊。對于組件化架構，我們一直在探索的就是基于t5的web框架模式下的各層徹底組件化。

　　組件高度自治，組件如何進行裝載和跨組件協同。組件部署到應用容器后形成可以提供計算能力的計算單元，因此組件本身一定要考慮和paas平臺的自動部署和應用托管匹配。符合paas平臺的總體接入規范。組件外部遵循統一的接口服務標準，內部又有同樣的技術架構。

　　對于基于DDD領域驅動架構來進行組件化架構設計是很好的一條分析設計思路。

　　產品集成和組裝

　　真正在業務組件化和組件能力化后，業務系統的概念足夠弱化，那么業務組件如何進行組裝和集成，完成一個核心的業務功能就更加重要了。業務驅動IT，架構自頂向下形成多個業務組件，識別復用和組件間的接口。而組件在開發完成后又必須進行組件集成，完成一個核心的業務功能。

原文轉自：http://www.anti-gravitydesign.com