微服務拆分及上線中遇到的幾個問題

前言

本篇文章不介紹微服務的理論基本。主要圍繞以下幾點：
1.拆分前(公司項目的現有的結構以及為什么需要微服務)；
2.拆分中(拆分過程中的主要原則和相關技術支持)；
3.拆分后(服務上線過程中遇到的問題及解決方案)
4.完善中

正文

1.拆分前

公司項目是一個SAAS化的服務產品，為企業提供一些特定領域的解決方案由此收取一些報酬並盈利。
公司的組織架構是：總部是在南方，有好幾個研發部門，我所在的部門在蘇州。
痛點是整個項目共用一個git倉庫，發版和本地編譯及其痛苦，發版時如果在測試環境不及時測出問題，等到線上才發現的話，會會滾版本，會把別的部門的好的代碼也會滾掉。

2.拆分中

把代碼copy一份到新的git倉庫，然后刪減掉本服務無關的代碼，服務建通過grpc通信，就是這么簡單

2.1. grpc的一些默認值的問題，很坑

3.拆分后

3.1. 服務連接問題

測試環境發現服務上線下線的過程中，其他服務會連接不到，就一瞬間的事情。
我們目前的服務發現的架構是基於etcd來做的。每個服務會在啟動時連接並訂閱etcd的某個目錄，用來監聽其他服務的上下線，其他服務的ip/port等信息會保存到一個map中，rpc請求時會根據服務名從這個map中取到服務的具體信息，然后連接並通信。具體哪個環節出現問題的還不太清楚。
解決方案是走的k8s的服務發現。

3.2. 緩存問題

    緩存是基於redis的發布訂閱來做服務間的同步更新的。我們redis的架構采用的是哨兵主從的模式。
    發現有時(偶發)服務A改了某個東西后，服務B沒有及時更新到，懷疑是主從切換導致的問題，服務A刪除redis1（主）的緩存，結果redis1瞬間失效，redis2成為主，結果1的數據還沒有更新到2上來。然后服務B查redis，發現redis上的錯誤數據。
     解決方案是改成了rpc通信，不走緩存同步。

3.3. 上線時的k8s配的超時時間的問題

    運維先了解了我們本地啟動大概不到30s，所以他們在k8s中的健康檢查也配了40s左右。結果發現服務一直重啟，日志又沒有報錯。

運維找到開發說服務有問題，開發也定位不到問題，最后才排查出是健康檢查的問題。

3.4. 路由問題

    原來所有路由都是主服務A中，現在切出了服務B，部分路由需要跳到服務B，考慮到工作量的問題就簡單在nginx里配了一下路由規則，結果就來坑了。原來是服務A的某個接口路由到了服務B。
    解決方案是前端在服務B的接口前統一加/servieB/api/XXX。

3.5. 緩存臟數據問題

    今天剛發現的問題。。很尷尬。由於我們服務代碼是從主服務copy過來並進行相應的刪減的。。。。
    **共享內存問題**

4.完善中

第三小節只介紹了將某個業務模塊拆成一個微服務過程中出現的問題，
本節則主要關注於整個微服務環境治理中出現的問題及響應的解決方案。

總結

公司存在即意味着業務會一直拓展，意味着代碼會越來越龐大。其實我們公司以前的項目一定意義上也算是微服務，弊端在於一個倉庫要管理所有的服務代碼。
微服務拆分上線時最好能灰度發布，（價值小的用戶先上。。。），避免影響到所有用戶（充錢多的不能惹）。

還有很多別的問題，有空再更新。