超哥是來自Amazon的頂級的架構師，經歷了Amazon整個向微服務架構遷移的過程，以及向serverless的演化過程，有著極其豐富的經驗，年過40，一直站在技術的最前沿，始終保持對技術的執著追求和熱情，是名副其實的技術大牛，能與之一起工作，榮幸之至！今天超哥給我們分享的主題《microservice & serverless》，是超哥實際工作經驗的一些分享，也為公司架構的演化提供了新的思路和指導。

microservice（微服務）這個可能是這些年最火的一種架構設計了，頻繁地出現在各種技術大會上，各大互聯網巨頭紛紛向這種架構演化，很多小的互聯網公司也往這些概念上去靠，大有一種不做微服務就要落伍的趨勢。事實上，很多對於微服務的理解比較粗淺，盲目的微服務化甚至會帶來更多的負面影響。

目前Amazon內部運行著超過2w過微服務，但是這些微服務並不是憑空產生的，在這之前，運行的服務都是超大的單體服務，但是隨著業務的發展，這種服務在整個研發的pipeline（設計→研發→編譯→測試→發布→部署→運維）中都出現了一些問題。設計階段，老的單體服務會給我們帶來一些技術限制，比如有些技術只有python語言的實現，但是我們的服務使用java開發，這樣我們不得不拿出一個更復雜的設計去解決類似的問題；研發階段，隨著開發人數越來越多，代碼沖突的問題越來越多，我們不得不花更多的時間去做這種無趣又沒有什麽意義的事情；編譯階段，越來越多的依賴很容易造成版本沖突，不同的版本也會引發兼容性的問題，而這種問題如果在運行時才暴露出來可能會造成嚴重業務影響；部署階段，很多的特性打包在一起發布，特性越多，出問題的概率也就越大；而最致命的是運維階段沒有回滾方案，一次上線中可能包含很多的特性，而其中任何一條特性的bug就需要回滾，然後可能有些特性需要變更數據格式，新特性能向前兼容老的數據格式，但是回滾後卻無法處理新的數據格式，因此無法回滾……就是在這樣的背景下，Amazon開始朝微服務的架構演化。

微服務擺脫了單體服務技術的束縛，可以自由地根據業務的特點，選擇最適合的技術去實現自己的服務；將一個大的開發流程拆成了很多個小的獨立的開發流程，彼此之間不在相互依賴，大大縮短了項目周期；代碼沖突的問題也得到了很好的改善；每次發布的特性很少，每天都能發布，而且能做到快速回滾。真正做到，持續集成，持續交付，敏捷開發。

微服務架構同時也帶來了一些新的問題。相比與單體服務，微服務的架構數據的傳輸依賴於rpc的調用，這個調用會帶來一些額外的網絡耗時，這種耗時往往需要業務上面去考慮是否能容忍，這種rpc的調用收到網絡環境的影響，失敗是很正常事情，因此需要失敗重試機制，於是代碼裏面到處都充斥著失敗重試的冗余代碼，影響代碼的可讀性，更糟糕的是會有雪崩效應，當某個底層服務出現問題時，比如響應時間過長，或者無法訪問，這種影響會層層傳遞到上層，最終導致整個業務系統掛掉；在測試上面也會變得更加困難，之前都在一個實例裏面，現在一個服務依賴很多其他的微服務，測試的時候都需要去mock，日誌也會分布在不同的服務下面，問題排查比較困難；此外，數據分布在不同的微服務上，在數據一致性上也會有些問題。所以在進行微服務設計的時候也要特別註意這些額外的負面影響，封裝重試邏輯，引入熔斷和限流機制，統一的日誌收集方式。

serverless（無服務器）架構可能是為了讓devOps從繁復的運維工作中解放出來的全新架構，最大的特點是整個系統基於AWS提供的各種服務，能夠做到自動的拓展以及按流量計費，不再需要人力去維護，大大提高了效率，同時按真實流量的計費對成本也有可能會有優化。而Fass架構，把業務需求封裝在一個函數內部，開發人員只需要關註自己的業務邏輯，然後通過網頁提交就能完成上線。我在想，當這些技術真正成熟和普及的時候，可能每個普通人，隨便花點時間學點python，也能做出一個的服務，而那個時候，我的價值又是什麽！？

轉載請註明出處
本文鏈接：http://hatlonely.github.io/2018/01/12/《microservice & serverless》by蔡超的一點感想/

《microservice & serverless》by蔡超的一點感想