前言

我或許，

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

也未曾一覽“云想衣裳花想容”的風(fēng)月。

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

閉目涌入一絲別樣的美。

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

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

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

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

Coding亦是如此。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

畢加索《牛的變形過程》

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

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

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

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

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

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

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

抽象的層次美-多維性

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

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

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

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

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

裸機(jī)抽象

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

虛擬機(jī)抽象

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

容器抽象

隨著微服務(wù)的興起，容器化成為一個(gè)標(biāo)準(zhǔn)的技術(shù)解決方案。

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

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

函數(shù)抽象

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

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

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

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

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

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

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

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

責(zé)任共擔(dān)模式

亞馬遜云科技的解決方案是責(zé)任共擔(dān)模式-抽出更多的時(shí)間干好自己更擅長的事情。

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

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

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

矛盾的共生方案

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

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

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

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

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

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

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

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

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

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

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

生成海報(bào)

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