引言：扇貝 2017 服務端技術回顧

隨著流量的提升，團隊的壯大，為了適應變化，2017年，我們的服務端進行了比較大的改造，全面擁抱了微服務，容器編排等。

從而很大程度上提高了開發效率，降低了維護成本。

這期間，我們碰到了很多難題，走了不少彎路，也積累了比較豐富的經驗。我們希望這些經驗和解決方案能夠給中小型的互聯網公司帶來啟發。

微服務

網上有很多微服務的科普和介紹，這裡從實踐角度講一點我們的心得：

1. 微服務的設計不光是技術問題，更是人的問題。理想的狀態是微服務都有對應的團隊持續開發，調優和維護。所以反過來講，團隊的規模和組織模式也會影響微服務的切分。
2. 微服務一定要有規劃，分層，分組。例如哪些是基礎型服務，哪些是業務型服務，哪些是邊界服務(直接接受公網流量的)，哪些是內部服務(不暴露在公網上)。
3. 微服務要採用 devops 模式，否則運維很可能成為瓶頸。每個微服務的技術團隊都要有從開發到部署到維護的所有許可權。
4. 微服務的服務治理非常重要，一定要捨得投入成本。包括：監控報警，日誌收集，服務發現，健康檢查，熔斷等等。

關於這些方面的具體實踐，我們後面的文章會再跟大家分享。

容器編排和 service mesh

關於容器編排，這兩年技術圈一直很火。很多公司都從傳統的運維架構遷到了基於容器編排技術的新架構上來。

在之前，出於團隊和技術的考慮，我們只是將服務的運行環境容器化(用docker來封裝運行環境)。

隨著 2017年 kubernetes 成為了容器編排領域的事實標準，我們也開始將微服務大規模遷移到 kubernetes 上。

除了 kubernetes 以外，還要解決的就是服務治理問題。

我們採用了 service mesh的方案。因為我們覺得一來實現了跨語言跨框架的通用服務治理方案，二來service mesh 是未來的趨勢。

當然由於目前的service mesh方案很多還不成熟，很多問題需要深入源碼甚至二次開發來解決。這些我們也會在後續的文章中給大家來慢慢分享我們的方案，以及開源一些我們用於生產環境的項目。

Open Source

我們是開源項目的受益者，所以我們也致力於力所能及之處，回饋一些能夠幫助到他人的開源項目。這些項目也許不成熟不完善，但是能解決階段性的問題。在扇貝，正是他們幫助我們的工程師構建起了支撐百萬級日活，十億級日請求量的產品。後面的文章里，我們會結合微服務，容器編排和service mesh給大家做詳細介紹。

作為引言，也是一個大綱。我們會不斷更新文中提到的內容，感謝關注扇貝技術團隊

推薦閱讀：