Spring Cloud在雲端計算SaaS中的實戰經驗分享

傳統的軟體模式是在開發出軟體產品後，需要去客戶現場進行實施，通常部署在區域網，這樣開發、部署及維護的成本都是比較高的。

現在隨著雲服務技術的蓬勃發展，就出現了SaaS模式。所謂SaaS模式即是把產品部署在雲伺服器上，從前的客戶變成了“租戶”，我們按照功能和租用時間對租戶進行收費。這樣的好處是，使用者可以按自己的需求來購買功能和時間，同時自己不需要維護伺服器，而我們作為SaaS提供商也免去了跑到客戶現場實施的麻煩，運維的風險則主要由IaaS提供商來承擔。

目前主流的SaaS多租戶資料庫方案有以下三種：

完全隔離：獨立資料庫，它的好處就是隔離度很高，但是佔用成本也相當高，而且資源共享度低。

共享+隔離：可以共享資料庫，但是有獨立的Schema。這樣它的各項指標相對來說都是比較平均的。

完全共享：共享資料庫和資料表。我個人不太推薦這種方式，因為雖然它的共享度很高，但是幾乎沒有隔離度，而且開發上的複雜度會隨著業務發展越來越高。

資料庫中的Schema是資料庫物件的集合。比如在Oracle中，一個使用者一般對應一個Schema。

對MySQL來說，Schema並不是Database的下級，而是等同於Database。比如執行create schema test，和createdatabase test是一樣的。

Oracle與MySQL的資料庫層級對應關係如下：

獨立Schema模式的優點：

高獨立性：每個租戶都擁有自己的庫，與其他租戶是隔離的；

高可擴充套件性：可以方便的進行橫向擴充套件和資料遷移；

業務開發簡單：開發時只需要考慮單租戶的業務邏輯即可，通過切換Schema來達到多租戶的效果，聯查的表更少；

定製化服務：使用者可以定製個性化服務，不影響其他租戶；

獨立Schema模式存在的問題：

1、資料庫越來越多怎麼辦？如果有10萬個租戶，就有10萬個庫，單個伺服器肯定無法承受。

2、如此多的資料庫，如何進行表的更新與維護？

3、租戶的資料都隔離開了，進行整體資料分析的時候怎麼辦？

為了解決第一個問題，我們採用了分散式多租戶資料庫叢集。假設有10萬租戶，它們可以分佈在不同的伺服器上，而且每臺伺服器上的數量都不是固定的，可以根據業務量進行分佈，必要時還可以進行租戶遷移。

當租戶分佈開以後，可使用如下方式來定位租戶：

第二和第三個問題，可以使用資料微服務來解決：

資料微服務可以專門用來處理新增Schema，更新資料結構、批量執行SQL以及統計分析等操作。

至於統計分析的時效性，租戶通常只關注自身業務的統計分析，因此我們在面向租戶時可以只對單個業務庫進行實時統計分析，資料量一般不大。而我們後臺對全域性資料的統計分析通常時效性要求不高，就可以使用非同步或定時任務處理，此時建議使用多個資料微服務來分割槽處理資料再彙總。當總體資料量大到一定程度，還可以引入Hadoop等大資料處理框架。

微服務大體上有兩種情況的拆分。第一種是根據業務功能進行拆分，微服務本身應該是高內聚的，微服務之間低耦合，微服務業務應該是單一的。

另一種情況就是從架構設計來拆分，是從基礎元件、效能均衡和資源分配這三個角度考慮的。

通常情況下，我們都可以拆分出許多通用業務微服務和基礎架構微服務，現在假設我們有這樣的通用業務服務池和基礎架構服務池。首先我們可能有很多不同的系統，它們一些通用的業務就放在通用業務池裡，但是它們本身也會有一些獨立的特殊業務。那麼我們既可以直接呼叫通用業務服務池裡的API，也可以在處理特殊業務時呼叫其他業務微服務的API，而這些業務微服務也同樣可以呼叫通用業務池裡的微服務。

產品不是由服務組成的，而是由API組成的。服務就是服務，我們不一定要讓它必須屬於哪個產品，而是要把不同服務的API組合成一個產品。

下面是一個使用Spring Cloud的服務拓撲舉例：

前後端協作

通常使用swagger方式中存在的問題：

各類與業務無關的註解大量汙染Controller程式碼，造成維護困難；

靈活性差，想要給特定人暴露特定介面（比如第三方）比較麻煩；

釋出生產時需要特殊處理來關閉swagger；

Swagger有時會與其他jar包衝突（比如springfox-swagger2.6.0會導致註冊Eureka異常）。

開發未動，文件先行。正式開發前優先編寫獨立的Swagger微服務供開發人員參考，讓Swagger迴歸文件本質；

專案初期，由Swagger微服務直接返回格式化的假資料供前端除錯，方便前後端並行開發；

前後端聯調時，前端可繼續由Swagger通過Feign來呼叫後端服務檢視資料，或直接連後端服務除錯真實業務邏輯；

可針對不同第三方的需求，提供不同的對外Swagger微服務讓對方除錯，靈活暴露介面。

後端服務完全不引入任何Swagger程式碼，保持程式碼純淨，也避免了Swagger衝突，釋出生產時直接關掉Swagger服務即可；

注意事項：

Swagger的介面路徑、引數等必須與真正的業務介面保持一致，嚴格遵守規範，方便前端直連後端時統一修改；

Swagger微服務中需要有相應的VO，這類東西可以編寫一次，到處複製。因此並不會增加工作量。

技術並不是全部

我今天的分享就到這裡，謝謝大家！