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

超哥是來自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/20...