微服務和SOA有什麼區別？

SOA如果理解稱為一種風格（面向服務）架構風格。那麼微服務也是遵從這種風格。

而另一種理解就是IBM，SAP，DELL搞得SOA解決方案。比如ESB（企業服務匯流排），所有的服務通過企業服務匯流排來進行組織互動，比如一個事務通過好幾個服務進行互動，那麼就需要在ESB中註冊WS-事務，ESB負責事務服務的編排和協議轉換。

而微服務則是更去中心化的SOA，所有服務的所有環節，這裡說的所有環節包括協議，業務，DB，都各自管理各自的了。每個服務各自負責各自的，關起門來自己玩，但是這樣的話，服務的治理，服務的發現等周邊工作就變得非常重要了。微服務的架構可以看成是康威定律的技術基礎。

康威定律，設計系統的組織，其產生的設計等同於組織之內、組織之間的溝通結構。換句話說，團隊的組織方式必然會對它產生的程式碼有影響。隨著時間的推移，架構也會影響到團隊的協作的好壞。當團隊瓦解時，程式碼的互動就很糟糕。當團隊協作時，架構就會整合的很好。

＝＝＝＝＝＝＝＝＝＝＝

服務網格和微服務有什麼區別？

服務網格的職責，即處理服務間通訊，這正是服務治理的核心所在。邊車模式是服務網格獨創的，每一個服務例項，服務網格都會在同一個主機上面一對一部署一個邊車程序，接管這個服務例項所有對外的網路通訊。具體的服務不需要複雜對外如何提供服務，只需要關注業務，返回哪些資料。對於具體的服務互動和通訊都是通過網格服務來完成。

＝＝＝＝＝＝＝＝＝＝＝

微服務架構下的事務處理？

微服務架構下的事務就是分散式事務，儘量避免，如果避免不了，根據CAP理論“最終一致性”處理，如果處理了一些事務，還有可能出現數據錯誤，通過日誌來找回資料，保證事務。

兩階段提交意思分為準備階段和提交階段，有一個事務協調者，給每個參與者傳送準備訊息，每個參與者在本地執行事務，但是不提交，或者傳送失敗的訊息。當事務協調者收到失敗訊息，直接給每個傳送者傳送回滾訊息，否則傳送commit訊息。

支付寶在分散式事務中設計了一套分散式事務框架，確保最終一致性。一個事務由一個主事務和多個從事務組成，主事務負責發起並完成整個業務活動。

＝＝＝＝＝＝＝＝＝＝＝

如何看待12306技術？

12306是一種動態庫存的概念，它比淘寶更復雜，一個商品被買了之後，可能去掉了另外幾個商品。

首先我們可以看看12306有哪些問題，首先是資料部署，大部分資料都部署在鐵路的內部專網，而且票務資料都留在各個鐵路局。所以早期的餘票查詢都會通過專有網路去各個鐵路局查詢，基本上把所有鐵路局的票放在一個大池子裡面，這個就是第一步要做的。

讀寫分離，買票其實很簡單，但是讀票就很難，把讀票和寫票進行分離，這個是非常有必要的。讀票分離之後，可以使用雲端的服務進行讀票的操作，利用雲的資源，比如CPU，記憶體等。現在已經是這麼做了，在14年的時候。查票基本佔網站流量90%以上。

前端優化加速。把所有的HTML，CSS，等提前載入好在本地，甚至可以包括有哪些列車，等資訊。

多機房的容災，資料在中國鐵路總公司和研究院各有一套系統，作為安全備份。

頻寬需要不斷提升。網路購票的人越來越多。

＝＝＝＝＝＝＝＝＝＝＝＝

談談淘寶的雙11？

阿里的技術每年都會經歷雙十一的考驗，也是一次對所有部門所有升級技術的考試。

比如2017年，阿里提到的混部技術，將離線任務（伏羲），和線上實時業務（Pouch容器化改造）通過排程技術進行有機融合起來。將所有機器的利用率得到很高的提升。

比如2015年完成的異地多活技術，阿里也花費了3年時間搭建完成。之前淘寶還是使用業界比較流行的兩地三中心的災備方案。兩地三中心的災備方案就是第一個做了同城的雙活，第二個做了異地的冷備。同城雙活是實時在使用接收的，異地冷備是用來備份資料的。但是有幾個問題，1 如果這個地方有災難了，那麼異地的要啟動服務是很不靠譜的。2 異地冷備是非同步的，延遲比較大 3 寫必然是單點寫，在寫操作高的情況下有可能有問題。4 資源浪費，異地冷備的方案平時沒有怎麼使用。

異地多活，在多個地域都有資料中心，切所有資料中心都承擔讀寫流量，並且寫並不是集中到一個點，任意一個數據中心出問題，其他中心都可以分鐘級別接管使用者流量。其中資料同步是很大的問題，阿里開發了自己的分散式資料同步系統otter。在2015雙十一，所有資料同步基本控制在1s以內。

虛擬化，阿里的linux核心是自己開發的，他們的虛擬化技術是基於docker開發優化的AliDocker技術。他們不僅把基礎組建固化在Docker中，也推動把技術業務都固化到docker中，最終電商的所有核心應用都在docker中有多應用了。2017年雙十一，幾十萬臺Docker容器支撐起了交易17.5萬每筆的峰值。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝

高併發時候的限流策略？

服務介面的流量控制策略：分流、降級、限流等

限流是下限策略，降低了服務介面的訪問頻率和併發量，換取服務介面和業務應用系統的高可用。

nginx限流，

在upstream的時候限流
也可以對一個ip連線數做限流
也可以限制每個ip每秒能請求多少次？

＝＝＝＝＝＝＝＝＝＝＝＝＝＝

高併發時候的降級策略？

降級有分為幾種降級策略

一般來說讀操作有很多降級的空間。比如我們最常用的是多級快取模式。使用多級快取來存放服務資料。當後端服務有問題，我們可以降級為只讀快取。
還有爬蟲降級，我們可以在降級的時候拒絕一些網際網路爬蟲之類的請求抓取。
動態頁面和靜態頁面的互相降級，頁面原先需要經過動態介面請求的，降級的時候變為獲取靜態頁面。原先是靜態頁面返回的，可以通過動態頁面進行返回。

寫操作我們其實也能降級。比如降級的時候我們使用快取寫，來讓寫操作統一寫入到快取中，最終使用非同步同步的方式來進行同步，保證資料一致性。

降級開關的自動開關。首先並不是開關自動一定是好的，一般會設定自動和手動的。然後自動開關根據系統負載，資源使用情況，SLA等指標進行降級。

=====================

聊聊全鏈路壓測？

在阿里2013年之前的壓測都是拿線上的流量，做流量回放，流量錄製等，對一臺機器進行壓力測試，獲取單臺機器的服務能力。但是這種情況和實際請求並不符合，單個系統ready並不代表了全域性ready, 究其原因是由於系統之間的相互依賴和相互關聯互相影響。所以獲取單機的能力值是偏向樂觀的。同時測試資源全部都集中在一些核心環節上，一些分散的業務並沒有得到很好的壓力測試。

阿里在2013年就開始研發核武器，全鏈路壓測。全鏈路壓測是使用不影響線上業務，但是資料與流量與線上業務隔離的生產環境。壓測的基礎資料，包括，壓測使用者，商鋪，商品等基礎資料。壓測會根據不同場景，測試不同的壓測量。

阿里最新的資料是全年，所有業務線自己的壓測會達到10000+次，公司級別的大促業務壓測能達到10+次。全鏈路壓測已經是大促穩定性最重要的核武器了。