最全的微服務知識科普

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

微服務

好處：實作跨團隊的解耦，實作更高的并發（目前單機隻能實作 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 與雲原生技術棧發揮出真正的價值和能量；
2. 研發多環境複雜應用傳遞核心技術；結合阿裡與生态中的核心業務場景，打造多環境複雜應用傳遞的業界标準與核心依賴（對标 Google Cloud Anthos 和 Microsoft Azure Arc ）；
3. 雲原生應用平台核心産品及後端架構設計與開發工作；在生态核心技術與前沿架構的加持下，在世界級雲廠商的平台場景中，用技術打造持續的雲産品生命力與競争力；
4. 持續推動阿裡經濟體應用平台架構演進，包括 Serverless 基礎設施、标準雲原生标準 PaaS 建構、新一代應用傳遞體系建構等核心技術工作。

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

履歷送出

lei.zhang AT

alibaba-inc.com

“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”