公有云SAAS產品不同於傳統的軟件包產品，我們不僅需要負責軟件的研發，同時需要負責產品的運維，面對眾多用戶，需要保障產品7X24不間斷運行；客戶業務是不斷變化的，產品需要在持續運行過程中進行持續升級，以滿足客戶業務不斷變化的需要。相對傳統軟件包產品，公有云產品的升級更加複雜，風險也更高，類似於在運動的汽車上更換輪胎。
設計的本質就是讓產品變化更容易。微服務架構是互聯網時代以適應快速的業務變化而產生的一種架構模式，提供了讓變化更容易的基礎。自2014年起開始得到業界的廣泛關注，近幾年，隨著DevOps技術的成熟，微服務架構模式得到越來越多企業的實踐應用。微服務架構的特點是能夠獨立開發獨立部署，獨立伸縮和獨立運維，技術上沒有免費的午餐，微服務在給我們帶來眾多好處的同時，也帶來了眾多的複雜性，這其中包括DevOps複雜性、分佈式系統複雜性等。我們必須採用合適的分析設計方法、工具和流程，改善產品設計架構、自動化DevOps、建立高質量的領域模型等，從而最大限度獲得微服務架構的好處，降低微服務架構帶來的負面影響。
產品研發時首先調查市場需求背景，縱觀國內，小微企業數量眾多。其典型特點是數量多，單個企業業務量相對較少，沒有專人負責系統管理和維護，整體IT水平不高，特別適合應用SAAS服務模式。而在近幾年，隨著雲計算技術的發展，社會上出現大量商業業務創新，像電子支付、電子雲倉和電子發票等商業基礎設施走向商業應用。如何集成社會上出現的一些商業基礎設施為小微企業所用？因此SaaS服務成為了眾多小微企業唯一的選擇。
進行問題分析時，需要明確客戶群，面向數量多的小微企業，工貿公司、貿易公司和製造商，單個企業的業務不復雜，但是做一款產品同時滿足多個企業是一個複雜問題。另外作為雲產品，要保證產品在7×24小時內始終運行，在這個始終運行的產品上做升級和維護也是一個高風險的活動。
基於以上問題和背景，我們提出幾個設計目標，如產品架構支持大規模併發用戶需要；模型和架構支持持續、快速演進；通過產品的開發積累企業基礎業務能力，為將來新產品的快速開發積累可用資源。
而基於設計目標，我們明確以下幾個總體思路。
第一是重視設計，設計既是產品的未來，只有好的設計，我們的產品才能再客戶業務成長的路上走得更遠。第二是充分利用第三方技術，專注我們自己擅長的領域。第三是在時間和資源有限的情況下，分離關注點，簡單實現，保障在將來有資源的情況下，系統能夠演進。第四是採用DDD方法進行領域切分和解耦，微服務充分保障業務的內聚。最後是最為業務系統，領域模型是其核心和基因，是將來支持業務演進的基礎，提高領域模型質量，模型設計適當超前。
SAAS產品研發專業強，涉及的技術棧和能力較多，前後端採用完全不同的技術棧，各自獨立開發。此外，作為一款滿足眾多用戶需求的產品，定製化是其基本能力，前後端的平臺是產品的基礎能力。與之相對應，研發組織切分為多個小團隊，例如產品，UI/UE，前端、後端、測試、運維、業務運營。
研發團隊切分為多個小組，各個小組之間相互協作。如何保障不同團隊之間合作高效，完整規範和標準必不可少，執行研發全生命週期的規範，可以有效提供工作質量和協作效率。
微服務架構模式在帶來好處的同時，也帶來DevOps的複雜性，建立自動化運維過程是使用微服務架構的必要條件。依據公司的產品開發發佈流程制定合適的分支方案、製品管理方案、持續集成方案、環境管理方案。
分支分為develop、test和release分支，將開發、測試和發佈進行空間上隔離；
開發人員從develop分支下載最新版本，構建成功之後發佈到Nexus，通過自動任務將Nexus上的snapshot包發佈到“Auto Testing”環境，然後在該環境上執行自動集成測試；
自動測試成功之後，將構建的包發佈到develop環境；
在develop環境中由開發人員完成人工確認和驗證；
人工確認完成之後，驅動自動任務將develop中內容merge/rebase到test分支，測試人員通過手工執行jenkins任務完成release包發佈到集成測試環境過程；
運維人員負責維護生產環境，生產環境支持灰度部署，降低新版本交付的風險。
採用微服務架構不僅僅採用一種新的技術方式，如果沒有采用相應的分析設計的方法進行輔助，其帶來的弊將大於利，我們會陷入從一個火坑跳入另外一個火坑的尷尬。需要從業務建模、系統建模、領域建模、物理建模幾個層次進行分步設計，提高微服務設計質量，保障產品將來可以持續演進。
分析設計包括工具、方法和流程。製造和使用工具是人類社會區別其它動物的標誌，採用合適的工具可以極大提高分析設計的效率和質量。分析設計工具採用EA，DB建模工具採用ERWin。方法是凝集業界的最佳實踐，領域驅動設計方法是面向對象思想的迴歸和昇華，正確掌握領域驅動設計的前提是對面向對象的設計技巧。DDD是對面向對象設計最重要的原則——軟件結構反映問題的結構的落地。採用DDD分析方法對業務進行分析和設計，分析設計流程包括業務建模、系統建模、領域建模和物理模型。
對於複雜系統，系統外觀是很難想象出來的，必須通過工程化方法分析得到的，也就是通過業務建模的方法分析得到系統外觀。業務建模是把整個組織都作為一個研究對象，選取典型的業務場景，識別組織中包含的角色和系統，並把系統看成是黑盒子，分析組織裡的角色和系統如何相互協作完成業務，對外輸出業務價值。
業務建模之後得到系統的外觀，然後通過系統建模分析系統裡面到底有哪些組件組成或者模塊組成的。切分模塊的目的是分離關注點，降低系統複雜性。把系統拆成一個個模塊，這些模塊之間怎麼相互協作，滿足系統外觀裡面所要求的功能，這就是系統系列圖。對複雜的系統，通過分析模塊之間的協作，得到每個模塊的外觀。
業務世界外在紛繁複雜，其內在本質的東西相對穩定，領域建模的目的就是通過事物的紛繁的現象和外觀洞悉事物本質。領域模型也是我們看待業務世界的一種方式，幫助企業在產品設計時理清業務中包含的概念以及概念之間的關係。領域模型是表達業務功能（表象）背後的業務本質的模型，領域模型屬於知識級模型，具有更高的穩定性，支持在線系統業務變更。
物理模型是領域模型的關係表達，是面向物理表。把表建好，用轉換的工具可以依據表生成代碼，保障設計的模型不僅僅是紙上或掛在牆上的一個擺設，是一個能夠真正落地驅動開發的東西。
基於SaaS產品實施方案，包括多項重要技術選擇，比如租戶模式，分層設計，應用架構，總體技術架構，模塊裡面的技術架構，以及在微服務架構下、分佈式環境下產品的一致性方案。
什麼叫租戶模式？SaaS產品需要使用應用、虛機和DB三種資源資源。按照對虛機、應用和DB的使用方式分為不同的模式。虛機模式就是每個租戶有獨立的虛機，有獨立的應用和獨立的DB，租戶資源不共享，租戶之間隔離性好，但資源利用率低。租戶獨立DB模式每個租戶共享虛機和應用，DB由每個租戶專用，虛機和應用資源利用率高，但DB資源利用率低。
第三種模式是租戶共享DB模式，虛機、應用和DB都為所有租戶共享，資源利用率高，租戶之間軟隔離，隔離性差。
對於小微企業群體，租戶數量大，載荷不均勻，對個性化需求要求不高，我們決定採用租戶共享DB模式。
對於複雜系統，分層設計是解決複雜性問題的重要手段之一。採用DDD的方法按照業務的視角對系統進行分層設計。同層之間和上下層之間可以調用，嚴格控制循環調用，控制依賴的複雜性。
前後端採用不同的技術棧，前後端進行分離設計，各自由獨立的部門進行開發。後端分為應用服務層和領域層。其中應用服務層是利用領域知識提供的服務能力，提供業務功能，解決具體業務問題。領域層包括核心領域層、支持子域層和通用子域層，提供領域知識服務能力。
核心領域層 - 為客戶核心業務提供服務；
支持子域層 - 支持業務某一方面的子域；
通用子域 - 用於整個系統的子域
從技術的視角，能力層（包括通用子域服務、支持子域服務和核心子域服務）各個微服務之間通過RPC方式進行調用。應用服務層通過RPC方式調用領域服務層。應用服務層通過REST方式對外發布服務，由前端NodeJS接口服務器進行調用。前端應用通過HTTP/HTTPS的方式訪問NodeJS服務。
生成物理模型之後，依據物理模型和插件生成Repository層、領域層和持久層，模型不再是掛在牆上的擺設，通過模型驅動代碼，讓模型真正落地。採用知識綁定方式將貧血的對象與知識件綁定，貧血對象變為智能對象（Smart Object）。實際上這種方案是考慮自動代碼生成在貧血和充血模型之間的折中。
不同於傳統單體系統，可以通過XA事務解決分佈式資源數據一致性問題。在分佈式系統運行場景下，各個服務運行在不同的進程中，各個進程獨立運行，維護業務一致性是一個複雜的問題。系統提供兩種一致性機制，即TCC的強一致性和基於消息+TCC調用的最終一致性。兩種一致性機制適應不同的場景。
在很多業務場景下，在客戶請求之後，系統需要做一序列複雜操作。這些操作中，有些操作需要即時執行並響應；還有些操作實時性要求不高，可以在請求響應之後再交給系統處理。基於消息+TCC的最終一致性方式就是應用這種場景的一致性機制。通過消息的方式將系統解耦，進行異步操作，同時也起到削峰填谷的作用，平衡系統載荷。
相對傳統軟件包產品，雲產品升級是一個高風險的活動，設計高質量的領域架構和靈活的領域模型是雲產品從容應對業務變化的基礎。在建立雲產品研發體系時，構建包括核心業務服務能力、支持業務服務能力和通用業務服務能力等公司基礎業務服務能力，能極大縮短後期產品研發週期，這些基礎服務能力是公司快速業務創新的基礎。
閱讀更多 儒雅程序員 的文章
