史上最全的微服務知識科普

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

微服務

好處：實現跨團隊的解耦，實現更高的併發（目前單機只能實現 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