歸一性與普適性的多重奏-淺談技術(shù)抽象美

前言

我或許，

未曾親身經(jīng)歷“長袖一拂元都門”的巍峨。

也未曾一覽“云想衣裳花想容”的風月。

但我有幸能尋著唐宋大家的筆觸，喃喃低吟中，

閉目涌入一絲別樣的美。

是流蘇云疊？是汩汩泉涌？亦是，亦不是。

就像李白的詩詞，梵高的油墨，莫扎特的音符，王羲之的書卷。

既有意象，又切換著具象。

美存在于留有一絲的想象中，

Coding亦是如此。

業(yè)務(wù)重構(gòu)的思考-抽象美是什么？

近年來，企業(yè)數(shù)智化轉(zhuǎn)型不斷加速的同時，想必每個程序員都切身感受到這樣的痛苦：

比如短時間內(nèi)需求變更、壓縮工時，導致代碼產(chǎn)出與設(shè)計背離；或者接盤了一個老項目，在語句與結(jié)構(gòu)混亂、代碼重復(fù)、沒有注釋的代碼山中翻找“硬幣”。

不美的事物會給人帶來身體與心靈的雙重疲勞，那么什么是技術(shù)之美呢？抽象的美感又是什么？

科學與藝術(shù)是不可分的，兩者都在追求真理的普遍性。而抽象強調(diào)歸一和普適，最終在多層次下實現(xiàn)降低業(yè)務(wù)復(fù)雜度。但只知理論方法，不親身體驗，對于欣賞抽象之美就會有偏差。

只有了解抽象的特點與場景中的問題，才會真正的明白什么是“抽象之美“。

歸一與普適的多重奏-論抽象之美

抽象的創(chuàng)造美-歸一性

如果抽象原則是筆和顏料，那么抽象設(shè)計就是繪畫底稿，抽象結(jié)果就是最終呈現(xiàn)的作品。

近些年，隨著微服務(wù)架構(gòu)火熱，很多單體架構(gòu)的企業(yè)級應(yīng)用改造為微服務(wù)，但是隨著應(yīng)用體積越來越大，管理越來越麻煩。特別是部署一套新環(huán)境的時候，隨之而來的服務(wù)發(fā)現(xiàn)、負載均衡、Trace跟蹤、流量管理、安全認證等問題讓人困擾。

而Service Mesh 就是為此而生的經(jīng)典抽象，下圖是Amazon App Mesh的示意圖：

亞馬遜云科技（Amazon Web Service）提供了一個完整的解決方案，通過服務(wù)網(wǎng)格讓服務(wù)輕松跨多種類型的計算基礎(chǔ)設(shè)施相互通信。把所需要處理的通信場景降維到一定區(qū)間內(nèi)。通過控件以配置和標準化流量在服務(wù)之間的流動方式。實施自定義流量路由規(guī)則，來保證服務(wù)在部署期間、故障后以及應(yīng)用程序擴展時都高度可用。

在上述過程中，亞馬遜服務(wù)網(wǎng)格抽象美體現(xiàn)在：將共性的技術(shù)治理部分剝離出來，徹底解耦應(yīng)用與框架；并解決了異構(gòu)開發(fā)語言問題，不同開發(fā)語言開發(fā)的應(yīng)用，統(tǒng)一被通信代理模塊接管。使得原本復(fù)雜的邏輯場景在一定區(qū)間內(nèi)歸一化。

抽象的美，在于進階之后的創(chuàng)造與歸一。

抽象的“具象美”-普適性

畢加索《牛的變形過程》

雖然抽象是與具象相對的一個概念，但是我們還是可以用“具象”的描述去體會抽象美。

抽象的美一部分在于它的泛化，可以將我們對具體事物的操作泛化到所有相似的事物上。

當我們總結(jié)事物、業(yè)務(wù)的規(guī)律后進行抽象，然后把抽象具體化，再泛化到其他事物、場景上可以有效減少我們重復(fù)思考的過程。

例如Amazon CodePipeline就是通過開發(fā)過程抽象，形成了 Amazon CodeBuild、Amazon CodeDeploy 和各種其他工具的持續(xù)集成或持續(xù)交付工作流。

這種抽象工作流在宏觀角度上實現(xiàn)可運行、可觀測、可治理、可變更。微觀角度上可實現(xiàn)工作流順暢和高效，各個環(huán)境自動觸發(fā)和流轉(zhuǎn)。

這樣開發(fā)者、測試人員、運維工程師、IT工程師之間就不必過多地相互關(guān)聯(lián)。使得整個流程更加輕盈/獨立，并具有高度的普適性，而這就是一種抽象的美。

抽象的美不再是遙不可及的星辰，也許在我們工作的點滴中就已經(jīng)“具象”地表達出來了。

抽象的層次美-多維性

抽象是一種思維模式，它是建立在封裝之上的。抽象是從不同的角度、不同的層次看待問題。

層次越高，就越抽象。我們可以從過程-數(shù)據(jù)-控制進行抽象；可以從變量、函數(shù)、接口、消息傳遞、設(shè)計模式、應(yīng)用進行抽象；也可以從視圖層、邏輯層、物理層進行抽象。這就意味著不同層次的抽象下，視角是完全不同的。

而抽象的美加上層次，就像在讀一本緊張刺激的懸疑小說，環(huán)環(huán)相扣、情節(jié)動蕩，又像在讀一本宏大的科幻小說，從微觀到宏觀，架空出一個完整的世界。

那么在我們的業(yè)務(wù)架構(gòu)設(shè)計中，有哪些抽象之美碰撞出的火花呢？

接下來可以通過一個亞馬遜云科技經(jīng)典圖示去感受下抽象的層次之美：

裸機抽象

裸機抽象使得應(yīng)用程序可以利用底層硬件功能，因為某些功能在虛擬環(huán)境中不總是受到全面的支持。在這種抽象下，可以實現(xiàn)硬件上直接運行或在非虛擬環(huán)境中獲得授權(quán)和支持的應(yīng)用程序。

虛擬機抽象

虛擬機抽象我在另一篇文章中有所提及，我曾使用過Amazon Lightsail，在短短15分鐘之內(nèi)就通過Amazon Lightsail部署了一個簡單的web應(yīng)用。我只需關(guān)注客戶操作系統(tǒng)及應(yīng)用的中間件、應(yīng)用程序等，無需過多操心管理硬件和虛擬機監(jiān)控程序，包括它們的生命周期。

容器抽象

隨著微服務(wù)的興起，容器化成為一個標準的技術(shù)解決方案。

圖示中的亞馬遜云科技 ECS，它是一個具有高擴展性、高性能的容器管理服務(wù)，支持 Docker，無需安裝、操作和擴展集群管理基礎(chǔ)架構(gòu)。而使用EKS 可以基于 Kubernetes 進行容器控制。

這種抽象使得用戶從管理容器控制平面的重任中解放出來。

函數(shù)抽象

Lambda 是一個執(zhí)行環(huán)境，允許亞馬遜云科技客戶運行單個函數(shù)。因此，無需管理和運行整個 OS 實例來運行代碼，也無需在用戶構(gòu)建的容器中跟蹤所有的軟件依賴項來運行代碼，這種直接驅(qū)動或間接驅(qū)動的抽象模型，使得函數(shù)級抽象變得十分靈活。

當我們無需管理運行函數(shù)之下的基礎(chǔ)架構(gòu)，無需跟蹤物理主機狀態(tài)和機群容量，無需修補運行該函數(shù)的操作系統(tǒng)時。不僅抽離出無關(guān)緊要的重活，并且贏得了時間和金錢。

在用戶視角從底層抽象逐步上升到應(yīng)用抽象的過程中，抽象的層次越高，用戶的“爽點”體驗就越強烈。站在最高層次看待問題，用戶不需要去關(guān)心各個應(yīng)用內(nèi)部由哪些模塊、構(gòu)件組成，只需要將各個應(yīng)用拼裝來完成不同的任務(wù)。而通常系統(tǒng)的架構(gòu)圖就是這樣，只畫出各個具體的服務(wù)，關(guān)注服務(wù)之間的調(diào)用關(guān)系。一個服務(wù)，一個數(shù)據(jù)庫，一個消息隊列，一個緩存服務(wù)都只是一個圓圈而已。這就是一種歸一與普適結(jié)合的抽象美。

“優(yōu)雅”與“成本”的矛與盾

角色轉(zhuǎn)換的思考

一個優(yōu)秀的程序員或多或少都有一些自己的代碼“潔癖”，也不乏追求高度與深度的集大成者。

無論是追求代碼簡潔之道，還是抽象之美，團隊之間的個體差異都會對整個系統(tǒng)、產(chǎn)品的宏觀視角產(chǎn)生不同的影響。

當個人行為的“優(yōu)雅”上升到團隊、組織、企業(yè)。當不同層次的抽象帶來的“優(yōu)雅”與“成本”變得難以決策，我們?nèi)绾卫猛獠抠Y源進行兩者的平衡？

責任共擔模式

亞馬遜云科技的解決方案是責任共擔模式-抽出更多的時間干好自己更擅長的事情。

這就意味著在抽象層級的敘事線中，我們抽象出了使用者和服務(wù)者這兩個角色之間的行為集合?；谛湃渭肮糙A的原則，雙方著重于更適合本身的事情。

亞馬遜云科技著重于“云本身的魯棒” – 亞馬遜云科技保護運行所有亞馬遜云科技云服務(wù)的基礎(chǔ)設(shè)施。該基礎(chǔ)實施由運行亞馬遜云科技云服務(wù)的硬件、軟件、網(wǎng)絡(luò)和設(shè)備抽象而成。

客戶著重于“云內(nèi)部的魯棒” – 客戶基于亞馬遜云科技云服務(wù)，只需關(guān)注著云內(nèi)部的魯棒。對于抽象化服務(wù)，例如 Amazon S3 和 Amazon DynamoDB，亞馬遜云科技運營基礎(chǔ)設(shè)施層、操作系統(tǒng)和平臺，而客戶通過訪問終端節(jié)點存儲和檢索數(shù)據(jù)?？蛻糁恍枰撠煿芾砥鋽?shù)據(jù)（包括加密選項），對其資產(chǎn)進行分類，以及使用 IAM 工具分配適當?shù)臋?quán)限就可以實現(xiàn)完整的操作鏈路閉環(huán)。

矛盾的共生方案

當抽象的級別越高，云供應(yīng)商就越能產(chǎn)生價值。我們可以在業(yè)務(wù)架構(gòu)層中進行拆離，將“不擅長的部分”剝離出去，讓擅長的人來做。當企業(yè)把寄存關(guān)系看為共生關(guān)系時，短期來看雖投入了現(xiàn)金流，但長期下來，團隊可以集中精力去深入業(yè)務(wù)體系深耕。一方面減少人才流失，一方面無形中培養(yǎng)了差異化的核心競爭力。

追求抽象之美，也可以“兩全其美”。

不忘初心，每天都是“Day one”

我很欣賞亞馬遜創(chuàng)始人杰夫·貝索斯的Day one理念。

他說：“我們還是第一天”。

我們這代人趕上時代的紅利，很多人走出貧瘠的縣城，來到大城市，獲得了所謂的高薪。

曾經(jīng)我們都曾對于技術(shù)抱有美好的憧憬，在追逐美的路上不知疲倦地奔跑。

但也曾因反復(fù)需求變更加班到深夜，在功能實現(xiàn)與代碼優(yōu)雅的取舍中降低底線。

曾幾何時，我們在低頭狂碼中，漸漸忘記了那個抬頭仰望星空的少年。

我覺得每個開發(fā)者都應(yīng)該像亞馬遜的經(jīng)營理念一樣，擁抱變化，擁抱美好的代碼；

讓Coding變?yōu)槊赖南硎?，掉落為音符，在指尖流淌?/p>

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。