上一節我們已經學習了原型模式，稍微複習一下：通過重寫Object 類的clone() 方法實現淺克隆，淺克隆也要實現Cloneable 標記接口。而深克隆則是將對象通過序列化和反序列化 的方式進行創建和還原。

本小結將學習的是工廠模式，這個模式在平時是特別常用的，還需好好理解。我也將舉一些例子給大家
、

從生活出發

假設我們今天不想做飯，想出去吃飯、肯定選定一家好吃的川菜館,然後我們找好位置坐下，給廚師說，我想吃糖醋排骨。 稍微等待幾分鐘、菜就可以做好，然後給你呈上來。

這是一個很經典的例子，我們平時也經常有這樣的實際問題，你發現了么？

• 我只需要告訴廚師菜名，我要吃啥就行了
• 我不關注這個菜是怎麼生產的 new()

開始擼代碼

/**
 * 抽象產品 菜
 */
public interface FoodProduct {
    void show();
}
------------
/**
 * 具體產品
 */
public class HongShao implements FoodProduct {
    @Override
    public void show() {
        System.out.println("紅燒排骨");
    }
}
------------
public class TangCu implements FoodProduct {
    @Override
    public void show() {
        System.out.println("糖醋魚");
    }
}

創建廚房工廠

創建一個廚房類，廚房可以用來生產食物產品，我們只需要告訴廚房，這裡是通過id 編號的形式告訴廚房的。我們只需要告訴廚房所需要的食物 而不關心這個食物產品是如何創建出來的。

public class KitchenFactory {
    /**
     * id=1 上菜紅燒肉 id=2 糖醋魚
     * @param id
     */
    public FoodProduct cooking(int id) {
        if (1 == id) {
            return new HongShao();
        } else {
            return new TangCu();
        }
    }
}

KitchenFactory kitchen = new KitchenFactory();
FoodProduct food = kitchen.cooking(1);
food.show();
--------
紅燒排骨

理解工廠模式

通過這個簡單的例子，我們可以學習到：

• 無需關注對象是如何創建的。只需通過指定的關鍵字 就能拿到我需要的產品，這就是簡單工廠模式。

抽象工廠

http://c.biancheng.net/view/1351.html

抽象工廠，就是簡單工廠的抽象版、如何理解呢？我們上面的工廠（廚房）它已經是一個確定的對象 了。而抽象工廠，則是在廚房 的基礎上，再次衍生出一個接口，我們的廚房 則是這個抽象類的一個具體實例化。

代碼源於生活

我又要開始舉栗子了。請細細品

我們都知道小米 小米既可以生產手機 也可以生產電器用品 那麼這就是一個很好的例子。

小米抽象工廠 是一個巨大的工廠，它裏面有小米手機工廠 以及小米電器工廠 而不同的工廠，則生產不同的產品。

代碼教學開始

首先，我們得需要一個抽象工廠，這個工廠可以包含手機工廠和電器工廠。

public interface AbstractFactory {
    /**
     * 創建手機工廠
     * @return
     */
    PhoneFactory phoneFactory();
    /**
     * 創建電器工廠
     * @return
     */
    ElectricalFactory electricalFactory();
}

當然，手機工廠不知道是具體哪個工廠，反正它可以做一些事情，比如創建手機。

public interface PhoneFactory {
    /**
     * 手機工廠可以做的事情
     */
    void show();
}
-----------
public interface ElectricalFactory {
    /**
     * 電器工廠可以生產電器
     */
    void show();
}

上手實際創建一個小米工廠

public class XiaoMiFactory implements AbstractFactory {
    
    @Override
    public PhoneFactory phoneFactory() {
        return new XiaoMiPhoneFactory();
    }
    @Override
    public ElectricalFactory electricalFactory() {
        return new XiaoMiElectricalFactory();
    }
}
-------------
public class XiaoMiElectricalFactory implements ElectricalFactory {
    @Override
    public void show() {
        System.out.println("小米電器工廠可以生產電器。。比如小米掃地機器人");
    }
}
-------------
public class XiaoMiPhoneFactory implements PhoneFactory {
    @Override
    public void show() {
        System.out.println("小米手機工廠可以生產小米手機。。。");
    }
}

當然，小米工廠實現抽象工廠，那小米工廠就必須要包含兩個子工廠，手機工廠和電器工廠了。我們也可以創建一個華為工廠，其實是一樣的道理。

AbstractFactory factory = new XiaoMiFactory();

PhoneFactory phoneFactory = factory.phoneFactory();
phoneFactory.show();
--------
小米手機工廠可以生產小米手機。。。

我們從創建的小米工廠中拿出小米手機工廠 然後再執行手機工廠可以做事情，抽象工廠，就是在上面的簡單工廠的層次上進行了再次的抽象，將具體的工廠進行抽象。

假設我們按照上面的邏輯。對於一個工廠，我想要一部手機 我給工廠說一聲就行了。我不關心這個手機 是如何生產出來的。我該怎麼操作？

我稍微將之前的幾個接口作為稍微的改造。

public interface PhoneFactory {
    /**
     * 手機工廠可以做的事情
     */
    PhoneProduct show();
}
---------------
public class XiaoMiPhoneFactory implements PhoneFactory {
    @Override
    public PhoneProduct show() {
        return new PhoneProduct(1, "小米10 Pro");
    }
}
----------
//手機對象
public class PhoneProduct {

    private int id;

    private String name;
}

我們可以創建這樣一個訪問器，通過訪問器對象，將我們需要的對象名稱傳入就好比下單 它能自動匹配工廠，並且調用工廠創建產品 的方法，將我們需要的產品進行創建。

public class AbstractFactoryClient {

    public PhoneProduct createPhone(String name) {

        AbstractFactory factory = null;

        if ("xiaomi" == name) {
            factory = new XiaoMiFactory();
        } else {
            factory = new HuaweiFactory();
        }
        PhoneFactory phoneFactory = factory.phoneFactory();
        
        return phoneFactory.show();
    }
}

測試一下

AbstractFactoryClient factoryClient = new AbstractFactoryClient();
PhoneProduct product = factoryClient.createPhone("xiaomi");
System.out.println(product);
-----------
手機銘牌 編號：1,型號：小米10 Pro

小結

學習完本節，是否對於工廠模式和抽象工廠有了一個深入的了解呢？工廠模式其實在平時的代碼中，還是比較常用的。所以還是需要更加努力學習和使用！

代碼示例

https://gitee.com/mrc1999/Dev-Examples

參考

http://c.biancheng.net/view/1351.html

歡迎關注

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

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

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

背景

Kubernetes中的調度是將待處理的pod綁定到節點的過程，由Kubernetes的一個名為kube-scheduler的組件執行。調度程序的決定，無論是否可以或不能調度容器，都由其可配置策略指導，該策略包括一組規則，稱為謂詞和優先級。調度程序的決定受到其在第一次調度時出現新pod時的Kubernetes集群視圖的影響。由於Kubernetes集群非常動態且狀態隨時間而變化，因此可能需要將已經運行的pod移動到其他節點，原因如下：

• 一些節點不足或過度使用。
• 原始調度決策不再適用，因為在節點中添加或刪除了污點或標籤，不再滿足pod / node親和性要求。
• 某些節點發生故障，其pod已移至其他節點。
• 新節點將添加到群集中。

因此，可能會在群集中不太理想的節點上安排多個pod。Descheduler根據其政策，發現可以移動並移除它們的pod。請注意，在當前的實現中，descheduler不會安排更換被驅逐的pod，而是依賴於默認的調度程序。

Descheduler二次調度

GitHub地址：https://github.com/kubernetes-sigs/descheduler

下面是重要的配置

• configmap.yaml

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: descheduler-policy-configmap
  namespace: kube-system
data:
  policy.yaml: |
    apiVersion: "descheduler/v1alpha1"
    kind: "DeschedulerPolicy"
    strategies:
      "RemoveDuplicates":
         enabled: true
      "RemovePodsViolatingInterPodAntiAffinity":
         enabled: true
      "LowNodeUtilization":
         enabled: true
         params:
           nodeResourceUtilizationThresholds:
             thresholds:
               "cpu" : 30
               "memory": 40
               "pods": 50
             targetThresholds:
               "cpu" : 20
               "memory": 25
               "pods": 15

RemoveDuplicates策略

該策略發現未充分利用的節點，並且如果可能的話，從其他節點驅逐pod，希望在這些未充分利用的節點上安排被驅逐的pod的重新創建。此策略的參數配置在nodeResourceUtilizationThresholds。

節點的利用率低是由可配置的閾值決定的thresholds。thresholds可以按百分比為cpu，內存和pod數量配置閾值 。如果節點的使用率低於所有（cpu，內存和pod數）的閾值，則該節點被視為未充分利用。目前，pods的請求資源需求被考慮用於計算節點資源利用率。

還有另一個可配置的閾值，targetThresholds用於計算可以驅逐pod的潛在節點。任何節點，所述閾值之間，thresholds並且targetThresholds被視為適當地利用，並且不考慮驅逐。閾值targetThresholds也可以按百分比配置為cpu，內存和pod數量。

簡單的說：thresholds是沒有達到資源使用的node視為資源使用率低可以分配做為預選節點， targetThresholds是已經滿足這個條件的node資源緊張要把上面的pod遷移。

• cronjob.yaml

---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: descheduler-cronjob
  namespace: kube-system
spec:
　　#定時任務時間可調
  schedule: "*/10 * * * *"
  concurrencyPolicy: "Forbid"
  jobTemplate:
    spec:
      template:
        metadata:
          name: descheduler-pod
        spec:
          priorityClassName: system-cluster-critical
          containers:
          - name: descheduler
            image: aveshagarwal/descheduler
            #image: us.gcr.io/k8s-artifacts-prod/descheduler:v0.10.0
            volumeMounts:
            - mountPath: /policy-dir
              name: policy-volume
            command:
              - "/bin/descheduler"
            args:
              - "--policy-config-file"
              - "/policy-dir/policy.yaml"
              - "--v"
              - "3"
          restartPolicy: "Never"
          serviceAccountName: descheduler-sa
          volumes:
          - name: policy-volume
            configMap:
              name: descheduler-policy-configmap

• rbac.yaml

---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: descheduler-cluster-role
  namespace: kube-system
rules:
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create", "update"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list", "delete"]
- apiGroups: [""]
  resources: ["pods/eviction"]
  verbs: ["create"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: descheduler-sa
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: descheduler-cluster-role-binding
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: descheduler-cluster-role
subjects:
  - name: descheduler-sa
    kind: ServiceAccount
    namespace: kube-system

kubectl apply -f 執行上面三個文件,查看日誌如有滿足再次調度條件的 會重新發起二次調度均衡node資源。

 

 

 

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?