雲原生的進一步具象化

本文轉載自公衆號：HelloJava。

雲原生這個概念已經愈來愈深刻人心，但對「雲原生究竟是什麼？」這個問題，仍然是各類各樣的解讀，最近對雲原生具體是什麼有了點感觸，因而寫下來分享和探討下。

我如今認爲雲原生實際上是讓衆多的公司，經過基於雲的產品迅速得到在構建一個如今這個時代的應用（是否是有點像 AWS 一直講的 Modern Applications）所必需的各類基礎能力（如：極強的規模伸縮性、極高的可用性、極低的創新/運營成本、大數據的分析/運營能力等等），而不須要像之前的不少公司，爲了具有這些能力，投入巨大，或者用另一句話說：雲原生就是專業的基礎能力普惠化，隨手可得。

當今時代的應用和多年前的應用面臨的情況差異太大，這個差別和當今業務面臨的激烈競爭和玩法有很大的關係，我之前一直以爲像阿里在發展過程當中積累的不少能力，外面不多有公司會須要，就像當年百億、千億美金的公司是多麼難纔出現，但如今看來則徹底不同，因此這也奠基了當今時代的應用在技術層面能力的要求也遠不同，簡單說幾個點：

1. 對可用性的要求遠高於之前的應用：如今的應用一般一上線對可用性要求就已經不低了，由於一旦出問題就很容易把用戶送給競對；
2. 對伸縮性的能力要求也遠比之前高，主要體如今兩個方面：一是團隊規模，如今的業務公司很容易迅速發展到百人以上，而百人以上的研發效率如何保持儘可能不降低，這對系統的伸縮能力有着很高的要求；二是用戶規模，如今衆多業務的用戶規模能夠很快地突破百萬、千萬規模，這就要求系統必須能根據用戶規模快速地伸縮；
3. 創新和運營的成本必須低：業務競爭無比激烈，快是關鍵，因此怎麼在不須要太大投入的狀況下快速上線各類業務，是無比重要的；另外一個方面就是運營的成本，這個是和如今應用的用戶規模、激烈競爭密切相關的；
4. 大數據的玩法：如今的不少業務對獲客、推薦、搜索等的大數據化要求仍是至關高的。

阿里是一家在自身發展過程當中，逐步碰到上述的挑戰（當年的競爭環境基本還不會要求一個業務上來就把各類能力具有好），但之前也沒有云可用，因此在發展過程當中不斷積累各類能力，如今經過開源、雲商業化對外輸出這些能力，使得即便到了如今這樣的競爭環境下，各類有業務創新想法的同窗們，仍是能夠像當年同樣快速上線業務，而不是要先投入巨多力量、花費巨多時間把須要的基礎能力打磨出來。

我本身並無徹底經歷阿里的發展過程，接下來主要仍是簡單說下我本身經歷的一些。

1. 在 2007 年，淘寶在基礎能力上面臨的最大問題是伸縮性，兩個現象當時都出現了：用戶數量大量增長，加機器已經基本要加到瓶頸了；研發人員大量增加，研發效率下滑很是明顯。在這個階段，淘寶作了一輪很是重要的架構改造，磨練出了例如服務框架、消息中間件、分庫分表方案、分佈式文件系統、分佈式緩存等基礎技術產品，結合業務架構的從新設計，很好地解決掉了伸縮性的問題。
2. 在 2009 年，淘寶面臨了可用性問題，常常出各類故障，因而開始積累各類監控、快速恢復、tracing、系統設計裏如非關鍵路徑異步化等技能。可用性這塊的投入一直在持續，到後來爲解決 雙11 這種特殊狀況的可用性、肯定性訴求而創造的全鏈路壓測；經過同城雙活、異地多活的多機房體系構建的強容災能力以及快速恢復能力等；以及在線下場景加入後來面臨的不同的可用性方案等。各類場景的高可用方案的積累，也使得業務的可用性愈來愈有保障。
3. 2011 年左右，阿里開始以爲將來在資源投入上的運營成本可能會很誇張，因而在 2011 年開始經過容器化來提高機器使用效率、持續進行成本優化，後來又持續經過雲資源彈性來解決 雙11 這類型的短時高峯的成本投入問題，經過在線離線混部解決大數據機器投入愈來愈大、在線機器集羣利用率不高產生浪費的問題，通過多年努力，使得業務在高速增加的狀況下，機器資源投入上的運營成本仍是相對可控的。

如上文所講，阿里是依靠巨大的人力投入、場景打磨和多年的持續投入才逐漸造成了完備的能力。而如今的業務，則能夠用雲原生的方式構建，使自身一上來就具有這些能力，至少可以讓本身在現在激烈且要求更高的業務競爭環境中，不會在這些基礎能力上拖後腿，以此能夠花更多的精力、時間、資源在真正的業務創新上。這樣具象化的雲原生對整個社會的創新仍是至關有價值的。