# Amazon 和 Alibaba 軟體架構和工程 - 陳皓 (左耳朵耗子)

{%hackmd j86FNbMoRoeN4Xn0pg5ofw %}

> 請從這裡開始

> 三高：高效能、高可用、高併發

因為在中國很多人，所以搶個火車票都可以把...搞當機。這麼多年來我就是來跟當機搏鬥的。

後來我為40家公司提供這樣的軟體服務。

## 大綱
* 公司發展階段
* 軟體開發的挑戰
* 典型軟件架構演進
* 阿里巴巴和亞馬遜架構
* 分布式軟件架構

一旦你的公司變大以後就比較麻煩，會先講公司發展階段。再來是軟件開發的挑戰....

#### 第一階段 從零到一
企業一般來說有三個時期，第一個時期是從零到一，想法實現，愛怎麼做就怎麼做，做出來，發佈，讓用戶看到，有 feedback，你用怎樣的技術都可以，你只有功能性開發，functional 開發。

#### 第二階段 從一到十
第一階段你用什麼樣的技術都可以，就是 function 的開發。但是第二個階段，你就會進入從1到10的階段，我叫做用戶用獲取其(用戶獲取期？)，你要增加用戶，你的挑戰是**性能**和**穩定性**。

十個技術人員都能開發 website，但不是每個人都能支持 1 million 的穩定性。你需要架構。

人不夠的時候你愛怎麼用就怎麼用，像個小村一樣。但人數過多，你需要紅綠燈，你需要這

#### 第三階段 業務擴展期
> 擴張到別人領域

最後是業務擴展期，你要競爭，除了性能和穩定性，你還需要軟體生產流水線，服務化，分布化的開發平台，去 build 你的生態系，甚至還有大數據的平台。這是一個非常複雜的團隊了，需要很多技術做支援。

> 這是我們公司三個階段，不同階段會有不同架構，後端看不同的東西。

軟體有兩種複雜度，一種是業務複雜度。舉個例子。如果隨便開發網頁很簡單，但跑不掉業務問題。

##### 業務複雜度
電子商務，買個東西，有營銷，買一送一，買一百送兩百，突然退貨了，錢怎麼算？業務邏輯決定了軟體的下限。業務複雜度不能用技術降低。

##### 控制複雜度
再來是控制複雜度，裡面有很多控制變量，要用面向對象，多線程、並行，我們叫做控制複雜度。控制複雜度決定了軟體複雜度的下限。

如果兩個混合在一起，就會快速加深。很多的軟體都是在解開控制與邏輯。

> 把控制與邏輯給解開 decoupling

還有業務迭代速度越來越快。現在中國加班已經很恐怖了，晚上 11 點以後大廈外面的出租車擠到不行，程序員去找工作，三年的工作經驗，他問說你不就兩年嗎？他說我加班了。（大家笑）

我們要加班，但忽略軟體架構...技術本來就是在提高效率。

軟體的品質越來越要求，一個故障，多少網站掛掉？這些都還好，但銀行如果系統掛掉怎麼辦？影響到經濟生活，造成社會損失...軟件挑戰就是這樣

#### 網站初始 -- all in one
* 經典的三層架構 (單機、全同步)
* MVC、ORM
* 經典實作：LAMP、RoR、Django、Spring/Hibernate

#### 應用服務告警

LB Server
2x Web Server
SQL Server

前端，應用邏輯層，可能是 MySQL，我們把他們一沱放在一起，開發很快，調適測試很快，但隨著用戶越來越多，就發現要把數據庫庫拿出去，就把數據庫分出去了，前面應用邏輯和前面在一塊。

前面又不夠了，我們拆成兩塊，就需要 DNS 或是 load balance，輪尋兩台服務器，到單一數據庫

#### 數據庫負載變大
> 最後的瓶頸都會落在資料庫 io 上


最後負載太大，我們就做讀寫分離，寫到一邊，讀到另外一邊。讀庫可以有很多個，CRUD，性能最糟糕的其實是 select，因為 select 會有大量 join，很浪費性能，讀寫分離可以讓select到另外一邊，寫不會影響，寫不會代組件，會很快。這可以支撐註冊用戶到百萬，要是 select 過慢，加上緩存，這可以支撐百萬級用戶。但是這樣的架構也很麻煩。

> 讀寫分離可以支撐百萬用戶

#### 持續水平擴展


> 數據庫按服務分離

最後就會到這裡，我們會分離出來，阿里巴巴就變成這樣，搶紅包搶到整體掛掉。因為交易庫共享一個數據庫，他被拖死，拖死就整個前端沒有響應。

要是不分開，可能一個不重要的業務，拖死重要的業務，所以要垂直拆分，**他要死死到那裡，跟我怎麼死無關**。

這是水平擴展，我們把用戶庫、商品庫、交易庫，這是簡單的，基本上是這樣演化。

### 阿里巴巴的架構演化

我們看阿里巴巴的。
阿里巴巴我講個故事，這不是我畫的，阿里巴巴員工畫的。

圖片待補...

阿里巴巴有個淘寶，突然要做天貓。天貓是繼承在淘寶上的。他不過是個頁面，頁面是天貓的樣子，有些天貓的業務邏輯，但本質上繼承在淘寶上。


突然天貓變大了，他需要更多業務邏輯，把淘寶擠到一邊。但是底層有共享的東西，就成立共享業務部，會有共享各種買家，營銷活動，支付，訂單，物流，有些異步異步系統。

但是共享業務部承載了大量的業務邏輯。**淘寶叫做購物車，天貓說白領不用購物車，叫做購物袋！** 這是需求衝突。他就在裡面很難實現。這邊要這個樣子，那邊要那個樣子，就變慢。天貓就說我自己來做，就被擠擠成這樣，剩下技術的東西，技術人員就崩潰了。

後面又在化，淘寶跟天貓被壓在中間。後來又有一個聚划算，淘寶跟天貓的團購，他從淘寶和天貓抽數據出來，結果


能不能演變成這樣？經過很多這樣的摸爬滾打，阿里巴巴有各種架構實驗，神多了，神一多，公說公有理，婆說婆有理，屁股決定腦袋，開始說有利於自己的架構。

架構應該是怎樣？

最後有商品、品類價格這些共享業務，道具划算、淘寶、天貓、1688，還有BI...

演化就變成這樣

下面會有技術中間件，Big table，TFF，註冊中心，config server，業務中間件，打造成這樣。

> 基礎建設元件抽離

最終這個大中台，中間有個 PaaS，Application paas....業務邏輯全部在前台。

阿里巴巴有兩個原因。第一個，數據是未來，門店很多，收購公司多，優酷，視頻軟件也收購，都收購，要把數據打通，要有中台。在來要打的快，作戰怎麼作戰？要有中台火炮群，坦克飛機航母，我不管你地形怎樣，先炸一遍。

> 數據打通必須要有一個**中台**。

地面不斷適應地形，要有地面部隊去做本地訂製化，這是地面部隊。

後台不管前面怎麼弄，反正共享的東西就是這樣。這樣我重用的東西特別多，後面數據打的通，推進速度很快。這是阿里巴巴架構，他是為了要打仗、競爭，中台戰略是這樣。

## Amazon

### Amazon 的服務化「軍規」

所有團隊開發的程序模都要透過 service interface 將 data 與功能分開。

* 團隊間的程式模組訊息通信，都要透過這些接口
* 除了服務接口之外沒有其他通訊方式
* 任何技術都可以使用
* 所有的 Service Interface，毫無例外，都必須從骨子裡到表面上設計成對外開放的

除了 interface 之外，沒有其他方式，也不能到別人 db 中去 select。

亞馬遜有軍規，你都要通過 service interface 來處理，你不能去別人的數據庫select，不能用別的團隊的後門，只能用 service interface。所有的 service interface 毫無內外都要設計能對外公開。在亞馬遜很痛苦，做個內部系統也要有 service interface 給大家用。

這包括HTTP

> amazon 所有的 service 都要設計成以後是對外開放的

為什麼會這樣？因為 Bezos 覺得自己不是 Jobs，自己無法做好完美產品，所以交給大家做，我自己做好平台，平台要 API，微軟也是平台，亞馬遜的平台戰略，他要做基礎設施，你只要把貨放到我的倉庫，你就可以賣給全世界，他想做這件事，所以他盡可能開放 API。第一個開放的 API 就是 pricing，所以有自動化，別人自己來做定價系統。

亞馬遜有本書賣到 1000 美金。一個商戶他沒這本書，但他覺得有這本書可以讓他覺得專業。但是用戶下單怎麼辦？他就改成所有權往網站高 5%。另外一個商戶說，我有這本書，但我不想賣最便宜，就比最高價低 5%。動態標價，這兩個就開始一點一點下來，在過一陣子，這兩本書賣到了一千多萬美金。透過自動化可以做很多很好玩的東西。

這個平台戰略很誇張，20 年前就這樣了。

兩邊不一樣，阿里巴巴要營運，打仗，亞馬遜要做生態環境，做平台，讓別人做。他想要把零售部門...

#### 服務架構的演進

* Pre-SOA (單體應用)
* 高耦合
* 傳統 SOA
* 低耦合
* 微服務
* 解耦合

所以有三種。90 年代叫做單體應用，以前很好，都耦合在一起。2000 年有總線，所有的服務都要接上來，有人來調用它就動，所有服務都會連動總線。

但這就會聚眾無比。最後 2010 就會變成為服務。我們都會看很多，但我覺得亞馬遜 15 年前已經是為服務了。

#### Amazon 服務化架構


服務拆分後變成共享服務，有一個中心概念，但中間圍繞著其他服務。亞馬遜的地址服務，只是一個團隊在做，一個服務一個小團隊叫做 Two Pizza Team，這是全功能小團隊，需要全端 ops，他按 commitment 區分，團隊的 size 以兩張 pizza 能餵飽 (8人左右)

亞馬遜網站上選區域會估計時間，它會選一個地區，估計多少時間，這就是小服務，這就是 two pizza team 來做的。他們維護了一千多台機器，就是為了要算預估多長時間送到你那裡。

因為團隊很少，8 個人，最好什麼都能做，不分前後端，也不需要支持性的人，需要產出性的人。支持性的人就像是測試、PM、經理，更多要產出性的人。

團隊超過 10 個人每年要開調 10% 的人。

條件受限有什麼好處？要你做兩件事：簡化，簡化就要抓重點；再來是自動化。注意，簡化和自動化，創新來源就是這兩個。你們自己去思考一下，第一次工業革命、第二次工業革命，歷史上的工業革命，本質上就這兩個。

> 簡化、自動化
> 只有你條件受限才會這麼幹

在美國，人力成本很高，就自動化，中國人力成本低，就不會自動化，條件受限就會創新。

> **限制帶來創新**

我把關鍵技術跟大家講。

#### 亞馬遜的架構關鍵技術


亞馬遜有很多服務，下單，我需要調支付，需要後台倉庫，庫存，物流接口，亞馬遜超喜歡工作流服務編排引擎，多喜歡呢？喜歡到做出十幾個這樣的引擎。

他有個pub/sub服務消息總線，讓大家連動，有數據流，旁邊有數據倉庫，你丟訂單，進去看。

他非常高可用，他會是 event driven，喜歡拉系統，不是推系統，

架構特點：
* 高度可擴張
* 以事件基礎的架構
* 非同步通訊

### 亞馬遜的工程文化


* eat your dog food....
* 亞馬遜內部可以
* celebrate the simplification and automation

##### 三分文件規則
沒有做一個事情的時候先做三份文件，press release，USER manual，FAQ，不能超過三頁，不能用圖片。**你要是做的東西自己都搞不懂，怎麼讓用戶搞懂？**

為何要做新聞媒體搞？做的東西媒體不關心，怎麼辦？

##### 這邊是 AWS 的信條 Tenets

在雲上跟雲下一樣快

測兩次
防火勝於救火

太關注完美，我們應該先做好在迭代
先會走再會跑

之前有個用戶，亞馬遜有個功能沒有，Google有，亞馬遜要做。後來他們測了，發現慢了2ms，後來工程師說，我們發現雲上跟雲下一樣快，他們決定不做了，讓老大去做

### 軟體工程的
* 高可用的系統
* 自動化維護

什麼是SLA？多少個9，

> Simplified chart I'm using to explain the nines of availability. [Twitter](https://twitter.com/layer_3/status/1019398179215872000) [name=Christopher Church]

* 為了提高性能，我們有這些作法。
* 加暫存
* load balancer
* async
* db 鏡像
* db 區分

* 為了提高穩定性，有這些作法
* 拆分服務
* 服務冗餘
* 限流降級
* ha架構
* 高可用運維

雙11的時候，流量太多，就先弄掉中國西部，在來中國中部，最後中國東部，但保留北上廣，讓有錢人可以繼續用。

> 什麼城市我都可以不用管，就是要保留北京！


服務冗餘
load balance
服務發現
健康檢查
動態路由

服務解耦
sharding
異步通訊


分布式系統很難。紅色都是複雜度。
> 分佈式系統，最大的難度就是運維。

這是後端世界，給大家展示一下。

#### 微服務架構

* Configuration Management
* Service Discovery & Load Balancing
* Resilience & Fault Tolerance
* API Management & API Gateway
* Service Tracing Monitoring
* Centralized Metrics
* Centralized Logging
* Continuos Deployment
* Resource Scheduling
* Auto Scalling & Self Healing


藍色的是 spring cloud 可以支持的，綠色的是 Kubernates 可以支持的，剩下紅色是其他軟體可以支持的。

###### tags: `MW18`