微服務如何落地

04-26

為什麼要微服務化？

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

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

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

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

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

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

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

這裡有幾點心得：

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

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

要有架構組，架構組要負責微服務的基礎設施的建設，例如 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，上微服務的同學可以勾一勾