為什麼要微服務化？
在決定推動項技術升級之前，我習慣先問問自己為什麼要做，譬如收益和付出是什麼，如果沒有想清楚，寧願不做。
微服務也不例外，我們不能盲目跟風，一定要結合自己的實際，慎重地決定是否需要微服務化。
網上關於微服務好處的介紹有很多，這裡我想特別強調的是，從“人”的角度講，微服務帶來的優勢和挑戰。
微服務架構下，每個服務的複雜度大幅下降，從而維護成本也大幅降低。對於團隊來說，新人也可以更快地上手專案，貢獻程式碼。交接專案也變得更加容易。
單一服務架構下，隨著時間的推移，專案的複雜度必然越來越高，相關人員也會越來越多，從而程式碼的合併頻率會逐漸下降，許可權越來越難以分配，需要越來越重的測試，部署也越來越複雜，頻率越來越低。
然而微服務也會帶來很多問題，例如如果設計不合理，整體的複雜度會提高。寫程式碼的時候需要考慮呼叫失敗的情況，需要考慮分散式的事務（當然很多時候是設計不合理導致的），從而對人提出了更高的要求。
總之，微服務帶來了很多優勢，同時也帶來了很多挑戰，我們需要認真的審視自己，這些優勢對當下的我們是否是優勢，這些挑戰對當下的我們是否能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
歡迎關注我們的知乎專欄