倍可親

看似倒退的過程 - 技術的進步不是簡單的重複

作者:釣魚城  於 2021-6-30 05:16 發表於 最熱鬧的華人社交網路--貝殼村

通用分類:流水日記

早年流行的計算機軟體語言是C語言。這是一種流程化的語言(Procedural Programming Language, 或PPL, 請原諒我不能找到更恰當的詞來翻譯)。這種語言的設計理念強調每一個流程要由多個步驟逐一完成。如果說抽象(Abstraction)是科學研究一切實際問題的初始的一步,那麼C語言還是處於抽象過程中最低級的階段,是最接近於原生系統的計算機語言。因此人稱沒有C不能應用的領域,不能解決的問題。它的基本建造單元就是那一個個位元組(byte)和原始變數(primitive type)。C語言不屬於Object Oriented Programming(OOP)。所謂OOP, 把具有特定功能的代碼模塊化(Object oriented)。然後在建立一個程序或者程序庫的時候,只要把這些模塊(Objects)拿來合理地拼裝搭配在一起,就能很快做成一個完整的程序。這種OOP有利於模塊功能的標準化,通用化,並且便於重複使用和替代,也適合大規模生產,拼裝和測試, 以及運行的管理和維護。這顯著地縮短了軟體的生產周期。是走向大型複雜的軟體集約化生產最重要的一步。

                                     

                               

                                              Procedural   vs    Object Oriented


其實這種演化過程在近代的工業化進程中,早就不是第一次出現。舉個例子。以前人們建房屋,要自己準備泥沙,石子,和石灰。然後自己拌三合土,一小鏟一小鏟從桶里舀出來,附在用作2X4的竹篾材料上,來建房屋的牆(這是四川和重慶地區農村的建牆方法,北方或者其它地區可能不同)。這就是為什麼,以前的房屋建不高 - 主要是承重力不夠。這種修建過程也非常緩慢,因為要等前面的灰土干硬后才能繼續上灰。這裡基本的建築材料單位是石子和沙子。可以想象,用沙子一點一點來砌一堵牆,一棟樓,會是多麼漫長的一個過程。在計算機軟體的發展中,用C語言寫源代碼就是這樣的一個建牆過程,它用它自己的「沙」和「石子」來一片片的搭起一個程序。
後來人們發現,可以用粘土做成坯,再燒製成一塊塊的磚。這意味著基本建材單位模快化大型化了(對比一下磚頭和沙泥)。這產生了建築業的一次分工。可以在專門的工區生產磚這樣「大型」的建築材料,預先大批地製造出來,然後運到建築工地,再把它們一塊一塊砌起來就行了。這樣做,跟用三合土抹稀泥上牆相比,快速,簡單,專門;工作起來,省時省工省力。這掀起了一次建築工業和建築設計的革命。與此相似,計算機語言構架的模塊化(OOP), 同樣經歷了這樣一個過程。C++和Java等等就是這樣使用「磚塊」(Object),而不是僅僅使用「泥沙」(byte,primitive type)來建程序的例子。那就是為什麼,這些OOP構架變成了現代軟體發展的趨勢並經久不衰。

                                                    

                                                 Object Oriented Programming 
另一個例子是五十年代末集成電路的發明和應用。上世紀六七十年代的中小學生可能有這樣的經歷。那時,要想自己裝一個無線電(就是有一個或者兩個三極體的收音機),你要把一個一個分立的二極體,三極體,電阻,電容焊接起來。你自己要去鑽布線的孔,然後插基腳,連銅絲線,沾松香,焊錫,然後焊接。這樣做的結果,虛焊的點多,容易脫落,成功的機率小,質量不可靠。用這樣的工具和方法要想焊接出大型電路的可能性很小。那時根本沒有錢去買集成電路塊,也買不到 - 集成電路是軍用國防物資。後來半導體廠生產出印刷電路基板,預留了各個元件的位置。這樣雖然有一些好處,但仍舊不能把電路小型化。看著元件密密麻麻布滿了一版,其實所具有的功能還是太少。隨著電路越來越複雜,靠簡單重複地增大體積(volume),不可能是未來的發展方向。
一九五八年,德州儀器的工程師傑克。基爾比為了解決晶體管的成本居高不下(一個晶體管當時作價十美元),複雜電路需要的元件越來越多,電路總體積越來越大的問題,他利用其他同事休假,實驗室無人打擾的兩周時間,透徹地分析了問題的所在,提出了在一塊硅晶片上建造一個完整電路的設想, 由此可以把電路模塊化,並把體積做到極小。這就是集成電路的雛形。這是現代電子工業的一個飛躍,其意義非同尋常。
再回到建築材料的模塊化趨勢上來。儘管磚頭比直接用泥沙建房已經好了很多,人們覺得還可以繼續在模塊大型化這個方向上走下去。近幾十年,人們做出了更大更重的水泥預製件,可以達到幾十噸上百噸,然後把它們運到建築工地,橋樑工地,拼裝起來,這樣幾天就可以建一層樓,或者完成一個橋樑的跨栱。要是用水泥和著石子一鏟一鏟來慢慢修建,如果說不是不可能(橋栱可能真是不可能這樣建),那起碼也要化幾十倍上百倍的時間來做同等的工程量。

            

                                        使用預製件的橋樑拼裝

隨著時間的發展,這個使模塊大型化的過程在前幾年達到了極端。三D列印,甚至可以用印表機(printer)按設計藍圖把整棟房子列印出來,然後拉到工地上安裝好就行了。這樣可以隨時隨地大批量生產, 也方便更改設計。可以預見,未來模塊的大型化,會持續發展。這就是進入了所謂的整體化(Monolith)階段。以下是2019年一則新聞提到的第一所3D列印的商品房,要價30 萬美元。

       這棟3D列印的House,一共有1407平方英尺(130平方米)生活空間。
對比之下,近三十年計算機軟體的發展,也大致經歷了類似的發展過程。從九十年代IT大躍進開始,程序功能模塊化得到了強調和應用。人們發現用這些一塊一塊的「磚頭」(Objects)搭建一個大型的應用程序越來越方便,越來越快捷。一個以前看起來複雜無比的東西,現在三下兩下就拼裝好了。人們嘗到了模塊化(OOP) 的甜頭,因此傾向於建造更大更強的模塊,讓其具備所有需要的功能。就像可以把所有雞蛋裝在一個籃子里一樣,你可以把所有的子程序裝進一個大的軟體包里,把它捆緊紮好,這樣上火車,下飛機,到哪裡都只提一個包,很方便是不?這也就進入了整體化程序(monolithic programming)階段。一個整體化(monolithic) 程序,就是產生單一大型的功能整體。它包括資料存儲,數據分析,輸入輸出,以及所有的操作。
So far so good,形勢似乎一片大好。軟體構架的發展似乎走在正確的方向上。可是問題開始慢慢產生了。那就是,如果一個程序變得龐大無比,無所不包,其內部各部分之間必然存在著強烈的相互依賴和關聯。它的每一部分代碼都需要運行良好,否則整個程序就會停止運作。這產生了一個要麼大家一起工作,要麼一個不工作,全部不工作的結局!要是其中的一部分代碼不能正常運行,那就會造成整個程序宕機的後果!這怎麼得了!這不就是那種綁架式的愛情的翻版:說愛不愛我?愛,就一切相安無事,風平浪靜;不愛?那行,我們誰都別活了,一起跳崖!這種一榮俱榮,一損俱損的工作方式不反映現代英特網的特點,更不符合現代電商24小時不停機的要求!
從這裡出發,接下來,軟體構架的演化發生了跟傳統建築業發展方向上的分野 - 計算機程序設計的變革在於,模塊不僅僅要大型化,模塊更需要強調智能化。
確實如此。進入二十一世紀,軟體的構架設計出現了一個新的傾向。那就是放棄大型,單一的整體性(monolithic application)程序構架,而重新把大型程序小型化,把大而單一的程序分成一個個更小且相對獨立的程序個體(loose coupled)。這就是著名的微型服務塊(Micro-services) 構架。初看起來,這跟模塊(OOP)大型化的趨勢剛好相反。難道, 這是在簡單地走回頭路嗎?
這個問題也曾讓我困惑不解,不能判斷這是不是正確的發展方向。在仔細觀察分析之後,我慢慢認識到這種帶有「返祖」, 「回歸」特徵的微型化服務結構(micro-service)的優劣之處。原來此微型模塊和原來的小顆粒(泥沙,甚至磚石)是不一樣的!而且大相徑庭。看官,且聽我細細道來。
以前的一塊磚就是一塊磚,一堆泥沙燒制而成,其內部也沒有什麼特別的, 沒有任何功能設計(空心磚除外)。在這種情況下,當然是把這磚做得越大越好,做成超大型預製件最好。現在,對於一個所謂的微型服務程序塊(micro-service), 我們也可把它看著是一塊塊有不同功能的「磚塊」。但這磚塊有它自己完善的內部結構,一種功能化的內部結構。每一個micro-service程序塊,有它獨立的信息(data) 存儲,輸入輸出,數據處理,可以完全不依賴於其它的micro-service程序塊而獨立存在。但是,這些micro-service「磚」塊又能夠互相連接,溝通,可以協同起來做同一件事,就好像是一個大型的整體預製件一樣; 也可以分開來做不同的事。從某種意義上講,micro-service是一個模塊的智能化構架,就像磚被掏空了,被間諜在裡面裝了一台發報機。
也可以說,它的發端來自於現代仿生學。舉個例子,micro-service程序構架就像蜜蜂的複眼超級結構,蜜蜂原來的一個大眼睛,進化成了現在的成百上千(大約5000)的小複眼構成。一個小複眼都有一套集光系統和感光系統,複眼愈大,小複眼數愈多,視覺就愈發達。原來的一個大眼睛壞了,那個大眼睛就整個都壞了,兩個大眼睛壞了,那不就失明了?現在好了,一個小複眼壞了,其它的還好好的,讀書看報一點問題沒有,看球賽,玩遊戲,一點不輸給別人。甚至一個小複眼近視了,要配眼鏡,也只配一個沙粒那麼大的鏡片就夠了。說到底,就是小複眼壞一個修一個,不浪費材料。當然複眼系統大多數時候,合起來可以作為一個大眼睛用。不用說,用來恨人的時候,5000隻小複眼的聚光穿透力不比原來的一支大眼睛弱。哈哈。

                    

         蜜蜂的複眼。它的每一個複眼就像一個micro-service程序塊。壞了一個照常讀書看報。
能夠理解我在這兒的胡言亂語嗎?想象一下,如果我們所住房子的牆,不是一塊塊簡單的泥巴做成的磚,而是裡面有功能的智能磚,它們可以自動調節溫度,控制太陽光線的明暗,呼入室外的新鮮空氣,排除室內的廢氣,等等。它的好處是,不像地下室燒的那個大鍋爐,鍋爐如果壞了,冬天家裡可以把人凍成狗;也不像室外的空調機不工作了,夏天可以熱到讓人懷疑人生。如果一塊智能磚不好用了,也僅僅是這一塊磚不工作了,其它的仍舊好好地在幹活,因為它們是相互獨立的,或者說弱關聯的。你坐在房子里,幾乎感覺不到有什麼東西不工作了。這就是現代的通訊,電商,或者寬頻物聯網所要想達到的狀態。好處多不多?多!
看懂了micro-service程序構架是怎麼工作的,了解了為什麼要這麼設計,那麼回過頭來看看新近的產品里,有哪些是用了相近的設計理念的呢?別的不說,一個知名的產品就是特斯拉(Tesla)全電車的電池。這是一個由六百多個細胞電池(cell battery)整合成的一個電池聯合體,給車提供足夠的動力。人們會想,為啥不造一個單一的大電池呢?這當然考慮到了一個容錯(fault-tolerance)的問題,那就是如果只有一個大電池,那麼一旦它壞了,整個車就趴窩了。相反,如果使用細胞電池組成的電池陣列,那麼即使一半的細胞電池不工作了,車仍舊能開,你依舊能夠慢慢開回家跟家人一起吃晚餐。這是多麼好的一件事情。
認識到這樣一個既要保持功能分別,鬆散獨立, 又要聚小成大,集合成陣的矛盾綜合體的妙處,有些做伺服器(server)的公司,放棄了造更大更強的巨無霸伺服器(super computing server)的生產線。 反過來,他們用微型伺服器設計,比如說用幾百個使用Arm作為系統構架,手機大小的硬體組合成群。如果我沒有記錯的話,惠普幾年前就設計生產了一種這樣的工業用伺服器。據說能夠節能百分之九十。而且這種機器不容易完全壞。其道理不再重複。
跟歷史發展一樣,技術進步也是波浪式發展,螺旋式上升的。
文中所用圖片來自網上,一併致謝。

高興

感動

同情

搞笑

難過

拍磚

支持
1

鮮花

剛表態過的朋友 (1 人)

評論 (0 個評論)

facelist doodle 塗鴉板

您需要登錄后才可以評論 登錄 | 註冊

關於本站 | 隱私權政策 | 免責條款 | 版權聲明 | 聯絡我們

Copyright © 2001-2013 海外華人中文門戶:倍可親 (http://big5.backchina.com) All Rights Reserved.

程序系統基於 Discuz! X3.1 商業版 優化 Discuz! © 2001-2013 Comsenz Inc.

本站時間採用京港台時間 GMT+8, 2024-4-16 17:43

返回頂部