近日，豐田和克萊門森大學國際汽車研究中心合作，為下一代的司機創造出了一個全新的概念電動汽車——uBox。

豐田曾經發起了一個名為“Deep Orange”的合作專案，uBox正是項目的結晶。

據瞭解，豐田和克萊門森大學在過去的兩年裡一直致力於這款概念車的開發工作。uBox概念車使用了方形的設計、自動式車門，並用複合碳纖維和鋁合金支撐著一塊弧形玻璃。其全新設計的套件裝備均極大程度提升了整車的舒適性與功能性。

豐田表示汽車的內部配置可以根據司機的品味進行配置。座位安裝在導軌上，並且通風口、內飾、車內顏色方案都可以定制，可以下載新設計然後用3D印表機重新構建。它還擁有一個110伏的插座，可以為筆記型電腦等眾多設備充電。

至於動力系統方面，除了豐田將在uBox上搭載一台電動機引擎之外，目前並沒有獲得更多這方面的消息。

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

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

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

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

在軟件業，AOP為Aspect Oriented Programming的縮寫，意為：面向切面編程，通過預編譯方式和運行期動態代理實現程序功能的統一維護的一種技術。AOP是軟件開發中的一個熱點，利用AOP可以對業務邏輯的各個部分進行隔離，從而使得業務邏輯各部分之間的耦合度降低，提高程序的可重用性。

比如說三層的調用：UI => BLL => DAL，正常來說我們會在UI層調用BLL層某個類的某個方法，然後BLL層某個類的某個方法又會調用DAL層某個類的某個方法，可以說通常情況下我們都是這麼乾的；如果說UI調BLL、BLL調DAL是縱向的話，那麼AOP就是橫向的，AOP可以做到在調用BLL層或DAL層任意方法之前之後做一些統一的邏輯處理。

AOP的典型應用場景：日誌記錄、權限驗證、異常處理、緩存等

目前，可以實現AOP的類庫也有很多，如下：

AspectCore
Unity
Castle DynamicProxy
Dora.Interception

但是在.net core中有DispatchProxy類（命名空間:System.Reflection），提供實例化代理對象和處理其方法調度的機制，藉助它我們可以自己實現AOP，直接看示例

定義一個消息接口IMessage，其中有一個發送消息Send和接收消息Receive的方法定義：

    public interface IMessage
    {
        void Send(string content);
        void Receive(string content);
    }

定義电子郵件類EmailMessage實現消息接口IMessage，實現使用电子郵件發送和接收消息：

    public class EmailMessage : IMessage
    {
        public void Send(string content)
        {
            Console.WriteLine("Send Email:" + content);
        }
        public void Receive(string content)
        {
            Console.WriteLine("Receive Email:" + content);
        }
    }

定義日誌攔截器LogDispatchProxy 繼承自DispatchProxy類，重寫基類Invoke方法並在目標方法調用前後加上所需業務邏輯；然後定義TargetClass屬性，該屬性是目標方法所屬類的實例

    public class LogDispatchProxy : DispatchProxy
    {
        public object TargetClass { get; set; }
        protected override object Invoke(MethodInfo targetMethod, object[] args)
        {
            Write("方法執行前");
            var result = targetMethod.Invoke(TargetClass, args);
            Write("方法執行后");
            return result;
        }

        private void Write(string content)
        {
            Console.ForegroundColor = ConsoleColor.Red;
            Console.WriteLine(content);
            Console.ResetColor();
        }
    }

使用：

    class Program
    {
        static void Main(string[] args)
        {
            //使用DispatchProxy類的靜態方法Create生成代理類，其中Create是個泛型方法，泛型有兩個值，第一個值必須是接口，第二個值必須是DispatchProxy的子類
            IMessage messageDispatchProxy = DispatchProxy.Create<IMessage, LogDispatchProxy>();
            //創建一個實現了IMessage接口的類的實例，並賦值給代理類的TargetClass屬性
            ((LogDispatchProxy)messageDispatchProxy).TargetClass = new EmailMessage();
            messageDispatchProxy.Send("早上好");
            Console.WriteLine("=======================================");
            messageDispatchProxy.Receive("中午好");

            Console.ReadKey();
        }
    }

執行結果

我的理解：通過DispatchProxy.Create創建的代理類messageDispatchProxy 就是一個LogDispatchProxy類，並且利用我們提供的的實例實現了IMessage接口，所以messageDispatchProxy可以強轉為LogDispatchProxy或IMessage

至此，我們沒有通過任何第三方類庫，自己實現了一個AOP

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

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

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

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

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

電動車製造商 Tesla 的名字來自物理學家 Nikola Tesla，現在一家名叫 Nikola 的廠商則把目標放在電動卡車上，該公司推出了兩款電動卡車新品，其中純電動款單次充電可行駛 125 英里，油電混合的卡車則可以連續行駛 800 至 1,200 英里，無法充電或者加油。   Tesla 的目標市場取代人們日常出行乘坐的汽車，Nikola 同樣是製造電動車，但卻把目光放在了主要用於運輸的卡車上，致力於用電動車技術來升級傳統卡車。

該公司發表了兩款產品，Nikola One 是一款油電混合卡車，雖然目前還是一款概念車，但廣闊的商業前景已經吸引了巨大的關注，如果 Nikola 公司能夠最終把電動卡車推向市場，這將對卡車產業帶來巨大的影響。Nikola One 單次充電和加油，可連續行駛 800 至 1,200 英里 ，配置了 320kWh 電池，採用電池功能的每英里行駛成本僅是柴油發動機驅動行駛成本的五成。

Nikola One 能夠達到如此驚人的里程，主要是由於渦輪機和再生制動技術，在卡車行駛的同時能夠在內部給電池二次充電。   據 Nikola 公司透露，渦輪輸出了 400 kW 清潔能源為電池充電，這和其他廠商的油電混合車所採用的技術完全不同，多項技術都是第一次應用在卡車上。在滿載的狀況下，卡車從 0 到 65 英里的啟動時間不到 30 秒，上坡行駛也能夠達到了每小時 65 英里的速度，性能出眾。Nikola 公司的創始人、CEO Trevor Milton 表示，這款油電混合卡車聽起來可能像小說裡寫的，但團隊正在和一些美國最聰明的人合作，把這款卡車從實驗室帶向市場。Nikola One 電動卡車將改變交通運輸業的未來，消費者還需要等待一段時間。將在 2016 年年底展示原型車，定價至少高於 35 萬美元。

（本文授權轉載自《》─〈〉）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

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

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

作者 | 司徒放（姬風） 阿里巴巴技術專家

本文整理自司徒放（姬風）題目為《開源的黃金時代，阿里巴巴雲原生開源的探索與實踐》的演講。
關注“阿里巴巴雲原生”公眾號，回復關鍵詞“開源”即可下載本文 PPT。

導讀：從擁抱開源、貢獻開源、自主開源，到賦能開源，開源已升級為阿里技術戰略之一，且正為開發者源源不斷地輸送切實可見的價值。雲原生是阿里開源的重要領域，短短几年，以 K8s 為核心的雲原生開源生態迅猛發展，這是全世界開發者合作傑出成果，也是開源力量的結晶。

阿里巴巴的應用架構演進

大家好，我是司徒放，目前在阿里巴巴負責阿里雲的應用平台和微服務產品線。在和大家分享我們在雲原生應用方面的探索之前，先和大家介紹一下阿里巴巴在整個應用架構方面的演進歷程。

今年是阿里巴巴成立的二十周年，二十年前，阿里巴巴使用的這個應用的架構，還是單體應用模式，它有很多的業務模塊都在一個應用裏面，各個業務都在一個應用裏面開發，這個架構的一個好處是簡單，也非常容易部署，對小的創業公司來說是很方便的。它的缺點在於團隊變大變多之後，不能滿足快速迭代要求，因為每一個業務它需要去發布的時候，都需要在同一個應用上做修改、發布，當這個業務迭代非常快的時候，它同時的一個併發修改就非常多。

所以在 2008 年的時候，阿里巴巴就引進到了微服務架構，只是當時並不叫微服務，而是叫服務化架構。各個業務模式就按照服務的邊界來拆分，這是比較松耦合的一種方式，一個微服務應用是無狀態的，可以快速擴展實例。而且某個實例有異常比如宕機時會可以自動下線，不會影響整個服務架構的穩定性。微服務架構也比較容易推動整個互聯網公司的快速迭代需求。

大概三年前，阿里巴巴就走向了雲原生的架構。這是一個天然適合雲的、能夠充分利用雲的彈性能力和標準雲服務，給整個阿里巴巴的電商降低機器的準備成本，特別是類似於在大促雙十一需要很多機器去支撐，但是大促結束之後，這些機器有一半以上就可以歸還到雲上。

這個時候，阿里巴巴就在往雲原生的方向去邁進，而且通過整個雲服務能夠更快地加快整個阿里巴巴的技術構建。而且雲原生架構，是一個比較開放、標準、沒有侵入性的技術架構。

阿里巴巴在雲原生的開源進程

在阿里巴巴進入到了雲原生之後，我們看一下阿里巴巴在開源方面做了一些什麼樣的事情呢？

運維領域

首先，整個雲原生架構裏面最重要、最關鍵的一個基石就是 Kubernetes。
阿里巴巴在兩年前，就在大規模的落地 Kubernetes 的整套技術用來做我們機器資源的調度和管理。在內部有數十萬台級別的機器以及上百萬級別的容器規模，直接拿開源的 Kubernetes 到這種生產規模下是用不起來的，所以我們在上面做了很多性能優化，包括針對規模上的改造，使得整個 Kubernetes 在阿里巴巴內部能夠很順暢地 run 起來，阿里巴巴也在不斷地向上游去貢獻我們內部實踐和優化的代碼。
除了 Kubernetes 之外，在整個雲原生生態里還有像容器、etcd，我們也在不停地優化它的規模能力以及安全隔離方面的一些能力。同時，也開源了內部使用的蜻蜓（Dragonfly）用來做大規模的鏡像快速分發。

開發領域

在開發領域，阿里巴巴很早就已經使用了微服務架構，也對外進行了開源，比如說 Apache Dubbo，這個是比較知名的 RPC 框架；還有去年開源的 Nacos ，作為阿里巴巴集團支撐大規模的服務註冊發現、配置推送一個組件；另外，還有 Spring Cloud Alibaba，基於阿里開源的組件提供了一整套 Spring Cloud 最佳實現；還有像支撐整個阿里巴巴高可用的 Sentinel、以及 Apache RocketMQ 消息隊列，都是我們在開發領域做的開源。

這些組件其實隨着阿里巴巴進入雲原生時代之後，也在逐步結合雲原生做一些改進，比如說 Apache Dubbo，會更好地去適配我們未來的微服務 Service Mesh 架構，它會理解 Istio 的 xDS 協議，成為一種數據面；比如 Nacos，它為 Service Mesh 的 Istio 提供 MCP 協議的對接，成為雲原生微服務和傳統微服務互通的橋樑。

應用

在開發領域和運維領域之間，其實我認為還有一個很大的空缺，就是專門用來連接整個開發和運維的應用這一塊。

對於開發階段，寫完代碼之後交付的是一個應用包，而這個應用包也是整個運維繫統上運行的一個基礎顆粒。我們認為現在在雲原生階段，缺少了一個很好的應用交付和運維標準，大家在不同的公司會看到每個公司都有不一樣的運維平台，應用的部署和交付都沒有辦法被標準化。我們現在進入雲原生時代，推崇的是標準、開放，所以我們認為在這一塊上面還有很大的機會去做進一步的應用標準建設，這是我接下來想要和大家重點分享的一個話題。

雲上應用交付和運維的痛點

先看一下雲原生在交付和運維方面有哪些痛點呢？

剛剛也講到了，在進入到了微服務之後，我們面臨的一個問題就是應用的實例數會越來越多，會到成百上千的規模不斷往上增長；另外還有我們部署的環境也變得越來越多，比如說現在有不同的雲廠商，以及我們有很多專有雲的自建機房的輸出；另外還有很多自建的環境，這些環境多樣化以及我們應用在運行時它會以容器的方式去運行，可能還是以傳統的虛擬機的方式去運行，或者它會以函數的方式去運行，但是運行時也會有很多不一致，比如不同的環境、或運行時的不一致，會導致整個分佈式運維體系變得越來越複雜，它的監控、日誌採集也是一個很大的挑戰。

當這些應用已經放到雲上去運行的時候，由於很多的雲服務並沒有被標準化，很多這種雲的能力需要集成到應用上的時候，也會有很大集成的困難。而這些雲上應用運維的痛點以前也有類似的，我們可以跟過往的解決方案做一個對比。

過往解決方案

首先，是類似 Ansible、Puppet 這些基礎設施運維自動化的工具。這些工具對整個運維效率起到了很大的提升作用，減輕了運維同學的工作量，但是它使用的是一些自應用的模塊，而且它的概念是偏向於腳本運維的方式，非常的底層。

隨後出現了類似 Cloud Foundry 、Heroku 這種比較經典的應用平台，這些應用平台是以應用為中心去做運維和交付，往上把運維的工作進行了一個抽象，按照 buildpack 的方式去做運維和交付，通過 buildpack 的方式，可以簡化整個應用運維的工作，但是 buildpack 本身覆蓋的範圍比較窄，在運維和交付方面，缺乏一些運維交付的標準，所以它的可擴展性是比較差的。

隨着 Docker 容器的橫空出世，打破了傳統基於 buildpack 的應用交付模式，所以就出現了新一代的容器管理平台，而 Kubernetes 成為了雲原生時代一個新的容器平台事實標準。Kubernetes 本身提供了很多基礎服務抽象，比如說 Deployment、Service。在社區裏面它有一句很著名的定位：“Kubernetes is the platform for platforms.”也就是說，Kubernetes 定位是構建平台的平台，能夠簡化構建應用平台的複雜度，它不會再去做上層基於應用的抽象。大家可以發現歷史總是那麼相似，從過去的運維工具到後來基於應用的抽象，到現在容器出現打破運維格局，重新對這個領域進行洗牌，自然，在雲原生時代需要一個對應交付和運維應用的平台。

從過往解決方案引發的思考

關於雲原生時代的應用抽象，我們要做一個思考：我們需要什麼樣的應用抽象呢？

首先，它需要解決我們運維交付的一個複雜度，以及屏蔽底層細節差異。無論什麼時候，都是應用平台需要解決的問題。另外，參考我們過去比較傳統的應用平台的問題，比如說 buildpack 這種方式，它存在不通用/不易於擴展的問題，我們認為接下來的應用抽象，它應該要具備在應用運維方面更加通用、可擴展的描述能力。

除此之外，我們在推廣應用抽象的時候，還是要採用開源和社區的方式去推進，因為未來一定是更加標準和開放的，我們推廣這個應用抽象，就是希望有更多開發和運維工作者，能夠給這個標準提供更多的建議，能夠通過整個社區進一步推動整個應用交付和運維標準的發展。

Open Application Model – 開放應用模型

在上個月中旬，阿里雲和微軟聯合發布了“Open Application Model（開放應用模型）”這一個開源項目。我們希望通過這個開放應用模型，解決“在雲原生時代缺乏一種應用交付標準”的問題。（“Open Application Model -開放應用模型”後面簡稱為“OAM”）

OAM 的三種角色

OAM 裏面有三種不同的角色。

• 首先是應用開發。很明顯，應用開發是負責編寫業務邏輯的。比如說它會寫 Spark、Wordpress、Spring Cloud 等微服務的程序，它寫完這個微服務的程序之後呢，會按照 OAM 標準編寫一段應用定義；

• 第二個是應用運維的角色，就是負責應用的交付與運維；

• 第三個角色是基礎設施平台。基礎設施平台在 OAM 里的一個重要定位，在於它要將自己的基礎服務能力抽象成可被複用、被重用的模塊，並提供給開發和運維人員去使用。

OAM 核心概念解讀

下面為大家解讀以上的三個角色對應的三個核心概念。

• 首先是 Component。它是被開發人員定義的一個可被重用的應用組件，這個應用組件描述的就是這個應用它運行的方式；

• 第二個重要概念是 Trait。它是一種應用的運維特徵，是由基礎設施平台這個角色定義的，而這個定義它包含了可組合的應用運維特徵，這個特徵是其實是這個平台可以提供出來的某種運維能力抽象；

• 最後一個是 ApplicationConfiguration。運維人員負責把 Component 和 Trait 兩個綁定在一起，並且作為一個具體的實例化，生成了這個應用配置（ApplicationConfiguration）之後，就可以把應用部署起來。

用 OAM 描述的應用配置示意

接下來是一個具體的用 OAM 描述的應用配置文件（上圖文件做了一定內容簡化，具體以下面的 yaml 文本為準）。

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: wordpress
spec:
  workloadType: core.oam.dev/v1alpha1.Server
  containers:
    - name: test
      image: docker/wordpress:latest
      env:
        - name: key1
          fromParam: test-key
      ports:
        - type: tcp
          containerPort: 9999
          name: http
    parameters:
    - name: test-key
      type: string
---
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: wordpress-app
spec:
  components:
    - name: wordpress
      instanceName: wordpress-instance
      parameterValues:
        - name: replicas
          value: 3
        - name: test-key
          value: value-from-ops
      traits:
        - name: service
          parameterValues:
            - name: portMapping
              value: 
                - protocol: "TCP"
                  port: 52014
                  targetPort: 9999
        - name: rollout
          parameterValues:
            - name: canaryReplicas
              value: 1

由運維人員編寫的 ApplicationConfiquration 文件，它將 Component 和 Trait 兩個概念綁定在一起。首先裏面描述運維要部署一個叫 wordpress-app的應用，它引用了一個叫 wordpress 的 Component。這是開發人員在另一個配置文件 Component 定義的，他除了定義 wordpress 應如何運行（比如配置鏡像位置）以外，還允許運維配置運行實例的副本數以及運行時環境變量 test-key 的值。在 ApplicationConfiquration 里同時引用了兩個運維特徵，運維人員會填寫這個應用需要一個負載均衡，要做外網的端口映射，部署時需要採用金絲雀發布策略。這個文件對應到實際上的部署階段會變成如上圖右側所示，上面會有一個負載均衡，比如在雲上運行時，就會使用 SLB 去做負載均衡的自動分發，會給它配置外網 IP 和內外端口映射。

通過這個簡單的 yaml 文件，大家就可以了解到這個應用怎麼做快速部署，並且描述運維要具備什麼能力。

OAM 的設計理念

給大家總結一下，我所認為的 OAM 的重要的設計理念。

• 首先第一個是配置即代碼。所有的 OAM 上面的運維和交付的操作都會使用配置的方式，完全通過 yaml 文件去完成所有的交付運維配置；

• 第二個是依賴倒置。這個依賴倒置有點像 JAVA Spring 開發者使用 IoC 或者 DI 的這種模式，在寫這個應用配置的時候，只是依賴應用標準抽象，而這個標準抽象背後的實現實際上是由 OAM 的運行時去做“注入”，通過這個方式就使得我們的應用運維不依賴於我們具體的運行環境；

• 第三個是重要的設計理念就是角色關注點分離。剛剛上面講過 OAM 里的三種不同的重要角色：開發、運維以及基礎設置平台。這三種角色只需要編寫對應不同的配置文件，互相解耦。這樣開發不需要關心應用是怎麼運維的，只需要把運行時需要的配置暴露並描述出來；基礎平台只需要把平台能力提煉成 Trait；最終由運維人員把開發需要的參數和運維需要的能力進行結合。

• 第四個就是整個 OAM 的設計是一個可組合可擴展的方式。它會通過讓我們剛剛說到的 Traits 能夠按需組合、重用、移植和擴展。

EDAS & OAM

上面我們說了這麼多其實都是比較一些概念性的東西，接下來我們看一下，在阿里巴巴的雲產品 EDAS 對 OAM 所做一些落地方面的嘗試，這也是第一個在實際生產上面基於 OAM 對外可開放使用的雲產品。

下面會用 EDAS 為例，給大家做一個介紹，講解一下 OAM 具體怎麼運作。

EDAS 是什麼？

首先介紹一下 EDAS 是阿里雲上面的一個雲產品，它扮演着我剛才講到的類似於一個應用平台的一個角色：

• EDAS 從開發方面就提供了開發框架給我們雲上的開發者去使用；
• 開發者開發完程序之後，會把應用交付到 EDAS 上面去進行部署；
• 與此同時 EDAS 會對這個應用進行監控診斷，根據容量情況進行實例彈性伸縮；
• EDAS 會對上面的微服務進行註冊發現、服務治理；
• 提供應用的高可用保護，比如限流降級、熔斷等。

這些是 EDAS 作為應用平台在阿里雲上的產品定位。

EDAS 支持 OAM 的運行示意圖

那麼它在支持 OAM 在運行的時候又是什麼樣的呢？

如圖所示，一個開發人員，他首先需要去編寫一個按照 OAM 標準為參考去定義一個 Component。這個 Component 裏面會定義如開發應用類型是什麼樣子，比如它的鏡像路徑、它需要多大的存儲空間，以及它的環境變量是什麼樣子，這些都是開發人員在開發的時候需要去描述的內容。

對於阿里雲來說，它是一個基礎設施平台的身份。它在上面其實有很多運維的能力，比如說像監控報警、塊存儲、需要發布策略和彈性伸縮的策略。EDAS 會把這些平台能力抽象成一個一個獨立的 Trait，開放給運維人員使用。

在需要部署應用的時候，運維人員會選擇 EDAS 上提供的 Trait 並填寫相關參數，同時也設置好開發人員的 Component 的參數，這作為一次應用部署，生成了 ApplicationConfiguration 提交給 EDAS。

EDAS 作為 OAM 的運行時，在讀取到這份部署配置后，它會去實現 Trait 提供相應的運維特徵動作，比如說運維描述需要一個塊存儲，那麼 EDAS 會在阿里雲上面去申請一個具體的塊存儲對象，並綁定到這個應用上面。同時 EDAS 會提供一個容器環境（如 Kubernetes）去運行開發者定義的 Component 的工作負載，比如購買 ECS，配置好容器環境，把環境變量傳給容器，使 Component 能夠正常運行。

以上就是整個 EDAS 支持 OAM 的一個運行示意圖。

EDAS 支持 OAM 的對比

那麼 EDAS 在支持 OAM 之後，它的使用情況又會發生怎樣的變化呢？

在沒有使用 OAM 的時候，客戶需要和系統解釋我要做些什麼事情、我要怎麼做這個事情。比如說，他需要申請 5G NAS 存儲，並且要把它掛載到某個機器的某個目錄上面；或者他還有一個監控的需求，他需要告訴系統現在有一個業務指標文件，需要被監控採集，他要去設置這個文件的指標處理規則，最後把這個指標存儲成時間序列數據，並且設置報警閾值。在使用 OAM 之後，它就變成了描述式，他只要描述我需要什麼東西就夠了。比如開發者可以說這個目錄上面需要有 5G 的外置可讀寫存儲就夠了，具體這 5G 存儲怎麼申請是由 OAM 運行時去幫助解決的。另外，在監控的時候，他只需要描述自己的這個應用需要被監控、哪個指標需要被監控並報警就夠了，他不需要了解對接到具體是哪一個監控系統，他不需要去關心這些事情。

原來很多雲產品或者原來很多自定義運維平台都是需要依賴特定的 API 或者 CLI 這種模式去做運維的，這個時候應用要遷移到另外一個運維平台，它的代碼、鏡像、二進制包可以帶走，但是它的很多運維的設施、運維的配置包括監控的配置，這些東西都是只能留在這個平台上的，沒有辦法很容易地遷移到另外一個平台上面。而通過 OAM，可以將平台所有的運維配置以 yaml 導出，並且能夠很快地導入到另外一個環境、甚至是另一個應用平台上，整個系統會變得更加標準。

在使用 OAM 以前，運維人員需要去學習很多知識，比如使用的是 Kubernetes，他需要去了解整個容器和 Kubernetes 的使用方式，他要做定製和拓展就需要去學習 Kubernetes。如果他是從虛擬機的模式切換到容器的運維模式，這個時候他就需要很多時間去理解容器和虛擬機運維之間的差異。遷移到 OAM 之後，相當於 OAM 屏蔽了整個平台底層的細節，所以使得整個運維平台的 OAM 配置沒有多大差別。

最後一點就是定製的難度上面。剛剛也講到過，這個是 OAM 的一個重要的目標，讓整個運維的擴展能夠更容易的被發現、被組合、被替換。在使用 OAM 之前，運維的邏輯都散落在腳本裏面，或者說都在運維平台內部，這個時候很難去統一管理。而一套 OAM 的運行環境是可以自描述的，可以非常容易把平台提供的 Trait、Component 工作負載羅列出來，使用者可以替換或增加新的 Traits，在運行應用時可以自由選擇和組合這些 Traits。

OAM 後續規劃，歡迎社區貢獻

以上講了 OAM 相關的一些基本內容，實際上 OAM 剛剛開源還有很多需要補充和完善的地方，這裏也列出了 OAM 上最近這半年的計劃，希望大家能夠參与社區，在上面貢獻更多的想法。

主要有幾個規劃：

• 易用性方面
  • 提供 Kubernetes 一鍵導入工具；
  • 增加應用之間的依賴描述；
  • 不斷完善 OAM 的標準定義（Spec）；
  • 社區提供更多的 OAM 上的實踐案例；
• OAM 開發方面
  • 盡量進一步去做開發的簡化，包括一些字段的校驗工具、編寫 Controller 框架，方便更高效的開發 Trait 等實現；
  • 另外，OAM 它本身不僅僅是一個標準，它還提供了一個名為 Rudr 的參考開源實現；
• 功能方面
  • 提供新的基礎 Traits 去簡化應用運維管理，比如常見的流量管理、藍綠髮布；
  • 能對接更多的應用平台，比如說像 Windows、IoT 這樣的平台。

最後，我的演講就到這裏，謝謝大家！喜歡 OAM 的朋友可以掃描下方二維碼，謝謝！

更多詳細信息請關注“”。

“ 阿里巴巴雲原生微信公眾號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公眾號。”

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

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

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

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

目錄

示例代碼託管在：

博客園地址：

華為雲社區地址：

附件PPT來自開發文檔。術語里的cc指的是Chromium Compositor

一直以來都想了解瀏覽器合成層的運作機制，但是相關的中文資料大多比較關注框架和開發技術，這方面的資料實在是太少了，後來在chromium官方網站的文檔里找到了項目組成員malaykeshav在 2019年4月的一份關於瀏覽器合成流水線的演講PPT，個人感覺裏面講的非常清楚了，由於沒有找到視頻，有些部分只能自行理解，本文僅對關鍵信息做一些筆記，對此感興趣的讀者可以在文章開頭的github倉庫或附件中拿到這個PPT自行學習。

摘要

1.合成流水線

合成流水線，就是指瀏覽器處理合成層的工作流程，其基本步驟如下：

大致的流程就是說Paint環節會生成一個列表，列表裡登記了頁面元素的繪製指令，接着這個列表需要經過Raster光柵化處理，並在合成幀中處理紋理，最後的Draw環節才是將這些紋理圖展示在瀏覽器內容區。

2. 預定義UI層

chromium中預定義了一些指定類型的UI層，大致分為：

• Not Drawn – 為了處理透明度或濾鏡效果、transform變形或者clip剪裁的非繪製層
• Solid color layer – 固有顏色層
• Painted texture layer – Texture紋理會在這個層執行paint渲染和後續的rasterized光柵化任務
• Transferable resource layer – 共享資源層，可能是GPU裏面的Texture紋理也可能未來會發給GPU的位圖
• Surface layer – 臨時佔位層，因為自頂向下遍歷layer樹時子樹都還沒處理，需要先佔位最後再填充
• Nine patch layer – 用於實現陰影的層

3. paint是什麼意思

每個層layer是由若干個views組成的，所謂paint，就是每個views將自己對應圖形的繪製指令添加到層的可展示元素列表Display Item List里，這個列表會被添加到一個延遲執行的光柵化任務中，並最終生成當前層的texture紋理（可以理解為當前層的繪製結果），考慮到傳輸性能以及未來增量更新的需求，光柵化的結果會以tiles瓦片形式保存。在chrome中也可以看到頁面瓦片化拆分的結果:

4. 分層的優勢和劣勢

分層的優勢和劣勢也在此進行了說明，和之前我們主動思考的答案基本一致（暗爽一下）。

5. 視圖屬性及其處理方式

views中支持的屬性包含Clip剪裁，transform變換,effect效果（如半透明或濾鏡等）,mask遮罩，通常按照後序遍歷的方式自底向上進行遍歷處理。

clip剪裁的處理方式是在父節點和子節點之間插入一個剪裁層，用來將其子樹的渲染結果剪裁到限定的範圍內，然後再向上與父級進行合併；

transform變換直接作用於父節點，處理到這個節點時其子樹都已經處理完畢，直接將整體應用變形即可；

effect效果一般直接作用於當前處理的節點，有時也會產生交叉依賴的場景；

PPT第40頁中在介紹effect效果處理時描述了兩種不同的透明度處理需求，從而引出了一個Render Surface的概念，它相當於一個臨時的層，它的子樹需要先繪製在這個層上，然後再向上與父節點進行合併，屏幕就是是根級的Render Surface。

6. Quads

Layer遍歷處理輸出的結果被稱為Quads（從意思上理解好像就是指輸出了很多個矩形方塊），每個quad都持有它被繪製到目標緩衝區所需要的資源，根據它持有的資源不同可以分為：

• Solid Color-固定顏色型
• Texture– 紋理型
• Tile– 瓦片型
• Surface– 臨時繪圖表面型
• Video – 視頻幀型
• Render Pass – Render Surface類型的佔位區，Render Surface子樹處理完后填充到關聯的Render Pass

7. Compositor Frame

合成層真正的工作要開始了，主角概念Compositor Frame(合成幀)登場，它負責將quads合併繪製在一起，膠片里59-62頁非常清楚地展示了合成的過程，最終輸出的結果就是根節點的紋理。

chromium是多進程架構，Browser Process瀏覽器進程會對菜單欄等等容器部分的畫面生成合成幀來輸出，每個網頁的Render Process渲染進程會對頁面內容生成合成幀來輸出，最終的結果都被共享給GPU ProcessGPU進程進行聚合併生成最終完整的合成表面，接着在Display Compositor環節將最後的位圖展示在屏幕上。

8. 關於光柵化以及渲染方式

膠片里並沒有描述具體的光柵化的處理過程，但是layer輸出的quads看起來應該是光柵化以後的結果，推測應該是處理Display Item List中的繪圖指令時也和WebGL類似，經過頂點着色器和片元着色器的遍歷式處理機制，並在過程中自動完成像素插值。

9.【重要】軟件渲染和硬件渲染的區別

聲明：本節內容是個人理解，僅用作技術交流，不保證對！

軟件渲染和硬件渲染的區別對筆者而言一直非常抽象，只是知道基本概念。後來在（國內可能無法訪問）中《Compositor Thread Architecture》這篇合成器線程架構的文章中找到了一些相關描述，也解開了筆者心中一直以來的疑惑，相關部分摘抄如下：

Texture Upload

One challenge with all these textures is that we rasterize them on the main thread of the renderer process, but need to actually get them into the GPU memory. This requires handing information about these textures (and their contents) to the impl thread, then to the GPU process, and once there, into the GL/D3D driver. Done naively, this causes us to copy a single texture over and over again, something we definitely don’t want to do.

We have two tricks that we use right now to make this a bit faster. To understand them, an aside on “painting” versus “rasterization.”

• Painting is the word we use for telling webkit to dump a part of its RenderObject tree to a GraphicsContext. We can pass the painting routine a GraphicsContext implementation that executes the commands as it receives them, or we can pass it a recording context that simply writes down the commands as it receives them.
• Rasterization is the word we use for actually executing graphics context commands. We typically execute the rasterization commands with the CPU (software rendering) but could also execute them directly with the GPU using Ganesh.
• Upload: this is us actually taking the contents of a rasterized bitmap in main memory and sending it to the GPU as a texture.With these definitions in mind, we deal with texture upload with the following tricks:
• Per-tile painting: we pass WebKit paint a recording context that simply records the GraphicsContext operations into an SkPicture data structure. We can then rasterize several texture tiles from that one picture.
• SHM upload: instead of rasterizing into a void* from the renderer heap, we allocate a shared memory buffer and upload into that instead. The GPU process then issues its glTex* operations using that shared memory, avoiding one texture copy.The holy grail of texture upload is “zero copy” upload. With such a scheme, we manage to get a raw pointer inside the renderer process’ sandbox to GPU memory, which we software-rasterize directly into. We can’t yet do this anywhere, but it is something we fantasize about.

大概翻譯一下，方便英語水平一般的小夥伴理解，GPU處理圖片的方式是按照Texture進行貼圖的，對此不熟悉的小夥伴可以查看筆者以前發的有關Three.js相關的博文。

紋理上傳:
處理紋理的挑戰之一就是它是在渲染進程（可以理解為單個Tab網頁的進程）的主線程里進行的，但是最終需要將其放入GPU內存。這就需要將紋理數據遞交給合成器線程，然後再交給GPU進程（Chromium架構里有專門的GPU進程用來專門處理和GPU之間的協作任務），最後再傳遞給底層的Direct3D或OpenGL（也就是圖形學的底層技術），如果只是按照常規流程來處理，就會需要一次又一次來複制生成的紋理數據，這顯然不是我們想要的。
我們現在使用了兩個小方法來使這個流程變得快一點。它們分別作用於painting（繪製）和rasterization（光柵化）兩個階段。

• 1號知識點！！！Painting我們用來告訴webkit為RenderObject Tree的來生成對應的GraphicsContext。通過給painting routine（繪製流程）傳遞一個GraphicsContext的具體實現來執行這些已經編排好的繪製命令，也可以傳遞一個record context（記錄上下文）只是簡單地把繪圖命令都記錄下來。
• 2號知識點！！！Rasterization（光柵化）是指Graphics context關聯的繪圖命令實際被執行的過程。通常我們使用CPU（也就是軟件渲染的方式）來執行光柵化任務，也可以直接使用GPU來渲染（也就是硬件渲染的方式）。
• 上傳：指在主線程存儲區獲取到光柵化以後的位圖內容然後將它作為紋理上傳給GPU的過程，考慮到上述已經提及的定義，上傳過程是如下來處理的：
  • 瓦片繪製：我們在webkit中使用recording context來簡單地記錄Graphics Context的操作指令，將它存儲為SkPicture類型（直接使用軟件光柵化時生成的是SkBitmap類型），隨後可以從一張picture裏面光柵化處理得到多個紋理瓦片。
  • 共享內存：在軟件渲染的方式中，光柵化的結果會被存儲在renderer進程的堆內存里，現在不這樣搞了，我們重新分配了一塊共享緩衝區，然後通過它來傳遞相關對象，GPU進程隨後在獲取紋理時直接從共享內存中獲取就行了，這樣就避免了數據的拷貝。
    總的來說，紋理上傳的過程幾乎是零拷貝的。利用這樣的結構，我們在renderer進程（也就是網頁的渲染進程）的沙箱環境內也可以獲取到指向GPU 內存的指針，而在軟件光柵化的過程中，是直接將位圖結果放在這裏的。

• Painting: this is the process of asking Layers for their content. This is where we ask webkit to tell us what is on a layer. We might then rasterize that content into a bitmap using software, or we might do something fancier. Painting is a main thread operation.
• Drawing: this is the process of taking the layer tree and smashing it together with OpenGL onto the screen. Drawing is an impl-thread operation.
• painting:表示的過程是向Layers對象查詢層內容，也就是讓webkit告訴我們每一層上面到底有什麼。接下來我們就可以使用軟件光柵化的方式將這些內容處理為位圖，也可以做一些更牛的事情，painting是一個主線程行為。
• drawing：是指將Layer中的內容用OpenGL繪製在屏幕上的過程，它是另一個線程中的操作。

概念比較多沒有基礎的讀者可能理解起來有難度，我嘗試用自己的話複述一下：

【軟件渲染】的模式下，在paint時會直接利用Graphics Context繪圖上下文將結果繪製出來，在一個SkBitmap實例中保存為位圖信息；【硬件渲染】的模式下，在paint時傳入一個SkPicture實例，將需要執行的繪圖命令保存在裏面先不執行，然後通過共享內存將它傳給GPU進程，藉助GPU來最終去執行繪圖命令，生成多個瓦片化的位圖紋理結果（OpenGL中頂點着色器向片元着色器傳遞數據時可以自動進行數據插值，完成光柵化的任務）。 純軟件渲染里嚴格說是沒有合成層概念的，因為最終輸出的只有一張位圖，按照順序從下往上畫，和畫到一個新層上再把新層貼到已有結果上其實是一樣的。

不管使用哪種途徑，paint動作都是得到位圖數據，而最終的draw這個動作是藉助OpenGL和位圖數據最終把圖形显示在显示器上。

所以【硬件渲染】就是渲染進程把要做的事情和需要的數據都寫好，然後打包遞給GPU讓它去幹活。

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

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

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

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

一、HttpBasic模式的應用場景

HttpBasic登錄驗證模式是Spring Security實現登錄驗證最簡單的一種方式，也可以說是最簡陋的一種方式。它的目的並不是保障登錄驗證的絕對安全，而是提供一種“防君子不防小人”的登錄驗證。

就好像是我小時候寫日記，都買一個帶小鎖頭的日記本，實際上這個小鎖頭有什麼用呢？如果真正想看的人用一根釘子都能撬開。它的作用就是：某天你的父母想偷看你的日記，拿出來一看還帶把鎖，那就算了吧，怪麻煩的。

舉一個我使用HttpBasic模式的進行登錄驗證的例子：我曾經在一個公司擔任部門經理期間，開發了一套用於統計效率、分享知識、生成代碼、導出報表的Http接口。純粹是為了工作中提高效率，同時我又有一點點小私心，畢竟各部之間是有競爭的，所以我給這套接口加上了HttpBasic驗證。公司里隨便一個技術人員，最多只要給上一兩個小時，就可以把這個驗證破解了。說白了，這個工具的數據不那麼重要，加一道鎖的目的就是不讓它成為公開數據。如果有心人破解了，真想看看這裏面的數據，其實也無妨。這就是HttpBasic模式的典型應用場景。

二、spring boot2.0整合Spring security

spring boot 2,x版本maven方式引入Spring security坐標。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

三、HttpBasic登錄認證模式

如果使用的Spring Boot版本為1.X版本,依賴的Security 4.X版本，那麼就無需任何配置，啟動項目訪問則會彈出默認的httpbasic認證.

我們現在使用的是spring boot2.0版本（依賴Security 5.X版本），HttpBasic不再是默認的驗證模式，在spring security 5.x默認的驗證模式已經是表單模式。所以我們要使用Basic模式，需要自己調整一下。並且security.basic.enabled已經過時了，所以我們需要自己去編碼實現。

@Configuration
public class SecurityConfig extends WebSecurityConfigurerAdapter {
   
   @Override
   protected void configure(HttpSecurity http) throws Exception {
      http.httpBasic()//開啟httpbasic認證
      .and()
      .authorizeRequests()
      .anyRequest()
      .authenticated();//所有請求都需要登錄認證才能訪問
   }

}

啟動項目，在項目後台有這樣的一串日誌打印，冒號後面的就是默認密碼。

Using generated security password: 0cc59a43-c2e7-4c21-a38c-0df8d1a6d624

我們可以通過瀏覽器進行登錄驗證，默認的用戶名是user.（下面的登錄框不是我們開發的，是HttpBasic模式自帶的）

當然我們也可以通過application.yml指定配置用戶名密碼

spring:
    security:
      user:
        name: admin
        password: admin

四、HttpBasic模式的原理說明

• 首先，HttpBasic模式要求傳輸的用戶名密碼使用Base64模式進行加密。如果用戶名是 "admin"  ，密碼是“ admin”，則將字符串"admin:admin" 使用Base64編碼算法加密。加密結果可能是：YWtaW46YWRtaW4=。
• 然後，在Http請求中使用Authorization作為一個Header，“Basic YWtaW46YWRtaW4=“作為Header的值，發送給服務端。（注意這裏使用Basic+空格+加密串）
• 服務器在收到這樣的請求時，到達BasicAuthenticationFilter過濾器，將提取“ Authorization”的Header值，並使用用於驗證用戶身份的相同算法Base64進行解碼。
• 解碼結果與登錄驗證的用戶名密碼匹配，匹配成功則可以繼續過濾器後續的訪問。

所以，HttpBasic模式真的是非常簡單又簡陋的驗證模式，Base64的加密算法是可逆的，你知道上面的原理，分分鐘就破解掉。我們完全可以使用PostMan工具，發送Http請求進行登錄驗證。

期待您的關注

• 博主最近新寫了一本書：
• 本文轉載註明出處（必須帶連接，不能只轉文字）：。

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

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

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

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

一 部署ETCD集群

1.1 安裝ETCD

etcd 是基於 Raft 的分佈式 key-value 存儲系統，由 CoreOS 開發，常用於服務發現、共享配置以及併發控制（如 leader 選舉、分佈式鎖等）。kubernetes 使用 etcd 存儲所有運行數據。

  1 etcd 是基於 Raft 的分佈式 key-value 存儲系統，由 CoreOS 開發，常用於服務發現、共享配置以及併發控制（如 leader 選舉、分佈式鎖等）。kubernetes 使用 etcd 存儲所有運行數據。
  2 [root@k8smaster01 ~]# cd /opt/k8s/work
  3 [root@k8smaster01 work]# wget https://github.com/coreos/etcd/releases/download/v3.3.13/etcd-v3.3.13-linux-amd64.tar.gz
  4 [root@k8smaster01 work]# tar -xvf etcd-v3.3.13-linux-amd64.tar.gz

1.2 分發ETCD

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh
  3 [root@k8smaster01 work]# for master_ip in ${MASTER_IPS[@]}
  4   do
  5     echo ">>> ${master_ip}"
  6     scp etcd-v3.3.13-linux-amd64/etcd* root@${master_ip}:/opt/k8s/bin
  7     ssh root@${master_ip} "chmod +x /opt/k8s/bin/*"
  8   done

1.3 創建etcd證書和密鑰

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# cat > etcd-csr.json <<EOF
  3 {
  4     "CN": "etcd",
  5     "hosts": [
  6     "127.0.0.1",
  7     "172.24.8.71",
  8     "172.24.8.72",
  9     "172.24.8.73"
 10   ],
 11     "key": {
 12         "algo": "rsa",
 13         "size": 2048
 14     },
 15     "names": [
 16         {
 17             "C": "CN",
 18             "ST": "Shanghai",
 19             "L": "Shanghai",
 20             "O": "k8s",
 21             "OU": "System"
 22         }
 23     ]
 24 }
 25 EOF
 26 #創建etcd的CA證書請求文件

解釋：

hosts 字段指定授權使用該證書的 etcd 節點 IP 或域名列表，需要將 etcd 集群的三個節點 IP 都列在其中。

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# cfssl gencert -ca=/opt/k8s/work/ca.pem \
  3 -ca-key=/opt/k8s/work/ca-key.pem -config=/opt/k8s/work/ca-config.json \
  4 -profile=kubernetes etcd-csr.json | cfssljson -bare etcd	#生成CA密鑰（ca-key.pem）和證書（ca.pem）

1.4 分發證書和私鑰

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh
  3 [root@k8smaster01 work]# for master_ip in ${MASTER_IPS[@]}
  4   do
  5     echo ">>> ${master_ip}"
  6     ssh root@${master_ip} "mkdir -p /etc/etcd/cert"
  7     scp etcd*.pem root@${master_ip}:/etc/etcd/cert/
  8   done

1.5 創建etcd的systemd

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh
  3 [root@k8smaster01 work]# cat > etcd.service.template <<EOF
  4 [Unit]
  5 Description=Etcd Server
  6 After=network.target
  7 After=network-online.target
  8 Wants=network-online.target
  9 Documentation=https://github.com/coreos
 10 
 11 [Service]
 12 Type=notify
 13 WorkingDirectory=${ETCD_DATA_DIR}
 14 ExecStart=/opt/k8s/bin/etcd \\
 15   --data-dir=${ETCD_DATA_DIR} \\
 16   --wal-dir=${ETCD_WAL_DIR} \\
 17   --name=##MASTER_NAME## \\
 18   --cert-file=/etc/etcd/cert/etcd.pem \\
 19   --key-file=/etc/etcd/cert/etcd-key.pem \\
 20   --trusted-ca-file=/etc/kubernetes/cert/ca.pem \\
 21   --peer-cert-file=/etc/etcd/cert/etcd.pem \\
 22   --peer-key-file=/etc/etcd/cert/etcd-key.pem \\
 23   --peer-trusted-ca-file=/etc/kubernetes/cert/ca.pem \\
 24   --peer-client-cert-auth \\
 25   --client-cert-auth \\
 26   --listen-peer-urls=https://##MASTER_IP##:2380 \\
 27   --initial-advertise-peer-urls=https://##MASTER_IP##:2380 \\
 28   --listen-client-urls=https://##MASTER_IP##:2379,http://127.0.0.1:2379 \\
 29   --advertise-client-urls=https://##MASTER_IP##:2379 \\
 30   --initial-cluster-token=etcd-cluster-0 \\
 31   --initial-cluster=${ETCD_NODES} \\
 32   --initial-cluster-state=new \\
 33   --auto-compaction-mode=periodic \\
 34   --auto-compaction-retention=1 \\
 35   --max-request-bytes=33554432 \\
 36   --quota-backend-bytes=6442450944 \\
 37   --heartbeat-interval=250 \\
 38   --election-timeout=2000
 39 Restart=on-failure
 40 RestartSec=5
 41 LimitNOFILE=65536
 42 
 43 [Install]
 44 WantedBy=multi-user.target
 45 EOF

解釋：

WorkingDirectory、–data-dir：指定工作目錄和數據目錄為 ${ETCD_DATA_DIR}，需在啟動服務前創建這個目錄；

–wal-dir：指定 wal 目錄，為了提高性能，一般使用 SSD 或者和 –data-dir 不同的磁盤；

–name：指定節點名稱，當 –initial-cluster-state 值為 new 時，–name 的參數值必須位於 –initial-cluster 列表中；

–cert-file、–key-file：etcd server 與 client 通信時使用的證書和私鑰；

–trusted-ca-file：簽名 client 證書的 CA 證書，用於驗證 client 證書；

–peer-cert-file、–peer-key-file：etcd 與 peer 通信使用的證書和私鑰；

–peer-trusted-ca-file：簽名 peer 證書的 CA 證書，用於驗證 peer 證書。

1.6 修改systemd相應地址

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh
  3 [root@k8smaster01 work]# for (( i=0; i < 3; i++ ))
  4   do
  5     sed -e "s/##MASTER_NAME##/${MASTER_NAMES[i]}/" -e "s/##MASTER_IP##/${MASTER_IPS[i]}/" etcd.service.template > etcd-${MASTER_IPS[i]}.service
  6   done

1.7 分發etcd systemd

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh
  3 [root@k8smaster01 work]# for master_ip in ${MASTER_IPS[@]}
  4   do
  5     echo ">>> ${master_ip}"
  6     scp etcd-${master_ip}.service root@${master_ip}:/etc/systemd/system/etcd.service
  7   done

二 啟動並驗證

2.1 啟動ETCD

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh
  3 [root@k8smaster01 work]# for master_ip in ${MASTER_IPS[@]}
  4   do
  5     echo ">>> ${master_ip}"
  6     ssh root@${master_ip} "mkdir -p ${ETCD_DATA_DIR} ${ETCD_WAL_DIR}"
  7     ssh root@${master_ip} "systemctl daemon-reload && systemctl enable etcd && systemctl restart etcd " &
  8   done

2.2 檢查ETCD啟動

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh
  3 [root@k8smaster01 work]# for master_ip in ${MASTER_IPS[@]}
  4   do
  5     echo ">>> ${master_ip}"
  6     ssh root@${master_ip} "systemctl status etcd|grep Active"
  7   done

2.3 驗證服務狀態

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh
  3 [root@k8smaster01 work]# for master_ip in ${MASTER_IPS[@]}
  4   do
  5     echo ">>> ${master_ip}"
  6     ETCDCTL_API=3 /opt/k8s/bin/etcdctl \
  7     --endpoints=https://${master_ip}:2379 \
  8     --cacert=/etc/kubernetes/cert/ca.pem \
  9     --cert=/etc/etcd/cert/etcd.pem \
 10     --key=/etc/etcd/cert/etcd-key.pem endpoint health
 11   done

2.4 查看ETCD當前leader

  1 [root@k8smaster01 ~]# source /opt/k8s/bin/environment.sh
  2 [root@k8smaster01 ~]# ETCDCTL_API=3 /opt/k8s/bin/etcdctl \
  3   -w table --cacert=/etc/kubernetes/cert/ca.pem \
  4   --cert=/etc/etcd/cert/etcd.pem \
  5   --key=/etc/etcd/cert/etcd-key.pem \
  6   --endpoints=${ETCD_ENDPOINTS} endpoint status

如上所示，當前ETCD集群的leader為172.24.8.71。本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

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

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!