根據Gartner 2015年的技術成熟度曲線，SaaS是未來HCM軟件的大勢所趨，處于穩步爬升的階段。

這里不贅述SaaS的各種優勢，像體驗良好、靈活部署、按需付費、快速改進等。本文重點說明優秀的SaaS產品（特別是HCM產品）是如何進行技術設計以建立這些優勢的。

相比之下，如果做了糟糕的技術設計，就如同把產品和服務建筑在流沙之上，岌岌可危。

　　經典的計算機體系結構里，底層是硬件，中間是操作系統，上層是應用軟件。

可以把SaaS架構與經典架構做一個映射：底層是虛擬平臺層，中間是存儲和服務層，上層是應用邏輯層。下面按照自下而上的順序逐一論述。

虛擬平臺層

摩爾定律是計算機世界里最重要的一個定律。根據摩爾定律，今天的處理器的性能是1980年的處理器性能的100萬倍以上，今天一臺智能手機的計算能力超過1980年的IBM大型機。

得益于計算能力的指數增長，虛擬化的IaaS云服務大大降低了平臺軟硬件的部署成本，從而促進了SaaS服務的興起。

國外知名的云主機廠商有AWS和Linode，國內知名的云主機廠商有阿里云和騰訊云，各有優勢。操作系統方面，Windows、Linux、Unix是常用的選項。考慮到世界上80%以上的云服務都跑在Linux系統之上，而且Linux免費開源，Linux當然是最佳選擇。

接下來要考慮的就是技術棧的問題。SaaS是輕前端重后端的系統，通過把復雜性從終端轉移到云端，一方面保證用戶端良好的體驗，另一方面確保云端強大的進化能力。SaaS的技術核心在云計算，技術框架既要考慮開發效率，也要考慮程序性能，還要兼顧語言成熟度和開源社區支持。

老一代的框架有Widnows的.NET和Java的J2EE。基于Windows的架構基本得不到開源社區的支持（可見程序員們對Windows多不感冒）；Java架構成熟但是開發效率低，不太適用于快速迭代和敏捷開發。

新生代的框架包括Mean和Go。基于Nodejs的Mean架構發展迅猛，采用Java打通前后端成為統一的全棧開發語言，但是Nodejs在大數據和高并發下的表現有待進一步觀察；Go是Google力推的后端多并發編程語言，但由于是全新的語言，國內在工程師的深度和廣度上面都不太能確保。

中生代的框架包括Lnmp和Ruby on Rails。經典的Lnmp是世界上最廣為使用的Web服務框架，開發效率高，得到廣泛驗證穩定可靠，而且開源社區活躍。相比之下，Ruby在穩定性和社區支持方面稍遜一籌。

Lnmp架構在360和新浪微博得到廣泛應用，承載了每日億級PV的訪問量，Facebook的后端主力框架也是Lnmp。兜行的技術框架同樣采用Lnmp。

存儲和服務層

數據是企業最核心的信息。特別是HCM系統，能夠得到大量的員工數據，對于數據分析的要求非常強，如人事檔案還面臨數據字段的動態變化，這就要求HCM系統在數據的存儲結構設計時要充分考慮這幾點：

1、數據結構的靈活擴展

2、讀寫的效率與可靠性

3、數據庫CAP設計的平衡

面臨快速變化的用戶需求，傳統的強schema模式數據庫常常心有余而力不足。

比較激進的做法是直接升級到無schema的no-sql數據庫，比如MongoDB和CouchDB。但是no-sql數據庫在帶來靈活性的同時，也帶來了一些副作用，比如臨時表空間占用過大，不定期的垃圾回收機制導致性能抖動。

比較穩健的做法是基于穩定成熟的關系型數據庫，預留出動態字段，如mysql從5.7版本起原生支持JSON數據類型，或者采用EAV設計模式，把原本按列保存的數據轉換成按行保存。

固定字段長度的EAV表，在操作效率和穩定性上要高于no-sql數據庫。兜行的數據庫表設計里面，大量采用EAV模式。

緩存和讀寫分離是常用的提高讀寫效率的方法。比起Memcache，Redis因為支持內存數據結構，在緩存處理上更為靈活。我們可以利用Redis實現KV、消息隊列、列表、Hash，甚至用Redis實現鎖的功能。

更新緩存的Design Pattern有四種：Cache aside, Read through, Write through, Write behind caching。出于性能考慮通常選擇Cache Aside Pattern，出于一致性考慮通常會選擇Write through。

以兜行為例，后臺管理用的是Read through/Write through，前端訪問用的是Cache Aside Pattern。

HCM系統需要對數據做大量分析工作，這些工作涉及到兩類科學計算：統計分析和數據挖掘。

以考試為例，需要做的統計分析包括：最高分、最低分、平均分、方差、區段、每道題目的正確率，每個選項的選擇比例等；可以做的數據挖掘包括：成績預測，自變量與因變量的相關性等。

值得一提的是，企業的人數通常不會超過幾十萬人，大部分時候可以把所有數據導入內存，實現in-memory computing，既提高了速度又降低了分布式計算的復雜度。對于少數數據量極大的場景，可以把任務吐到map-reduce平臺完成。Python以豐富強大的科學運算庫著稱，是完成這些工作的得力工具。

在服務層除了科學計算服務，SaaS廠商通常還要支持CDN服務，以確保用戶快速訪問到網絡上的資源。

對于HCM產品，涉及到音視頻的課件和office文檔課件，所以還必須提供視頻編解碼服務和文檔轉換服務。另外，為了把消息及時通知到終端用戶，服務層還要支持消息推送，郵件通知，短信通知等多種機制。

SaaS服務的可靠性是很重要的指標，要達到5個9的可靠性水平(即99.999%的時間可用)，除了云主機自身的穩定，需要設計相應的應用監控、負載均衡和容災機制。

LVS可以用來實現負載均衡，避免單點故障。同時應用層的心跳監測和告警機制，也能及時發現故障。有趣的是，不少SaaS產品做的就是應用監測，比如New Relic，聽云APM和OneAPM。為了防止系統級的故障，數據和程序的鏡像應該在多處備份。

應用邏輯層

MVC是經典的程序設計架構，其實產品設計也遵循同樣的思路。把手機端/電腦端/網頁端等用戶端想象成V，用戶在界面上操作；把云端想象成M，做存儲和計算；把client和server之間的通信協議想象成C，完成控制與反饋。

前面說的內容大多與M有關，下面先說說C，即通信過程。

SOA和MicroService之爭一直是很熱的話題。求同存異地看，它們共同傳遞的信息是：把功能和服務內聚成模塊，模塊之間通過標準的接口進行通信，去掉大而全的core，變成獨立運轉的蟻群。聽起來是不是和面向對象的思想很相似呢？

抽象和內聚的設計模式是普適性的。對象之間通過函數調用來提供服務，而SOA和MicroService之間通過網絡請求來提供服務。據說Bezos在十幾年前就要求亞馬遜的所有產品都以網絡API形式提供服務，這是最早的SOA吧。

最常用的網絡請求是Http協議，Rest API是基于Http協議的一組規范，明確了CRUD四種操作對應的Http請求格式。工具型SaaS廠商的服務，很多以Rest API的形式提供。

HCM系統也會大量涉及到與企業內其它系統，如OA、CRM、ERP的對接和數據打通，基于Rest API的服務接口，就是不同系統間溝通交流的語言。

最后說說V，前端框架。

前端是技術世界里變化最快的角落。廣義來看，ios、android、windows pc、web、微信h5都是前端。

前端是用戶第一眼看到產品的地方，如何改善用戶體驗是前端最關心的問題。因為用戶看得見摸得到，所以展現層的修改和調整會特別頻繁，如何減少重復工作快速改進，這也是前端框架要解決的一個重要問題。web app和native app是前端的兩種形式，目前看來各有優劣。

web app的優點是開發速度快，云更新實時生效，不用維護歷史版本。缺點是每個獨立頁面都要發起若干個http請求，交互滯后明顯，體驗較差。新興的前端框架重點就要解決體驗問題，像Angular框架的最大優點就是減少了頁面請求。

native app的優點是體驗好，缺點是產品大量版本碎片，向下兼容維護工作量大。對于安卓手機，還有繞不開的適配問題。

較優的解決方案是Hybrid模式：在native里面嵌入若干的webview頁面，在效率和體驗之間找到平衡點。

相比傳統的On-premises系統，SaaS系統的架構發生了巨大的變化，分層和模塊化更為清晰，組合方式也更為復雜。這些變化，以及依然進行中的快速進化，會帶給用戶越來越好的產品和服務。