對於業務系統自己在架構設計的時候考慮擴展，原來更多的都是談的IT基礎技術架構自己的高可用性和高擴展性。而對於業務系統擴展性，簡單來講就是如何靈活的應對需求的變化和擴展，若是減小在處理變動或擴展中代碼不斷產生的壞味道。前端
說到擴展性，通常會談到數據庫擴展性和應用擴展性兩個方面的內容，固然不少應用的擴展性最終會反饋到數據庫自己的擴展性上面來。而對於應用自己的擴展性自己又包括了數據模型的擴展，接口的擴展，業務規則的擴展，流程的擴展幾個方面的內容，下面分別對上面內容進行描述。sql
數據庫設計的擴展性
對於數據庫設計的擴展性準備談兩個方面，一個是數據庫自己的拆分問題，一個是數據庫設計方面的內容。數據庫拆分重點是解決在非集羣架構下如何擴展的問題，數據庫設計重點是解決在IT基礎設施架構不變狀況下擴展和性能提高。數據庫
數據庫的水平拆分和垂直拆分設計模式
對於數據庫自己的擴展和性能，一個方面就是採用數據庫集羣架構，另一個關鍵方法就是進行數據庫拆分，而數據拆分自己分爲垂直拆分和水平拆分。服務器
垂直拆分簡單來講就是根據業務域將數據庫表拆分到不一樣的數據庫上面，而水平拆分則是指對於同一個數據庫表按照用戶，組織等其它拆分維度將數據水平拆分到不一樣的數據庫上，可是這些數據庫自己數據庫結構是同樣的。
垂直拆分實際上和咱們如今談的微服務架構下的數據庫拆分概念一致。架構
而水平拆分要解決的問題是若是已經進行微服務架構設計，可是單個微服務自己的數據庫性能沒法達到要求，這個時候就必須考慮水平拆分。例如咱們能夠按不一樣區域將用戶數據拆分到不一樣的數據庫中，或者按企業自己的多組織結構，將不一樣組織數據庫拆分到不一樣的數據庫中。併發
水平拆分自己應該對上層應用透明。框架
即上層應用並不清楚底層進行了數據庫水平拆分，而仍然像訪問一個沒有拆分的數據庫同樣進行數據庫的訪問，數據庫的CRUD操做等。在這個時候就須要在拆分完成的數據庫上面構建一層DaaS數據訪問層，也能夠叫作數據庫訪問中間件，即屏蔽底層拆分的複雜性。數據庫設計
拿Mysql數據庫來舉例，前面幾年就出現了不少的Mysql數據庫中間件，相似最先的Cobar，Amoeba，到360的Atlas，Mycat等。分佈式
拿Mycat數據庫中間件來看，具體的架構以下:
可是實際在DaaS中間件實現過程當中，自己對於上層應用仍然有要求，雖然如今中間件自己已經支持了相似分佈式事務處理等功能，可是仍是沒法支撐徹底意義上的所有Sql特性。同時在數據庫拆分後自己還存在數據如何拆分和分區，具體路由規則等問題。
從Mysql中間件自己這幾年的關注熱度來看，實際上自己存在降低趨勢。特別是相似TiDB，阿里的PolarDB採用其它技術實現方式更好的來解決了分佈式數據庫問題。
數據庫設計的擴展性
對於數據庫自己的擴展，最容易想到的就是如何面對業務表單對象自己的字段擴展，而這個最簡單的考慮就是預留彈性字段，好比一張訂單表預留10到20個字段作爲彈性擴展字段進行處理。其次，你也能夠考慮預留一個大字符串字段，將多個數據項轉變爲Json字符串後再進行存儲，特別是對於不涉及到具體業務規則，檢索條件的字段均可以這樣進行處理。
若是字段擴展極其不肯定，或者說針對不一樣的單據類型實際上擴展的字段數都不同等狀況，你也能夠考慮將傳統的數據庫橫表設計模式轉變爲縱表設計模式。這種擴展性最好，可是涉及到數據庫SQL查詢，關聯查詢會極其不方便，所以仍是要慎用。
其次，咱們不少時候還會把業務系統中常常變化的內容轉變爲配置進行存儲，這常常看到的就是各種基礎數據表，數據字典表，全局變量配置表，數據編碼映射表，編碼生成規則表等。這些數據表將業務自己可配置的內容持久化到數據庫中以方便進行修改。在一個業務系統自己進行集羣化部署的狀況下，這些配置信息是不適合放到中間件服務器的配置文件裏面的，持久化到數據庫表裏面反而是一個好的選擇。
再次，對於數據庫單表容量的擴展自己也是重點要考慮的問題。
拿咱們實際項目來講，對於ESB服務運行日誌的存儲，單個服務實例表的數據庫行數超過5億條，這個時候對模糊查詢性能影響極大，必須對數據庫表進行分區。在實際項目中，咱們基本是按天天來設計分區表，天天就產生一個分區表。
在採用分區後至少可以知足查區間範圍在一天內的數據庫會很快，其次就是對於數據庫按天進行清理或備份更加容易。可是即便這樣數據庫模糊查詢性能也很難知足要求。所以在這種狀況下還須要在數據庫上增長一級二級索引來解決問題。
應用層的擴展性設計
若是對於一個業務處理表單，自己CRUD功能實現後，後續這個業務表單須要擴展字段屬性，這類擴展其實是比較容易實現的，只要提早在數據庫表預留了擴展字段，即可以很方便的實現這種擴展能力。固然在考慮到界面展示的時候，咱們還須要考慮這些擴展屬性項是否進行顯示，這個內容自己也要可配置。
若是一個業務系統採用了流程引擎，那你能夠看到一個流程設計自己就很容易擴展，好比增長或刪除流程活動節點，選擇活動節點的處理角色和參與人等，這些內容自己可配置，擴展沒有問題。
一個業務系統自己也分爲多個模塊或組件，那麼模塊間的接口自己穩定性就很重要，那麼接口如何保證可擴展？
對於接口的擴展實際上和數據庫表擴展思路相似，咱們能夠在接口上面啓用多個擴展字段，也能夠在接口中啓用一個存儲大Json串的擴展字典，在Json串中能夠靈活定義和傳輸多個字段內容。
一個業務系統自己的變動每每涉及到數據對象的變動，流程的變動和規則的變動。而這裏面最麻煩的就是規則的變動，而規則的變動說到擴展和可配置性，你們容易想到的就是啓用規則引擎來進行處理。而實際上對於複雜規則的實現，即便你採用了規則引擎，裏面也要寫大量的腳本代碼，即這部分採用規則引擎自己並無太大的意義可言。
所以對於規則的擴展核心是如何將規則從原有的業務系統單據中剝離出來，即咱們首先定義的標準的規則擴展接口，同時在接口中輸入你須要使用到的數據對象，當須要擴展的時候咱們僅僅對接口內容進行實現。
能夠構想一個最簡單的場景，對於採購訂單建立功能，咱們能夠考慮在訂單建立Button事件處理中增長對接口方法的擴展和調用。即訂單保存的時候涉及到以下步驟：
//ISaveBefore.Process(Form Data); //Save(); //ISaveAfter.Process(Form Data);
即當你須要在訂單保持前進行預處理，或者是在訂單保持成功後進行額外操做的時候，你徹底能夠對上面兩個接口方法進行實現。這兩個接口方法實際上對保存事件先後進行了攔截，而攔截到的內容如何處理你徹底能夠本身進行擴展。
爲什麼要採用上面的方式進行設計？你能夠想下若是一個CRM系統你面臨諸多的客戶，每一個客戶可能都存在會在你的標準CRM版本上面進行定製。對於訂單建立功能90%的功能都是標準功能，可是僅僅是先後的處理規則和邏輯有少許差別。那麼咱們這樣設計就很方便針對不一樣的客戶擴展不一樣的定製代碼包，而確保CRM產品主幹版本只有一套，這種方式能夠最大化產品複用度，同時由標準化配置管理工做。
其次當咱們實施了上百家客戶的CRM系統後，你會發現全部用到的規則自己也能夠進行標準化，好比標準化爲100個規則邏輯，而實際上客戶在實施的時候是選擇要啓用哪些規則控制。這個時候你就能夠考慮規則自己也可進行靈活配置的事情了。
舉例來講。
ISaveBefore.Process(Form Data)
{
//將不一樣的規則項獨立出來
BusinessRule1();
BusinessRule2();
BusinessRuleN();
}
而後咱們再須要一個簡單的配置表，來配置一個新客戶究竟啓用哪些規則項就能夠了。對於啓用的規則項就執行，對於不啓用的規則項就不執行。在這種處理方式下，雖然咱們沒有啓用規則引擎，可是規則自己造成了條目化的規則庫或規則片斷，其次規則片斷能夠靈活綁定到客戶項目上。這種規則處理的靈活性將足夠咱們在實際實施項目中靈活應對。
經過相似AOP的思路，攔截進行擴展，將是應用層擴展的一個關鍵思路點。這種擴展方式雖然沒有實現徹底的靈活可配置化，可是卻具有了至關的靈活性和可管理性。
基於SOA思想擴展性設計
再從新強調下SOA架構思想的一個關鍵即上層的應用或流程應該是基於服務組裝和編排出來的，當上層應用出現變化的時候，不少時候並不須要底層的服務進行變化或修改，而只須要對服務從新進行組裝。
這個和當前咱們談的中臺架構思想是一致的，即前端應用會出現業務需求變動或變化，可是大部分時候中臺能力並不須要變化，而只須要對前端應用邏輯進行修改。
在私有云PaaS平臺建設裏面，我當時就給出告終合SOA架構思想的一個完整的業務組件邏輯設計的一個參考圖，具體以下：
在整個架構中，橫向分爲了平臺層，服務層和應用層。對於服務層能夠理解爲當前中臺提供的共享API服務能力開放是一個道理。對於應用層，原來叫薄應用，也能夠理解當前微服務下的前端應用。總體的架構徹底符合我在前面一篇文章談到的資源+服務+應用的三層架構模式。
對於應用層而言，其中仍然分爲數據層、業務邏輯層和展示層的三層架構模式：
數據層
數據層主要包括了對於主數據等共享數據的訪問和讀取，也包括了對業務組件模塊本身私有數據的CRUD操做。數據層能夠直接調用DaaS服務層能力操做底層數據庫，也能夠直接調用封裝後的領域數據服務能力查詢和訪問數據。
業務邏輯層
業務邏輯層和傳統業務邏輯層最大的區別是體現了SOA服務化的思想。即對於業務流程和功能的業務實現是經過平臺層提供的技術服務和業務服務能力進行組合和組裝實現的。這既能夠經過傳統的代碼開發和服務調用來實現，也能夠經過相似BPEL設計和建模工具等可視化的進行靈活配置和實現。
能夠看到，對於業務邏輯層的重點就是對已有的各類業務服務，數據服務，技術服務能力進行組合，完成一個關鍵的業務功能實現。
展示層
展示層主要是各類前端和界面實現技術，傳統的如JSP，HTML，JQuery等。也包括當前主流的相似VUE，React, Angular等Web前端開發框架。展示層經過調用邏輯層的服務能力進行數據的存取和業務規則的實現，同時也包括了界面集成技術實現多個業務組件的界面集成。
業務系統可擴展總結
最後再簡單總結下一個應用系統的可擴展設計。
其一，可擴展設計涉及到數據庫，應用層，業務規則邏輯，界面層的多處可擴展性。必需要各個分層，各個點上都考慮到可擴展性，每每纔可以完成一個完整的擴展性設計需求。
其二，可擴展性設計一方面是解決的業務系統併發量增長後的可擴展能力，一個方面重點是解決的業務需求變動的時候系統自己的適應變化度。對於變化的適應自己又分多個層面，便是否須要變動數據庫，是否須要變動應用開發代碼，是否須要從新編譯等。在擴展性設計中最好的就是儘可能不要涉及到從新編譯和版本部署。
其三，可擴展性設計每每會犧牲性能，所以也不能過分的使用擴展性和冗餘設計，致使總體應用架構性能出現明顯降低。