為什麼混合雲是未來雲計算的主流形态?

上期文章我介紹了我們蘑菇街之是以選擇上雲，是基于怎樣的全面考量。今天我們來聊一聊，對于蘑菇街這樣有着一定規模體量的産品，我們在不同時期和不同階段，對雲的使用方式是怎樣的。

關于混合雲

對于“混合雲”這三個字，你應該不會陌生。但是，“混合雲”又是比較寬泛一個概念，随着技術趨勢的發展，這個概念的内涵和外延也在不斷發生着變化。 從字面上了解，“混合雲”即私有雲和公有雲的混合搭配，這也是最開始對混合雲最簡單直接的解釋。

但是随着公有雲服務越來越豐富，我們對公有雲的應用也不再僅僅限于資源層面，而更多地展現在雲服務層面。是以，不同時期、不同角色、不同團隊、不同行業對于混合雲的使用和了解可能都會不同。

為了友善了解，我們以CDN為例。 我們使用的CDN服務，其實是雲服務最早被應用的典型形态。但是，在早期，更多的是專業CDN廠商提供這類服務，而不是騰訊雲和阿裡雲這樣的公有雲巨頭來提供，同時它跟我們 實際接觸到的機器資源又有很大的不同。

是以在很長一段時間内，我們并沒有意識到這就是雲服務。但是，這種使用模式，從雲的特性來講，就是混合雲模式，但是不同時期，不同背景的人對它的了解可能就完全不一樣。

關于CDN這一塊，在後續專欄中，我将會單獨撰寫文章進行詳細介紹。

我們對混合雲概念的熟知，更多的還是在公有雲服務興起之後。因為其提供了更加靈活、便捷的資源彈性能力，滿足了行業内普遍的彈性需求，被應用到大量的彈性應用場景中，與 業務自身所在的IDC機房形成一個整體，就有了混合雲模式。

對于目前新興的創業公司，除部分因政策監管因素無法上雲的業務外，基本都會将業務完整地放到公有雲上運作。 但是對于類似蘑菇街這樣的産品，因為在公有雲蓬勃發展之前就已經建設了自有的技術體系和架構，是以在選擇上雲的過程中，就需要有個過渡過程，這個過程就是混合雲需求存在的應用場景。

下面我就分享一下，蘑菇街上雲過程中的幾項基礎設施，在過渡階段以及後續建設上的思路。

我們所經曆的幾個基礎設施建設階段 第一個階段，完全托管IDC模式。我們選擇與電信營運商或者第三方ISP合作，租賃其IDC機房中的機櫃。而其他主機硬體和網絡裝置都是我們自行采購，然後放入機房中進行托管。

這種模式我在上篇文章中也介紹過，會随着業務規模體量不斷增加而出現一系列問題。

第二個階段，資源短期租賃模式。上期文章中我曾介紹過，因為電商大促的例行化，以及峰值流量的激增，導緻我們短時資源需求量龐大。如果再靠一次性采購模式，付出的成本巨 大，且後期成本閑置，造成嚴重的浪費。

我們曾跟營運商或第三方ISP談過一些短期租賃合作，因為營運商或ISP服務商在機櫃資源上相對充裕，通常在它們完全租賃出去之前，也會存在閑置情況。是以如果我們能夠向它們 短期租賃機櫃，這對我們雙方都是有益的。

但是，隻有機櫃沒有資源也是沒有意義的。是以在資源上，營運商和ISP會利用其廣泛的合作管道優勢，幫助我們與其自身，或與第三方達成資源上的短期租賃合作。 這種合作模式，在前兩年确實幫我們在資源緊張和成本優化方面，解決了很大的難題。

雖然機櫃和硬體資源在形态上還不能稱之為雲，方式上也不夠靈活，但是這種模式起到的作用，很大程度上滿足了我們對彈性的需求，是以我們内部戲稱這種模式為“人肉雲”，或者 叫“人工雲”。

這種模式令我深有感觸，頓時豁然開朗:

解決問題，有時跳出純技術思維模式，嘗試通過外部合作和溝通的模式，一樣可以有很好的解決方案，甚至可以解決在技術層面解決不了的問題。 第三個階段，同城混合雲模式。近些年營運商和ISP服務商也在做自己的公有雲體系，是以随着他們服務的不斷完善，後來為了能夠提升傳遞效率，我們也會嘗試使用他們的公有雲業務。

這裡我這是以提到同城混合雲模式，主要原因是，作為營運商和ISP服務商，他們的雲資源可以與我們在同一機房或同城機房。這種模式最大的優勢就是可以與我們的IDC網絡專線拉 通，大大降低網絡時延，網絡品質相對穩定，同時成本也相對較低。

如果是跨城甚至是跨省，就會頻繁發生網絡抖動、丢包這些問題。對于時延敏感的服務，是完全滿足不了要求的，且微服務間頻繁調用産生的大流量帶寬需求，成本也是非常巨大的。

是以，這種情況下，雖然公有雲的各項産品和服務相對完善，但是如果在對應的城市沒有公有雲節點，或者距離較遠，又或者專線品質不高，就基本沒法滿足我們規模化使用的場景。

但也不是全部無法滿足。後面一篇文章我會介紹通過公有雲建設CDN和二級CDN體系的内容，雖然沒有專線，但仍然可以滿足部分業務場景。

通過上面的内容，你可以看到，同城營運商和ISP服務商在公有雲服務方面優勢巨大，且這種優勢主要展現在地域和網絡資源品質上。

我想，營運商的公有雲業務在近期有不錯的發展，這也是很重要的原因之一。

第四個階段，公有雲體系内混合雲模式。上篇文章我介紹到，從長遠的角度考慮，為了能夠更加全面和深入地利用好雲計算的産品技術，我們整體搬遷到了騰訊雲。

這個階段初期，我們使用的還是完全獨立的實體機資源。這種資源使用模式與之前托管IDC模式相比，除硬體和網絡外，作業系統和各項技術棧還完全是由我們自己運維。

之是以這樣做，還是為了保證遷移過程的平穩。因為我們自身的技術體系和架構已經非常龐大，也有較高的複雜度。

要想在另外一套基礎設施上将這套精密的體系部署、調測、運作起來，同時還要保證各項性能名額以及系統容量不出問題，項目難度就已經非常高了。而這樣做可以很好地防止軟體架構發生變化，避免各種複雜因素交織在一起所導緻的業務穩定性的不可控。

之前我看到有很多人批評，甚至是貶低這種公有雲提供獨立實體機資源的模式，認為這是換湯不換藥，或者認為這是技術含量太低、技術水準不足的表現。但是我認為這種了解還是太片面。

單純從技術角度來講，這種模式或許沒有展現出公有雲的特性，但是從實際業務場景和實際客戶需求來講卻是必要的。而且對于類似蘑菇街這樣有着大規模業務體量和複雜技術架構的産品來說，它還滿足了使用者的過度需求。

是以，我認為騰訊雲在這一方面還是展現出了“客戶第一”的意識的。 當然，搬遷到騰訊雲之後，下一個階段，我們必然會利用更多的雲資源和雲服務。比如無狀态的Web服務或者微服務應用，在大促時完全可以利用雲的彈性優勢進行快速的資源擴縮 容。

但是對于資料庫或大資料這樣的存儲類業務，因為它們本身又是支援業務運作的核心基礎設施，是以短期内我們仍然還是采用獨占實體機的模式。我們主要基于下面兩方面進行考量。

1.技術架構比對問題。以資料庫為例，我們自研了分布式資料庫中間件和大量的工具，比如對分庫分表的支援和資料遷移轉換等等。還針對具體的業務場景和特性在資料庫和作業系統 層面做了大量的優化工作，包括但不限于各類參數的調優，以及部分特性的定制。

再者，雲上資源也無法規模化地滿足我們對硬體的特定需求，是以我們在這種模式下，就很難一下子将雲服務利用起來，而其它的分布式元件也會存在類似問題。

歸根結底，這還是雲上的技術體系和原有的業務技術體系不比對的沖突所導緻的，需要二者花更多的時間來磨合。同時，這也決定了在未來很長一段時間内，混合雲模式才是最佳實踐模式。

2.資料安全問題。我認為一些有政策要求或政策限制的業務，需要慎重考慮這個問題。

比如金融行業，或者某些ToB 的業務，由于各種競争或敏感問題，客戶本身就不允許你的服務在雲上，那麼在資料安全問題上需要更全面地考慮，這種情況下如果采用混合雲模式就會受到很大限制。

但是，如果沒有上面這些問題的困擾，我認為上雲是最好的選擇。上雲前後需要建立起彼此互相之間的信任，同時也可以共同簽署資訊安全約定，在法律層面進行限制。

總結