微服務如何落地

為什麼要微服務化?

在決定推動項技術升級之前,我習慣先問問自己為什麼要做,譬如收益和付出是什麼,如果沒有想清楚,寧願不做。

微服務也不例外,我們不能盲目跟風,一定要結合自己的實際,慎重地決定是否需要微服務化。

網上關於微服務好處的介紹有很多,這裡我想特彆強調的是,從「人」的角度講,微服務帶來的優勢和挑戰。

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

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

然而微服務也會帶來很多問題,例如如果設計不合理,整體的複雜度會提高。寫代碼的時候需要考慮調用失敗的情況,需要考慮分散式的事務(當然很多時候是設計不合理導致的),從而對人提出了更高的要求。

總之,微服務帶來了很多優勢,同時也帶來了很多挑戰,我們需要認真的審視自己,這些優勢對當下的我們是否是優勢,這些挑戰對當下的我們是否能hold住。

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

這裡有幾點心得:

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

關鍵問題二:微服務和 DevOps

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

  • 要有架構組,架構組要負責微服務的基礎設施的建設,例如 CI/CD系統, Kubernetes 集群,Service Mesh 集群,監控報警系統,日誌收集系統,基礎的工具和庫的構建和維護。業務團隊(無論是寫基礎業務的還是其他業務的)能從架構組那裡得到一個穩定可靠的 PaaS以及一攬子配套工具
  • 每個微服務要有固定的團隊負責(實踐中,可以是對微服務分組,每組微服務對應一組特定的人)。每個團隊都要有人負責 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

推薦閱讀:

TAG:DevOps | 微服務架構 | 扇貝網 |