ReactNative分佈式熱更新系統

時間 2019-11-07

原文原文鏈接

熱更新是一個很是方便的方案。在應對大量用戶和深度定製的時候必定不能使用開源的方案。通常第三方的這種方案，服務器帶寬較小，或者不夠靈活，不能知足本身的想法。這裏推薦本身實現對應的熱更新方案。只須要少許代碼便可支持。下面推薦一種靈活的熱更新方案。包括客戶端的改造、接口設計、界面開發，同時是開源的！能夠自由改造。java

體驗地址：demo 用戶名密碼都是：adminnode

基礎數據的準備和實現

首先第一點，一個APP若是要支持熱更新，須要在打開APP（或者其餘進入RN頁面以前）就要判斷是否須要更新bundle文件。這裏就是咱們實現熱更新的節點。一旦須要熱更新就開始下載文件，而判斷的接口就是咱們此次文章的核心內容。這裏簡單貼出安卓和ios兩端的下載邏輯。ios

請求以前須要在head中附帶上客戶端的幾個重要信息。客戶端版本號version、客戶端惟一id:clientid、客戶端類型platform、客戶端品牌brand。c++

ios下載的例子git

-(void)doCheckUpdate
{
  self.upView.viewButtonStart.hidden = YES;
  if ([XCUploadManager isFileExist:[XCUploadManager bundlePathUrl].path])
  {//沙盒裏已經有了下載好的jsbundle，以沙盒文件優先
    self.oldSign = [FileHash md5HashOfFileAtPath:[XCUploadManager bundlePathUrl].path];
  }else
  {//真機計算出的包內bundlemd5有變化，多是壓縮了，因此這裏寫死初始化的md5
    // NSString *ipPath = [[NSBundle mainBundle] pathForResource:@"main" ofType:@"jsbundle"];
    // self.oldSign = [FileHash md5HashOfFileAtPath:ipPath];
    self.oldSign = projectBundleMd5;
  }
  
  AFHTTPSessionManager *_sharedClient = [[AFHTTPSessionManager alloc] initWithBaseURL:[NSURL URLWithString:@"http://test.com"]];
  
  [self initAFNetClient:_sharedClient];

  [_sharedClient GET:@"api/check" parameters:nil progress:nil success:^(NSURLSessionDataTask * __unused task, id JSON) {
    NSDictionary *dic = [JSON valueForKeyPath:@"data"];
    BOOL isNeedLoadBundle = YES;
    if ([dic isKindOfClass:[NSDictionary class]])
    {
      self.updateSign = [dic stringForKey:@"sign"];
      self.downLoadUrl = [dic stringForKey:@"downloadUrl"];

      if(self.updateSign.length && self.oldSign.length && (![self.updateSign isEqualToString:self.oldSign]))
      {
        //須要更新bundle文件了
        self.upView.viewUpdate.hidden = NO;
        [self updateBundleNow];
        isNeedLoadBundle = NO;
      }else
      {
        //不須要更新bundle文件，再處理跳過按鈕顯示邏輯
        [self.upView showSkipButtonOrNot];
      }
    }
    if (isNeedLoadBundle) {
      [self loadBundle];
    }
  } failure:^(NSURLSessionDataTask *__unused task, NSError *error) {
    [self loadBundle];
  }];
}
複製代碼

安卓下載的例子github

private void requestData() {

        subscribe = DalingNetwork
                .getDalingApi()
                .getBundleVersion()
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new BaseSubscriber<BundleVersionResponse>() {
                    @Override
                    public void onError(Throwable e) {
                        startMainActivity();
                        e.printStackTrace();
                    }

                    @Override
                    public void onNext(final BundleVersionResponse response) {
                        isJSNeedUpdate = false;
                        if (response.status == 0) {
                            if (response.data != null) {
                                if (MainApplication.getApplication().getBundleMD5().equalsIgnoreCase(response.data.sign)) {
                                    //和本地版本相同，直接進入主頁
                                    isJSNeedUpdate = false;
                                    tv_skip.setVisibility(View.VISIBLE);
                                    startMainActivity();
                                } else {
                                    //下載升級
                                    isJSNeedUpdate = true;
                                    downloadSign = response.data.sign;
                                    downloadUrl = response.data.downloadUrl;
                                    downLoad(response.data.downloadUrl, response.data.sign);
                                }
                            }
                        } else {
                            startMainActivity();
                        }
                    }
                });
    }
複製代碼

系統設計方案

首先來看一下咱們是怎樣設計客戶端獲取更新邏輯的。 web

客戶端請求的時候會帶上版本號、平臺2個重要信息。
接口拿到請求以後查詢對應的本地緩存，沒有則去數據庫查詢。
從查詢結果中篩查對應的3段數據：白名單、灰度、全量，判斷順序從左到右。
返回查詢以後對應的結果。

數據庫等設計

上面的設計是基礎的邏輯，下面咱們繼續細化邏輯。其中爲了支持更好的性能和分佈式作了一些其餘的方案設計。redis

根據邏輯自行設計是徹底能夠的😁數據庫

數據庫設計

咱們選擇MySQL做爲基礎數據庫，負責存儲每次發佈以後的數據保存。後端

fe_bundle表存儲的是每次發佈的bundle信息，主要分3個部分：

表自己須要的數據。id、狀態、操做人、發佈說明。
判斷是否更新的依據字段。版本號、平臺、客戶端id、bundle的簽名、地址、壓縮包的地址。
做爲附加數據在接口返回的。標籤id、標籤內容。

fe_labels表就是做爲附加數據存儲的。若是想要在接口上返回一些複雜的操做，好比顯示隱藏某個界面、是否加載某個bundle、是否強制更新等，均可以在這裏設置。這個表自己只支持添加和是否啓用，不支持刪除，防止誤操做。

根據實際狀況減小字段的長度能夠優化數據庫的查詢性能。好比暱稱的長度不會超過10個字符。大量數據的狀況下添加索引也會提升數據庫性能。查詢的時候只查詢須要的字段也能夠減小查詢的時間。

發佈訂閱設計

使用發佈訂閱模式主要是爲了同步每次發佈的結果。這樣作能夠解耦發佈和本地緩存更新，多個服務器支持也不會出現資源爭奪或者更新不及時的狀況。

這裏使用的是redis的發佈訂閱模式，能夠選的其餘方案有MQ的消息隊列等方式。在收到消息的時候主動更新本地緩存。

本地緩存設計

接口響應速度快不快的關鍵就是在本地緩存這裏了。畢竟在用戶大量訪問的狀況下，一個數據庫是很是難支撐的。這裏利用本地緩存減小數據庫的查詢，不論是面對多少用戶，實際在工做的就只有接口所在的服務器線程。並且這裏利用了nodejs的高併發優點，只要機器抗的住，咱們的服務就不會卡頓或者掛掉。服務能支持的併發數幾乎等於機器支持的併發數。