微服務如何落地

爲何要微服務化？

在決定推進項技術升級以前，我習慣先問問本身爲何要作，譬如收益和付出是什麼，若是沒有想清楚，寧願不作。

微服務也不例外，咱們不能盲目跟風，必定要結合本身的實際，慎重地決定是否須要微服務化。

網上關於微服務好處的介紹有不少，這裏我想特別強調的是，從「人」的角度講，微服務帶來的優點和挑戰。

微服務架構下，每一個服務的複雜度大幅降低，從而維護成本也大幅下降。對於團隊來講，新人也能夠更快地上手項目，貢獻代碼。交接項目也變得更加容易。

單一服務架構下，隨着時間的推移，項目的複雜度必然愈來愈高，相關人員也會愈來愈多，從而代碼的合併頻率會逐漸降低，權限愈來愈難以分配，須要愈來愈重的測試，部署也愈來愈複雜，頻率愈來愈低。

然而微服務也會帶來不少問題，例如若是設計不合理，總體的複雜度會提升。寫代碼的時候須要考慮調用失敗的狀況，須要考慮分佈式的事務（固然不少時候是設計不合理致使的），從而對人提出了更高的要求。

總之，微服務帶來了不少優點，同時也帶來了不少挑戰，咱們須要認真的審視本身，這些優點對當下的咱們是不是優點，這些挑戰對當下的咱們是否能hold住。

關鍵問題一：如何劃分微服務

這裏有幾點心得：

• 區分邊界服務和內部服務。所謂邊界服務就是會接受公網流量的服務，好比處理 HTTP 請求的服務，反之就是內部服務。邊界服務和內部服務在安全方面的考慮是不同的(例如邊界服務須要作針對User的鑑權等等)
• 區分基礎和業務服務。業務服務追求變化，feature，基礎服務追求穩定，性能。
• 微服務的調用，必定要考慮調用會失敗。
• 沒有把握的作到合理拆分的時候能夠選擇先不拆，等到發現瓶頸了天然就知道怎麼拆了

關鍵問題二：微服務和 DevOps

微服務除了是個技術活，更是個管理活。咱們得有和微服務相融的團隊組織方式和工做流程。

• 要有架構組，架構組要負責微服務的基礎設施的建設，例如 CI/CD系統， Kubernetes 集羣，Service Mesh 集羣，監控報警系統，日誌手機系統，基礎的工具和庫的構建和維護。
• 每一個微服務要有固定的團隊負責(實踐中，能夠是對微服務分組，每組微服務對應一組特定的人)。每一個團隊都要有人負責 DevOps 全套流程，包括 CI/CD 的使用，Kubernetes yaml 的維護，組內權限的分配，監控報警的響應等等。每一個團隊都對本身負責的微服務全權負責(從開發，到上線，到維護，到調優)。

在扇貝，咱們就對微服務根據其業務特性，技術特性作了一些分組，每組微服務對應 2-3 人的 DevOps 團隊，每一個團隊實現本身的 DevOps 流程(架構團隊提供流程模板)。

每一個團隊使用 GitLab CI 來實現 CI/CD：提交PR開始跑測試，測試經過進入代碼Review，Review經過合併進主分支，開始自動構建 Docker Image，而後依次部署到 集成測試，預發佈，生產環境。

每一個團隊均可以在監控報警系統中看到本身負責的項目的運行數據，甚至自定義監控數據和報警指標，當數據發生異常，本身會收到報警，而後去處理。

不一樣的微服務團隊相互獨立，經過gRPC 和 Celery 實現數據交換。

最後給你們推薦下微服務全家桶，做爲一個Check List，上微服務的同窗能夠勾一勾

• [ ] DevOps(CI/CD)
• [ ] Container(Docker)
• [ ] Kubernetes
• [ ] Service Mesh

---

歡迎關注咱們的知乎專欄