前言業(yè)務(wù)基礎(chǔ)平臺(tái)是業(yè)務(wù)邏輯應(yīng)用和基礎(chǔ)架構(gòu)平臺(tái)之間的一個(gè)中間層，解決 “應(yīng)用軟件的業(yè)務(wù)描述和操作系統(tǒng)平臺(tái)、軟件基礎(chǔ)架構(gòu)平臺(tái)之間的交互與管理問題”。很多國內(nèi)軟件廠商，很難在操作系統(tǒng)平臺(tái)和軟件基礎(chǔ)架構(gòu)平臺(tái)上有所作為，因此國內(nèi)眾多的軟件廠商紛紛推出自己的業(yè)務(wù)基礎(chǔ)平臺(tái)，把業(yè)務(wù)基礎(chǔ)平臺(tái)看作自己的核心技術(shù)。當(dāng)前比較流行的業(yè)務(wù)基礎(chǔ)平臺(tái)大多都是基于早期的技術(shù)架構(gòu)，雖然經(jīng)過了多年的發(fā)展，但是由于技術(shù)架構(gòu)不是完全基于 SOA 的組件化概念搭建，組件化支持并不是很徹底，如何在 SOA 下搭建組件化業(yè)務(wù)基礎(chǔ)平臺(tái)成為當(dāng)前軟件開發(fā)商所面臨的新課題，本文將會(huì)基于組件化的概念，介紹一種搭建組件化業(yè)務(wù)基礎(chǔ)平臺(tái)的思路，首先我們看一下什么是“業(yè)務(wù)基礎(chǔ)平臺(tái)”，以及組件化概念。 業(yè)務(wù)基礎(chǔ)平臺(tái)如前言所述，業(yè)務(wù)基礎(chǔ)平臺(tái)是業(yè)務(wù)邏輯應(yīng)用和基礎(chǔ)架構(gòu)平臺(tái)之間的一個(gè)中間層，解決 “應(yīng)用軟件的業(yè)務(wù)描述和操作系統(tǒng)平臺(tái)、軟件基礎(chǔ)架構(gòu)平臺(tái)之間的交互與管理問題”。操作系統(tǒng)平臺(tái)解決了“應(yīng)用軟件系統(tǒng)與硬件之間的交互與管理問題”，軟件基礎(chǔ)架構(gòu)平臺(tái)解決了“應(yīng)用軟件系統(tǒng)與操作系統(tǒng)平臺(tái)之間的交互與管理問題”，而業(yè)務(wù)基礎(chǔ)平臺(tái)則是解決了“應(yīng)用軟件的業(yè)務(wù)描述與操作系統(tǒng)平臺(tái)、軟件基礎(chǔ)架構(gòu)平臺(tái)之間的交互與管理問題”。如下圖所示： 圖 1. 業(yè)務(wù)基礎(chǔ)平臺(tái)在技術(shù)架構(gòu)中的位置 一般業(yè)務(wù)基礎(chǔ)平臺(tái)都包含兩個(gè)部分，運(yùn)行環(huán)境和開發(fā)環(huán)境，開發(fā)環(huán)境主要用于解決如何更加快速的開發(fā)，也是業(yè)務(wù)基礎(chǔ)平臺(tái)的核心內(nèi)容，本文主要介紹業(yè)務(wù)基礎(chǔ)平臺(tái)的運(yùn)行環(huán)境架構(gòu)，關(guān)于開發(fā)環(huán)境將不在進(jìn)一步論述。 業(yè)務(wù)組件和公共組件業(yè)務(wù)組件（Business Component，BC）是一個(gè)可以獨(dú)立運(yùn)行的系統(tǒng)或者模塊，業(yè)務(wù)組件的目的是以方便業(yè)務(wù)組件獨(dú)立升級(jí)和減少不必要的組件之間的交互為基本原則，通過一定程度的分離，實(shí)現(xiàn)軟件重用（Software Reuse）。如果業(yè)務(wù)組件是共用的，是其它業(yè)務(wù)組件需要重用的，稱之為公共業(yè)務(wù)組件（簡稱公共組件），所有的公共組件組成企業(yè)架構(gòu)中技術(shù)架構(gòu)的公共服務(wù)平臺(tái)，比如主數(shù)據(jù)管理、系統(tǒng)管理、統(tǒng)一認(rèn)證管理、通用報(bào)表等，這些都是公共組件。詳見之前的文章《面向服務(wù)體系架構(gòu)（SOA）和業(yè)務(wù)組件（BC）的思考》（以下簡稱 SOA 和 BC）關(guān)于業(yè)務(wù)組件和公共組件的說明。 組件化業(yè)務(wù)基礎(chǔ)平臺(tái)基于組件化業(yè)務(wù)基礎(chǔ)平臺(tái)和傳統(tǒng)的業(yè)務(wù)基礎(chǔ)平臺(tái)主要的差異在于組件化業(yè)務(wù)基礎(chǔ)平臺(tái)具有更多的靈活性、可擴(kuò)展性，能夠更加方便的進(jìn)行組件升級(jí)和組件維護(hù)。特別是對(duì)于大型的行業(yè)軟件來說，易于升級(jí)、易于維護(hù)，能夠靈活的擴(kuò)展成為評(píng)測(cè)一個(gè)業(yè)務(wù)基礎(chǔ)平臺(tái)的一個(gè)重要標(biāo)準(zhǔn)，隨著業(yè)務(wù)的不斷發(fā)展，很多一體化行業(yè)軟件代碼數(shù)量已經(jīng)超過 1G，如何對(duì)如此龐大規(guī)模的代碼進(jìn)行維護(hù)、升級(jí)成為軟件開發(fā)者和運(yùn)維管理者日益關(guān)注的一個(gè)課題，代碼關(guān)系復(fù)雜、系統(tǒng)啟動(dòng)慢成為一個(gè)大型系統(tǒng)所面臨的一個(gè)主要矛盾。組件化業(yè)務(wù)基礎(chǔ)平臺(tái)主要用于解決簡化開發(fā)，快速系統(tǒng)維護(hù)的問題，以下通過對(duì)兩種業(yè)務(wù)基礎(chǔ)平臺(tái)的對(duì)比，對(duì)組件化業(yè)務(wù)基礎(chǔ)平臺(tái)的組件實(shí)現(xiàn)、調(diào)用方式、所包含的公共組件及組件進(jìn)行說明。 傳統(tǒng)的業(yè)務(wù)基礎(chǔ)平臺(tái)當(dāng)前在 J2EE 框架下業(yè)務(wù)基礎(chǔ)平臺(tái)基本上是采用了“Spring Framework”、“Expresso Framework”、等開源軟件為基礎(chǔ)的框架，業(yè)務(wù)系統(tǒng)基于業(yè)務(wù)基礎(chǔ)平臺(tái)進(jìn)行開發(fā)，在一個(gè)企業(yè)內(nèi)部，很容易形成基于一個(gè)業(yè)務(wù)基礎(chǔ)平臺(tái)橫向開發(fā)出多個(gè)業(yè)務(wù)模塊，甚至是跨行業(yè)的業(yè)務(wù)組件，基于一個(gè)業(yè)務(wù)基礎(chǔ)平臺(tái)開發(fā)的系統(tǒng)，所有的業(yè)務(wù)組件可以基于一個(gè)數(shù)據(jù)庫運(yùn)行，搭建一體化的業(yè)務(wù)應(yīng)用系統(tǒng)。當(dāng)前常見的業(yè)務(wù)基礎(chǔ)平臺(tái)包括浪潮 Loushang 平臺(tái)、SAP 的 Net Weaver、金蝶 Apusic、普元 EOS 等。其架構(gòu)如下圖所示： 圖 2. 業(yè)務(wù)基礎(chǔ)平臺(tái)模型 但是這種模式存在幾個(gè)重大的缺陷：
如何既能實(shí)現(xiàn)一體化，又可以解決以上問題是當(dāng)前業(yè)務(wù)基礎(chǔ)平臺(tái)需要解決的問題。 組件化業(yè)務(wù)基礎(chǔ)平臺(tái)在《面向服務(wù)體系架構(gòu)（SOA）和數(shù)據(jù)倉庫（DW）的思考》（以下簡稱《 SOA 和 DW 》）一文中曾經(jīng)提出一個(gè)原則：“軟件的核心是重用，方法是分離，關(guān)鍵是標(biāo)準(zhǔn)”，組件化基礎(chǔ)業(yè)務(wù)平臺(tái)依然是遵循這個(gè)原則。隨著 SOA 技術(shù)的逐步發(fā)展，SOA 已經(jīng)成為像面向?qū)ο笠粯与m然不像“云計(jì)算”那樣時(shí)髦，卻成為一個(gè)重要的軟件體系設(shè)計(jì)模式。由于很多軟件都是基于業(yè)務(wù)基礎(chǔ)平臺(tái)進(jìn)行開發(fā)的，業(yè)務(wù)基礎(chǔ)平臺(tái)的組件化成為組件化開發(fā)的一個(gè)基礎(chǔ)的要求，如果業(yè)務(wù)基礎(chǔ)平臺(tái)沒有實(shí)現(xiàn)組件化，組件化開發(fā)還是停留在之前的遺留系統(tǒng)改造的概念中。如何實(shí)現(xiàn)業(yè)務(wù)基礎(chǔ)平臺(tái)的組件化，如何利用組件化對(duì)業(yè)務(wù)基礎(chǔ)平臺(tái)進(jìn)行改造成為業(yè)務(wù)基礎(chǔ)平臺(tái)關(guān)注的一個(gè)焦點(diǎn)。 組件化開發(fā)，首先是業(yè)務(wù)基礎(chǔ)平臺(tái)本身的組件化，把業(yè)務(wù)基礎(chǔ)平臺(tái)看成是一個(gè)獨(dú)立的組件，即《 SOA 和 BC 》所描述的基于企業(yè)集成平臺(tái)（企業(yè)門戶、應(yīng)用集成、數(shù)據(jù)集成）的公共組件所描述的內(nèi)容。 業(yè)務(wù)基礎(chǔ)平臺(tái)的組件化，并不是所有的內(nèi)容全部組件化，有些內(nèi)容是無法分離出去的，因此首先要把業(yè)務(wù)基礎(chǔ)平臺(tái)的內(nèi)核分離出來，建立一個(gè)業(yè)務(wù)基礎(chǔ)平臺(tái)的微內(nèi)核，微內(nèi)核是跟每一個(gè)業(yè)務(wù)組件緊密相關(guān)的。然后把業(yè)務(wù)基礎(chǔ)平臺(tái)中可以分離出來的內(nèi)容單獨(dú)作為一個(gè)組件，即公共組件，從而實(shí)現(xiàn)業(yè)務(wù)組件和公共組件的分離。 業(yè)務(wù)組件和公共組件使用一個(gè)數(shù)據(jù)庫，通過公共組件及相關(guān)的標(biāo)準(zhǔn)實(shí)現(xiàn)整合，如果還有已有的系統(tǒng)，則通過企業(yè)集成平臺(tái)進(jìn)行整合。如下圖所示： 圖 3. 組件化業(yè)務(wù)基礎(chǔ)平臺(tái)模型 業(yè)務(wù)基礎(chǔ)平臺(tái)主要業(yè)務(wù)組件公共服務(wù)組件包含系統(tǒng)管理、流程管理、主數(shù)據(jù)管理、元數(shù)據(jù)管理等，在數(shù)據(jù)層面分別對(duì)應(yīng)著系統(tǒng)數(shù)據(jù)、流程數(shù)據(jù)、主數(shù)據(jù)和元數(shù)據(jù)等數(shù)據(jù)?？紤]到公共服務(wù)組件的獨(dú)立性，特別是保證每一個(gè)組件獨(dú)立升級(jí)之后不會(huì)影響到其他的公共服務(wù)組件以及業(yè)務(wù)組件，因此需要對(duì)公共服務(wù)組件進(jìn)行隔離。 圖 4. 業(yè)務(wù)基礎(chǔ)平臺(tái)主要業(yè)務(wù)組件 系統(tǒng)管理主要包含：用戶管理、功能管理、權(quán)限管理、認(rèn)證管理等功能，其中需要特別注意的是實(shí)現(xiàn)不同的業(yè)務(wù)組件的統(tǒng)一認(rèn)證的問題，即實(shí)現(xiàn)不同的業(yè)務(wù)組件部署在不同的應(yīng)用下（在 J2EE 環(huán)境下為 EAR 文件）的單點(diǎn)登錄。 主數(shù)據(jù)管理主要包含：主數(shù)據(jù)模型管理、主數(shù)據(jù)質(zhì)量控制、主數(shù)據(jù)監(jiān)控等功能，主要實(shí)現(xiàn)各個(gè)組件之間公用的基礎(chǔ)數(shù)據(jù)的管理，需要考慮主數(shù)據(jù)在那個(gè)業(yè)務(wù)組件中進(jìn)行維護(hù)的問題，不同的主數(shù)據(jù)需要在不同的業(yè)務(wù)組件中完成，而不是所有的主數(shù)據(jù)都在主數(shù)據(jù)管理組件完成。 流程管理主要包含：代辦任務(wù)管理、流程自定義、流程引擎等功能，主要實(shí)現(xiàn)對(duì)代辦任務(wù)的統(tǒng)一管理、流程的管理。流程管理主要實(shí)現(xiàn)流程和業(yè)務(wù)的分離，并實(shí)現(xiàn)辦公用的靈活流程、業(yè)務(wù)用的固定流程，詳見《基于 SOA 的工作流（WF）整合》的描述。 元數(shù)據(jù)的管理主要包含：元數(shù)據(jù)管理、數(shù)據(jù)質(zhì)量監(jiān)控等功能，主要實(shí)現(xiàn)技術(shù)元數(shù)據(jù)和業(yè)務(wù)元數(shù)據(jù)的管理。 業(yè)務(wù)基礎(chǔ)平臺(tái)組件接口調(diào)用方式在實(shí)際開發(fā)應(yīng)用中，性能是很重要的一個(gè)非功能性需求，特別是針對(duì)大型的應(yīng)用系統(tǒng)，性能是決定項(xiàng)目成敗的一個(gè)關(guān)鍵因素，業(yè)務(wù)基礎(chǔ)平臺(tái)的架構(gòu)決對(duì)性能問題有著重大的影響。如何在實(shí)現(xiàn)松耦合的基礎(chǔ)上，進(jìn)一步提升性能問題（包括保證數(shù)據(jù)庫事務(wù)處理），是大型應(yīng)用軟件的業(yè)務(wù)基礎(chǔ)平臺(tái)必須要解決的一個(gè)問題，不能僅僅是為了組件化而組件化，如果不能解決性能問題，組件化就不能在大型的應(yīng)用系統(tǒng)中得到廣泛應(yīng)用，因此需要根據(jù)在實(shí)際開發(fā)過程中碰到的不同的場景，采用不同的調(diào)用方式，除了組件化中提到的服務(wù)，還有要有其他的方式作為補(bǔ)充，即能實(shí)現(xiàn)松耦合，又可以保證性能，實(shí)現(xiàn)不同層次的不同調(diào)用。 實(shí)現(xiàn)組件化，首先要定義清晰、簡單的業(yè)務(wù)組件界面，特別是業(yè)務(wù)組件和公共組件之間的界面，然后建立一個(gè)兼顧松耦合、性能的調(diào)用方式及不同的調(diào)用方式的標(biāo)準(zhǔn)。在《 SOA 和 ROA 》描述了業(yè)務(wù)組件接口模型，除了人機(jī)交互界面（沒有組件之間的調(diào)用關(guān)系），組件之間的調(diào)用關(guān)系主要有服務(wù)接口和數(shù)據(jù)接口兩種。如下圖所示： 圖 5. 業(yè)務(wù)組件接口模型 在上述接口模型中，組件的接口是面向集成平臺(tái)的，在組件化業(yè)務(wù)基礎(chǔ)平臺(tái)組件模型中，由于是基于一個(gè)統(tǒng)一業(yè)務(wù)基礎(chǔ)平臺(tái)，因此可以增加一個(gè)通過 API 調(diào)用的接口方式，提高調(diào)用效率和保證事務(wù)處理，同時(shí)為了進(jìn)一步優(yōu)化性能，服務(wù)接口可以分成重量級(jí)的 SOAP 和輕量級(jí)的 REST 兩種，因此可以把組件之間的調(diào)用關(guān)系進(jìn)一步分成四種（如下圖所示）。在不同的層級(jí)，從性能和耦合性兩個(gè)角度，組件間可以選擇不同的調(diào)用方式， 具體采用那種調(diào)用關(guān)系主要是考慮性能、接口復(fù)雜度、耦合性等問題，不同的業(yè)務(wù)組件，特別是不同的廠商之間開發(fā)的組件采用基于 SOAP 的服務(wù)，同一個(gè)廠商開發(fā)的不同組件之間通過 REST 服務(wù)進(jìn)行調(diào)用或者直接采用數(shù)據(jù)接口進(jìn)行調(diào)用。一個(gè)業(yè)務(wù)組件內(nèi)部，業(yè)務(wù)組件和公共模塊之間的調(diào)用，以及為了保證事務(wù)處理，直接通過在不同的業(yè)務(wù)組件中內(nèi)嵌模塊的方式，實(shí)現(xiàn) API 調(diào)用，如下圖所示： 圖 6. 組件化業(yè)務(wù)基礎(chǔ)平臺(tái)接口調(diào)用方式
業(yè)務(wù)組件之間于 SOAP 的 Web 服務(wù)調(diào)用或者 REST Web 服務(wù)調(diào)用，因?yàn)榛?SOAP 的 Web 服務(wù)擁有眾多的標(biāo)準(zhǔn)，可以方便的實(shí)現(xiàn)跨平臺(tái)調(diào)用，適用于不同廠商之間的業(yè)務(wù)組件調(diào)用，同一個(gè)廠商之間的不同組件調(diào)用可以直接通過能夠提供很好性能的 REST Web 服務(wù)調(diào)用。
不同的業(yè)務(wù)組件之間需要事物處理的調(diào)用，通過內(nèi)嵌一個(gè)內(nèi)核業(yè)務(wù)處理模塊的方式進(jìn)行，如庫存處理相關(guān)業(yè)務(wù)，在訂單模塊和采購模塊都需要調(diào)用，通過服務(wù)方式很難處理事物，可以將一個(gè)簡化的庫存模塊（如 Jar 包，建議采用 OSGi 架構(gòu)，WAS8 已經(jīng)提供了很好的支持）直接內(nèi)嵌到訂單模塊和采購模塊，如下圖“庫存模塊內(nèi)嵌到訂單和采購業(yè)務(wù)組件”所示；工作流引擎也可以采用這樣的方式，詳見《基于 SOA 的工作流（WF）整合》的說明。
圖 7. 庫存模塊內(nèi)嵌到訂單和采購業(yè)務(wù)組件 界面組件和業(yè)務(wù)邏輯組件應(yīng)該是可以完全獨(dú)立的，在完全實(shí)現(xiàn)組件化業(yè)務(wù)基礎(chǔ)平臺(tái)中，界面組件應(yīng)該是可以獨(dú)立部署的，界面組件和業(yè)務(wù)邏輯組件之間通過 REST 的服務(wù)交互，詳見《 SOA 和 ROA 》所描述的架構(gòu)說明。業(yè)務(wù)邏輯組件可以沒有任何界面，完全獨(dú)立于界面顯示，實(shí)現(xiàn)界面和業(yè)務(wù)的分離。在 J2EE 環(huán)境中，完全可以實(shí)現(xiàn)業(yè)務(wù)組件全部由 Jar 包組成，不含任何界面內(nèi)容，界面組件則完全采用 JSP 實(shí)現(xiàn)。 基于數(shù)據(jù)接口調(diào)詳見《 SOA 和 DW 》關(guān)于共享庫的描述，在實(shí)現(xiàn)所有的組件公用一個(gè)數(shù)據(jù)庫的基礎(chǔ)上，不同業(yè)務(wù)組件需要確定數(shù)據(jù)接口作為共享標(biāo)準(zhǔn)（如下圖所示深藍(lán)色部分流程、系統(tǒng)、主數(shù)據(jù)、業(yè)務(wù)一、業(yè)務(wù)二、···），其中有些數(shù)據(jù)是不需要在不同的業(yè)務(wù)組件進(jìn)行共享的，則屬于組件內(nèi)部的數(shù)據(jù)，（如下圖所示淡藍(lán)色部分流程、系統(tǒng)、主數(shù)據(jù)、業(yè)務(wù)一、業(yè)務(wù)二、···），對(duì)于業(yè)務(wù)基礎(chǔ)平臺(tái)所包含的業(yè)務(wù)組件流程、系統(tǒng)、主數(shù)據(jù)也采用這樣的方式，可以保證業(yè)務(wù)基礎(chǔ)平臺(tái)向下兼容的進(jìn)行獨(dú)立升級(jí)，而不會(huì)影響到其他的業(yè)務(wù)組件。 圖 8. 數(shù)據(jù)接口實(shí)現(xiàn)思路 內(nèi)部服務(wù)總線可以不同于當(dāng)前商業(yè) ESB，采用比較復(fù)雜的服務(wù)總線產(chǎn)品，內(nèi)部服務(wù)總線為了提高性能，可以采用簡化處理，僅僅實(shí)現(xiàn)服務(wù)路由的功能，甚至僅僅實(shí)現(xiàn)一個(gè)服務(wù)注冊(cè)管理即可。簡化處理主要是解決當(dāng)前 ESB 所遇到的性能問題，如果沒有服務(wù)動(dòng)態(tài)變化的需求，可以不考慮服務(wù)編排的問題。 業(yè)務(wù)基礎(chǔ)平臺(tái)組件版本為了保證業(yè)務(wù)組件的靈活的擴(kuò)展，還有一個(gè)很重要的因素，就是版本的兼容，要實(shí)現(xiàn)以上不同層次的接口調(diào)用的向下兼容，包含服務(wù)接口、API 接口、數(shù)據(jù)接口，即升級(jí)之后的應(yīng)該和老版本可以兼容。特別是數(shù)據(jù)庫接口，必須實(shí)現(xiàn)向下兼容，不然無法實(shí)現(xiàn)一體化數(shù)據(jù)庫，造成升級(jí)困難。數(shù)據(jù)接口并非是所有的數(shù)據(jù)模型，主要是針對(duì)核心對(duì)象模型建立的對(duì)象基本關(guān)系模型，關(guān)于基礎(chǔ)對(duì)象模型的建立，可以參見《基于面向?qū)ο螅∣O）的數(shù)據(jù)庫設(shè)計(jì)模式探討 1、2 》所描述“對(duì)象關(guān)系模型”建模的思路，建立更加穩(wěn)定的數(shù)據(jù)模型，保證數(shù)據(jù)接口的穩(wěn)定。后續(xù)文章會(huì)進(jìn)一步的描述關(guān)于建立通用數(shù)據(jù)模型的思路。 實(shí)現(xiàn)了四個(gè)層面的接口向下兼容的，組件就可以獨(dú)立升而不會(huì)相互影響，保證不同業(yè)務(wù)組件的版本兼容，對(duì)于一個(gè)業(yè)務(wù)組件內(nèi)部，不同的模塊之間，需要保證版本一致，如業(yè)務(wù)基礎(chǔ)平臺(tái)的內(nèi)核，需要跟業(yè)務(wù)組件的版本保持一致。保證一個(gè)和業(yè)務(wù)組件本身的版本兼容，不同的業(yè)務(wù)組件之間可以版本不同，但是數(shù)據(jù)結(jié)構(gòu)要兼容。 圖 9. 不同版本的業(yè)務(wù)基礎(chǔ)平臺(tái)整合 業(yè)務(wù)基礎(chǔ)平臺(tái)和集成平臺(tái)通過以上分析可以看到，組件化業(yè)務(wù)基礎(chǔ)平臺(tái)和集成平臺(tái)有所不同，基于一個(gè)業(yè)務(wù)基礎(chǔ)平臺(tái)構(gòu)建一體化系統(tǒng)有著諸多的限制，和集成平臺(tái)相比組件化業(yè)務(wù)基礎(chǔ)平臺(tái)需要更多的標(biāo)準(zhǔn)（如 API、數(shù)據(jù)接口等），限制也更加嚴(yán)格，尤其是針對(duì)不同的廠商，同時(shí)適應(yīng)這些標(biāo)準(zhǔn)比較困難，因此更適合用于同一個(gè)廠商內(nèi)部的不同業(yè)務(wù)組件之間的一體化。不同廠商的系統(tǒng)或者業(yè)務(wù)組件，遺留系統(tǒng)，則需要通過集成平臺(tái)進(jìn)行集成，來搭建一體化系統(tǒng)。通過集成平臺(tái)，采用通用的標(biāo)準(zhǔn)，對(duì)系統(tǒng)進(jìn)行簡單的改造就可以實(shí)現(xiàn)集成。 為了使組件化業(yè)務(wù)基礎(chǔ)平臺(tái)具有更加廣泛的應(yīng)用，可以進(jìn)一步完善，實(shí)現(xiàn)對(duì)跨數(shù)據(jù)庫的管理，用于解決超大型的應(yīng)用對(duì)性能的要求，業(yè)務(wù)數(shù)據(jù)可以分別部署在多臺(tái)機(jī)器中，數(shù)據(jù)庫有多個(gè)實(shí)例，分散數(shù)據(jù)庫的壓力。同時(shí)可以支持在遵循所有相關(guān)標(biāo)準(zhǔn)的基礎(chǔ)上其他廠商的業(yè)務(wù)組件，如果實(shí)現(xiàn)多個(gè)廠商基于一個(gè)基礎(chǔ)業(yè)務(wù)平臺(tái)開發(fā)，需要其他的廠商的緊密配合。如下圖所示： 圖 10. 不同廠商的組件通過集成平臺(tái)進(jìn)行整合 注：如果部署兩個(gè)數(shù)據(jù)庫，考慮到性能問題，需要考慮將公共組件的數(shù)據(jù)復(fù)制一份到獨(dú)立部署的數(shù)據(jù)庫中，特別是主數(shù)據(jù)、權(quán)限數(shù)據(jù)等，跟業(yè)務(wù)緊密相關(guān)，具體實(shí)現(xiàn)方式不在本文探討的課題。 總結(jié)相比傳統(tǒng)的業(yè)務(wù)基礎(chǔ)平臺(tái)，組件化業(yè)務(wù)基礎(chǔ)平臺(tái)能夠?qū)崿F(xiàn)業(yè)務(wù)基礎(chǔ)平臺(tái)組件之間以及業(yè)務(wù)組件之間的松耦合，可以實(shí)現(xiàn)：
|
|
|
