阿里高級技術專家：研發效能的追求永無止境

背景

大約在5年前，也就是2013年我剛加入阿里的時候，那個時候 DevOps 的風剛吹起來沒多久，有家公司宣稱可以一天發佈幾十上百次，這意味着相比傳統軟件公司幾週一次的發佈來講，他們響應商業需求的能力能夠甩後者幾條街，並且這差距根本不是加班能遇上的。今天的 AliExpress 技術團隊小几百人的規模，可一天發佈幾十次也已經司空見慣了，這主要得益於三個方面：

很是完全地微服務化，拆分粒度很細，且旗幟鮮明地反對重二方庫。

阿里集團總體的運維標準化，尤爲是 Docker 技術的全面覆蓋。

AliExpress SRE 團隊不斷努力保證穩定性。

然而，效能這個東西，你永遠不會說：「夠了，夠快了」，尤爲是在當下的消費型社會，人人都是消費者，而消費者巴不得腦子裏的慾望剛閃現出來，你的商品或服務瞬間就到他面前。何況，隨着咱們不斷國際化的步伐，新的因素必然會影響原來的高效能。

溝通帶寬衰減問題

第一個因素是研發團隊自身的發展和變化，今天的 AliExpress 技術團隊已是一個名副其實的分佈式國際化團隊，工做地是杭州+深圳+莫斯科+馬德里+其餘歐亞都市，外籍同窗的比例是 15%，並且能看到這個比例會不斷提升，新的國外工做地點也會增長。而這樣的團隊，對比在同一層樓裏的一羣中國人組成的團隊，是有本質的區別的。

咱們能夠將人與人之間的溝通和網絡通訊作類比，咱們知道網絡通訊是有帶寬的，從早期的撥號上網幾十K，到如今的家庭寬帶主流的幾十上百M，再到數據中心內部局域網內部G級別的數量級，帶寬越大，能傳輸的信息也就越多（一般浪費也就越多）。而人與人之間溝通也能夠認爲是有帶寬的，例如充分信任的全由中國工程師組成小團隊，平時相互一塊兒吃飯散步聊天，你們彼此都特別瞭解，溝通起來就特別順暢，想到一個點子轉個朝向說兩句對方就懂了。可對於一個分佈式國際化團隊來講，這個溝通帶寬但是衰減得厲害：

• 中文到英文的轉換，衰減一次。對於大多數人來講，英語不是母語，溝通的效率天然會下降。
• 單地到多地，衰減一次。電話，視頻，釘釘，都沒有面對面溝通來的高效。（不然你們都不會不約而同地刷臉了）
• 時差，再衰減一次。杭州和莫斯科的時差是5個小時，因此基本上北京時間上午咱們是聯繫不上莫斯科的同窗的。
• 文化的差別，再衰減一次。例如不少咱們能夠用來加強感情的團建方法，擼串K歌王者吃雞，外籍同窗可能徹底不感冒。

那有人可能會說，既然溝通成本這麼高，那直接在一個地方所有招中國工程師多簡單？這麼作簡單是簡單的了，可都這麼搞的話，怎麼在全球範圍吸引優秀的人才呢？更況且 AliExpress 的用戶基本都是老外，這後面的人才若是全是中國人，聽起來這生意就不太靠譜對不？谷歌微軟亞馬遜，哪家不是在全世界蒐羅頂尖人才？

因此說，既然溝通帶寬的衰減是難以免的，那咱們惟有把對這帶寬的利用率提上去。具體咱們已經作了，或者在作一些事情：

儘量和行業主流技術接軌，下降工程師學習成本。咱們基於開源 Spring Boot 作的阿里巴巴生態集成，摒棄 antx, webx, pandora，都是這個思路。

English First：註釋，文檔，工具，英文必選，中文可選。

服務發現，讓全部微服務可見，加強自描述，可搜索。

擁抱 Kotlin

關於開發效率，我我的認爲全部 Java 程序員都應該認認真真、仔仔細細去看下 Kotlin，由於這門語言太簡潔了，並且和 Java 能夠無縫互操做，徹底具有生產環境使用的條件。

有關簡潔，我這兩天把一塊 Java 代碼改爲了 Koltin，在絲絕不下降可讀性的狀況下（實際上可讀性是提升了），代碼行妥妥地減小了 1/3 。

此外我忍不住分享一下最近我基於 Sergey 的 Kotlin HSF DSL 寫的一個將函數發佈成 HSF 服務的功能：

只須要不到 15 行代碼，就能夠啓動一個 Spring Boot 應用，把一個字符串小寫的功能發佈成 HSF 服務，你們能夠對比下 Java 須要寫多少東西。語言層面的升級，給框架，中間件，API設計帶來更多的可能性，這就能使咱們砍掉更多的所謂腳手架代碼，讓業務代碼更精簡，更優雅，進而帶來效率提高。

做爲程序員，若是隻掌握一種語言，是很是危險的，由於這種語言的各類設計會禁錮你的思惟。我本身會在業餘看一些其餘語言，不過在平常工做中基本也只能寫 Java（若是 shell 也算一種語言的話，仍是寫過些 shell 的）。不過從如今開始，我會開始儘量地用 Kotlin 寫代碼，個人團隊也全面把平常編程語言從 Java 切換到 Kotlin，其實咱們都已經不算 Early Adoptor 啦，雷卷在一年多前就已經不停在鼓吹 Koltin 並上線了一個應用，AliExpress 俄羅斯辦公室的 Sergey 等同窗也已經在生產用上了 Kotlin，Sergey 我的也在不少地方分享他的經驗。

咱們會推進 AliExpress 擁抱 Koltin，從語言層面來提高咱們的效率。

阿里資深技術專家雷卷，在他最近的一篇談程序員學習的文章中寫了不少東西，我都是很認同的，其中一段話尤爲想點贊：

不要和程序員談本身的編程歷史，不少經驗今天已經不適用啦，可能有一些，可是會給別人帶來甄別成本，別人也懶得來甄別。2-3年不關注技術，基本快和程序員和編程絕緣啦，不是絕對，可是一般不會錯。

持續學習，與諸君共勉。

FaaS

Function as a Service，又一個新的 Buzz Word？是的，不過我還真的相信這個 Buzz Word，行業裏 AWS Lambda, Google Cloud Functions, Microsoft Azure Functions 等服務相繼推出，你們都在嘗試把本身的業務往上面搬，這其中的道理在哪？

若是做爲雲服務提供商，這個道理是很顯而易見。你的對手按照 docker instance 收費，2 core 4g 起，一小時多少錢；若是你能作到按調用次數收費，一小時內運行了 30 次。那這個價格差必然是數量級的，用這一招就能夠秒殺對手了。

上面所說的純粹是硬件成本的考量，但咱們還須要從效率方面看這個事情。

首先因爲 Function 天生是無狀態的，並且是足夠輕量的，那麼理論上作到 ms 級別的 auto scaling 是沒有問題的，例如 graalvm 就在這方面頗有潛力。

ms 級別的 auto scaling 不只可以大幅提高資源利用率，更是提高了運維效率，開發幾乎就再也不須要考慮容量的事情的。例如在雙11的時候，咱們作大量的壓測，很大程度上是爲了保證系統各個部分的水位在預測的安全的線上，若是作到了實時擴縮，那麼當流量高峯來的時候再擴容好了。

什麼是輕量？

今天不少工程師可能已經忘了輕量的概念是什麼，你們就是各類侵入，寫個簡單的應用，打出來的 jar 包，業務代碼的佔比每每不到 1/10。

先不說這裏可能無謂浪費了多少內存，無謂增長了多少啓動時間。這個 client 那個 share 滿天飛帶來的最麻煩的後果就是，開發常常要作各類升級，並且一升就掛，一查就半天。打着所謂性能旗號的各類重客戶端，就是反服務化的；各類缺少細心設計的 API 致使的不兼容升級（並且是暴力推進，不升級卡發佈），就是反工程師操守的。

微服務化作得好的，應該積累一大批輕量的接口，使用這些接口甚至都不須要引入什麼 share/open/client 的依賴，直接用 HSF 的泛化調用便可，這樣的接口才不對用戶有代碼侵入。

咱們已經在 AliExpress 嘗試（並已經上線）基於 Koltin DSL 和 HSF 泛化調用編寫 Function，用戶只須要依賴很簡單的一個 FaaS SDK 就能夠編寫業務代碼，基於前面提到的阿基米德服務發現，他能夠快速重用現有服務，作一些聚合和過濾的操做，知足業務需求，這個在貼近無線的業務中很是有用。固然，這個嘗試只是一個開始，但咱們已經看到，其實有大量的業務邏輯（在 AliExpress 多是 5/1 至 1/3）其實自身不依賴於數據，能夠作成 Function，並且咱們能夠作到讓這些業務不依賴任何業務二方庫，甚至藉助 Service Mesh 等技術，不依賴於任何中間件 client。這些業務的 owner 不須要關心各類亂七八糟的升級問題，不須要關心容量問題，真正地只關心本身的業務邏輯。

我認爲這是 FaaS 該成爲的樣子，而我及個人團隊，正不斷努力去實現之。

做者介紹

許曉斌，阿里高級技術專家，《Maven實戰》做者，《Maven權威指南》譯者，併合譯有《Cucumber：行爲驅動開發指南》，曾經負責維護 Maven 中央倉庫，參與開發 Maven 倉庫管理軟件 Sonatype Nexus。曾屢次在 ScrumGathering 和 AgileTour 等大會上發表演講。工做之餘喜歡讀讀人文、跑跑步。

 

原文連接 更多技術乾貨 請關注阿里云云棲社區微信號 ：yunqiinsight