一 前期準備

1.1 前置條件

• 集群部署：Kubernetes集群部署參考003——019。
• glusterfs-Kubernetes部署：參考《附010.Kubernetes永久存儲之GlusterFS超融合部署》。

1.2 部署規劃

本實驗使用StatefulSet部署MongoDB集群，同時每個MongoDB實例使用glusterfs實現永久存儲。從而部署無單點故障、高可用、可動態擴展的MongoDB集群。

部署架構如下：

二 創建StatefulSet

2.1 創建storageclass存儲類型

  1 [root@k8smaster01 ~]# vi heketi-secret.yaml			#創建用於保存密碼的secret
  2 apiVersion: v1
  3 kind: Secret
  4 metadata:
  5   name: heketi-secret
  6   namespace: heketi
  7 data:
  8   # base64 encoded password. E.g.: echo -n "mypassword" | base64
  9   key: YWRtaW4xMjM=
 10 type: kubernetes.io/glusterfs

  1 [root@k8smaster01 heketi]# kubectl create -f heketi-secret.yaml	#創建heketi
  2 [root@k8smaster01 heketi]# kubectl get secrets -n heketi
  3 NAME                                 TYPE                                  DATA   AGE
  4 default-token-6n746                  kubernetes.io/service-account-token   3      144m
  5 heketi-config-secret                 Opaque                                3      142m
  6 heketi-secret                        kubernetes.io/glusterfs               1      3m1s
  7 heketi-service-account-token-ljlkb   kubernetes.io/service-account-token   3      143m
  8 [root@k8smaster01 ~]# mkdir mongo
  9 [root@k8smaster01 ~]# cd mongo

  1 [root@k8smaster01 heketi]# vi storageclass-fast.yaml
  2 apiVersion: storage.k8s.io/v1
  3 kind: StorageClass
  4 metadata:
  5   name: fast
  6 parameters:
  7   resturl: "http://10.254.82.26:8080"
  8   clusterid: "d96022e907f82045dcc426a752adc47c"
  9   restauthenabled: "true"
 10   restuser: "admin"
 11   secretName: "heketi-secret"
 12   secretNamespace: "default"
 13   volumetype: "replicate:3"
 14 provisioner: kubernetes.io/glusterfs
 15 reclaimPolicy: Delete

  1 [root@k8smaster01 heketi]# kubectl create -f storageclass-fast.yaml
  2 [root@k8smaster01 heketi]# kubectl get storageclasses/fast

2.2 授權ServiceAccount

本實驗2.4步驟需要使用mongo-sidecar的pod來配置管理mongo pod。

由於默認的service account僅僅只能獲取當前Pod自身的相關屬性，無法觀察到其他名稱空間Pod的相關屬性信息。如果想要擴展Pod，或者一個Pod需要用於管理其他Pod或者是其他資源對象，是無法通過自身的名稱空間的serviceaccount進行獲取其他Pod的相關屬性信息的，因此需要進行手動創建一個serviceaccount，並在創建Pod時進行定義。或者直接將默認的serviceaccount進行授權。

  1 [root@uk8s-m-01 mongo]# vi defaultaccout.yaml
  2 ---
  3 apiVersion: rbac.authorization.k8s.io/v1beta1
  4 kind: ClusterRoleBinding
  5 metadata:
  6   name: DDefault-Cluster-Admin
  7 subjects:
  8   - kind: ServiceAccount
  9     # Reference to upper's `metadata.name`
 10     name: default
 11     # Reference to upper's `metadata.namespace`
 12     namespace: default
 13 roleRef:
 14   kind: ClusterRole
 15   name: cluster-admin
 16   apiGroup: rbac.authorization.k8s.io
 17 
 18 [root@uk8s-m-01 mongo]# kubectl apply -f defaultaccout.yaml

2.3 創建headless Service

  1 [root@k8smaster01 mongo]# vi mongo-headless-service.yaml

略

提示：本實驗直接將headless結合在StatefulSet同一個yaml文件中，參考2.4。

2.4 創建StatefulSet

  1 [root@k8smaster01 mongo]# vi statefulset-mongo.yaml
  2 ---
  3 apiVersion: v1
  4 kind: Service
  5 metadata:
  6   name: mongo
  7   labels:
  8     name: mongo
  9 spec:
 10   ports:
 11   - port: 27017
 12     targetPort: 27017
 13   clusterIP: None
 14   selector:
 15     role: mongo
 16 ---                                  #以上為headless-service
 17 apiVersion: apps/v1beta1
 18 kind: StatefulSet
 19 metadata:
 20   name: mongo
 21 spec:
 22   serviceName: "mongo"
 23   replicas: 3
 24   template:
 25     metadata:
 26       labels:
 27         role: mongo
 28         environment: test
 29     spec:
 30       terminationGracePeriodSeconds: 10
 31       containers:
 32         - name: mongo
 33           image: mongo:3.4             #新版可能不支持smallfiles參數，因此指定為3.4版本
 34           command:
 35             - mongod
 36             - "--replSet"
 37             - rs0
 38             - "--bind_ip"
 39             - 0.0.0.0
 40             - "--smallfiles"           #使用較小的默認文件
 41             - "--noprealloc"           #禁用數據文件預分配
 42           ports:
 43             - containerPort: 27017
 44           volumeMounts:
 45             - name: mongo-persistent-storage
 46               mountPath: /data/db
 47         - name: mongo-sidecar
 48           image: cvallance/mongo-k8s-sidecar
 49           env:
 50             - name: MONGO_SIDECAR_POD_LABELS
 51               value: "role=mongo,environment=test"
 52             - name: KUBERNETES_MONGO_SERVICE_NAME
 53               value: "mongo"
 54   volumeClaimTemplates:
 55   - metadata:
 56       name: mongo-persistent-storage
 57       annotations:
 58         volume.beta.kubernetes.io/storage-class: "fast"
 59     spec:
 60       accessModes: [ "ReadWriteOnce" ]
 61       resources:
 62         requests:
 63           storage: 2Gi

釋義：

1. 該StatefulSet定義了兩個容器：mingo和mongo-sidecar。mongo是主服務程序，mongo-sidecar是將多個mongo實例進行集群設置的工具。同時mongo-sidecar中設置了如下環境變量：

• MONGO_SIDECAR_POD_LABELS：設置為mongo容器的標籤，用於sidecar查詢它所要管理的MongoDB集群實例。
• KUBERNETES_MONGO_SERVICE_NAME：它的值為mongo，表示sidecar將使用mongo這個服務名來完成MongoDB集群的設置。

1. replicas=3表示MongoDB集群由3個mongo實例組成。
2. volumeClaimTemplates是StatefulSet最重要的存儲設置。在annotations段設置volume.beta.kubernetes.io/storage-class=”fast”表示使用名為fast的StorageClass自動為每個mongo Pod實例分配後端存儲。
3. resources.requests.storage=2Gi表示為每個mongo實例都分配2GiB的磁盤空間。

  1 [root@k8smaster01 mongo]# kubectl create -f statefulset-mongo.yaml	#創建mongo

提示：由於國內mongo鏡像可能無法pull，建議通過VPN等方式提前pull鏡像，然後上傳至所有node節點。

  1 [root@VPN ~]# docker pull cvallance/mongo-k8s-sidecar:latest
  2 [root@VPN ~]# docker pull mongo:3.4.4
  3 [root@VPN ~]# docker save -o mongo-k8s-sidecar.tar cvallance/mongo-k8s-sidecar:latest
  4 [root@VPN ~]# docker save -o mongo_3_4_4.tar mongo:3.4.4
  5 [root@k8snode01 ~]# docker load -i mongo-k8s-sidecar.tar
  6 [root@k8snode01 ~]# docker load -i mongo.tar
  7 [root@k8snode01 ~]# docker images

創建異常可通過如下方式刪除，重新創建：

  1 kubectl delete -f statefulset-mongo.yaml
  2 kubectl delete -f mongo-headless-service.yaml
  3 kubectl delete pvc -l role=mongo

三 確認驗證

3.1 查看資源

  1 [root@k8smaster01 mongo]# kubectl get pod -l role=mongo			#查看集群pod
  2 NAME      READY   STATUS    RESTARTS   AGE
  3 mongo-0   2/2     Running   0          9m44s
  4 mongo-1   2/2     Running   0          7m51s
  5 mongo-2   2/2     Running   0          6m1s

StatefulSet會用volumeClaimTemplates中的定義為每個Pod副本都創建一個PVC實例，每個PVC的名稱由StatefulSet定義中volumeClaimTemplates的名稱和Pod副本的名稱組合而成。

  1 [root@k8smaster01 mongo]# kubectl get pvc

  1 [root@k8smaster01 mongo]# kubectl get pods mongo-0 -o yaml | grep -A 3 volumes	#查看掛載

3.2 查看mongo集群

登錄任意一個mongo Pod，在mongo命令行界面用rs.status()命令查看MongoDB集群的狀態，該mongodb集群已由sidecar完成了創建。在集群中包含3個節點 每個節點的名稱都是StatefulSet設置的DNS域名格式的網絡標識名稱：

mongo-0.mongo.default.svc.cluster.local

mongo-1.mongo.default.svc.cluster.local

mongo-2.mongo.default.svc.cluster.local

同時，可以查看每個mongo實例各自的角色（PRIMARY或SECONDARY）。

  1 [root@k8smaster01 mongo]# kubectl exec -ti mongo-0 -- mongo
  2 ……
  3 rs0:PRIMARY> rs.status()

四 集群常見管理

4.1 MongoDB擴容

運行環境過程中，若3個mongo實例不足以滿足業務的要求，可對mongo集群進行擴容。僅需要通過對StatefulSet進行scale操作，從而實現在mongo集群中自動添加新的mongo節點。

  1 [root@k8smaster01 ~]# kubectl scale statefulset mongo --replicas=4	#擴容為4個
  2 [root@k8smaster01 ~]# kubectl get pod -l role=mongo
  3 NAME      READY   STATUS    RESTARTS   AGE
  4 mongo-0   2/2     Running   0          105m
  5 mongo-1   2/2     Running   0          103m
  6 mongo-2   2/2     Running   0          101m
  7 mongo-3   2/2     Running   0          50m

4.2 查看集群成員

  1 [root@k8smaster01 mongo]# kubectl exec -ti mongo-0 -- mongo
  2 ……
  3 rs0:PRIMARY> rs.status()
  4 ……

4.3 故障自動恢復

若在系統運行過程中，某個mongo實例或其所在主機發生故障，則StatefulSet將會自動重建該mongo實例，並保證其身份（ID）和使用的數據（PVC） 不變。以下為mongo-0實例發生故障進行模擬，StatefulSet將會自動重建mongo-0實例，併為其掛載之前分配的PVC“mongo-persistent-storage-mongo-0”。新的服務“mongo-0”在重新啟動后，原數據庫中的數據不會丟失，可繼續使用。

  1 [root@k8smaster01 ~]# kubectl get pvc
  2 [root@k8smaster01 ~]# kubectl delete pod mongo-0
  3 [root@k8smaster01 mongo]# kubectl exec -ti mongo-0 -- mongo
  4 ……
  5 rs0:PRIMARY> rs.status()
  6 ……

提示：進入某個實例查看mongo集群的狀態，mongo-0發生故障前在集群中的角色為PRIMARY，在其脫離集群后，mongo集群會自動選出一個SECONDARY節點提升為PRIMARY節點（本例中為mongo-2）。重啟后的mongo-0則會成為一個新的SECONDARY節點。本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置，台北網頁設計，各種案例分享

前言

這一篇來源我的公眾號，如果你沒看過，正好直接看看，如果看過了也可以再看看，我稍微修改了一些內容，今天講解的內容如下：

 

 

 

 

 

 

 

一、什麼是單例模式

 

【單例模式】，英文名稱：Singleton Pattern，這個模式很簡單，一個類型只需要一個實例，他是屬於創建類型的一種常用的軟件設計模式。通過單例模式的方法創建的類在當前進程中只有一個實例（根據需要，也有可能一個線程中屬於單例，如：僅線程上下文內使用同一個實例）。

1、單例類只能有一個實例。

2、單例類必須自己創建自己的唯一實例。

3、單例類必須給所有其他對象提供這一實例。

 

那咱們大概知道了，其實說白了，就是我們整個項目周期內，只會有一個實例，當項目停止的時候，實例銷毀，當重新啟動的時候，我們的實例又會產品。

上文中說到了一個名詞【創建類型】的設計模式，那什麼是創建類型的設計模式呢？

創建型（Creational）模式：負責對象創建，我們使用這個模式，就是為了創建我們需要的對象實例的。

 

那除了創建型還有其他兩種類型的模式：

結構型（Structural）模式：處理類與對象間的組合

行為型（Behavioral）模式：類與對象交互中的職責分

這兩種設計模式，以後會慢慢說到，這裏先按下不表。

咱們就重點從0開始分析分析如何創建一個單例模式的對象實例。

 

二、如何創建單例模式

 

實現單例模式有很多方法：從“懶漢式”到“餓漢式”，最後“雙檢鎖”模式，這裏咱們就慢慢的，從一步一步的開始講解如何創建單例。

 

1、正常的思考邏輯順序

 

既然要創建單一的實例，那我們首先需要學會如何去創建一個實例，這個很簡單，相信每個人都會創建實例，就比如說這樣的：

/// <summary>
/// 定義一個天氣類
/// </summary>
public class WeatherForecast
{
    public WeatherForecast()
    {
        Date = DateTime.Now;
    }
    public DateTime Date { get; set; }
    public int TemperatureC { get; set; }
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
    public string Summary { get; set; }
}


 [HttpGet]
 public WeatherForecast Get()
 {
     // 實例化一個對象實例
     WeatherForecast weather = new WeatherForecast();
     return weather;
 }

 

我們每次訪問的時候，時間都是會變化，所以我們的實例也是一直在創建，在變化：

 

 

相信每個人都能看到這個代碼是什麼意思，不多說，直接往下走，我們知道，單例模式的核心目的就是：

必須保證這個實例在整個系統的運行周期內是唯一的，這樣可以保證中間不會出現問題。

 

那好，我們改進改進，不是說要唯一一個么，好說！我直接返回不就行了：

 

 /// <summary>
 /// 定義一個天氣類
 /// </summary>
 public class WeatherForecast
 {
     // 定義一個靜態變量來保存類的唯一實例
     private static WeatherForecast uniqueInstance;

     // 定義私有構造函數，使外界不能創建該類實例
     private WeatherForecast()
     {
         Date = DateTime.Now;
     }
     /// <summary>
     /// 靜態方法，來返回唯一實例
     /// 如果存在，則返回
     /// </summary>
     /// <returns></returns>
     public static WeatherForecast GetInstance()
     {
         // 如果類的實例不存在則創建，否則直接返回
         // 其實嚴格意義上來說，這個不屬於【單例】
         if (uniqueInstance == null)
         {
             uniqueInstance = new WeatherForecast();
         }
         return uniqueInstance;
     }
     public DateTime Date { get; set; }public int TemperatureC { get; set; }
     public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
     public string Summary { get; set; }
 }

 

 

然後我們修改一下調用方法，因為我們的默認構造函數已經私有化了，不允許再創建實例了，所以我們直接這麼調用：

[HttpGet]
 public WeatherForecast Get()
 {
     // 實例化一個對象實例
     WeatherForecast weather = WeatherForecast.GetInstance();
     return weather;
 }

 

最後來看看效果：

 

 

這個時候，我們可以看到，時間已經不發生變化了，也就是說我們的實例是唯一的了，大功告成！是不是很開心！

 

但是，別著急，問題來了，我們目前是單線程的，所以只有一個，那如果多線程呢，如果多個線程同時訪問，會不會也會正常呢？

這裏我們做一個測試，我們在項目啟動的時候，用多線程去調用：

 

 [HttpGet]
 public WeatherForecast Get()
 {
     // 實例化一個對象實例
     //WeatherForecast weather = WeatherForecast.GetInstance();

     // 多線程去調用
     for (int i = 0; i < 3; i++)
     {
         var th = new Thread(
         new ParameterizedThreadStart((state) =>
         {
             WeatherForecast.GetInstance();
         })
         );
         th.Start(i);
     }
     return null;
 }

 

然後我們看看效果是怎樣的，按照我們的思路，應該是只會走一遍構造函數，其實不是：

 

 

 

 

 

 

3個線程在第一次訪問GetInstance方法時，同時判斷(uniqueInstance ==null)這個條件時都返回真，然後都去創建了實例，這個肯定是不對的。那怎麼辦呢，只要讓GetInstance方法只運行一個線程運行就好了，我們可以加一個鎖來控制他，代碼如下：

public class WeatherForecast
{
    // 定義一個靜態變量來保存類的唯一實例
    private static WeatherForecast uniqueInstance;
    // 定義一個鎖，防止多線程
    private static readonly object locker = new object();

    // 定義私有構造函數，使外界不能創建該類實例
    private WeatherForecast()
    {
        Date = DateTime.Now;
    }
    /// <summary>
    /// 靜態方法，來返回唯一實例
    /// 如果存在，則返回
    /// </summary>
    /// <returns></returns>
    public static WeatherForecast GetInstance()
    {
        // 當第一個線程執行的時候，會對locker對象 "加鎖"，
        // 當其他線程執行的時候，會等待 locker 執行完解鎖
        lock (locker)
        {
            // 如果類的實例不存在則創建，否則直接返回
            if (uniqueInstance == null)
            {
                uniqueInstance = new WeatherForecast();
            }
        }

        return uniqueInstance;
    }
    public DateTime Date { get; set; }

    public int TemperatureC { get; set; }

    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);

    public string Summary { get; set; }
}

 

這個時候，我們再併發測試，發現已經都一樣了，這樣就達到了我們想要的效果，但是這樣真的是最完美的么，其實不是的，因為我們加鎖，只是第一次判斷是否為空，如果創建好了以後，以後就不用去管這個 lock 鎖了，我們只關心的是 uniqueInstance 是否為空，那我們再完善一下：

 

/// <summary>
/// 定義一個天氣類
/// </summary>
public class WeatherForecast
{
    // 定義一個靜態變量來保存類的唯一實例
    private static WeatherForecast uniqueInstance;
    // 定義一個鎖，防止多線程
    private static readonly object locker = new object();

    // 定義私有構造函數，使外界不能創建該類實例
    private WeatherForecast()
    {
        Date = DateTime.Now;
    }
    /// <summary>
    /// 靜態方法，來返回唯一實例
    /// 如果存在，則返回
    /// </summary>
    /// <returns></returns>
    public static WeatherForecast GetInstance()
    {
        // 當第一個線程執行的時候，會對locker對象 "加鎖"，
        // 當其他線程執行的時候，會等待 locker 執行完解鎖
        if (uniqueInstance == null)
        {
            lock (locker)
            {
                // 如果類的實例不存在則創建，否則直接返回
                if (uniqueInstance == null)
                {
                    uniqueInstance = new WeatherForecast();
                }
            }
        }

        return uniqueInstance;
    }
    public DateTime Date { get; set; }
    public int TemperatureC { get; set; }
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
    public string Summary { get; set; }
}

 

這樣才最終的完美實現我們的單例模式！搞定。

 

2、幽靈事件：指令重排

當然，如果你看完了上邊的那四步已經可以出師了，平時我們就是這麼使用的，也是這麼想的，但是真的就是萬無一失么，有一個 JAVA 的朋友提出了這個問題，C# 中我沒有聽說過，是我孤陋寡聞了么：

單例模式的幽靈事件，時令重排會偶爾導致單例模式失效。

 

是不是聽起來感覺很高大上，而不知所云，沒關係，咱們平時用不到，但是可以了解了解：

為何要指令重排？       

指令重排是指的 volatile，現在的CPU一般採用流水線來執行指令。一個指令的執行被分成：取指、譯碼、訪存、執行、寫回、等若干個階段。然後，多條指令可以同時存在於流水線中，同時被執行。
指令流水線並不是串行的，並不會因為一個耗時很長的指令在“執行”階段呆很長時間，而導致後續的指令都卡在“執行”之前的階段上。
相反，流水線是并行的，多個指令可以同時處於同一個階段，只要CPU內部相應的處理部件未被佔滿即可。比如說CPU有一個加法器和一個除法器，那麼一條加法指令和一條除法指令就可能同時處於“執行”階段, 而兩條加法指令在“執行”階段就只能串行工作。
相比於串行+阻塞的方式，流水線像這樣并行的工作，效率是非常高的。

然而，這樣一來，亂序可能就產生了。比如一條加法指令原本出現在一條除法指令的後面，但是由於除法的執行時間很長，在它執行完之前，加法可能先執行完了。再比如兩條訪存指令，可能由於第二條指令命中了cache而導致它先於第一條指令完成。
一般情況下，指令亂序並不是CPU在執行指令之前刻意去調整順序。CPU總是順序的去內存裏面取指令，然後將其順序的放入指令流水線。但是指令執行時的各種條件，指令與指令之間的相互影響，可能導致順序放入流水線的指令，最終亂序執行完成。這就是所謂的“順序流入，亂序流出”。

 

這個是從網上摘錄的，大概意思看看就行,理解雙檢鎖失效原因有兩個重點

1、編譯器的寫操作重排問題.
例 : B b = new B();

上面這一句並不是原子性的操作,一部分是new一個B對象,一部分是將new出來的對象賦值給b.

直覺來說我們可能認為是先構造對象再賦值.但是很遺憾,這個順序並不是固定的.再編譯器的重排作用下,可能會出現先賦值再構造對象的情況.

2、結合上下文,結合使用情景.

理解了1中的寫操作重排以後,我卡住了一下.因為我真不知道這種重排到底會帶來什麼影響.實際上是因為我看代碼看的不夠仔細,沒有意識到使用場景.雙檢鎖的一種常見使用場景就是在單例模式下初始化一個單例並返回,然後調用初始化方法的方法體內使用初始化完成的單例對象.

 

三、Singleton = 單例 ？

 上邊我們說了很多，也介紹了很多單例的原理和步驟，那這裏問題來了，我們在學習依賴注入的時候，用到的 Singleton 的單例注入，是不是和上邊說的一回事兒呢，這裏咱們直接多多線程測試一下就行：

 

/// <summary>
/// 定義一個心情類
/// </summary>
public class Feeling
{
    public Feeling()
    {
        Date = DateTime.Now;
    }
    public DateTime Date { get; set; }
}


 // 單例注入
 services.AddSingleton<Feeling>();


[HttpGet]
public WeatherForecast Get()
{

    // 多線程去調用
    for (int i = 0; i < 3; i++)
    {
        var th = new Thread(
        new ParameterizedThreadStart((state) =>
        {
            //WeatherForecast.GetInstance();
            
            // 此刻的心情
            Feeling feeling = new Feeling();
            Console.WriteLine(feeling.Date);
        })
        );
        th.Start(i);
    }
    return null;
}

 

測試的結果，情理之中，也是意料之外：

 

 

竟然和我們上邊說的是一樣的， 
Singleton是一種懶漢模式 的單例， 因為結論可以看出，有時候我們使用單例模式，並不是寫一個 Sigleton 就能滿足的。    

四、單例模式的優缺點

 

        【優】、單例模式的優點：

             （1）、保證唯一性：防止其他對象實例化，保證實例的唯一性；

             （2）、全局性：定義好數據后，可以再整個項目種的任何地方使用當前實例，以及數據；

        【劣】、單例模式的缺點： 

             （1）、內存常駐：因為單例的生命周期最長，存在整個開發系統內，如果一直添加數據，或者是常駐的話，會造成一定的內存消耗。

 

以下內容來自百度百科：

優點

一、實例控制 單例模式會阻止其他對象實例化其自己的單例對象的副本，從而確保所有對象都訪問唯一實例。
二、靈活性 因為類控制了實例化過程，所以類可以靈活更改實例化過程。  

缺點

一、開銷 雖然數量很少，但如果每次對象請求引用時都要檢查是否存在類的實例，將仍然需要一些開銷。可以通過使用靜態初始化解決此問題。
二、可能的開發混淆 使用單例對象（尤其在類庫中定義的對象）時，開發人員必須記住自己不能使用
new關鍵字實例化對象。因為可能無法訪問庫源代碼，因此應用程序開發人員可能會意外發現自己無法直接實例化此類。
三、對象生存期 不能解決刪除單個對象的問題。在提供內存管理的語言中（例如基於.NET Framework的語言），只有單例類能夠導致實例被取消分配，因為它包含對該實例的私有引用。在某些語言中（如 C++），其他類可以刪除對象實例，但這樣會導致單例類中出現懸浮引用。

 

五、示例代碼

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

系列博客，原文在筆者所維護的github上：，
點擊star加星不要吝嗇，星越多筆者越努力。

2.1 線性反向傳播

2.1.1 正向計算的實例

假設我們有一個函數：

\[z = x \cdot y \tag{1}\]

其中:

\[x = 2w + 3b \tag{2}\]

\[y = 2b + 1 \tag{3}\]

計算圖如圖2-4。

圖2-4 簡單線性計算的計算圖

注意這裏x, y, z不是變量，只是計算結果。w, b是才變量。因為在後面要學習的神經網絡中，我們要最終求解的是w和b的值，在這裏先預熱一下。

當w = 3, b = 4時，會得到圖2-5的結果。

圖2-5 計算結果

最終的z值，受到了前面很多因素的影響：變量w，變量b，計算式x，計算式y。常數是個定值，不考慮。

2.1.2 反向傳播求解w

求w的偏導

目前的z=162，如果我們想讓z變小一些，比如目標是z=150，w應該如何變化呢？為了簡化問題，我們先只考慮改變w的值，而令b值固定為4。

如果想解決這個問題，我們可以在輸入端一點一點的試，把w變成4試試，再變成3.5試試……直到滿意為止。現在我們將要學習一個更好的解決辦法：反向傳播。

我們從z開始一層一層向回看，圖中各節點關於變量w的偏導計算結果如下：

\[因為z = x \cdot y，其中x = 2w + 3b，y = 2b + 1\]

所以：

\[\frac{\partial{z}}{\partial{w}}=\frac{\partial{z}}{\partial{x}} \cdot \frac{\partial{x}}{\partial{w}}=y \cdot 2=18 \tag{4}\]

其中：

\[\frac{\partial{z}}{\partial{x}}=\frac{\partial{}}{\partial{x}}(x \cdot y)=y=9\]

\[\frac{\partial{x}}{\partial{w}}=\frac{\partial{}}{\partial{w}}(2w+3b)=2\]

圖2-6 對w的偏導求解過程

圖2-6其實就是鏈式法則的具體表現，z的誤差通過中間的x傳遞到w。如果不是用鏈式法則，而是直接用z的表達式計算對w的偏導數，會是什麼樣呢？我們來試驗一下。

根據公式1、2、3，我們有：

\[z=x \cdot y=(2w+3b)(2b+1)=4wb+2w+6b^2+3b \tag{5}\]

對上式求w的偏導：

\[ {\partial z \over \partial w}=4b+2=4 \cdot 4 + 2=18 \tag{6} \]

公式4和公式6的結果完全一致！所以，請大家相信鏈式法則的科學性。

求w的具體變化值

公式4和公式6的含義是：當w變化一點點時，z會發生w的變化值的18倍的變化。記住我們的目標是讓z=150，目前在初始狀態時是162，所以，問題轉化為：當我們需要z從162變到150時，w需要變化多少？

既然：

\[ \Delta z = 18 \cdot \Delta w \]

則：

\[ \Delta w = {\Delta z \over 18}={162-150 \over 18}= 0.6667 \]

所以：

\[w = w – 0.6667=2.3333\]
\[x=2w+3b=16.6667\]
\[z=x \cdot y=16.6667 \times 9=150.0003\]

我們一下子就成功地讓z值變成了150.0003，與150的目標非常地接近，這就是偏導數的威力所在。

【課堂練習】推導z對b的偏導數，結果在下一小節中使用

2.1.3 反向傳播求解b

求b的偏導

這次我們令w的值固定為3，變化b的值，目標還是讓z=150。同上一小節一樣，先求b的偏導數。

注意，在上一小節中，求w的導數只經過了一條路：從z到x到w。但是求b的導數時要經過兩條路，如圖2-7所示：

1. 從z到x到b
2. 從z到y到b

圖2-7 對b的偏導求解過程

從複合導數公式來看，這兩者應該是相加的關係，所以有：

\[\frac{\partial{z}}{\partial{b}}=\frac{\partial{z}}{\partial{x}} \cdot \frac{\partial{x}}{\partial{b}}+\frac{\partial{z}}{\partial{y}}\cdot\frac{\partial{y}}{\partial{b}}=y \cdot 3+x \cdot 2=63 \tag{7}\]

其中：

\[\frac{\partial{z}}{\partial{x}}=\frac{\partial{}}{\partial{x}}(x \cdot y)=y=9\]
\[\frac{\partial{z}}{\partial{y}}=\frac{\partial{}}{\partial{y}}(x \cdot y)=x=18\]
\[\frac{\partial{x}}{\partial{b}}=\frac{\partial{}}{\partial{b}}(2w+3b)=3\]
\[\frac{\partial{y}}{\partial{b}}=\frac{\partial{}}{\partial{b}}(2b+1)=2\]

我們不妨再驗證一下鏈式求導的正確性。把公式5再拿過來：

\[z=x \cdot y=(2w+3b)(2b+1)=4wb+2w+6b^2+3b \tag{5}\]

對上式求b的偏導：

\[ {\partial z \over \partial b}=4w+12b+3=12+48+3=63 \tag{8} \]

結果和公式7的鏈式法則一樣。

求b的具體變化值

公式7和公式8的含義是：當b變化一點點時，z會發生b的變化值的63倍的變化。記住我們的目標是讓z=150，目前在初始狀態時是162，所以，問題轉化為：當我們需要z從162變到150時，b需要變化多少？

既然：

\[\Delta z = 63 \cdot \Delta b\]

則：

\[ \Delta b = {\Delta z \over 63}={162-150 \over 63}=​0.1905 \]

所以：
\[ b=b-0.1905=3.8095 \]
\[x=2w+3b=17.4285\]
\[y=2b+1=8.619\]
\[z=x \cdot y=17.4285 \times 8.619=150.2162\]

這個結果也是與150很接近了，但是精度還不夠。再迭代幾次，應該可以近似等於150了，直到誤差不大於1e-4時，我們就可以結束迭代了，對於計算機來說，這些運算的執行速度很快。

【課題練習】請自己嘗試手動繼續迭代兩次，看看誤差的精度可以達到多少？

這個問題用數學公式倒推求解一個二次方程，就能直接得到準確的b值嗎？是的！但是我們是要說明機器學習的方法，機器並不會解二次方程，而且很多時候不是用二次方程就能解決實際問題的。而上例所示，是用機器所擅長的迭代計算的方法來不斷逼近真實解，這就是機器學習的真諦！而且這種方法是普遍適用的。

2.1.4 同時求解w和b的變化值

這次我們要同時改變w和b，到達最終結果為z=150的目的。

已知\(\Delta z=12\)，我們不妨把這個誤差的一半算在w賬上，另外一半算在b的賬上：

\[\Delta b=\frac{\Delta z / 2}{63} = \frac{12/2}{63}=0.095\]

\[\Delta w=\frac{\Delta z / 2}{18} = \frac{12/2}{18}=0.333\]

• \(w = w-\Delta w=3-0.333=2.667\)
• \(b = b – \Delta b=4-0.095=3.905\)
• \(x=2w+3b=2 \times 2.667+3 \times 3.905=17.049\)
• \(y=2b+1=2 \times 3.905+1=8.81\)
• \(z=x \times y=17.049 \times 8.81=150.2\)

【課堂練習】用Python代碼實現以上雙變量的反向傳播計算過程

容易出現的問題：

1. 在檢查Δz時的值時，注意要用絕對值，因為有可能是個負數
2. 在計算Δb和Δw時，第一次時，它們對z的貢獻值分別是1/63和1/18，但是第二次時，由於b和w值的變化，對於z的貢獻值也會有微小變化，所以要重新計算。具體解釋如下：

\[ \frac{\partial{z}}{\partial{b}}=\frac{\partial{z}}{\partial{x}} \cdot \frac{\partial{x}}{\partial{b}}+\frac{\partial{z}}{\partial{y}}\cdot\frac{\partial{y}}{\partial{b}}=y \cdot 3+x \cdot 2=3y+2x \]
\[ \frac{\partial{z}}{\partial{w}}=\frac{\partial{z}}{\partial{x}} \cdot \frac{\partial{x}}{\partial{w}}+\frac{\partial{z}}{\partial{y}}\cdot\frac{\partial{y}}{\partial{w}}=y \cdot 2+x \cdot 0 = 2y \]
所以，在每次迭代中，要重新計算下面兩個值：
\[ \Delta b=\frac{\Delta z}{3y+2x} \]
\[ \Delta w=\frac{\Delta z}{2y} \]

以下是程序的運行結果。

沒有在迭代中重新計算Δb的貢獻值：

single variable: b -----
w=3.000000,b=4.000000,z=162.000000,delta_z=12.000000
delta_b=0.190476
w=3.000000,b=3.809524,z=150.217687,delta_z=0.217687
delta_b=0.003455
w=3.000000,b=3.806068,z=150.007970,delta_z=0.007970
delta_b=0.000127
w=3.000000,b=3.805942,z=150.000294,delta_z=0.000294
delta_b=0.000005
w=3.000000,b=3.805937,z=150.000011,delta_z=0.000011
delta_b=0.000000
w=3.000000,b=3.805937,z=150.000000,delta_z=0.000000
done!
final b=3.805937

在每次迭代中都重新計算Δb的貢獻值：

single variable new: b -----
w=3.000000,b=4.000000,z=162.000000,delta_z=12.000000
factor_b=63.000000, delta_b=0.190476
w=3.000000,b=3.809524,z=150.217687,delta_z=0.217687
factor_b=60.714286, delta_b=0.003585
w=3.000000,b=3.805938,z=150.000077,delta_z=0.000077
factor_b=60.671261, delta_b=0.000001
w=3.000000,b=3.805937,z=150.000000,delta_z=0.000000
done!
final b=3.805937

從以上兩個結果對比中，可以看到三點：

1. factor_b第一次是63，以後每次都會略微降低一些
2. 第二個函數迭代了3次就結束了，而第一個函數迭代了5次，效率不一樣
3. 最後得到的結果是一樣的，因為這個問題只有一個解

對於雙變量的迭代，有同樣的問題：

沒有在迭代中重新計算Δb,Δw的貢獻值(factor_b和factor_w每次都保持63和18)：

double variable: w, b -----
w=3.000000,b=4.000000,z=162.000000,delta_z=12.000000
delta_b=0.095238, delta_w=0.333333
w=2.666667,b=3.904762,z=150.181406,delta_z=0.181406
delta_b=0.001440, delta_w=0.005039
w=2.661628,b=3.903322,z=150.005526,delta_z=0.005526
delta_b=0.000044, delta_w=0.000154
w=2.661474,b=3.903278,z=150.000170,delta_z=0.000170
delta_b=0.000001, delta_w=0.000005
w=2.661469,b=3.903277,z=150.000005,delta_z=0.000005
done!
final b=3.903277
final w=2.661469

在每次迭代中都重新計算Δb,Δw的貢獻值(factor_b和factor_w每次都變化)：

double variable new: w, b -----
w=3.000000,b=4.000000,z=162.000000,delta_z=12.000000
factor_b=63.000000, factor_w=18.000000, delta_b=0.095238, delta_w=0.333333
w=2.666667,b=3.904762,z=150.181406,delta_z=0.181406
factor_b=60.523810, factor_w=17.619048, delta_b=0.001499, delta_w=0.005148
w=2.661519,b=3.903263,z=150.000044,delta_z=0.000044
factor_b=60.485234, factor_w=17.613053, delta_b=0.000000, delta_w=0.000001
w=2.661517,b=3.903263,z=150.000000,delta_z=0.000000
done!
final b=3.903263
final w=2.661517

這個與第一個單變量迭代不同的地方是：這個問題可以有多個解，所以兩種方式都可以得到各自的正確解，但是第二種方式效率高，而且滿足梯度下降的概念。

參考資料

代碼位置

ch02, Level1

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置，台北網頁設計，各種案例分享

.NET Core love gRPC

千呼萬喚的 .NET Core 3.0 終於在 9 月份正式發布，在它的眾多新特性中，除了性能得到了大大提高，比較受關注的應該是 ASP.NET Core 3.0 對 gRPC 的集成了。
它的源碼託管在 grpc-dotnet 這個 Github 庫中，由微軟 .NET 團隊與谷歌 gRPC 團隊共同維護.

.NET Core 對 gRPC 的支持在 grpc 官方倉庫早已有實現（grpc/csharp），但服務端沒有很好地與 ASP.NET Core 集成，使用起來還需要自己進行一些集成擴展。
而 ASP.NET Core 3.0 新增了 gRPC 服務的託管功能，能讓 gRPC 與 ASP.NET Core 框架本身的特性很好地結合，如日誌、依賴注入、身份認證和授權，並由 Kestrel 服務器提供 HTTP/2 鏈接，性能上得到充分保障。

推薦把項目中已有的 RPC 框架或者內部服務間 REST 調用都遷移到 gRPC 上，因為它已經是雲原生應用的標準 RPC 框架，在整個 CNCF 主導下的雲原生應用開發生態里 gRpc 有着舉足輕重的地位。

對於 gRPC 的使用方式，前段時間已經有其他大神寫的幾篇文章了，這裏就不再贅述了。
本文主要介紹的是區別於標準使用規範的，但對.NET 應用更加友好的使用方式，最後會提供源碼來展示。

作為對比，還是要列一下標準的使用步驟：

1. 定義 proto 文件，包含服務、方法、消息對象的定義
2. 引入 Grpc.Tools Nuget 包並添加指定 proto 路徑和生成模式
3. 生成項目，得到服務端的抽象類或客戶端的調用客戶端組件
4. 實現服務端抽象類，並在 ASP.NET Core 註冊這個服務的路由端點
5. DI 註冊 gRPC 服務。
6. 客戶端用 Grpc.Net.ClientFactory Nuget 包進行統一配置和依賴注入

.NET Core 對 gRPC 的大力支持使開發者開發效率大大提高，入門難度也減少了許多，完全可以成為跟 WebApi 等一樣的 .NET Core 技術棧的標配。

proto 在單一語言系統架構中的局限性

使用 proto 文件的好處是多語言支持，同一份 proto 可以生成各種語言的服務和客戶端，可以讓用不同語言開發的微服務直接互相遠程調用。但 proto 文件作為不同服務間的契約，不可以經常修改，否則就會對使用了它的服務造成不同程度的影響，因此對 proto 文件的版本控制需要得到重視。

另外，我們的應用程序還不應該與 gRPC 耦合，否則就會導致系統架構被這些實現細節所綁架。直接依賴 proto 文件和由它生成的代碼，就是對 gRPC 的強耦合。

例如，當應用程序在演進的過程中，複雜度還未達到完全部署隔離的必要時，為了避免因“完全邊界”引入的部署運維複雜性，又能預留隔離的可能性，需要有一層接口層作為“不完全邊界”。

又比如，目前在 windows 系統的 iis 上還不支持 grpc-dotnet，當有 windows 上的應用程序需要使用 RPC，就需要換成 REST 的實現了。

因此，為了不讓應用程序對 gRPC 過於依賴，還應該使用一層抽象（接口）層與其解耦，用接口來隔離對 RPC 實現的依賴，這樣在需要使用不同的實現時，可以通過註冊不同的實現來方便地切換。

在這些場景下，本文要介紹的 Code-First gRPC 使用方法就發揮作用了。

Code-First gRPC

說了這麼久，我好像還沒正式介紹 Code-First gRPC，到底他有多適合在單一語言系統架構中實現 gRPC 呢？下面要介紹的就是基於大名鼎鼎的 protobuf-net 實現的 gRPC 框架，protobuf-net.Grpc。

protobuf-net 是在過去十幾年前到現在一直在 .NET 中有名的 Protobuf 庫，想用 Protobuf 序列化時就會用到這個庫。他的特性就是可以把 C# 代碼編寫的類能以 Protobuf 的協議進行序列化和反序列化，而不是 proto 文件再生成這些類。而 protobuf-net.Grpc 則是一脈相承，可以把 C# 寫的接口，在服務端方便地把接口的實現類註冊成 ASP.NET Core 的 gRPC 服務，在客戶端把接口動態代理實現為調用客戶端，調用前面的這個服務端。

用法很簡單，只要聲明一個接口為您的服務契約：

[ServiceContract]
public interface IMyAmazingService {
    ValueTask<SearchResponse> SearchAsync(SearchRequest request);
    // ...
}

然後實現該接口的服務端：

public class MyServer : IMyAmazingService {
    // ...
}

或者向系統獲取客戶端：

var client = http.CreateGrpcService<IMyAmazingService>();
var results = await client.SearchAsync(request);

這相當於以下 .proto 中的服務：

service MyAmazingService {
    rpc Search (SearchRequest) returns (SearchResponse) {}
    // ...
}

protobuf-net.Grpc 同樣通過普通類型定義支持 gRPC 的四種模式，把 C# 8.0 中最新的 IAsyncEnumerable 類型識別成 proto 中的 stream，單向流、雙向流都可以實現！而且用 IAsyncEnumerable 實現可比 proto 生成的類方便很多。

例如 proto 雙向流定義：

rpc chat(stream ChatRequest) returns ( stream ChatResponse);

生成出來的方法是：

Task BathTheCat(IAsyncStreamReader<ChatRequest> requestStream, IServerStreamWriter<ChatResponse> responseStream)

而 protobuf-net.Grpc 只要定義一個方法：

IAsyncEnumerable<ChatResponse> SubscribeAsync(IAsyncEnumerable<ChatRequest> requestStream);

由此可見，protobuf-net.Grpc 無需在契約層引入第三方庫，充分運用了 C# 類型系統，把方法、類型映射到兼容了 gRPC 的服務定義上。

上文所說的 proto 局限也迎刃而解了，函數調用、gRPC、REST 都能方便切換。（REST 實現可以參考我的開源框架 shriek-fx 中的 Shriek.ServiceProxy.Http ）組件。

下一篇，我將主要介紹利用 protobuf-net.Grpc 的 gRPC 雙向流模式與 Blazor 實現一個簡單的在線即時聊天室。

相關鏈接：

• protobuf-net.Grpc：
• shriek-fx：
• GrpcChat:

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象