從進入互聯網公司開始工作起，每個人都在問自己，CRUD 到底有什麼技術含量？
別覺得 CRUD 只是業務工程師的問題，無論你在寫什麼程序，基本上都是在和數據打交道，除了讀就是寫。只不過讀寫的時候還會附帶一些領域相關的行爲。比如：
編譯器：讀文本，做 parse 網絡程序：讀連接，decode，encode，寫連接 數據庫：從磁盤上讀，從內存裏讀，向磁盤裏寫，向內存裏寫
工程上，誰也沒有權力鄙視誰，你覺得領域的技術含量高，只不過是領域內的工作做的人少罷了。不管門檻多麼高的工程領域，只要工程師紅利們蜂擁而至，總有一款內卷適合你。
自動化
我們可能會以相同的工作在公司內做了無數遍爲由，痛斥公司無情，領導 sb，但是我們可以換一個角度。重複的工作，我們不可以把它自動化嗎？
當然可以。比如我們需要關注某個渠道的新聞，每次都要輸入網址/點擊收藏夾，等待加載。像日常作業一樣去完成這些工作。我們可以做一個定時的爬蟲，把新聞爬到我們自己的服務器上，通過一個簡單的 RSS 服務和訂閱就可以把這個流程自動化了。
公司要支持疫情期間的項目，每天上傳一些志願者的白名單，需要把這些白名單導入在線數據庫。我們肯定不希望每次都去寫噁心的 awk 腳本來做這件事情，只要給運營人員一個上傳的接口，並在後臺自動 parse，導入就可以了。
線上的系統爆炸了，我們要找出引起爆炸的爆炸源，並且電話通知負責人起牀修 bug。這麼顯式的流程，只要做好系統員工關聯以及自動外呼就可以了。
相同的工作，或許每次只需要 5 分鐘就可以完成，但只要重複過三次，那你就應該想辦法把它自動化，讓生活更美好。
有了自動化的思想，你纔是一個軟件工程師，而不是一個命令執行機器。
配置化
軟件系統本質上是真實世界的適配，這種適配在軟件的迭代早期是通過代碼來體現的。
最粗暴的是 if else，switch，可是我們希望複用啊，甚至還希望能不改代碼重啓就能實現功能切換。
常見的複雜軟件都有外掛的配置，複雜的業務系統也大多有配置。可能是項目啓動時需要讀取的 config file，也可能是在遠程配置系統/db 裏存儲的配置。
配置化是讓軟件能夠在不改代碼的前提下實現功能修改的方式，軟件根據配置的變化情況改變自身的行爲模式。
像 nginx 這樣的軟件，我們可以用配置讓它做一個 L4 的反向代理，也可以作爲一個 L7 的 http 服務器。
業務軟件的配置化，體現在對業務變化模式的預判上。
-
如果業務流程變化多，配置內容就是工作流配置。 -
如果計算邏輯變化多，配置內容就是各種表達式配置。 -
如果上游系統變化多，配置內容就是 ACL 的映射配置。
配置內容在系統內部使用時，文本形式的配置已經能夠滿足大部分需求了。
如果嫌 nginx 那樣的配置格式麻煩，用 json 可以表達任意形式的數據結構、邏輯流程、映射方式。這裏你可以有些疑惑，我們可以認爲：
-
代碼和 AST 之間是可以互相轉換的 -
AST 可以被 Marshal 爲 json -
所以 json 從原理上可以表達一切程序邏輯
如果一套系統的配置需求主要來自於外部，那麼基於文本的配置是不合適的。我們時常可以看到一些開源軟件的配置機器冗長晦澀(k8s：正是在下)。這些配置由人來編寫是機器反人類的。
何況配置本身還存在上下文關聯，如果軟件文檔寫的不夠詳細，正確地配置系統前，我們甚至還得先去讀軟件的實現代碼，使用成本極高。
UI 化
上下文有關聯的配置，在文本中非常難配置，而在 UI 中則非常容易。我們可以將合法配置的前提知識都編寫到 UI 的關聯彈出邏輯中，或者校驗邏輯中。這樣用戶便可以通過簡單的交互，迅速知曉軟件配置的遊戲規則。
如果還是希望用文本來配置，還可以使用所見即所得的方式來縮短配置編輯到生效的反饋時間，來幫助用戶迅速發現配置中的錯誤，及時修正，像 swagger editor[1] 那樣：
將軟件配置由文本配置變爲界面配置，在某些公司被稱爲配置“白屏化”。
平臺化
只要用 UI 化的思路做系統，遲早會形成一堆散落的接入系統。平臺化是對這些系統進行整合的一個機會，以某個具體的主題，把所有相關的流程聚合在一起。
例如 paas 平臺，流式計算平臺，業務工作流編排平臺，文檔平臺。
在互聯網公司，知識只有沉澱成爲平臺才能成爲公共知識，否則只不過是老員工腦子裏的糨糊罷了。
中臺化
當平臺不只服務於當前的業務，有更爲泛化的基礎能力時，便可以在公司內進行輸出。例如一套整合了大數據基礎設施和業務接入完整流程的數據平臺，不見得只在外賣場景可用，也可以用於網約車，可以用於酒旅。
有些公司把跨業務領域的能力稱爲商業能力，例如電商的售前，訂單流程，售後，都可以沉澱爲跨業務的通用功能。
中臺建設的最終產出物是一套結合了業務 SDK，多租戶隔離能力，自動化擴容能力，相應業務邏輯展現爲 UI 能力的多套完整的大平臺。對架構師的抽象能力，工程師的技術能力，基礎設施的運維能力都是有巨大考驗的。
從業務收益上看，這些帶界面的中臺可以大大降低工程師與 PM，PD，PXX 交流的門檻，非顛覆性的業務，甚至不需要工程師參與就可以由業務人員羅列出所有修改點自己修改完畢了。
被優化
業務技術系統主要支持業務，如果公司的商業模式不再發生大的變化，對於支持系統來說，系統做的好的特點是開發人員們存在感極低，只要領域專家在平臺上稍微點點鼠標就可以完成接入申請，找幾個新手從平臺上抄一兩行示例代碼就可以完成升級工作。
這時候你就應該被公司優化了。
參考資料
swagger editor: https://editor.swagger.io/
你可能還喜歡
點擊下方圖片即可閱讀
雲原生是一種信仰 🤘
關注公衆號
後臺回覆◉k8s◉獲取史上最方便快捷的 Kubernetes 高可用部署工具，只需一條命令，連 ssh 都不需要！
點擊 "閱讀原文" 獲取更好的閱讀體驗！
發現朋友圈變“安靜”了嗎？
本文分享自微信公衆號 - 雲原生實驗室（cloud_native_yang）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。