我先來打個比方。我早上從北京過來，在北京，樹上的葉子已經掉光了；來到這邊之後，卻發現自己穿的有點多，梧桐樹上還滿是綠葉；而前年的這個時候我去廣州，那邊還是鳥語花香。從地域的維度看，同一個時間點，三個地方，出現三種不同的狀況。相應的，如果從時間的維度來觀察技術發展的脈絡，我們一樣也可以從這個歷史中借鑑出，未來技術的發展趨勢。

93年的時候Linux剛剛出現，那個時候網際網路還處於起步階段。到99年的時候，Linux在國內有一個熱潮，這主要是因為資本的力量帶動了基礎設施的繁榮。來到07年，在這之前有一個開源的組織運作Linux社群的發展，這主要是為了避免出現unix多版本分裂的可能性，這需要以一個基金會的方式控制整個技術的發展還有社群的繁榮。2007年的時候Linux的基金會成立，從而推動整個Linux的技術發展。事實上，Linux現在已經是非常穩定的技術，大家會毫不猶豫地使用它。

在2010年的7月開始出現開源的雲平臺。實際上在之前是AWS率先推出開源的雲服務。在2012年的9月份，僅僅用了兩年，和Linux成立foundation一樣，OpenStack Foundation也成立了來運作OpenStack的發展。基金會的工作主要有兩個方面，第一個是從技術層面，有委員會把握整個技術的發展；第二就是繁榮生態，生態包括技術生態和企業生態。其實OpenStack有4個開源的競爭對手，但是經過7年的發展，最後OpenStack勝出。現在如果大家選擇開源的雲平臺技術，OpenStack是唯一的選擇。

其實從Linux到OpenStack已經印證了開源技術發展的思路。

2013年的7月份，Docker把自己的技術開源了。時間來到第二年2014年的7月份，谷歌就把其內部使用的系統Kubernetes開源出來，立刻就有一些大的廠商對其進行支援，比如說微軟。並在隨後的第二年就宣佈成立了Foundation。參照以前開源技術的發展脈絡，我們可以看到，有基金會的運作，能夠讓這個技術發展更加成熟：有一個規範的方式，有一個合理的方向，以穩妥的方式發展。另外，有基金會的運作，大家把生態，包括技術生態和企業生態，做好，能夠讓這個專案做越做好，越做越大。因此，基於之前Linux和OpenStack的經驗，Kubernetes的後發優勢時間會相對縮短。對比一下，OpenStack在之前的時候實際上並沒有先發優勢，但是由於有Foundation的運作，組織這個技術的發展，繁榮技術生態和企業生態，這個事情是可以做成的。

剛才說到的三個不同的開源技術，它們的定位層次是不一樣的。Linux作業系統，毫無疑問是伺服器端開源作業系統的首選，它屬於對單個物理機器的管理。來到OpenStack，它實際上是資料中心的作業系統，它把所有物理機器管理起來，同時把所有網路、儲存也管理起來。。而Kubernetes，實際上是基於對服務的管理。

我們公司基於對於不同開源技術的理解，用開源技術來打造我們的產品。我們主要是結合了openstack和Kubernetes來打造一種能提供給企業不同場景的雲服務平臺。

這是之前的一個統計，一些形態的演講，包括一些數字，我們可以參考一下。企業的形態實際上是多種多樣的。對於一些傳統企業來說，他們的需求沒有像網際網路企業這麼快，為了在統一平臺下提供雲服務，需要考慮多種場景和形態，包括混合雲和多雲管理能力。

對於K8S和openstack的結合，我們可以分別從使用者和組織架構兩個角度來考慮。它們兩者的結合非常適配CI/CD 以及Devops的場景。OpenStack就是在底層默默地進行管理，方便使用者的使用，而K8S就是把上層的服務做好。

這裡列出了14個Foundation(基金會)，實際上情況應該是還要比這個更多。而這個社群，cncf社群的話主要有兩個，一個就是有比較強話語權的Kubernetes，還有就是其它。這主要是因為這個組織實際上是由Google發起的，它自然而然就在這個組織中擁有比較強的話語權。而其它就是圍繞它相關的周邊來進行的。其實這跟OpenStack一樣的。OpenStack最核心的是什麼？是建立的虛機。不管是儲存還是網路，實際上最終都是為了服務虛機的。

這裡面做一下kubercon的介紹。

1、谷歌主導和引領，投入了大量的力量在K8S社群，是專案走向的實際控制人。

2、微軟讓K8S更易用。

3、亞馬遜，深度融合AWS已有基礎設施服務。

這裡主要是兩點：社群保證K8S本身的穩定，以及相容性的保證。OpenStack為什麼能夠建立好比較好的企業生態？就是因為它有非常好的架構，能夠讓所有的企業都融入其中。在未來的資料中心裡面，每個公司都能有所貢獻，這個相當於眾人拾柴火焰高。而標準化的力量遠大於單個廠商和產品，K8S實際上就是以一個非常健康的方式發展。

最終是希望形成一種樂高式的平臺。如果有人熟悉AWS這個服務的話，它在中國的服務可能只有二三十個，但是在美國的話已經接近上千，包括它的服務和各種應用。使用者可以把各種各樣的服務組裝起來形成一個應用系統，讓你的東西跑上去，這就是這種樂高積木式的發展方式。

很多的發展規律是類似的，我們可以通過這個東西反過來看，這同時也是我們ECUE組織提供機會讓大家坐下來一起探討的初衷。任何一個領域，都會有人去探索。探索的過程，都會需要一段時間，大家不斷髮掘熱點，互補，成長，相互借鑑經驗，最後會突出來一家。很多的發展方式都是這樣的。

KubeCon上有幾個熱度比較高的，一個是Service Mesh，一個是Servless，還有一個是Hybrid Cloud。

Service Mesh就是說，服務還是服務，Service Mesh會把其它的都管好，比如流量的管控等。

Service Mesh從去年開始，去年6月份是0.3版本。1.0版本是比較高的，算是穩定版本。kubernetes應該是15年7月份釋出1.0版本，現在kubernetes來到了1.9版本，這個速度非常快。實際上每個開源軟體都會有這樣子的一個過程。

這裡是不同的企業提出來的一些不同的概念，都是對Service Mesh提出的一些要求和希望。

這裡解釋了對各個層次完成抽象之後，我們為什麼需要一個旁路的服務來做這個事情。

這相當於是Service Mesh的4大特性。首先，資源是我們使用的核心。雖然我們從服務層、資源層等各個層次觀察到的東西是不一樣的。但Service Mesh作為本身執行服務的載體來看，我關注的點就是圖中這麼多。比如剛才提到的虛擬機器，可能需要監控，需要日誌，甚至將來需要有工單。這些跟我們的虛擬機器實際上是完全沒有關係的，但是作為整體業務來看就有關係了。因為知道這些以後，會更方便我們運維，更方便我們去完善。

Kubecon熱點之hybrid cloud。hybrid它願意跟外面合作做所謂的混合雲，凡是給我帶來客戶的都是我的合作伙伴，後面會提到我們的方式是什麼樣子的。

這裡是混合雲實現的一些形態，一些特定的場景，比如訪問量激增，比如出海等。而中國的國情不太一樣，包括微信，包括資料安全，都有一些和國外不太相同的對於私有云的要求，這就需要一種混合雲的能力來讓我們來幫助去實現這些。在我們客戶裡面，由於O2O的興起，TCL在14年底就完成了這種雲的建設。再比如說在運營商領域，在不遠的將來會比較大規模地使用混合雲，將之前所有固化的硬體軟體化，最終實現成本降低。

谷歌實際上是希望藉助K8S來推廣它自己的混合雲，這是它的理念。

谷歌通過kubernetes實現混合雲應用管理。你管你的服務好了，服務可以直接搭出來。

並不是所有的服務都是由一個機器來做，肯定需要多機型的。在我們的雲上之後，可以方便的管理這些不同類別的叢集，附帶的話就需要認證等。

這是我們產品的簡單介紹，簡單說兩點：第一點就是我們在平臺上提供統一的操作方式和體驗，而承載這個平臺的，可以是裸機容器，也可以是虛機。做企業業務的都知道，企業業務是比較複雜的，最主要的就是各種各樣的合規性、各種各樣的部門和各種各樣的流程。對於網際網路企業來說，就是流量非常大，對效能要求比較高。還有其他型別的客戶，比如金融類，對安全方面的要求尤其苛刻，需要各種級別的保護等。我們這裡統一的管理介面、統一編排和統一應用中心，可以實現各種功能，方便實現各種服務。另外就是我們跟OpenStack和kubernetes本身有一個結合。實際上大家都在努力的探索，最終也會做出來一種，正確、可用、效能可以保證的，這種一級一級提高。這是一個不斷迭代演進的過程。

我們會提供一個Adapter，以一種外掛的方式，去和不同的Cloud對接。而它們必定存在不同的區域，比如有中國的、美國的。我們可以用不同的帳號去對接。我們會根據客戶的情況，提供特定的Adapter，填寫必要的對接資訊，就可以實現對混合雲的統一管控。

如果還有將服務層面打通的需求。我們會需要將連線打通，可以是vpn，可以是專線，這取決於你對服務質量的要求。然後是從K8S層面，會對底層進行標記，來區分出公有亦或是私有，包括計費，包括審計都會涉及得到。再上層就是對應的服務，即對應的使用過程。這是混合雲加上kubernetes的一種方式。

關於微服務，它本身有很多的設計原則。對應到我們的產品本身，實際上是以微服務的設計原則本身來實現相應的功能支援，並提供對於場景的一些支援。

這裡首先是容器技術本身帶來的好處。其實對於容器技術的好處，不同企業有不同的看法，網際網路企業在這方面做得比較靠前，規模上做的比較大，也有經驗的積累，這是不斷深耕的過程。但是我們公司主要是將其做成產品，因此我們首先是考慮它的共性，然後根據這些特性，比較全地進行覆蓋。
--------------------- 
作者：Go中國 
來源：CSDN 
原文：https://blog.csdn.net/RA681t58CJxsgCkJ31/article/details/79650113 
版權宣告：本文為博主原創文章，轉載請附上博文連結！