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

摘要

雲賬房CTO張英磊基於本身的我的經驗，分享Spring Cloud在雲計算SaaS中的實戰經驗，但願能爲你們帶來一些思路上的幫助。

內容來源：2017年5月6日，雲賬房CTO張英磊在「Spring Cloud中國社區技術沙龍-北京站」進行《Spring Cloud在雲計算SaaS中的實戰經驗分享》演講分享。IT 大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2084 | 5分鐘閱讀

嘉賓演講視頻及PPT回顧：t.cn/RETMgVo

SaaS漫談

SaaS模式是什麼？

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

如今隨着雲服務技術的蓬勃發展，就出現了SaaS模式。所謂SaaS模式便是把產品部署在雲服務器上，從前的客戶變成了「租戶」，咱們按照功能和租用時間對租戶進行收費。這樣的好處是，用戶能夠按本身的需求來購買功能和時間，同時本身不須要維護服務器，而咱們做爲SaaS提供商也免去了跑到客戶現場實施的麻煩，運維的風險則主要由IaaS提供商來承擔。

SaaS多租戶數據庫方案

目前主流的SaaS多租戶數據庫方案有如下三種：

徹底隔離：獨立數據庫，它的好處就是隔離度很高，可是佔用成本也至關高，並且資源共享度低。

共享+隔離：能夠共享數據庫，可是有獨立的Schema。這樣它的各項指標相對來講都是比較平均的。

徹底共享：共享數據庫和數據表。我我的不太推薦這種方式，由於雖然它的共享度很高，可是幾乎沒有隔離度，並且開發上的複雜度會隨着業務發展愈來愈高。

什麼是Schema？

數據庫中的Schema是數據庫對象的集合。好比在Oracle中，一個用戶通常對應一個Schema。

對MySQL來講，Schema並非Database的下級，而是等同於Database。好比執行create schema test，和createdatabase test是同樣的。

Oracle與MySQL的數據庫層級對應關係以下：

獨立Schema模式的優勢和問題

獨立Schema模式的優勢：

高獨立性：每一個租戶都擁有本身的庫，與其餘租戶是隔離的；

高可擴展性：能夠方便的進行橫向擴展和數據遷移；

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

定製化服務：用戶能夠定製個性化服務，不影響其餘租戶；

獨立Schema模式存在的問題：

一、數據庫愈來愈多怎麼辦？若是有10萬個租戶，就有10萬個庫，單個服務器確定沒法承受。

二、如此多的數據庫，如何進行表的更新與維護？

三、租戶的數據都隔離開了，進行總體數據分析的時候怎麼辦？

分佈式多租戶數據庫集羣

爲了解決第一個問題，咱們採用了分佈式多租戶數據庫集羣。假設有10萬租戶，它們能夠分佈在不一樣的服務器上，並且每臺服務器上的數量都不是固定的，能夠根據業務量進行分佈，必要時還能夠進行租戶遷移。

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

數據微服務

第二和第三個問題，可使用數據微服務來解決：

數據微服務能夠專門用來處理新增Schema，更新數據結構、批量執行SQL以及統計分析等操做。

至於統計分析的時效性，租戶一般只關注自身業務的統計分析，所以咱們在面向租戶時能夠只對單個業務庫進行實時統計分析，數據量通常不大。而咱們後臺對全局數據的統計分析一般時效性要求不高，就可使用異步或定時任務處理，此時建議使用多個數據微服務來分區處理數據再彙總。當整體數據量大到必定程度，還能夠引入Hadoop等大數據處理框架。

架構設計

微服務的拆分原則

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

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

業務架構設計

一般狀況下，咱們均可以拆分出許多通用業務微服務和基礎架構微服務，如今假設咱們有這樣的通用業務服務池和基礎架構服務池。首先咱們可能有不少不一樣的系統，它們一些通用的業務就放在通用業務池裏，可是它們自己也會有一些獨立的特殊業務。那麼咱們既能夠直接調用通用業務服務池裏的API，也能夠在處理特殊業務時調用其餘業務微服務的API，而這些業務微服務也一樣能夠調用通用業務池裏的微服務。

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

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

實戰經驗分享

配置集中化管理

先後端協做

一般使用swagger方式中存在的問題：

各種與業務無關的註解大量污染Controller代碼，形成維護困難；

靈活性差，想要給特定人暴露特定接口（好比第三方）比較麻煩；

發佈生產時須要特殊處理來關閉swagger；

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

Spring Cloud + Swagger

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

項目初期，由Swagger微服務直接返回格式化的假數據供前端調試，方便先後端並行開發；

先後端聯調時，前端可繼續由Swagger經過Feign來調用後端服務查看數據，或直接連後端服務調試真實業務邏輯；

可針對不一樣第三方的需求，提供不一樣的對外Swagger微服務讓對方調試，靈活暴露接口。

後端服務徹底不引入任何Swagger代碼，保持代碼純淨，也避免了Swagger衝突，發佈生產時直接關掉Swagger服務便可；

注意事項：

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

Swagger微服務中須要有相應的VO，這類東西能夠編寫一次，處處複製。所以並不會增長工做量。

總結

技術並非所有

我今天的分享就到這裏，謝謝你們！