作者 | 董鵬  阿里巴巴技術專家

微服務

好處：實現跨團隊的解耦，實現更高的併發（目前單機只能實現 c10k）不用再拷貝程式碼，基礎服務可以公用，更好的支援服務治理，能夠更好的相容雲端計算平臺。

RPC

• rpc：像呼叫本地方法一樣呼叫遠端函式；
• 客戶端：一般利用動態代理生成一個介面的實現類，在這個實現類裡通過網路把介面名稱、引數、方法序列化後傳出去，然後控制同步呼叫還是非同步呼叫，非同步呼叫需要設定一個回撥函式；

客戶端還需要維護負載均衡、超時處理、連線池管理等，連線池維護了和多個 server 的連線，靠此做負載均衡，當某個伺服器當機後去除該連線。請求上下文維護了請求 ID 和回撥函式，超時的請求當回覆報文到達後由於找不到請求上下文就會丟棄。

• 服務端：維護連線，網路收到請求後反序列化獲得方法名稱，介面名稱，引數名稱後通過反射進行呼叫，然後將結果在傳回客戶端；
• 序列化的方式：一種是隻序列化欄位的值，反序列化的時候重新構建物件再把值設定進去，另外一種方式直接將整個物件的結構序列化成二進位制。

前者節省空間，後者反序列化速度快，目前的序列化框架也是在反序列化時間和佔用空間之間權衡。有點類似哈夫曼編碼，或者資料庫怎麼儲存一行一行的資料。

註冊中心

一般有 3 種模式：

• f5 做集中式代理；
• 客戶端嵌入式代理例如 dubbo；
• 還有一種是綜合上面兩種，多個客戶端共用一個代理，代理作為一個獨立程式部署在和客戶端伺服器同一臺物理機上，ServiceMesh 就是這種模式。

zookeeper 不適合做註冊中心的原因：zookeeper 為了一致性犧牲了可用性，但是註冊中心實際上對一致性要求並不高，不一致產生的後果也就是某個服務下線了而客戶端並不知道，但是客戶端通過重試其他節點就可以了。

另外當發生網路分割槽的時候，如果超過半數節點掛了，zookeeper 就不可用，但是實際上它應該仍然可以對它所在機房的節點提供註冊服務，例如三個機房分別放了 2 臺、2 臺、1 臺，如果各個機房之間網路斷了，但是機房內部上是通的，這樣註冊中心不可用即使內部節點也不能服務了。

zookeeper 並不是嚴格的一致性，它支援讀寫分離，其它節點收到寫請求會轉發給 master 節點，而其它節點可以支援讀請求，當資料還沒有從主節點複製過來的時候讀到的可能是過期的資料。

配置中心

配置中心的需求：保證高可用、實時通知、灰度釋出、許可權控制、一鍵回滾、環境隔離（開發/測試/生產）等，目前的開源實現：nacos disconf apollo。

• disconf:scan 模組掃描註解和監聽器；
• store 模組將遠端獲取到的配置儲存到本地，本地一個 job 檢測配置是否有變化，有變化就通知監聽器；
• fetch 模組從遠端通過 http 獲取配置；
• watch 模組監聽 zookeeper 上節點的變化，有變化就會呼叫 fetch 進行獲取。

apollo 有以下 4 個模組：

- portal 作為一個管理後臺，提供管理員操作的入口。 有獨立的資料庫；

- adminservice 提供配置的修改和釋出服務的底層服務，和 configservice 公用一個資料庫 configdb，每次修改配置就會往資料庫裡插入一條記錄 releasemessage；

- configservice  用一個定時任務去掃描資料庫是否有新的 releasemessage，有的話就通知客戶端，而客戶端採用定時輪詢的方式去查詢 configservice 是否有新訊息，這裡採用 deferredresult 非同步執行；

- eruka 為 adminservice 和 configservice 提供了註冊發現的服務。客戶端獲取到配置檔案後也會寫入磁碟。

任務排程

• 執行器也就是應用本身，任務單元也就是具體執行任務的執行緒，能夠主動註冊排程器中，並在啟動的時候進行更新，例如刪除已經清空的任務；
• 排程中心支援叢集部署避免單點，可以選舉一個主節點，其它為 slave；
• 支援負載均衡演算法為每個任務隨機選擇執行器，能夠支援失敗重試，將執行很慢或者失去連線的執行器移除；
• 支援控制任務併發，例如是否允許一個任務沒執行完又被排程；
• 支援任務依賴，例如一個任務沒執行完另一個任務不能執行，或者自動執行另外一個任務；
• 支援任務分片，將一個任務根據引數分片到不同的執行器上一起執行；
• 可以取消一個任務；
• 已經支援 glue 模式，可以不用釋出就執行一個任務單元。

分散式鎖

• redis setnx 裡面已經有引數可以支援分散式鎖，但是最好能把鎖的擁有方存到 value 裡，釋放的時候做比較，不然可能釋放錯鎖,也就是會出現 A 釋放了 B 的鎖；
• zk 採用建立臨時節點，其他建立失敗的執行緒監聽鎖的狀態。

SET resource_name my_random_value NX PX 30000複製程式碼

統一監控

• 收集日誌並分析，日誌也可以和 rpc 鏈路進行關聯，也可以對日誌進行降噪或者壓縮儲存；
• 提供 api 的方式以及攔截器模式，可以基於 javaagent 做到無嵌入；
• 實現 opentracing 鏈路追蹤；
• 可以基於 disruptor ringbuffer 的生產消費者模式；
• 海量資料的儲存 elasticsearch；
• 報表生成，監控指標設定；
• 各個節點進行收集，訊息上傳到服務端統一處理；
• 監控指標：rpc 鏈路、資料庫、cpu 指標等、http 狀態、各種中介軟體；
• 日誌收集可以通過直接在日誌框架上加攔截器，或者用 flink+kafka 收集。

快取

先清空快取還是先更新資料庫？

• 如果是更新快取而不是刪除快取：則不管哪種方式都會造成快取和資料庫不一致；
• 如果是刪除快取：則先刪除快取在更新資料庫，如果更新資料庫失敗了也沒有太大影響，快取被清了重新載入即可。但是也要考慮到快取穿透的問題，如果這個時候大流量進來是否會壓垮資料庫？

以上是考慮到分散式事務中一個成功一個失敗的情況，但是這種概率畢竟是小的，可以用在併發量不是很高但是對資料一致性要求很高的情況，如果併發很高建議先更新資料庫後清空快取。

如果先清空快取，後更新資料庫，在還沒有更新到資料庫的情況下另外一個事務去查詢，發現快取沒命中就去資料庫取，然後又寫入快取，之後上一個事務的資料庫更新，這樣就導致了快取和資料庫不一致，如果先更新資料庫再清空快取，更新完資料庫後快取還沒更新，這個時候來讀取快取是舊的值，也出現不一致，但是最終清空快取後會一致。

不過這種方式也會產生永久不一致，但是概率很小，例如一個讀請求，沒有命中快取，這個時候可能另一個執行緒剛好清空快取，然後它就去資料裡面取，但是又有一個執行緒在它讀完資料庫後將資料庫改為另外一個值，這樣那個讀請求寫入到快取的資料就是髒資料了。

redis 採用單執行緒模型，對只有 io 操作來說效能很好，但是 redis 也提供了計算功能，如排序聚合，cpu 在計算的時候所有的 io 操作都是阻塞的。

memecached 先申請一塊記憶體，將其分割成大小不等的若干記憶體塊以儲存不同大小的鍵值對。這種方式效率高但是可能產生空間浪費。而 redis 只是單純的包裝了下 malloc 和 free。

redis 提供了兩種方式持久化資料，一種方式是把某一時刻所有的資料都寫入磁碟，另外一種方式通過增量日誌的形式

memecache 提供了 cas 來保證資料一致性；redis 提供了事務，將一連串指令一起執行或者回滾。

memechache 只能通過一致性雜湊來進行叢集，而 redis 提供了叢集功能，客戶端做路由選擇那個 master 節點，master 節點可以有多個 slave 節點做為備用和讀。

redis 中的字串沒有采用 c 語言裡的結構，額外加上了空閒記憶體和已佔用記憶體，這樣讀取的時候由於已經知道 char 陣列大小，所以可以直接取出，避免遍歷操作，當字串變大或縮小的時候可以避免重新分配記憶體，可以用到空閒空間，也就是 redis 會預分配一個空間。

另外 redis 裡的雜湊，用了兩個 table 儲存，主要為了擴容，也就是 rehash，這樣當擴容的時候雙方就可以互換，redis 採用漸近式擴容，也就是每一次操作都執行兩個雜湊表，當新增的時候只在新表。set 資料結構可以用來儲存總的點贊次數，而 zset 是一個有序連結串列，為了加快查詢用跳錶進行儲存。

• 如何防止快取雪崩：快取要高可用，可以設定多級快取；
• 如何預防快取穿透：設定不同的失效時間。

訊息佇列

如何保證訊息的順序

嚴格的一致，只能一個生產者，傳送到一個 broker 上，然後只有一個佇列一個消費者，但是這種模式有很多弊端，一個地方異常將阻塞整個流程，RocketMQ 將這個問題交給應用層處理，也就是傳送端自己選擇傳送到哪個佇列，例如同一個訂單的訊息傳送到同一個佇列。但是演算法在其中一個佇列異常的時候也會有問題。

如何保證訊息不重複

只要網路上傳輸肯定會有這種問題，所以應用層最好能夠支援冪等，或者用一張去重表儲存每一個處理過的訊息 ID。

傳送訊息流程

• 先獲取 topic 對應的路由資訊（路由資訊會從 namesrv 返回，在客戶端快取，返回這個 topic 對應哪幾個 broker 以及每個 broker 上有多少個佇列）；
• 如果沒有獲取到，可能沒有 topic，需要自動建立，自動建立是客戶端發資訊個 namesrv,namesrv在去請求 broker，broker 建立好後返回
• 根據路由策略獲取一個 queue（從所有的 queue 中根據對應的路由策略獲取 queue，然後再判斷這個 queue 對應的 broker 是否健康，健康就返回），這個地方就可以做到 broker 的高可用；
• 所以我們發現訊息是發給哪個 broker 的哪個 queue 是在客戶端傳送的時候決定的，不是在生成 commitlog 之後再派發的，這樣我們就可以指定都到某一個固定 queue 了；
• 訊息傳送的時候會構建傳送請求，裡面包含了訊息體、佇列資訊和 topic 資訊等，訊息體裡面會增加一個訊息ID；
• 如果訊息重試多次後還是失敗就會進入死信佇列，一個固定的 topic。

訊息儲存

每個 commitlog 大小為 1G，第二個檔案的起始偏移量就是 1G 的 byte 大小，當根據一個偏移量獲取對應某個檔案的時候，根據偏移量對 1G 取餘就可以，這些 commitlog 檔案通過一個檔案佇列維護，每次寫檔案返回佇列的最後一個檔案，然後需要加鎖。

建立完檔案後會進行預熱，預熱的時候會在每一個記憶體頁 4kb 裡面寫一個 byte0，讓系統對快取頁快取，防止真正寫入的時候發生缺頁，mmap 的機制是隻會記錄一個虛擬地址，當缺頁時才會去獲取實體記憶體的地址。

建立檔案有兩種方式：

• 一種是 FileChannel.map 獲取 MappedByteBuffer；
• 另外一種是使用堆外記憶體池，然後 flush。

訊息的消費

一個佇列只能被一個客戶端消費。

當存在多個佇列，但只有一個客戶端的時候，這個客戶端需要去 4 個佇列上消費，當只有一個佇列的時候只會有一個客戶端可以收到訊息，所以一般情況下需要客戶端數量和佇列數量一致，客戶端一般會儲存每個佇列消費的位置，因為這個佇列只會有一個客戶端消費，所以這個客戶端每次消費都會記錄下佇列的 offset,broker 端，也會記錄同一個 grouo 消費的 offset。

MappedByteBuffer 的原理是老的 read 是先將資料從檔案系統讀取到作業系統核心快取，然後再將資料拷貝到使用者態的記憶體供應用使用，而使用 mmap 可以將檔案的資料或者某一段資料對映到虛擬記憶體，這個時候並沒有進行資料讀取，當使用者訪問虛擬記憶體的地址的時候會觸發缺頁異常，這個時候會從底層檔案系統直接將資料讀取到使用者態記憶體。

而 MappedByteBuffer 通過 FileChannel 的 map 方法進行對映的時候會返回一個虛擬地址，MappedByteBuffer就是通過這個虛擬地址配合 UnSafe 獲取位元組資料。

作業系統在觸發缺頁異常的時候會去檔案系統讀取資料載入到記憶體，這個時候一般會進行預讀取，一般為 4KB，當系統下次訪問資料的時候就不會發生缺頁異常，因為資料已經在記憶體裡了，為了讓 MappedByteBuffer 讀取檔案的速度更高，我們可以對 MappedByteBuffer 所對映的檔案進行預熱，例如將每個 pagecache 寫一個資料，這樣在真正寫資料的時候就不會發生缺頁了。

分庫分表

一般三種方式：在 dao 層和 orm 層利用 mybatis 攔截器，基於 jdbc 層進行攔截重寫 JDBC 介面做增強，基於資料庫代理。

jdbc 代理，實現 datasource,connection,preparestatement,druid 解析 sql,生成執行計劃，利用 resultset 對結果集進行合併（group by order max sum）。

分表策略，一般是雜湊，要保證分庫和分表的演算法完全沒有關聯，不然會資料分佈不均勻。

資料擴容的時候可以通過配置中心動態的修改寫入策略，如何一開始可以先讀老表，資料同時寫入新表和老表，等資料遷移完成後，在讀新表並雙寫，之後在讀新表寫新表。

唯一 id

資料庫自增 id，一次取多個，單機限制，另外資料庫自增 id 內部也用了個鎖，只是在 sql 執行結束即使事務沒提交也會釋放鎖。

雪花演算法變種 ： 15 位時間戳，4 位自增序列，2 位區分訂單型別，7 位機器ID，2 位分庫字尾，2 位分表字尾，共 32 位。

利用 zookeeper 的順序節點獲取自增 ID。

分散式事務

兩階段提交：事務管理器，資源管理器，一階段準備，二階段提交 （XA 方案對業務無侵入，由資料庫廠商提供支援,但是效能很差）。

事物補償

TCC ：也是兩階段，第一階段嘗試鎖定資源，第二階段確認或者回滾。

設計規範：

• 業務操作分成兩部，例如轉賬：嘗試階段為凍結餘額，第二階段提交為從凍結餘額扣款，回滾為解凍；
• 事務協調器記錄主事務日誌和分支事務日誌，支援在任意一步發生異常後進行補償或者逆向補償保證最終一致性；
• 併發控制，降低鎖的粒度提高併發，保證兩個事務間不需要加排他鎖，例如熱點賬戶的轉賬操作，由於第一階段進行了凍結，所以後面的扣減餘額不同事務之間沒有影響；
• 允許空回滾：可能一階段的嘗試操作發生超時，然後二階段發起回滾，回滾的時候要判斷一階段是否進行過操作，如果一階段沒有收到請求，回滾操作直接返回成功；
• 避免一階段操作懸掛：可能一階段超時，二階段回滾後，一階段的請求到達，這時候要拒絕一階段的嘗試操作；
• 冪等控制，由於第一階段和第二階段的操作可能都會執行多次，另外操作介面最好能提供狀態查詢介面供後臺的補償任務正常執行。

框架事務（seata）

• 一階段：框架會攔截業務 sql,根據語句執行前結果生成 undolog , 根據語句執行後對結果生成 redolog , 根據資料庫表名加主鍵生成行鎖；
• 二階段：如果事務正常結束，將刪除 undolog redolog 行鎖，如果事務將回滾，則執行 undolog sql , 刪除中間資料，在執行 undolog 的時候會校驗髒寫，也就是有沒有其他事務已經修改了這行記錄，就用 redolog 做對比，如果出現髒寫只能人工修資料 （二階段的清理工作可以非同步執行）。

開啟事務的時候會向 tc 申請一個全域性的事務 id，這個事務 id 會通過 rpc 框架的攔截器傳入到被呼叫端，然後放入 threadlocal，被呼叫方在執行 sql 的時候會去檢查一下是否在一個全域性事務裡。

預設的隔離級別為讀未提交，因為事務一階段已經本地事務提交而全域性事務並沒有完成，後續可能會回滾，其他事務可以看到這個狀態，提供的讀已提交的方式是通過 for update，當解析到該語句的時候會檢查是否存在行鎖衝突，如果存在衝突就等待直到釋放。

• tm 向 tc 發起開啟一個全域性事務，生成一個全域性唯一的 xid；
• xid 在微服務呼叫鏈上進行傳遞；
• rm 向 tc 註冊分支事務；
• tm 向 tc 發起全域性提交或者回滾決議；
• tc 向 rm 發起回滾或提交請求。

一致性訊息佇列:先傳送半訊息，如果成功了在執行本地事務，本地事務成功就提交半訊息，本地事務失敗就回滾半訊息，如果訊息佇列長期沒有收到確認或者回滾可以反查本地事務的狀態，消費端收到訊息後，執行消費端業務，如果執行失敗可以重新獲取，執行成功傳送消費成功的確認。

MYCAT

CAP

• C：一致性
• A：可用性
• P：分割槽容忍性

可以簡單地這樣理解：MySQL 單機是C；主從同步複製 CP；主從非同步複製 AP。

Zookeeper 選擇了 P，但是既沒有實現 C，也沒有實現 A，而是選擇最終一致性。可以在多個節點上讀取，但是隻允許一個節點接受寫請求，其他節點接收的寫請求會轉發給主節點，只要過半節點返回成功就會提交。

如果一個客戶端連線的正好是沒有被提交的 follower 節點，那麼這個節點上讀取到的資料就是舊的，這樣就出現了資料的不一致，所以沒有完全實現 C。由於需要過半節點返回成功才提交，如果超過半數返回失敗或者不返回，那麼 zookeeper 將出現不可用，所以也沒有完全實現 A。

當然衡量一個系統是 CP 還是 AP，可以根據它犧牲 A 更多還是犧牲 C 更多，而 ZK 其實就是犧牲了 A 來滿足 C，當超過叢集半數的節點當機後，系統將不可用，這也是不建議使用 zk 做註冊中心的原因。

CAP 理論只是描述了在分散式環境中一致性、可用性、分割槽容忍不能同時滿足，並沒有讓我們一定要三選二，由於網路分割槽在分散式環境下是不可避免的，所以為了追求高可用，往往我們會犧牲強一執行，採用弱一致性和最終一致性的方案，也就是著名的 BASE 理論，而 base 理論其實是針對傳統關係型資料的 ACID 而言的。

但 ACID 的提出是基於單節點下的，在分散式環境下，如何協調資料一致性，也就是在資料的隔離級別上做出取捨，即使是單機的關係型資料庫為了提高效能，也就是可用性，定義了隔離級別，去打破 ACID 裡面的強一致性 C，當然資料庫也是為業務服務的，某些業務或者說大部分業務都沒有強一致性的需求。

秒殺的處理

• 動靜分離：ajax 不重新整理頁面，快取，cdn；
• 發現熱點資料：業務流程上變通讓熱點業務隔離出來，也通過鏈路監控獲取一段時間的熱點資料；
• 隔離：業務隔離，資料庫隔離；
• 兜底方案：服務降級，限流；
• 流量削峰：排隊，過濾無效請求，答題或者驗證碼，訊息佇列；
• 減庫存：（下單減庫存使用者不付款需要回滾，付款減庫存最終可能庫存不足需要退款，下單後佔庫存一段時間後在回滾）。

正常電商採用第三種，秒殺採用第一種，不超賣的控制不用放在應用層，直接在 sql 層加 where 語句進行判斷，但是 mysql 針對同一行記錄也就是同一個商品的減庫存，肯定會高併發下爭取行鎖，這將導致資料庫的 tps 下降（死鎖檢測會遍歷所有需要等待鎖的連線，這個操作非常耗 cpu），從而影響其他商品的銷售，所以我們可以將請求在應用層進行排隊，如果份額較少可以直接捨棄，另一種方案是在資料庫層排隊，這種方案需要採用 mysql 的補丁。

docker

namespace

docker 在建立容器程式的時候可以指定一組 namespace 引數，這樣容器就只能看到當前 namespace 所限定的資源、檔案、裝置、網路、使用者、配置資訊，而對於宿主機和其他不相關的程式就看不到了，PID namespace 讓程式只看到當前 namespace 內的程式，Mount namespace 讓程式只看到當前 namespace 內的掛載點資訊，Network namespace 讓程式只看到當前 namespace 內的網路卡和配置資訊，

cgroup

全名 linux control group，用來限制一個程式組能夠使用的資源上限，如 CPU、記憶體、網路等，另外 Cgroup 還能夠對程式設定優先順序和將程式掛起和恢復，cgroup 對使用者暴露的介面是一個檔案系統，/sys/fs/cgroup 下這個目錄下面有 cpuset,memery 等檔案，每一個可以被管理的資源都會有一個檔案，如何對一個程式設定資源訪問上限呢？

在 /sys/fs/cgroup 目錄下新建一個資料夾，系統會預設建立上面一系列檔案，然後 docker 容器啟動後，將程式 ID 寫入 taskid 檔案中，在根據 docker 啟動時候傳人的引數修改對應的資原始檔。

chroot

通過 chroot 來更改 change root file system 更改程式的根目錄到掛載的位置，一般會通過 chroot 掛載一個完整的 linux 的檔案系統，但是不包括 linux 核心，這樣當我們交付一個 docker 映象的時候，不僅包含需要執行的程式還包括這個程式依賴執行的這個環境，因為我們打包了整個依賴的 linux 檔案系統，對一個應用來說，作業系統才是它所依賴的最完整的依賴庫。

增量層

docker 在映象的設計中引入層的概念，也就是使用者在製作 docker 映象中的每一次修改，都是在原來的 rootfs 上新增一層 roofs，之後通過一種聯合檔案系統 union fs 的技術進行合併，合併的過程中如果兩個 rootfs 中有相同的檔案，則會用最外層的檔案覆蓋原來的檔案來進行去重操作。

舉個例子，我們從映象中心 pull 一個 mysql 的映象到本地，當我們通過這個映象建立一個容器的時候，就在這個映象原有的層上新加了一個增 roofs，這個檔案系統只保留增量修改，包括檔案的新增刪除、修改，這個增量層會藉助 union fs 和原有層一起掛載到同一個目錄，這個增加的層可以讀寫，原有的其他層只能讀，於是就保證了所有對 docker 映象的操作都是增量。

之後使用者可以 commit 這個映象將對該映象的修改生成一個新的映象，新的映象就包含了原有的層和新增的層，只有最原始的層才是一個完整的 linux fs, 那麼既然只讀層不允許修改，我怎麼刪除只讀層的檔案呢？這時只需要在讀寫層（也就是最外層），生成一個 whiteout 檔案來遮擋原來的檔案就可以了。

釋出與部署

目前的大部分公司採用下面的部署方式。

• 建立 pileline 指定專案名稱和對應的 tag，以及依賴工程。一個 pipeline 指一個完整的專案生命週期(開發提交程式碼到程式碼倉庫、打包、部署到開發環境、自動化測試、部署到測試環境、部署到生產環境)；
• 根據專案名稱和 tag 去 gitlab 上拉取最新的程式碼(利用 java 裡的 Runtime 執行 shell 指令碼)；
• 利用 maven 進行打包，這個時候可以為 maven 建立一個單獨的 workspace (shell 指令碼)；
• 根據預先寫好的 docfile，拷貝 maven 打的包生成映象，並上傳映象 (shell 指令碼)；
• 通過 K8s 的 api 在測試環境釋出升級；
• 通過灰度等方案發布到生產環境。
  -
  

阿里雲-雲原生應用平臺-基礎軟體中臺團隊（原容器平臺基礎軟體團隊）招聘高階工程師/技術專家/高階技術專家

TL;DR

阿里雲 - 雲原生應用平臺 - 基礎軟體中臺團隊（原容器平臺基礎軟體團隊）誠邀 Kubernetes/容器/ Serverless/應用交付技術領域專家（ P6-P8 ）加盟。

工作年限：建議 P6-7 三年起，P8 五年起，具體看實際能力。
工作地點：

• 國內：北京，杭州，深圳；
• 海外：舊金山灣區、西雅圖

簡歷立刻回覆，2~3 周出結果。節後入職。

工作內容

基礎產品事業部是阿里雲智慧事業群的核心研發部門，負責計算、儲存、網路、安全、中介軟體、系統軟體等研發。而云原生應用平臺基礎軟體終態團隊致力於打造穩定、標準、先進的雲原生應用系統平臺，推動行業面向雲原生技術升級與革命。

在這裡，既有 CNCF TOC 和 SIG 聯席主席，也有 etcd 創始人、K8s Operator 創始人與 Kubernetes 核心維護成員組成的、國內最頂尖的 Kubernetes 技術團隊。

在這裡，你將同來自全球的雲原生技術領域專家們（如 Helm 專案的創始人、Istio 專案的創始人）密切合作，在獨一無二的場景與規模中從事 Kubernetes、Service Mesh、Serverless、Open Application Model （ OAM ）等雲端計算生態核心技術的研發與落地工作，在業界標杆級的平臺上，既賦能阿里巴巴全球經濟體，更服務全世界的開發者使用者。

1. 以 Kubernetes 為核心，推動並打造下一代 "以應用為中心" 的基礎技術體系；在阿里經濟體場景中，研發和落地“以應用為中心”的基礎設施架構和基於 Open Application Model （ OAM ）的下一代 NoOps 體系，讓 Kubernetes 與雲原生技術棧發揮出真正的價值和能量；

1. 研發多環境複雜應用交付核心技術；結合阿里與生態中的核心業務場景，打造多環境複雜應用交付的業界標準與核心依賴（對標 Google Cloud Anthos 和 Microsoft Azure Arc ）；

1. 雲原生應用平臺核心產品及後端架構設計與開發工作；在生態核心技術與前沿架構的加持下，在世界級雲廠商的平臺場景中，用技術打造持續的雲產品生命力與競爭力；

1. 持續推動阿里經濟體應用平臺架構演進，包括 Serverless 基礎設施、標準雲原生標準 PaaS 構建、新一代應用交付體系構建等核心技術工作。

技術要求：Go/Rust/Java/C++，Linux，分散式系統

簡歷提交

lei.zhang AT alibaba-inc.com