這不是小編第一次參加UCloud 使用者大會了，但還是被每次絕對首發出場的老季驚了一把，咋回事兒捏？

作為科技圈小編真真頭一次遇到如此調侃自己公司的老大，“很多人覺得我們的公司名稱UCloud，實在是不好記，聽起來就像刻光碟的……”老季在臺上憨厚地笑著，場下的聽眾們也被這突如其來的一句話逗樂了。

儘管這不過是句玩笑，但從“UCloud”名稱本意來看，當然這也是老季本次爆料給大家的，關於公司名稱的“官方正解”哈：“UCloud”本意是指優秀的雲服務，立刻就可以得到；但經過多年的努力與奮鬥，也是趨於成熟的企業文化的體現，或許“優秀，是刻苦努力得到的！”這種詮釋在如今看來更合適一些。

當然名稱的解讀只是一方面，那個在上海的寒冷中脫胎而出、至今一路高歌猛進的UCloud，做到的可不僅僅是這些，而是一直以來始終堅持“能夠幫助使用者的技術才是真正的好技術、技術只有為使用者創造價值，才能體現自身價值”這樣的信條；並在“憑藉雲端計算技術服務使用者”的漫長實踐中，體驗“客戶的需求是下一個產品”，通過深入瞭解使用者痛點，用技術研發產品來滿足需求，這都是老季與其背後的團隊每天都做的大事兒！

“精神理念的堅守+技術產品的研發實踐”，造就了UCloud從2012年至今，始終奔跑在根據使用者需求不斷創新的道路上，而每一次的使用者大會就是這些“新”的集中呈現與總結。

會上“刻”出的第一張盤：UCloudStack

現場，UCloud技術副總裁楊鐳一上場就開始了“一路到底”抖包袱的節奏，最初他果斷瞄準了從2015年開始逐漸走“下坡路”的OpenStack。他總結道“過去OpenStack這個開源專案無疑取得了巨大成功，但這幾年卻一路向下，但如果仔細觀察另一個一年火過一年的關鍵詞’私有云’，就會發現其中熱度不減反增的趨向，只能說明OpenStack這個解決方案的熱度降低了而已。” 

通過OpenStack以及私有云的充分鋪墊後，透析技術發展的趨向，作為一家從公有云入局的行業公司，楊鐳表示，UCloud一直在思考怎樣能夠將技術與產品帶到更多領域，目前的解決方案是什麼？就是最新研發的、輕量級且可以私有化的雲端計算軟體系統UCloudStack。更進一步瞭解，這款新寵實際上作為UCloud的技術和產品的集合，如今推出的為企業場景定製的解決方案中的第一款產品，也是一個輕量的平臺解決方案。

你可能會產生疑問，本身已經基於公有云運營了六年時間，為啥要轉頭做起了重構定製呢？關於這個問題，UCloudStack產品研發的負責人文天樂是如此回答的：“實際上此次重構定製主要集中在兩個層面，分別是部署規模以及快速交付。“公有云通常具有成千上萬的資料的資料中心，但企業卻達不到這個層級，我們不可能將公有云的直接架構完全照搬至使用者的資料中心，大量的裁剪、複用以及優化工作比較繁重。”

恰好出爐的這款產品剛剛可以解決如此問題，如果追根究底其合適的使用者場景，主要集中在短期內或者由於資料安全影響，無法使用公有云的客戶；需要將行業雲、園區雲、政務雲完全獨立部署在成熟領域並具備完全可運維的工具的使用者；以及短期不能上公有云，但是有虛擬化和雲化需求的企業等。

面對這些“特殊”企業的訴求，UCloud會從虛擬化核心、虛擬化網路、計量計費、多租戶、雲管理平臺、分散式儲存等六大核心能力出發，實現完整的產品線上大多數功能，並可以放心構建在不同的X86伺服器和普通的交換機上。

談及UCloudStack產品的方案特性，相關技術人員著重強調了兩點，分別是實現從小規模到大規模的平滑過渡與升級，以及成本的最佳優化。

在企業發展中，業務發展初期可以用6-10臺解決雲平臺部署問題；但當業務發展到一定規模的時候，就需要擴充套件到800臺以上的這種能力，所以實現從小規模到大規模的平滑過渡和升級，這事兒很關鍵。

此外就是對成本優化的不懈追求了。如果將公有云上的混合雲方案完全移植到UCloudStack私有化部署的平臺上，那些利用使用者存量無法虛擬化的特殊裝置，就可以妥妥比較方便地整合在雲中做到共同使用與管理。更重要的一點，該軟體平臺不繫結任何一個廠商特性，簡單來說如果不追求效能和可靠性的情況下，用兩臺PC也是可以部署這個平臺的。

突出強調的是，如果使用者需要把這套系統整合在原有的使用者管理系統中，通過API就能完成更加方便的整合工作；此外，業務實現分離和組建化以後，如果有定製需求，還可以支援快速定製的迭代，這個實現過程中無論是純軟體交付，還是軟硬一體交付均可實現。

文天樂補充道，“其實我們專業服務中就包含為使用者設計資料中心架構這一項，目前標準中為使用者推薦了三種資料中心架構設計模式，而第一種是從價效比和可擴充套件性出發都是最好的。主要是建議使用者計算、儲存等融合在一起，利用交換機的迭代提供整個物理基礎設施環境的可靠性。 ”倘若使用者對儲存效能有更高的可用性要求，還可以單獨做成儲存網路與儲存裝置進行優化。

有沒有見過凌晨四點鐘的上海呢？SDN網路表示，我誕生於此！

“有沒有見過凌晨四點鐘的上海呢？”楊鐳發問現場。

這不是一個頗有毒雞湯意味兒的梗，因為此般真實存在的辛勞，網路產品研發部門的邱模烔就深深品嚐過，那還是在研發SDN網路的過程中。

“我們今天所講的重點是技術本質，或者也可以被認為是SDN網路的精華，但其實可以歸結為兩點，自主可控、進化能力。”開場言簡意賅。

因為動手實踐過，雖說講的是SDN網路的技術本質，但邱模烔一上臺打出的比方卻是形象生動，最合適的莫過於“造車”。

在他看來，SDN網路就像造車一樣，假如搞不定哪些汽車的關鍵零部件，什麼發動機、變速箱還有懸掛器等，車做不到很舒適，而且也是跑不快的。但造車人深深知道，那些核心的器件無法直接購買到，怎麼辦？必須靜下心來自己做，而且沒有任何先前的參考。

例如針對物理雲網關的實踐，他表示，過去UCloud有物理雲主機，主要可以用來解決特定場景下使用者的業務問題。為了讓這臺普通的伺服器具備SDN的能力，研發人員採用了硬體SDN 交換機，即將伺服器連線在硬體交換機上已達成效。

“但隨著時間，我們發現硬體的SDN交換機限制較大，油表數較少，直接限制物理雲的規模。為了解決這類困難，同樣基於X86伺服器，我們自己又研發了一個物理雲網關的轉化叢集，可做到線性擴充套件。換句話說，如果之前是100臺用8臺網關叢集，如今200臺就可以用16臺進行擴充套件，更重要是可以升級。”邱模烔詳細表示。

從這個例子可以看出，後來UCloud決定自己開發軟體SDN來代替硬體SDN，也完全是基於解決進化能力的問題，無論需要兩年還是29個月。

在對軟體SDN成功研發表示自豪之餘，邱模烔表示仍有兩個問題還未解決，分別是不支援可驅動以及地址空間的受限。

為了有效解決這兩個問題，UCloud有分別推出了SDN的第四版本以及第五版本，也就是1.5和2.0。其中2.0版本在功能特性上，都表現出了相對領先的水平，還具有自己的顯著特徵，例如跨子網可用區、跨VIP漂移等，使用者可以從這版SDN中構建自己的虛擬資料中心、規劃子網、定義路由等。

對於網路這種非常核心的系統，自主可控與進化能力幾乎決定了一切，這一點不是僅僅研製出一兩個新功能、新特性就搞定的，需要長期打磨，這也是以邱模烔為代表的SDN技術研發團隊一致認為的事兒。

現場UCloud還推出了基於可程式設計白盒交換機的UXR網路架構平臺。該平臺利用基於P4開發的核心交換路由器，達成了公有云網路平臺與物理雲網絡、UCloud全球骨幹承載網路、混合雲網絡等異構網路架構的完美解耦，並提供了精確到IP粒度的網路灰度釋出能力；UCloud並表示未來也將在智慧網絡卡研發上發力，讓我們一起期待。

從沒經歷過的資料中心遷移，必須也要試一試！

在你的職業生涯中，是否經歷過資料中心被迫關閉的尷尬？UCloud應用雲產品中心總監吳斌煒向大家分享了他的經歷。

“事情發生在我們在韓國設定的資料中心，由於各種外因被迫需要關閉……當時我們聽到'換地方'這個需求的時候，確實內心是非常崩潰的。但資料中心絕不能關閉，必須馬上制定出有效的應對方案。

而資料中心的遷移是UCloud之前從未做過的。經過技術團隊分析，目前機房存在兩類產品，一類是商品承載使用者的產品，主要涉及主機網路產品並存在於使用者的業務中；另一類則是控制產品的管理模組，而這些模組控制了產品的建立、刪除以及擴容操作。

團隊成員們權衡利弊之後，決定將原來分屬在兩個機房的產品合成部署在一個機房中進行遷移工作，具體的遷移工作就涉及到控制系統遷移以及產品遷移兩部分。

針對控制系統的遷移，吳斌煒說：“在開始遷移工作的時候，最先著手的就是控制系統遷移，主要是相對簡單，一旦出現錯誤也比較容易恢復。在這種架構下，控制系統就相當於主編的模式，只需要做到系統下線，自動就可以完成切換，當然經過實踐來看，這個做法針對無狀態模組相對容易，但對於位於下端的公共資料庫來說就稍微麻煩一些了。”

可以想見的一點，資料庫的切換工作順利實施，最重要的是保證兩邊資料的一致性。據瞭解，當時完成資料切換的時候，技術人員選擇將控制檯功能暫時關閉，主要為了防止資料庫內有新的資料接入，但由於這個關閉的舉措，大概在15分鐘左右，使用者無法進入控制檯是比較重要的影響。

總體來說，在控制系統層面的遷移之後，資料層面的遷移有相對簡單了許多，憑藉比較成熟的遷移工具，例如主機遷移可做到對使用者影響在1秒之內。

有人說機房建設就是粗放型，用錢“砸”就好了！話說建設機房的確很費錢，這事兒不假，但建成之後出現的使用者痛點可不是用錢就能夠解決的了……

經過多年的海外機房建設，UCloud解鎖了名叫“硬體隔離組”的新功能，足見能夠成功完成上文描述的“遷移任務”，並不奇怪。

為什麼會做這個產品呢？楊鐳坦言，UCloud成功出海之後，大多數面臨的質疑就是“如果你宕機了該怎麼辦”的問題，這源於人們會十分傾向性認為在國內的宕機會得到第一時間的快速恢復，但國外就“不敢保證”的疑惑。

還是宕機這個問題，不幸出現宕機之後又將如何通過產品以及技術手段保證業務影響的最小化呢？

UCloud經過多年運營的積累發現由記憶體引發的宕機機率還是很高，約佔三分之一，甚至連伺服器宕機都極有可能是記憶體的問題。

“所以現在UCloud正在做的事情就是通過核心隔離錯誤的位元位，主要分幾種情況，第一個可糾正就是記錄一下，發一個報警簡訊就可以了；第二個不可糾正，可恢復，我就把這個故障在核心中設定為可以忽略的錯誤。”還有一種方式，就是隔離之後透傳給虛擬機器，讓裡面的核心可以“感受”到如今外面的記憶體出現了故障，這樣就可以達成在虛擬機器內部第二次隔離的效果，完成此項工作，預計由記憶體引發的宕機可以減少90%。

楊鐳坦言這項創新技術還存在很多挑戰。首先需要對核心進行比較深入的修改與維護，同時還要保證在所有伺服器上透明更新。作為一個雲服務來講，已經不像十年前那樣提供軟體，所謂服務就是使用者不要關心具體過程，而是充分感受到所帶來的進化與好處，這就是服務與軟體非常不同的地方。

雖然這項創新看上去簡單，但十分安全，一定程度上也展示了未來UCloud對以SGX為代表的技術的投入，不可否認的是，如今的加密技術確實很火爆。

TA，基於硬體，能夠做到將關鍵階段的運算放入CPU內建晶片中，而不是傳統記憶體裡，即使核心與虛擬化軟體出漏洞時，也可以高效保證安全。但值得明確的一點，資料安全這件事兒，技術保障固然重要，但相對的意識層面也應該跟上才是。

六年前，UCloud僅僅是一個只有十幾個人組成的創業團隊，未來的一切還有太多未知……

六年裡，在雲市場的摸爬滾打中，它頻頻謝絕巨頭們遞過來的橄欖枝，堅持純內資；自帶“中立”基因，熱衷自主研發到如今……

六年後，在巨頭們“揮金如土”的歲月裡，在他們“所到之處、寸草不生”的情勢下，它依舊可以手握“中立”大旗，一騎絕塵，成長為如今服務使用者超過8萬的雲服務商，不得不說是一件神奇確又令人佩服的事兒。

最後想用那句經典的話結尾，“客戶的需求是下一個產品”，毋容置疑，UCloud的未來還會有更多驚喜呈現！