[[245691]]

背景

大約在5年前，也就是2013年我剛加入阿里的時(shí)候，那個(gè)時(shí)候 DevOps 的風(fēng)剛吹起來(lái)沒(méi)多久，有家公司宣稱能夠一天發(fā)布幾十上百次，這意味著相比傳統(tǒng)軟件公司幾周一次的發(fā)布來(lái)說(shuō)，他們響應(yīng)商業(yè)需求的能力可以甩后者幾條街，而且這差距根本不是加班能趕上的。今天的 AliExpress 技術(shù)團(tuán)隊(duì)小幾百人的規(guī)模，可一天發(fā)布幾十次也已經(jīng)司空見(jiàn)慣了，這主要得益于三個(gè)方面：

1. 非常徹底地微服務(wù)化，拆分粒度很細(xì)，且旗幟鮮明地反對(duì)重二方庫(kù)。
2. 阿里集團(tuán)整體的運(yùn)維標(biāo)準(zhǔn)化，尤其是 Docker 技術(shù)的全面覆蓋。
3. AliExpress SRE 團(tuán)隊(duì)不斷努力保證穩(wěn)定性。

然而，效能這個(gè)東西，你永遠(yuǎn)不會(huì)說(shuō)：“夠了，夠快了”，尤其是在當(dāng)下的消費(fèi)型社會(huì)，人人都是消費(fèi)者，而消費(fèi)者恨不得腦子里的欲望剛閃現(xiàn)出來(lái)，你的商品或服務(wù)瞬間就到他面前。況且，隨著我們不斷國(guó)際化的步伐，新的因素必然會(huì)影響原來(lái)的高效能。

溝通帶寬衰減問(wèn)題

***個(gè)因素是研發(fā)團(tuán)隊(duì)自身的發(fā)展和變化，今天的 AliExpress 技術(shù)團(tuán)隊(duì)已經(jīng)是一個(gè)名副其實(shí)的分布式國(guó)際化團(tuán)隊(duì)，工作地是杭州+深圳+莫斯科+馬德里+其他歐亞都市，外籍同學(xué)的比例是 15%，而且能看到這個(gè)比例會(huì)不斷提高，新的國(guó)外工作地點(diǎn)也會(huì)增加。而這樣的團(tuán)隊(duì)，對(duì)比在同一層樓里的一群中國(guó)人組成的團(tuán)隊(duì)，是有本質(zhì)的區(qū)別的。

我們可以將人與人之間的溝通和網(wǎng)絡(luò)通信做類比，我們知道網(wǎng)絡(luò)通信是有帶寬的，從早期的撥號(hào)上網(wǎng)幾十K，到現(xiàn)在的家庭寬帶主流的幾十上百M(fèi)，再到數(shù)據(jù)中心內(nèi)部局域網(wǎng)內(nèi)部G級(jí)別的數(shù)量級(jí)，帶寬越大，能傳輸?shù)男畔⒁簿驮蕉?通常浪費(fèi)也就越多)。而人與人之間溝通也可以認(rèn)為是有帶寬的，例如充分信任的全由中國(guó)工程師組成小團(tuán)隊(duì)，平時(shí)相互一起吃飯散步聊天，大家彼此都特別了解，溝通起來(lái)就特別順暢，想到一個(gè)點(diǎn)子轉(zhuǎn)個(gè)朝向說(shuō)兩句對(duì)方就懂了?？蓪?duì)于一個(gè)分布式國(guó)際化團(tuán)隊(duì)來(lái)說(shuō)，這個(gè)溝通帶寬可是衰減得厲害：

• 中文到英文的轉(zhuǎn)換，衰減一次。對(duì)于大多數(shù)人來(lái)說(shuō)，英語(yǔ)不是母語(yǔ)，溝通的效率自然會(huì)降低。
• 單地到多地，衰減一次。電話，視頻，釘釘，都沒(méi)有面對(duì)面溝通來(lái)的高效。(否則大家都不會(huì)不約而同地刷臉了)
• 時(shí)差，再衰減一次。杭州和莫斯科的時(shí)差是5個(gè)小時(shí)，所以基本上北京時(shí)間上午我們是聯(lián)系不上莫斯科的同學(xué)的。
• 文化的差異，再衰減一次。例如很多我們可以用來(lái)增強(qiáng)感情的團(tuán)建方法，擼串K歌王者吃雞，外籍同學(xué)可能完全不感冒。

那有人可能會(huì)說(shuō)，既然溝通成本這么高，那直接在一個(gè)地方全部招中國(guó)工程師多簡(jiǎn)單?這么做簡(jiǎn)單是簡(jiǎn)單的了，可都這么搞的話，怎么在全球范圍吸引優(yōu)秀的人才呢?更何況 AliExpress 的用戶基本都是老外，這后面的人才如果全是中國(guó)人，聽(tīng)起來(lái)這生意就不太靠譜對(duì)不?谷歌微軟亞馬遜，哪家不是在全世界搜羅***人才?

所以說(shuō)，既然溝通帶寬的衰減是難以避免的，那我們唯有把對(duì)這帶寬的利用率提上去。具體我們已經(jīng)做了，或者在做一些事情：

1. 盡可能和行業(yè)主流技術(shù)接軌，降低工程師學(xué)習(xí)成本。我們基于開(kāi)源 Spring Boot 做的阿里巴巴生態(tài)集成，摒棄 antx, webx, pandora，都是這個(gè)思路。
2. English First：注釋，文檔，工具，英文必選，中文可選。
3. 服務(wù)發(fā)現(xiàn)，讓所有微服務(wù)可見(jiàn)，增強(qiáng)自描述，可搜索。

擁抱 Kotlin

關(guān)于開(kāi)發(fā)效率，我個(gè)人認(rèn)為所有 Java 程序員都應(yīng)該認(rèn)認(rèn)真真、仔仔細(xì)細(xì)去看下 Kotlin，因?yàn)檫@門(mén)語(yǔ)言太簡(jiǎn)潔了，而且和 Java 可以無(wú)縫互操作，完全具備生產(chǎn)環(huán)境使用的條件。

有關(guān)簡(jiǎn)潔，我這兩天把一塊 Java 代碼改成了 Koltin，在絲毫不降低可讀性的情況下(實(shí)際上可讀性是提高了)，代碼行妥妥地減少了 1/3 。

此外我忍不住分享一下最近我基于 Sergey 的 Kotlin HSF DSL 寫(xiě)的一個(gè)將函數(shù)發(fā)布成 HSF 服務(wù)的功能：

只需要不到 15 行代碼，就可以啟動(dòng)一個(gè) Spring Boot 應(yīng)用，把一個(gè)字符串小寫(xiě)的功能發(fā)布成 HSF 服務(wù)，大家可以對(duì)比下 Java 需要寫(xiě)多少東西。語(yǔ)言層面的升級(jí)，給框架，中間件，API設(shè)計(jì)帶來(lái)更多的可能性，這就能使我們砍掉更多的所謂腳手架代碼，讓業(yè)務(wù)代碼更精簡(jiǎn)，更優(yōu)雅，進(jìn)而帶來(lái)效率提升。

作為程序員，如果只掌握一種語(yǔ)言，是非常危險(xiǎn)的，因?yàn)檫@種語(yǔ)言的各種設(shè)計(jì)會(huì)禁錮你的思維。我自己會(huì)在業(yè)余看一些其他語(yǔ)言，不過(guò)在日常工作中基本也只能寫(xiě) Java(如果 shell 也算一種語(yǔ)言的話，還是寫(xiě)過(guò)些 shell 的)。不過(guò)從現(xiàn)在開(kāi)始，我會(huì)開(kāi)始盡可能地用 Kotlin 寫(xiě)代碼，我的團(tuán)隊(duì)也全面把日常編程語(yǔ)言從 Java 切換到 Kotlin，其實(shí)我們都已經(jīng)不算 Early Adoptor 啦，雷卷在一年多前就已經(jīng)不停在鼓吹 Koltin 并上線了一個(gè)應(yīng)用，AliExpress 俄羅斯辦公室的 Sergey 等同學(xué)也已經(jīng)在生產(chǎn)用上了 Kotlin，Sergey 個(gè)人也在很多地方分享他的經(jīng)驗(yàn)。

我們會(huì)推動(dòng) AliExpress 擁抱 Koltin，從語(yǔ)言層面來(lái)提升我們的效率。

阿里資深技術(shù)專家雷卷，在他最近的一篇談程序員學(xué)習(xí)的文章中寫(xiě)了很多東西，我都是很認(rèn)同的，其中一段話尤其想點(diǎn)贊：

不要和程序員談自己的編程歷史，很多經(jīng)驗(yàn)今天已經(jīng)不適用啦，可能有一些，但是會(huì)給別人帶來(lái)甄別成本，別人也懶得來(lái)甄別。2-3年不關(guān)注技術(shù)，基本快和程序員和編程絕緣啦，不是絕對(duì)，但是通常不會(huì)錯(cuò)。

FaaS

Function as a Service，又一個(gè)新的 Buzz Word?是的，不過(guò)我還真的相信這個(gè) Buzz Word，行業(yè)里 AWS Lambda, Google Cloud Functions, Microsoft Azure Functions 等服務(wù)相繼推出，大家都在嘗試把自己的業(yè)務(wù)往上面搬，這其中的道理在哪?

如果作為云服務(wù)提供商，這個(gè)道理是很顯而易見(jiàn)。你的對(duì)手按照 docker instance 收費(fèi)，2 core 4g 起，一小時(shí)多少錢(qián);如果你能做到按調(diào)用次數(shù)收費(fèi)，一小時(shí)內(nèi)運(yùn)行了 30 次。那這個(gè)價(jià)格差必然是數(shù)量級(jí)的，用這一招就可以秒殺對(duì)手了。

上面所說(shuō)的純粹是硬件成本的考量，但我們還需要從效率方面看這個(gè)事情。

首先由于 Function 天生是無(wú)狀態(tài)的，而且是足夠輕量的，那么理論上做到 ms 級(jí)別的 auto scaling 是沒(méi)有問(wèn)題的，例如 graalvm 就在這方面很有潛力。

ms 級(jí)別的 auto scaling 不僅能夠大幅提升資源利用率，更是提升了運(yùn)維效率，開(kāi)發(fā)幾乎就不再需要考慮容量的事情的。例如在雙11的時(shí)候，我們做大量的壓測(cè)，很大程度上是為了保證系統(tǒng)各個(gè)部分的水位在預(yù)測(cè)的安全的線上，如果做到了實(shí)時(shí)擴(kuò)縮，那么當(dāng)流量高峰來(lái)的時(shí)候再擴(kuò)容好了。

什么是輕量?

今天很多工程師可能已經(jīng)忘了輕量的概念是什么，大家就是各種侵入，寫(xiě)個(gè)簡(jiǎn)單的應(yīng)用，打出來(lái)的 jar 包，業(yè)務(wù)代碼的占比往往不到 1/10。

先不說(shuō)這里可能無(wú)謂浪費(fèi)了多少內(nèi)存，無(wú)謂增加了多少啟動(dòng)時(shí)間。這個(gè) client 那個(gè) share 滿天飛帶來(lái)的最麻煩的后果就是，開(kāi)發(fā)經(jīng)常要做各種升級(jí)，而且一升就掛，一查就半天。打著所謂性能旗號(hào)的各種重客戶端，就是反服務(wù)化的;各種缺乏細(xì)心設(shè)計(jì)的 API 導(dǎo)致的不兼容升級(jí)(而且是暴力推動(dòng)，不升級(jí)卡發(fā)布)，就是反工程師操守的。

微服務(wù)化做得好的，應(yīng)該積累一大批輕量的接口，使用這些接口甚至都不需要引入什么 share/open/client 的依賴，直接用 HSF 的泛化調(diào)用即可，這樣的接口才不對(duì)用戶有代碼侵入。

我們已經(jīng)在 AliExpress 嘗試(并已經(jīng)上線)基于 Koltin DSL 和 HSF 泛化調(diào)用編寫(xiě) Function，用戶只需要依賴很簡(jiǎn)單的一個(gè) FaaS SDK 就可以編寫(xiě)業(yè)務(wù)代碼，基于前面提到的阿基米德服務(wù)發(fā)現(xiàn)，他可以快速重用現(xiàn)有服務(wù)，做一些聚合和過(guò)濾的操作，滿足業(yè)務(wù)需求，這個(gè)在貼近無(wú)線的業(yè)務(wù)中非常有用。當(dāng)然，這個(gè)嘗試只是一個(gè)開(kāi)始，但我們已經(jīng)看到，其實(shí)有大量的業(yè)務(wù)邏輯(在 AliExpress 可能是 5/1 至 1/3)其實(shí)自身不依賴于數(shù)據(jù)，可以做成 Function，而且我們可以做到讓這些業(yè)務(wù)不依賴任何業(yè)務(wù)二方庫(kù)，甚至借助 Service Mesh 等技術(shù)，不依賴于任何中間件 client。這些業(yè)務(wù)的 owner 不需要關(guān)心各種亂七八糟的升級(jí)問(wèn)題，不需要關(guān)心容量問(wèn)題，真正地只關(guān)心自己的業(yè)務(wù)邏輯。

我認(rèn)為這是 FaaS 該成為的樣子，而我及我的團(tuán)隊(duì)，正不斷努力去實(shí)現(xiàn)之。

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文