前言

我或許，

未曾親身經歷“長袖一拂元都門”的巍峨。

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

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

閉目涌入一絲別樣的美。

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

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

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

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

Coding亦是如此。

業務重構的思考-抽象美是什么？

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

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

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

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

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

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

抽象的創造美-歸一性

如果抽象原則是筆和顏料，那么抽象設計就是繪畫底稿，抽象結果就是最終呈現的作品。

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

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

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

在上述過程中，亞馬遜服務網格抽象美體現在：將共性的技術治理部分剝離出來，徹底解耦應用與框架；并解決了異構開發語言問題，不同開發語言開發的應用，統一被通信代理模塊接管。使得原本復雜的邏輯場景在一定區間內歸一化。

抽象的美，在于進階之后的創造與歸一。

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

畢加索《牛的變形過程》

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

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

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

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

這種抽象工作流在宏觀角度上實現可運行、可觀測、可治理、可變更。微觀角度上可實現工作流順暢和高效，各個環境自動觸發和流轉。

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

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

抽象的層次美-多維性

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

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

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

那么在我們的業務架構設計中，有哪些抽象之美碰撞出的火花呢？

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

裸機抽象

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

虛擬機抽象

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

容器抽象

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

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

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

函數抽象

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

當我們無需管理運行函數之下的基礎架構，無需跟蹤物理主機狀態和機群容量，無需修補運行該函數的操作系統時。不僅抽離出無關緊要的重活，并且贏得了時間和金錢。

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

“優雅”與“成本”的矛與盾

角色轉換的思考

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

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

當個人行為的“優雅”上升到團隊、組織、企業。當不同層次的抽象帶來的“優雅”與“成本”變得難以決策，我們如何利用外部資源進行兩者的平衡？

責任共擔模式

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

這就意味著在抽象層級的敘事線中，我們抽象出了使用者和服務者這兩個角色之間的行為集合。基于信任及共贏的原則，雙方著重于更適合本身的事情。

亞馬遜云科技著重于“云本身的魯棒” – 亞馬遜云科技保護運行所有亞馬遜云科技云服務的基礎設施。該基礎實施由運行亞馬遜云科技云服務的硬件、軟件、網絡和設備抽象而成。

客戶著重于“云內部的魯棒” – 客戶基于亞馬遜云科技云服務，只需關注著云內部的魯棒。對于抽象化服務，例如 Amazon S3 和 Amazon DynamoDB，亞馬遜云科技運營基礎設施層、操作系統和平臺，而客戶通過訪問終端節點存儲和檢索數據?？蛻糁恍枰撠煿芾砥鋽祿ò用苓x項），對其資產進行分類，以及使用 IAM 工具分配適當的權限就可以實現完整的操作鏈路閉環。

矛盾的共生方案

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

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

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

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

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

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

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

但也曾因反復需求變更加班到深夜，在功能實現與代碼優雅的取舍中降低底線。

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

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

讓Coding變為美的享受，掉落為音符，在指尖流淌。

多位大咖現身說法

如何用充滿“技術美感”的方式

幫助開發者

實現更簡單、自由、高效的開發

此外，還有大量專家觀點碰撞

創新賽、動手實踐等環節

精彩不斷，干貨滿滿

攜手大家一起“自由構建，探索無限”