toB的SaaS平台研發難點和應對政策

§1）管理，技術和業務的平衡；

      SaaS平台對于業務架構師的要求很高，需要在管理、技術和業務之間取得一種平衡。我的建議是以管理為目标，進行技術和業務架構的适應和比對。因為本質上，SaaS平台本身就是大資料，而大資料的設計還是堅持“ 面向應用（業務）架構”原則。另外，系統架構或者進階研發人員參與産品需求分析和業務架構應越早越好。

§2）通用性和個性化的平衡

    這是個難點，解決這個問題的一般方法就是可配置化，比如采用流程引擎，智能表單，業務流程抽象，模闆化等可配置化技術，但不能做得太過，不能最後做成了二次開發或者幹脆就是一個新的開發工具（典型的如SAP的系統）。大部分的目标使用者都沒有這個開發能力，是以必須進行平衡。比如，我經曆過一家公司，我們做到頁面的全配置化顯示，看起來節省了前端開發和後端開發的工作量，但由于配置參數太多，最後反而增加了很多配置學習成本，配置使用成本，以及配置無法滿足業務時的定制成本，整體上的成本反而不劃算。後面這種模式不了了之，白白耗費了幾百萬。

    簡單易用和專業複雜性之間的平衡，也是個性化和通用性的之間的平衡，如果太複雜或者需要二次開發顯然是不現實的，為了解決這個問題，行業領域垂直細分就是一個不錯的選擇，畢竟領域越細分通用性就會好些。

§3）分布式架構的切割次元和粒度（事務性強）

    ToB的業務一般來說事務性特别強，單純的采用微服務或者傳統系統模式都不是特别好，我的建議是根據 二八原則，為解決80%的問題可以采用簡單的分布式資料存儲模型，其它20%部分可以采用微服務這種架構。分布式架構中涉及到分割次元和粒度，根據自身的業務特性去考慮，次元不要過多，最多3維，粒度以最大化事務同庫為基本原則。應用無狀态是基本的原則，類似于記憶體資料庫的東西盡量不要用，這種方式不利于分布式負載均衡的處理。我們的産品采用的是我們自己研發的三大模型（分布式計算模型，分布式部署模型，分布式資料存儲及通路模型），很好的解決了這些問題。

§4）标準化，一體化（業務連續性，一緻性）

    隻要是管理系統，标準化是最基本的，标準化的目标是支撐業務的連續性、一緻性。這裡采用的就是對業務資料必須進行分類分層，對資料歸屬規則和權限架構結合最大程度的減少權限設計的簡化和一般化。

§5）其它：資料庫使用原則，資料隔離級别等

資料庫使用的原則就是資料庫隻進行資料的基本操作，業務邏輯不要放在資料庫（比如用存儲過程，視圖等）。而資料隔離基本上都是需要支援表隔離，資料庫隔離，實體隔離三種級别。   對于SaaS應用，還面臨多組織（集團模式），多語言，多時區的問題，多組織相對來說比較好解決，利用企業标準化和業務資料歸屬及權限就可以解決；多語言處理的基本原則就是配置資料庫化，傳統的程式多語音包可以做到資料庫配置層，當然系統架構底層最好是配合做一些規劃；多時區的問題本質是個時間标準的問題，這個是個時間技巧處理的事情，相對比較簡單。