當今軟件發展的現狀很是適合 Cloud Native 環境

時間 2019-11-06

原文原文鏈接

當今軟件行業正發生着鉅變。自上世紀50年代計算機誕生以來，軟件從最初的手工做坊式的交付方式，逐漸演變成爲了職業化開發、團隊化開發，進而定製了軟件件行業的相關規範，造成了軟件產業。html

今天，不管是大型企業仍是我的開發者，都或多或少採用了雲的方式來開發、部署應用。無論是私有云，仍是公有云，都終將給整個軟件產業帶來的革命。我的計算機或者以手機爲表明的智能設備已經走進尋常百姓家了。每一個人幾乎都擁有手機，手機不只僅是通訊工具，還能發語音、看視頻、玩遊戲，讓人與人之間的聯繫變得更加緊密。智能手環隨時監控你的身體情況，並根據你天天的運動量、身體指標來給你提供合理的飲食運動建議。出門逛街甚至不須要帶錢包了，吃飯購物搭車時使用手機就能夠支付費用，多麼方便快捷。智能家居系統更是你生活上的「管家」，何時該睡覺了，智能家居系統就自動拉上窗簾，關燈；早上起牀了，智能家居系統會自動拉開窗簾，並播放動人的音樂，讓你能夠愉快地享受新的一天的來臨；你不再用擔憂家裏的安全狀況，智能家居系統會幫你監控一切，有異常狀況時會及時發送通知到你的手機，讓你第一時間掌握家裏的情況。將來，每一個人都可以擁有《Iron Man》（鋼鐵俠）中所描述的智能管家 Jarvis。而這一切，都離不開背後那個神祕的巨人——分佈式系統。正是那些看不見的分佈式系統，天天處理着數以億計的計算，提供可靠而穩定的服務。這些系統每每是以 Cloud Native 方式來部署、運維的。git

軟件需求的發展

早期的軟件，大多數是由使用該軟件的我的或機構研製的，因此軟件每每帶有很是強烈的我的色彩。早期的軟件開發也沒有什麼系統的方法論能夠遵循，徹底是「我的英雄主義」，也不存在所謂的軟件設計，純粹就是某我的的頭腦中思想的表達。並且，當時的軟件每每是圍繞硬件的需求來定製化開發的，有什麼樣的硬件就有什麼樣的軟件。因此，軟件缺少通用性。同時，因爲軟件開發過程不須要與他人協做，因此，軟件除了源代碼外，每每沒有軟件設計、使用說明書等文檔。這樣，就形成了軟件行業缺少經驗的傳承。github

從60年代中期到70年代中期是計算機系統發展的第二個時期，在這一時期軟件開始被看成一種產品被普遍使用。所謂產品，就是能夠提供給不一樣的人使用，從而提升了軟件的重用率，下降了軟件開發的成本。好比，之前，一套軟件，只能專門提供給某我的使用。如今，同一套軟件能夠批量的賣給不一樣的人，顯然，分攤到相同軟件上的開發成本而言，賣的越多，成本天然就越低。這個時期，出現了相似「軟件做坊」的專職替別人的開發軟件的團體。雖然是團體協做，但軟件開發的方法基本上仍然沿用早期的個體化軟件開發方式，這樣致使的問題是，軟件的數量急劇膨脹，軟件需求日趨複雜，軟件的維護難度也就愈來愈大，開發成本變得愈來愈高了，從而致使軟件項目頻頻遭遇失敗。這就演變成了「軟件危機」。spring

「軟件危機」迫令人們開始思考軟件的開發方式，使得人們開始對軟件及其特性進行了更加深刻的研究，人們對待軟件的觀念也在發生悄然的改變。在早期，因爲計算機的數量不多，只有少數軍方或者科研機構纔有機會接觸到計算機，這就讓大多數人認爲，軟件開發人員都是稀少且優秀的（一開始確實也是如此，畢竟計算機最初製做者都是數學界的天才）。因爲，軟件開發的技能，只能被少數人所掌握，因此大多數人對於「什麼是好的軟件」缺少共識。實際上，早期那些被認爲是優秀的程序經常很難被別人看懂，裏面充斥着各類程序技巧。加之，當時的硬件資源比較緊缺，迫使開發人員在編程時，每每須要考慮更少的佔用機子資源，從而會採用不易閱讀的「精簡」方式來開發，這更加加劇了軟件的個性化。而如今人們廣泛認爲，優秀的程序除了功能正確，性能優良以外，還應該更加讓人容易看懂、容易使用、容易修改和擴充。這就是軟件可維護性的要求。編程

1968年 NATO 會議上首次提出「軟件危機」(Software Crisis)這個名詞，同時，提出了指望經過「軟件工程（Sotfwrae Engineeirng）」來解決「軟件危機」。「軟件工程」的目的，就是要把軟件開發從「藝術」和「個體行爲」向「工程」和「羣體協同工做」進行轉化，從而解決「軟件危機」包含兩方面問題：安全

如何開發軟件，以知足不斷增加，日趨複雜的需求；
如何維護數量不斷膨脹的軟件產品。

事實證實，在軟件的可行性分析方面，事先對軟件的進行可行性分析，能夠有效的規避軟件失敗的風險，提升軟件的開發的成功率。架構

在需求方面，軟件行業的規範是，須要制定相應的軟件規格說明書、軟件需求說明書，從而讓開發工做有了依據，劃清了開發邊界，並在必定程度上減小了「需求蔓延」的狀況的發生。app

在架構設計方面，需制定軟件架構說明書，劃分了系統之間的界限，約定了系統間的通訊接口，並將系統分爲多個模塊。這樣，更容易將任務分解，從而下降系統的複雜性。運維

今天，制定軟件需求的方式愈來愈多樣化了。客戶與系統分析師也許只是通過簡單的口頭討論，制定了粗略的協議，就安排開發工程師進行原型設計了。開發工程師開發一個微服務，並部署到雲容器中，從而能夠實現軟件的交付。甚至，能夠不用編寫任何寫後臺代碼，直接使用雲服務供應商所提供的 API，使應用快速推向市場。客戶在使用完這個應用時，立刻就能將本身體驗反饋到開發團隊，使開發團隊可以快速的響應客戶的需求變化，並促使軟件進行升級。分佈式

經過敏捷的方式，最終軟件造成了「開發——測試——部署——反饋」的良性循環，軟件產品也獲得了進化。而這整個過程，都比傳統的需求獲取的方式將更加的迅捷。

開發方式的鉅變

早些年，瀑布模型仍是標準的軟件開發模型。瀑布模型將軟件生命週期劃分爲制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，而且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。在瀑布模型中，軟件開發的各項活動嚴格按照線性方式進行，當前活動接受上一項活動的工做結果，實施完成所需的工做內容。當前活動的工做結果須要進行驗證，如驗證經過，則該結果做爲下一項活動的輸入，繼續進行下一項活動，不然返回修改。

瀑布模型優勢是嚴格遵循預先計劃的步驟順序進行，一切循序漸進，整個過程比較嚴謹。同時，瀑布模型強調文檔的做用，並要求每一個階段都要仔細驗證文檔的內容。可是，這種模型的線性過程太理想化，主要存在如下幾個方面的問題在：

各個階段的劃分徹底固定，階段之間產生大量的文檔，極大地增長了工做量；
因爲開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增長了開發的風險；
早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果；
各個軟件生命週期銜接花費時間較長，團隊人員交流成本大。

瀑布式方法在需求不明而且在項目進行過程當中可能變化的狀況下基本是不可行的，因此瀑布式方法很是適合需求明確的軟件開發。但在現在，時間就是金錢，如何快速搶佔市場，是每一個互聯網企業須要考慮的第一要素。因此，快速迭代、頻繁發佈的原型開發、敏捷開發方式，被愈來愈多的互聯網企業所採用。甚至，不少傳統企業，也在逐步向敏捷的「短平快」的開發方式靠攏。畢竟，誰願意等待呢？

客戶將需求告訴了你，固然是越快但願獲得反饋越好，那麼，最快的方式莫過於在原有系統的基礎上，搭建一個原型提供給客戶做爲參考。客戶拿到原型以後，確定會反饋他的意見，是好或者壞的方面都會有。這樣，開發人員就能根據客戶的反饋，來對原型進行快速更改，快速發佈新的版本，從而實現了良好的反饋閉環。

今天，Cloud Native 的開發方式正在流行。Cloud Native 是以雲架構爲優先的應用開發模式。Cloud Native 利於最大化整合現有的雲計算所提供的資源，同時也最大化節約了項目啓動的成本。

雲是大勢所趨

目前，愈來愈多的企業已經在大規模開始擁抱雲，在雲環境開發應用、部署應用、發佈應用。將來，愈來愈多的開發者也將採用 Cloud Native 來開發應用。

那麼，爲何咱們須要使用 Cloud Native？

雲計算的第一個浪潮是關於成本節約和業務敏捷性，尤爲是雲計算的基礎設施更加廉價。隨着雲計算的不斷髮展，企業開始採用基礎架構即服務（IaaS）和平臺即服務（PaaS）服務，並利用它們構建利用雲的彈性和可伸縮性的應用程序，同時也可以知足雲環境下的容錯性。
不少企業傾向於使用微服務架構來開發應用。微服務開發快速，職責單一，可以更快速的被客戶所採納。同時，這些應用可以經過快速迭代的方式，獲得進化，贏得客戶的承認。Cloud Native 能夠打通微服務開發、測試、部署、發佈的整個流程環節。
雲供應商爲迎合市場，提供了知足各類場景方案的 API，例如用於定位的 Google Maps，用於社交協做的認證平臺等。將全部這些 API 與企業業務的特性和功能混合在一塊兒，可讓他們爲客戶構建獨特的方案。全部這些整合都在 API 層面進行。這意味着，無論是移動應用仍是傳統的桌面應用都能無縫集成。因此，採用 Cloud Native 所開發的應用都且具有極強的可擴展性。
軟件不可能不出故障。傳統的企業級開發方式，須要有專職人員來對企業應用進行監控與維護。而在 Cloud Native 架構下，底層的服務或者是 API 都由將部署到雲中，等價於將繁重的運維工做轉移給了雲平臺供應商。這意味着客戶應用將獲得更加專業的看護，同時，也節省了運維成本。

那麼如何來實現 Cloud Native 呢？其實這是一個很是大的話題，好比，做爲開發者，你須要瞭解目前市面上流行的雲供應商，瞭解微服務、SOA，瞭解 HTTP 和 REST，瞭解領域驅動設計（DDD），瞭解CI\CD和TDD，瞭解兩個披薩，瞭解分佈式的經常使用架構和模式等等。這裏每同樣都是一個龐大的課題，還好目前市面上已經有了一些資料可供學習，好比《Cloud Native 分佈式架構原理與實踐》，能夠很是全面的指導開發者輕鬆入門 Cloud Native。