文/董慶陽
軟件不像硬件，看得見，摸得着。硬件規格是數據化的，清清楚楚。軟件沒有這麼直觀，要把軟件講清楚不是件容易的事情。聽軟件大師們講軟件，抽象、建模、分層等等，也很難懂，卻又不敢質疑，但很多情況下就沒有這麼幸運了。所以，還是要設法把軟件通俗易懂地講出來。這裏針對大家關心的一些軟件問題做個嘗試，以我對軟件的一知半解，儘量以科普化的語言來探討。
這些年，軟件在發生什麼變化？
過去 10 年，硬件的計算能力提升了 100 倍。軟件發生了什麼變化？軟件開發語言從早期的 Basic、Fortran、C，到現在的Java、C#、Python、PHP，當前常用的開發語言不下百種。軟件新技術也層出不窮，XaaS、開源、容器、服務，等等。和硬件不斷提升處理能力相比，軟件的發展主線是什麼？
這 10 年來，軟件代碼量至少增加了 100 倍。軟件技術發展的主線，就是不斷提升軟件開發效率和開發者體驗，不斷降低軟件開發入門門檻，讓越來越多的人蔘與到軟件開發，不斷提升軟件生產力。軟件生產力的快速發展，也帶動軟件生產關係的不斷髮展，比如開源。和硬件發展的 Scale Up，軟件發展天生就是 Scale Out。要說構建生態圈這種能力，軟件絕對是一流的。互聯網軟件正是把握這個規律，不斷應用最新的軟件開發技術和開發模式，不斷降低軟件的生產成本。
我們當前的編程語言和編程方式，16 年來幾乎沒有變化。從開發能力上講，是沒有跟上軟件發展腳步的。
什麼是嵌入式軟件，嵌入式軟件發展的方向是什麼？
什麼是嵌入式軟件？早期對嵌入式軟件的理解，就是嵌入在硬件系統中，和硬件耦合很緊，隨設備一起銷售的軟件。十多年過去了，從概念定義看，無線軟件仍屬於嵌入式軟件範疇，但自從 Linux 從 PC/服務器端移植到嵌入式環境後，嵌入式軟件也在發生變化，和普通的 PC、服務器軟件開發環境相比，技術上沒有本質區別。從下面的對比可以更清晰地看出來：
嵌入式軟件和互聯網軟件真正的區別在商業交付模式和運營模式。既然在技術特徵上沒有太大區別，互聯網軟件上很多好的開發方式就可以用在嵌入式軟件。比如互聯網軟件開發的 SDK+IDE，大量代碼都可以自動生成，對效率的提升不是一點點。遺憾的是 SDK+IDE 在我們當前的軟件開發中用的很少。開發一套好的 SDK+IDE 很難，並且很多人對 SDK+IDE 自動生成代碼的成見是資源消耗大、性能差。這些認識都已過時，即使如此，以 1% 的性能損失換 10 倍的開發效率，幹不幹？
千萬不要自認爲是嵌入式軟件而停止前進的腳步。嵌入式軟件發展的方向也是要提升軟件開發效率和開發者體驗。
爲什麼要打破當前的 Monolithic 軟件模式？
人們常用澳大利亞 Ayers 巨石來形容單體 (Monolithic) 軟件。高 348 米，長 3000 米，周長 9.4 公里，對一塊石頭來說是壯觀的，但對軟件來說並非好事。Monolithic 軟件，每個單元上運行的軟件都是一個不可分割的整體。在這個整體中，要優化一個性能，要增刪一個特性，必須編譯整個版本、驗證所有的用例、交付升級整個版本。客戶說要增加一個窗戶，而我們總是每次給客戶整幢大樓。
我們當前的開發組織一般都是按模塊來劃分的，比如 OM 組、信令組、小區管理組、算法組等。組和特性是完全交織的關係。比如開發一個 HSPA 特性，需要平臺組、OM 組、傳輸組、信令組、小區管理組、算法組都要參與，都要修改。反過來看，每個組幾乎和所有的特性都有關係。這種網狀關係導致修改特性的影響、故障的擴散範圍根本不可知。每個開發者修改代碼花的時間並不多，大量的時間發生在等待和驗證。除了驗證自己開發或修改的特性之外，還要等待別人的缺陷修復，還要驗證自己的修改不影響其它特性。這就是當前程序員痛苦的根源。
有沒有可能控制修改特性中故障傳播的範圍？有，我們要打破 Monolithic 軟件模式。
CBB 組件應用了這麼多年，爲什麼現在提服務化，是噱頭，還是救命稻草？
爲什麼提從組件化到服務化？要回答這個問題，先要理解什麼是服務。學通信的，Service 這個詞最令人費解。服務 or 業務？幾乎在不同的場合，就有不同的含義。舉個例子就比較容易理解了，華爲公司使用外包人員有兩種方式：一種方式是把外包人員直接放到華爲公司，由華爲負責外包人員的工作安排、輸出監控、績效管理。這種方式看起來直接、效率高，但也有缺點，就是華爲公司要負責外包人員的管理、衣食住行甚至思想動態。哪天某個外包人員出點啥事，華爲公司也要負責。
另一種方式是外包人員交由外包公司來管理。華爲向外包公司提業務和質量需求，外包公司用多少人、怎麼做，華爲公司都不管，把事情搞定就行。這種方式前期可能麻煩些，但後續麻煩少，可替換性也很強。華爲公司想換一個外包公司也很容易，甚至可以並行找不同的外包公司做備胎。第一種方式就是組件化，第二種方式就是服務化。
組件化是初級的複用手段。把公共的功能做成二進制組件，供不同的產品調用。避免重複開發，提升開發效率。組件化發展到現在，缺點也很明顯。比如相同的 VPP 組件，無線幾乎所有產品都要用，每個產品都要對它進行適配、資源管理和操作維護管理，額外的開銷還是很大。並且產品很容易被 CBB 組件綁架，一旦用了某個平臺或組件，就很難換了。組件化的缺點就是服務化的優點。服務化改造後，自己的數據信息自己管理，對外提供易用的服務接口。使用方只管功能，不用關心內部實現，不用去適配、管理組件的運行環境、資源，並且替換比較容易，跨平臺遷移幾乎是零成本。這對於被厚重平臺綁架的產品來說，絕對是一個福音。
服務化天生的複用性好，耦合性低，自治性強。用好了是提升效率的一個手段。華爲當前外包模式希望切換到 FP，不謀而合啊。
容器和微服務是什麼鬼？
當前 Docker 容器比較火，以至於很多人認爲容器是 Docker 發明的。其實容器就是一個程序的運行環境。在 20 多年前就有了，一直不溫不火，最近容器又爆紅，有取代虛擬機之勢，主要是因爲 Docker 在容器內提供了一個開發環境和部署方案，讓開發者更容易利用容器來開發和部署自己的應用。應了上面那句話，降低門檻就是提升生產力啊。
“微服務”和“服務”一字之差，事實上是有較大差異的。在實現層面，組件化強調對複雜系統分而治之，降低整體複雜度，但沒有強調數據信息的自治和功能的易用性。而服務化在誕生初始，只強調通過易用的服務化接口打通企業內應用，異構軟件能共存，忽視了對服務內部實現方式的定義。微服務則綜合了組件化和服務化兩者的優點——應用按足夠小的服務粒度進行分解，獨立開發，啓動輕便，快速開發、快速測試。每個微服務根據自身特點分配計算與存儲資源，並且可獨立伸縮、新陳代謝。
微服務的故障隔離能力好，服務間不影響，每個服務可以在任何時候被修改或升級，不影響其它服務。開發者減少相互的等待和依賴，自主性更強，體驗更好。看起來不錯啊，是打破 Monolithic 的一個利器。技術上已經通過驗證，正在商用產品落地。行與不行，快見分曉了。
微服務是支持 DevOps 的革命性架構，使系統改變的成本很低，但微服務間的協調是一個十分複雜的工程，需要自動化工具配套。華爲無線工具部已經啓動相關工作，大家盡情期待哦！
（更多華爲資訊請關注華爲開發者社區，華爲自己的對外開放門戶:http://developer.huawei.com/ict/cn/ ,不要問我叫啥，別人都叫我雷鋒）
