尋夢新聞LINE@每日推播熱門推薦文章，趣聞不漏接❤️
關於混合雲
對於「混合雲」這三個字，你應該不會陌生。但是，「混合雲」又是比較寬泛一個概念，隨著技術趨勢的發展，這個概念的內涵和外延也在不斷發生著變化。
從字面上理解，「混合雲」即私有雲和公有雲的混合搭配，這也是最開始對混合雲最簡單直接的解釋。
但是隨著公有雲服務越來越豐富，我們對公有雲的應用也不再僅僅限於資源層面，而更多地體現在雲服務層面。所以，不同時期、不同角色、不同團隊、不同行業對於混合雲的使用和理解可能都會不同。
為了方便理解，我們以CDN為例。
我們使用的CDN服務，其實是雲服務最早被應用的典型形態。但是，在早期，更多的是專業CDN廠商提供這類服務，而不是騰訊雲和阿里雲這樣的公有雲巨頭來提供，同時它跟我們實際接觸到的機器資源又有很大的不同。
所以在很長一段時間內，我們並沒有意識到這就是雲服務。但是，這種使用模式，從雲的特性來講，就是混合雲模式，但是不同時期，不同背景的人對它的理解可能就完全不一樣。
我們對混合雲概念的熟知，更多的還是在公有雲服務興起之後。因為其提供了更加靈活、便捷的資源彈性能力，滿足了行業內普遍的彈性需求，被應用到大量的彈性應用場景中，與業務自身所在的IDC機房形成一個整體，就有了混合雲模式。
對於當前新興的創業公司，除部分因政策監管因素無法上雲的業務外，基本都會將業務完整地放到公有雲上運行。
但是對於類似蘑菇街這樣的產品，因為在公有雲蓬勃發展之前就已經建設了自有的技術體系和架構，所以在選擇上雲的過程中，就需要有個過渡過程，這個過程就是混合雲需求存在的應用場景。
下面我就分享一下，蘑菇街上雲過程中的幾項基礎設施，在過渡階段以及後續建設上的思路。
我們所經歷的幾個基礎設施建設階段
第一個階段，完全托管IDC模式。
我們選擇與電信經營商或者第三方ISP合作，租賃其IDC機房中的機櫃。而其他主機硬件和網路設備都是我們自行採購，然後放入機房中進行托管。
這種模式我在上篇文章中也介紹過，會隨著業務規模體量不斷增加而出現一系列問題。
第二個階段，資源短期租賃模式。
我曾介紹過，因為電商大促的例行化，以及峰值流量的激增，導致我們短時資源需求量龐大。如果再靠一次性採購模式，付出的成本巨大，且後期成本閒置，造成嚴重的浪費。
我們曾跟經營商或第三方ISP談過一些短期租賃合作，因為經營商或ISP服務商在機櫃資源上相對充裕，通常在它們完全租賃出去之前，也會存在閒置情況。所以如果我們能夠向它們短期租賃機櫃，這對我們雙方都是有益的。
但是，只有機櫃沒有資源也是沒有意義的。所以在資源上，經營商和ISP會利用其廣泛的合作管道優勢，幫助我們與其自身，或與第三方達成資源上的短期租賃合作。
這種合作模式，在前兩年確實幫我們在資源緊張和成本優化方面，解決了很大的難題。
雖然機櫃和硬件資源在形態上還不能稱之為雲，方式上也不夠靈活，但是這種模式起到的作用，很大程度上滿足了我們對彈性的需求，所以我們內部戲稱這種模式為「人肉雲」，或者叫「人工雲」。
這種模式令我深有感觸，頓時豁然開朗：
解決問題，有時跳出純技術思維模式，嘗試通過外部合作和溝通的模式，一樣可以有很好的解決方案，甚至可以解決在技術層面解決不了的問題。
第三個階段，同城混合雲模式。
近些年經營商和ISP服務商也在做自己的公有雲體系，所以隨著他們服務的不斷完善，後來為了能夠提升交付效率，我們也會嘗試使用他們的公有雲業務。
這里我這所以提到同城混合雲模式，主要原因是，作為經營商和ISP服務商，他們的雲資源可以與我們在同一機房或同城機房。這種模式最大的優勢就是可以與我們的IDC網路專線拉通，大大降低網路時延，網路質量相對穩定，同時成本也相對較低。
如果是跨城甚至是跨省，就會頻繁發生網路抖動、丟包這些問題。對於時延敏感的服務，是完全滿足不了要求的，且微服務間頻繁調用產生的大流量帶寬需求，成本也是非常巨大的。
所以，這種情況下，雖然公有雲的各項產品和服務相對完善，但是如果在對應的城市沒有公有雲節點，或者距離較遠，又或者專線質量不高，就基本沒法滿足我們規模化使用的場景。
但也不是全部無法滿足。後面一篇文章我會介紹通過公有雲建設CDN和二級CDN體系的內容，雖然沒有專線，但仍然可以滿足部分業務場景。
通過上面的內容，你可以看到，同城經營商和ISP服務商在公有雲服務方面優勢巨大，且這種優勢主要體現在地域和網路資源質量上。
我想，經營商的公有雲業務在近期有不錯的發展，這也是很重要的原因之一。
第四個階段，公有雲體系內混合雲模式。
這個階段初期，我們使用的還是完全獨立的物理機資源。這種資源使用模式與之前托管IDC模式相比，除硬件和網路外，操作系統和各項技術棧還完全是由我們自己運維。
之所以這樣做，還是為了保證遷移過程的平穩。因為我們自身的技術體系和架構已經非常龐大，也有較高的複雜度。
要想在另外一套基礎設施上將這套精密的體系部署、調測、運行起來，同時還要保證各項性能指標以及系統容量不出問題，項目難度就已經非常高了。而這樣做可以很好地防止軟件架構發生變化，避免各種複雜因素交織在一起所導致的業務穩定性的不可控。
之前我看到有很多人批評，甚至是貶低這種公有雲提供獨立物理機資源的模式，認為這是換湯不換藥，或者認為這是技術含量太低、技術水平不足的表現。但是我認為這種理解還是太片面。
單純從技術角度來講，這種模式或許沒有體現出公有雲的特性，但是從實際業務場景和實際客戶需求來講卻是必要的。而且對於類似蘑菇街這樣有著大規模業務體量和複雜技術架構的產品來說，它還滿足了用戶的過度需求。無狀態的Web服務或者微服務應用，在大促時完全可以利用雲的彈性優勢進行快速的資源擴縮容。
但是對於數據庫或大數據這樣的存儲類業務，因為它們本身又是支持業務運行的核心基礎設施，所以短期內我們仍然還是採用獨占物理機的模式。我們主要基於下面兩方面進行考量。
1.技術架構匹配問題。以數據庫為例，我們自研了分布式數據庫中間件和大量的工具，比如對分庫分表的支持和數據遷移轉換等等。還針對具體的業務場景和特性在數據庫和操作系統層面做了大量的優化工作，包括但不限於各類參數的調優，以及部分特性的定制。
再者，雲上資源也無法規模化地滿足我們對硬件的特定需求，所以我們在這種模式下，就很難一下子將雲服務利用起來，而其它的分布式組件也會存在類似問題。
歸根結底，這還是雲上的技術體系和原有的業務技術體系不匹配的矛盾所導致的，需要二者花更多的時間來磨合。同時，這也決定了在未來很長一段時間內，混合雲模式才是最佳實踐模式。
2.數據安全問題。我認為一些有政策要求或政策限制的業務，需要慎重考慮這個問題。
比如金融行業，或者某些ToB的業務，由於各種競爭或敏感問題，客戶本身就不允許你的服務在雲上，那麼在數據安全問題上需要更全面地考慮，這種情況下如果採用混合雲模式就會受到很大限制。
但是，如果沒有上面這些問題的困擾，我認為上雲是最好的選擇。上雲前後需要建立起彼此相互之間的信任，同時也可以共同簽署信息安全約定，在法律層面進行約束。
退一萬步講，即使不上雲，我們的數據在自己的機房里就一定100%安全嗎？我想這才是需要我們真正考慮的問題。
