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

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

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

經(jīng)典的計算機體系結構里，底層是硬件，中間是操作系統(tǒng)，上層是應用軟件。

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

虛擬平臺層

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

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

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

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

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

新生代的框架包括Mean和Go?；贜odejs的Mean架構發(fā)展迅猛，采用Javascript打通前后端成為統(tǒng)一的全棧開發(fā)語言，但是Nodejs在大數(shù)據(jù)和高并發(fā)下的表現(xiàn)有待進一步觀察；Go是Google力推的后端多并發(fā)編程語言，但由于是全新的語言，國內在工程師的深度和廣度上面都不太能確保。

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

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

存儲和服務層

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

1、數(shù)據(jù)結構的靈活擴展

2、讀寫的效率與可靠性

3、數(shù)據(jù)庫CAP設計的平衡

面臨快速變化的用戶需求，傳統(tǒng)的強schema模式數(shù)據(jù)庫常常心有余而力不足。

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

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

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

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

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

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

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

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

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

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

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

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

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

應用邏輯層

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

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

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

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

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

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

最后說說V，前端框架。

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

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

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

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

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

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

--結束END--

投稿請發(fā)送至: 郵箱/tougao@2b.cn QQ/2799880133 微信/shawe_ren