技術只是基礎

　　該系列的兩篇文章《.Net微服務實戰之技術選型篇》和《.Net微服務實戰之技術架構分層篇》都是以技術角度出發描述微服務架構的實施。

　　如果技術選型篇敘述的是工具，那麼架構分層篇講的就是技巧，而本篇要討論的就是原則。一直以來我會給身邊向我探討問題的人灌輸一種理念，沒有什麼技術銀彈，因為我們做的是軟件工程，提供的是問題相應的解決方案，不同類型問題的解決方案是存在着本質上的差異。

　　繼續提供之前的源碼：https://github.com/SkyChenSky/Sikiro

PS：該篇文章與.Net無關，其實主要是沿用前面兩篇文章的命名，此外我認為DevOps不是簡單的工具使用，應從軟件工程角度進行出發。

什麼才是優秀的架構設計？

　　曾經有好幾個同行問過我同一個問題：什麼才是優秀的架構設計？我一直信奉着兩句話和一個定律：

• 架構服務於業務，技術服務於架構 
• 康威定律（簡單理解成組織架構的設計等同於系統架構的設計）

　　架構設計其實就是一種方案的取捨，在有限的資源里(包括但不限人力、時間)能讓團隊順利的實施技術，同時滿足業務規模的需要，我認為可以稱之為優秀的架構設計，簡單來說兩個字合適

架構核心要素

　　核心的主要5大：性能、可用性、伸縮性、擴展性、安全性。 

　　而我們所討論的微服務，選擇了擴展性，犧牲了可用性、性能，擴展性的目的就是為了快速響應需求變化、降低系統耦合度、提高系統模塊的復用度。而微服務的調用是通過跨進程的網絡通信的，跟進程內方法調用比無疑是慢了一個單位；原本單服務99.99%高可用，假如現在三個服務就是99.99%*99.99%*99.99%=99.97%。

　　當然我們可以在基於微服務的通過引入其他技術提高可用性、伸縮性和安全，但是確保無疑是犧牲了性能，除了性能還會在團隊開發效率與運維複雜度上會受到影響。由此可見，沒有萬能技術手段，而架構其實在取捨。

　　引入一種技術必定帶新的技術問題這是個必然結果，剛提到團隊開發效率與運維複雜度會受到影響，那是否有辦法緩解甚至解決並提高呢？既然涉及到團隊、流程這些關鍵字那麼就應該向軟件工程方向尋找方案，合適架構實施還需要合適的開發模式進行支撐的，而風靡全球的DevOps就是不二之選。

軟件工程

 　　在行業盛傳的一條公式：軟件 = 軟件工程 + 程序，可想而知軟件工程的佔據多麼重要的比重。那麼什麼是軟件工程？百度是這麼解釋的：

　　軟件工程是研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟件，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來的學科。它涉及到程序設計語言、數據庫、軟件開發工具、系統平台、標準、設計模式等方面。

　　我自己重新總結了一個軟件工程的通俗描述，通過多人協作、有目標、有步驟、有計劃的並使用科學方法論指導開發與維護程序的這個過程。也可以用一條公式表達：軟件工程 = 工具 + 流程 + 模式。

軟件危機

　　軟件工程的出現目的是為了解決軟件危機的。軟件危機其實是當時落後的軟件生產方式無法滿足迅速增長的計算機軟件需求，從而導致軟件開發與維護過程中出現一列的嚴重問題的現象。那麼三次軟件危機是什麼呢？我整理了個表格（詳細可以自行百度閱讀）

 　　由上可見，軟件的快速發展直接促使了軟件工程上的進步，新的工具、新的開發與設計模式，新的協作流程也隨之而生。

開發模式的發展

　　我工作多年經歷了多家公司，所經歷的有三種開發模式，瀑布、敏捷、DevOps。那麼這三種主流的開發模式也對應着三個發展階段：

瀑布開發模式

　　瀑布開發模式是在第一次軟件危機1970時Winston Royce博士提出來。其思想是把項目過程劃分為主要的六個階段：需求收集、需求分析、軟件設計、程序編碼、軟件測試、運行維護。團隊劃分也通過崗位職責進行劃分：產品團隊、開發團隊、測試團隊、運維團隊。到目前為止該開發模式仍然用到做項目制的開發團隊。

　　那麼其優點與劣勢也很明顯，優點是計劃明確，職責清晰，按部就班的完成就好。缺點是周期容易拖得太長，不容易調整變更，每個人只為自己職責範圍內的負責，跨部門溝通成本大（這就是為什麼我在圖裡畫了兩堵牆的原因）。我自己呆過一個瀑布模式的團隊，在項目立項后就會被項目經理調動資源成為團隊，而開發人員只會在這一次批次負責編碼與修改測試反饋的問題，基本上上線后的問題跟你無關（除非緊急嚴重的），其他的BUG也許是下一個批次的另外一個開發人員幫你填。

 敏捷開發模式

　　準確的說敏捷開發是一種價值觀和原則的體現，2001年17位IT大佬想把瀑布發模式這種重量級的開發過程替換成一種更加輕量級，可惜大家都沒有達成統一意見因此把各自都認同的觀念整理出來成為敏捷宣言。

　　敏捷開發其實把產品、開發、測試三種崗位職責的人緊密的聯繫了起來，由原來長周期的大目標拆解成了一個個短周期的小目標。他之所以快，不是因為寫代碼快了，而是節省了很多不必要的前置條件與返工，同時小步快跑的交付也可以提高團隊的士氣，一個長周期項目那枯燥、乏味、痛苦的過程，誰試誰知道。

　　舉個例子，大家都是為公司的同個產品努力，沒有什麼合同談判可言，只要需求要求相互了解清楚並且可行就可以開幹了。寫詳細設計文檔的時間，還不如花時間多溝通下需求的核心點，想辦法設計得更容易滿足需求。短周期的交付后，產品與客戶就可以及時的查看交付效果並相應的優化與調整。（快速響應並不代表隨時隨地接受變更響應，可以統一歸到下一個迭代周期，我不贊同拍拍腦袋的變更，自己都沒清楚的功能怎麼說服客戶使用？）

　　敏捷開發的最大好處之一就是短周期的持續交付，這樣方式能在現階段的互聯網行業得到更快速的響應與市場的搶佔，同時能很好的進行技術改進與試錯。但是這種”野蠻的“方式會讓開發團隊與運維團隊形成一條鴻溝，而鴻溝的形成主要原因是運維團隊希望軟件的運作是可靠的，所以他們對資源的變動、新技術的使用尤為的小心、謹慎。

　　我曾經呆過一個敏捷開發團隊，生產出了問題運維團隊會自行去修改配置，當然會越改越錯了，而且一天發布次數多了，就會起爭執。

DevOps

　　DevOps可以看過是敏捷的擴展與延申，它的出現就是為了解決開發團隊與運維團隊的那條鴻溝，只要存在人工處理的方式擔心的問題總會出現，同一段程序無論執行多少次相同輸入的輸出總是一致的，但是人的處理卻不能保證，那麼使用自動化改善協作的過程，鴻溝自然就跨越了，。那麼開發團隊與運維團隊就可以為相同的目標與方向而努力。而組織架構也將演變成如下：

　　從上圖也與開頭的康威定律做了一個很好的呼應。

 我是如何實施DevOps的？

技術

　　這個角度是大家最樂意去關注的，在我們團隊主要使用了以下技術，腳本什麼的我就不花時間貼出來了，在我看來工具的使用，只要花點時間就能解決。

　　原本代碼檢查想引入SonarQube代替人工檢查+Reshaper，可惜於服務器資源不足。

　　對於一般的團隊，我建議優先從Gitlab+Jenkins搭建好完成CI/CD，其次把日誌系統給完善起來，這兩者完成得越早，給團隊帶來的收益就越高，後續才會有更多的時間來完善整套技術體系，這是一個良性的循環。

人

　　人延申出的就是團隊與文化，經過上面的講解大家都意識到軟件工程就是一樣多人協作的工作，只有團隊目標一致，共同負責承擔團隊的項目，願意一同與項目成長才能很好的實施DevOps。就像多匹馬拉車一樣，只有它們都有共同的目標的時候才能快速拉車到目的，如果他們一匹向東一匹西，只會讓馬車無法前行甚至四分五裂。

　　在我的團隊，因為在招聘人員的時候已經進行過了篩選，所以在合作上非常的順利，當然我也經常在例會和業餘的時候都會給大家傳達思想，讓團隊成員真正的從實際意義上去理解現在的做法。

　　對於已經成型的團隊來說如何去落地呢？無非三種，激勵、考核和逐步試行。如果有條件的公司可以設置獎金激勵，如果有績效考核的可以將DevOps實施納入考核目標，如果兩者都沒的，那就選取團隊里願意改變的同事進行試行，使用過後都說好的那麼更會有說服力。　

流程　

 　　為了落實了文化的改進與技術的使用的這個過程，我們需要科學的、有步驟、有計劃的方式完成這項工作，並且可以讓這套標準化的方式可以重複使用到其他項目上。

　　在我的團隊是有產品、前端開發，後端開發、測試、運維組成的。我採用了原型模式+DevOps模式：

• 　　產品人員會優先使用Axure RP工具把需求整理產出原型並與需求方確認。
• 　　產品確認好的原型就是我們技術的輸入，技術拿到需求後會做一次需求評審，主要是排查需求疑惑和確認需求目標。
• 　　需求明確后，由我使用Visual Project任務拆解與排期，任務會建立在我們的項目管理系統Redmine上，如果任務周期過程，我會拆分成多個可交付的短周期，一般會控制在2個星期內。
• 　　接到任務后，大家就跟根據自己的任務使用PowerDesigner數據庫設計（早期是由我獨裁設計，後期團隊發展壯大了，就由業務負責人各自設計），在這個階段，如果有新的服務與新的工具庫需要部署，我就會正面與運維溝通讓他把自動化給完成。
• 　　因為我們是前後端分離的，所以我們使用了Swagger減少了寫接口文檔的時間，所有任務是否完成以前端是否對接好接口為主導，前端對接好后，就會在Redmine修改自己的任務狀態並新建一個測試任務給到測試。
• 　　測試會根據自己寫好的測試用例，進行對完成的任務進行場景測試，如果有BUG會在Redmine提給相應的人進行修改。一般會先由前端人員排查是否是他的交互上的BUG，如果確認是數據問題那麼就會轉給後端開發，開發人員定位BUG時，可以通過我們的SkyWalking和Kibana聯合定位問題，定位問題時間一般都在2-10分鐘。
• 　　代碼合併到測試分支后就會通過Jenkins發布到測試環境，生產環境的發布是合併到生產環境後手動確認發布的。

　　除此之外，每周一會有一個例會內容不限工作，也可以分享周末去哪裡娛樂了。在該迭代周期快到結束的2-3天會開一個進度會議，看看大家完成情況。因為公司沒有下午茶，所以我們自己通過玩搶紅包領到最大的兩個的請吃下午茶，最少一星期一次。

 結束

　　該篇到這裏就分享結束了，也是該系列的最後一篇，我曾經認為技術與管理必須二選一，自從我成為了一個技術與團隊的負責人後，終於讓我認識到，一個優秀的技術思想還是需要一些管理手段才能很好的實施，而我們的技術管理無非就是軟件工程。

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

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

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

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

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

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

※聚甘新

特斯拉執行長馬斯克（Elon Musk）再發豪語，宣稱旗下電動車在2017年底，就能具備自動駕駛功能，一路從洛杉磯開到紐約。Seeking Alpha網站認為，特斯拉有信心在短時間內開發出自動駕駛系統，得歸功於Nvidia。

Seeking Alpha 24日報導，特斯拉原本與以色列商Mobileye合作，採用EyeQ3晶片，旗下電動車具備自動緊急煞車、碰撞警示、維持車道等功能，不過特斯拉和Mobileye分手，改採Nvidia系統之後，原有的先進駕駛輔助系統（ADAS）全部泡湯。

既然如此，特斯拉為何敢放話明年底就有自動駕駛？文章稱，Nvidia研發出革命性的自駕系統，該公司蒐集人類實際開車影片，搭配方向盤的操控角度，用來訓練類神經網路（Neural Network、NN）；也就是說，每一格駕駛畫面，都有正確答案，讓NN學會打方向盤的角度；再搭配偏離車道時，如何修正重回線道的資料等，讓電腦掌握開車技巧。

這個方式的特點在於，NN能「全面」掌握駕駛技術。在此之前，業者多把自駕細分成多個項目，如辨識物體、道路等，接著再加以結合，無法確認電腦是否真的完全抓到開車訣竅。Nvidia這套新方法簡單快速，不到一年就有極佳成效，汽車能在多種狀況下自動駕駛（影片見此），如果以此一系統為基礎，應能迅速讓自駕功力大增。文章猜測，特斯拉正是相中此點，才捨棄舊愛Mobileye、改和Nvidia合作。

文章指稱，特斯拉運用Nvidia技術開發出自駕車模型，能從人類實際開車情況和反應中學習，加快研發進展。然而該文警告，問題是機器學習不知道什麼時候會碰上瓶頸，以為NN能就此一帆風順學會開車，過於樂觀。自駕車門檻極高，NN學習過程或許會陷入停滯，難以達標。該文指出，目前谷歌自駕車的開車技術仍不如人類，特斯拉更是遠遠落後。

BusinessInsider報導，特斯拉（Tesla Motors Inc.）執行長（CEO）馬斯克（Elon Musk）19日在記者會上表示，2017年底特斯拉旗下車種將可啟動無人駕駛模式、自洛杉磯開到紐約時代廣場。馬斯克今年初曾表示，特斯拉自駕車將可在2018年橫越美國。他在19日的媒體發表會上提到，特斯拉自駕車的安全性比人類駕駛要高出一倍或更多，硬體基礎已經都準備妥當，只待軟體以及相關法規到位。

特斯拉10月19日發布新聞稿宣布，即日起出廠的旗下所有電動車（包括Model 3）都將配備全自動駕駛硬體配件。特斯拉指出，自駕功能將令車輛安全性大幅提高。

特斯拉新出廠車款配備8個鏡頭、具有360度視角，可視距離達250公尺；12個新版超音波感測器將可進一步提升車輛視覺能力、使得軟硬物件偵測距離較前一代提升一倍。具有增強處理效能的前向雷達可讓車輛掌握前方的車輛動向以及大雨、霧、灰塵等路況。

（本文由授權提供。照片來源：shared by CC 2.0）

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

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

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

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

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

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

※聚甘新

首先是個人的一些閱讀源碼的小技巧，不一定適用每個人，可以直接跳過。

閱讀源碼的一些個人技巧

博客+總結

個人覺得大多數情況下跟着一篇優秀的博客配合著看就足夠了，之後再自己寫博客總結一遍加深印象，畫一下流程圖基本都能理順。（圖為學AQS時本人畫的獲取獨佔鎖流程圖）

類關係

配合idea看類之間的關係（ctrl+alt+shift+u）的功能也能更好的理解整個項目的整體架構。因為很多源碼其實並不是真的複雜，只是為了擴展性優雅簡潔等原因建立了大量的接口和抽象類以及各種設計模式，使得項目看起來很龐大很複雜，藉助這個功能有利於你排除掉一些你暫時不想去關心的設計邏輯。知道那個部分才是最核心的邏輯，專註於去看核心代碼。 

多看註釋

但是如果你看的博客裏面剛好缺少了一部分你想看的內容，而你又找不到資料，需要自己去看，又或者你想看的源碼一點點資料都找不到的情況下想去看源碼。

這個時候比較有作用的就是註釋，源碼中的註釋看不懂也沒關係，放到百度翻譯里基本也能理解大概的意思。仔細看完方法或類的註釋之後你就理解了接下來這個類大致是在做什麼，之後讀它的源碼會通順很多，有一些方法或類甚至在你看完註釋之後就已經能知道你想看的內容了，已經沒有需要繼續往下讀了。

不僅僅是類或方法的註釋文檔，方法中代碼的註釋也很重要，基本上稍微複雜一點點的代碼，甚至有時候加個鎖，作者都會認認真真的寫一行註釋解釋自己這麼做的原因。

適當囫圇吞棗

還有一點是適當忽略一些不重要的細節，這個主要看你想看什麼，一般我們看第一遍大多數只是想知道大致的流程是什麼樣的，所以可以適當忽略併發邏輯和一些方法里的內容（看一眼註釋先知道這個方法會做什麼的就夠了）。第一遍大致知道流程，第二第三遍再去深究細節和併發邏輯等。

善用debug

多用debug，很多時候源碼走的路線會和你想象中的有很大不同，你以為會進入這個if，其實他偷偷進了else。

短路機制

經常看到利用短路機制的代碼，這裏以 AbstractQueuedSynchronizer 的 acquire 方法為例子，只有 tryAcquire 獲取鎖失敗， !tryAcquire 返回 true 時才會執行後面進入阻塞隊列並掛起的方法，如果獲取鎖成功了，根據短路機制自然不會執行入隊方法。

// AbstractQueuedSynchronizer.acquire(int arg)
if (!tryAcquire(arg) &&
    acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) {
    selfInterrupt();
}

拆高低位

ReentrantReadWriteLock的這段代碼里將AQS的state一分為二給共享鎖和獨佔鎖使用，個人覺得這種設計非常巧妙：

// ReentrantReadWriteLock
abstract static class Sync extends AbstractQueuedSynchronizer {
    // 下面這塊說的就是將 state 一分為二，高 16 位用於共享模式，低16位用於獨佔模式
    static final int SHARED_SHIFT   = 16;
    static final int SHARED_UNIT    = (1 << SHARED_SHIFT);
    static final int MAX_COUNT      = (1 << SHARED_SHIFT) - 1;
    static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
    // 取 c 的高 16 位值，代表讀鎖的獲取次數(包括重入)
    static int sharedCount(int c)    { return c >>> SHARED_SHIFT; }
    // 取 c 的低 16 位值，代表寫鎖的重入次數，因為寫鎖是獨佔模式
    static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

 While(n– > 0)和while (–n >= 0)

忘記在哪裡看到的了，翻了一下瀏覽記錄應該是在Java AIO部分的源碼里，這種寫法感覺很簡潔就記下來了，不過可讀性似乎不太高，特別是第一種乍一看還以為是lambda表達式

意思等同於 for (int i = 0; i < n; i++)  ，但是 while(n– > 0) 和 while (–n >= 0) 這種寫法會直接改變n的值

xx = null

在很多jdk的源碼中我們都可以看到 xx = null // help GC 這樣的代碼，用來置空引用，幫助jvm完成gc。具體可以了解可達性算法。

這裏我們以LinkList為例子：

// LinkList 的方法
private E unlinkFirst(Node<E> f) {
    final E element = f.item;
    final Node<E> next = f.next;
    f.item = null;
    f.next = null; // help GC
    first = next;
    if (next == null)
        last = null;
    else
        next.prev = null;
    size--;
    modCount++;
    return element;
}

位移運算符

在很多地方都會使用位移來進行運算，平時寫算法題也一樣很多人都這麼使用，下面以 ArrayList 的 grow 方法為例子，這裏通過右移1位使 oldCapacity 變為原來的0.5倍，之後加上它本身得到  newCapacity 

// ArrayList.grow(int minCapacity)
private void grow(int minCapacity) {
    // . . . . . .
    int newCapacity = oldCapacity + (oldCapacity >> 1);//newCapacity就是1.5倍的oldCapacity
    // . . . . . . 
}

以上是我目前的水平所能總結出來的，後續學到其他的會繼續更新，如果大家有什麼補充的請告訴我

最後慣例附一圖：（根本不存在想雇傭我的地方( ´_ゝ`).jpg）

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

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

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

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

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

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

※聚甘新

VUE+Element 前端是一個純粹的前端處理，前面介紹了很多都是Vue+Element開發的基礎，從本章隨筆開始，就需要進入深水區了，需要結合ABP框架使用（如果不知道，請自行補習一下我的隨筆：ABP框架使用），ABP框架作為後端，是一個非常不錯的技術方向，但是前端再使用Asp.NET 進行開發的話，雖然會快捷一點，不過可能顯得有點累贅了，因此BS的前端選項採用Vue+Element來做管理（後續可能會視情況加入Vue+AntDesign），CS前端我已經完成了使用Winform+ABP的模式了。本篇隨筆主要介紹Vue+Element+ABP的整合方式，先從登錄開始介紹。

 1、ABP開發框架的回顧

ABP是ASP.NET Boilerplate的簡稱，ABP是一個開源且文檔友好的應用程序框架。ABP不僅僅是一個框架，它還提供了一個最徍實踐的基於領域驅動設計(DDD)的體繫結構模型。

啟動Host的項目，我們可以看到Swagger的管理界面如下所示。

我們登錄獲得用戶訪問令牌token后，測試字典類型或者字典數據的接口，才能返迴響應的數據。

我根據ABP後端項目之間的關係，整理了一個架構的圖形。

應用服務層是整個ABP框架的靈魂所在，對內協同倉儲對象實現數據的處理，對外配合Web.Core、Web.Host項目提供Web API的服務，而Web.Core、Web.Host項目幾乎不需要進行修改，因此應用服務層就是一個非常關鍵的部分，需要考慮對用戶登錄的驗證、接口權限的認證、以及對審計日誌的記錄處理，以及異常的跟蹤和傳遞，基本上應用服務層就是一個大內總管的角色，重要性不言而喻。

對於通過Winform方式展示界面，以Web API方式和後端的ABP的Web API服務進行數據交互，是我們之前已經完成的項目，項目界面如下所示。

主體框架界面採用的是基於菜單的動態生成，以及多文檔的界面布局，具有非常好的美觀性和易用性。

左側的功能樹列表和頂部的菜單模塊，可以根據角色擁有的權限進行動態構建，不同的角色具有不同的菜單功能點，如下是測試用戶登錄后具有的界面。

2、Vue+Element整合ABP框架的前端登錄處理

之前我們開發完成的Vue+Element的前端項目，默認已經具有登錄系統的功能，不過登錄是採用mock方式進行驗證並處理的，本篇隨筆介紹是基於實際的ABP項目進行用戶身份的登錄處理，這個也是開發其他接口展示數據的開始步驟，必須通過真實的用戶身份登錄後台，獲得對應的token令牌，才能進行下一步接口的開發工作。

例如對應登錄界面上，界面效果如下所示。

在用戶登錄界面中，我們處理用戶登錄邏輯代碼如下所示。

    // 處理登錄事件
    handleLogin() {
      this.$refs.loginForm.validate(valid => {
        if (valid) {
          this.loading = true
          this.$store
            .dispatch('user/login', this.loginForm)
            .then(() => {
              this.$router.push({ path: this.redirect || '/' })
              this.loading = false
            })
            .catch(() => {
              this.loading = false
            })
        } else {
          console.log('error submit!!')
          return false
        }
      })
    }

這裏主要就是調用Store模塊裏面的用戶Action處理操作。

例如對於用戶store模塊裏面的登錄Action函數如下所示。

const actions = {
  // user login
  login({ commit }, userInfo) {
    const { username, password } = userInfo
    return new Promise((resolve, reject) => {
      login({ username: username.trim(), password: password }).then(response => {
        const { result } = response // 獲取返回對象的 result
 var token = result.accessToken var userId = result.userId // 記錄令牌和用戶Id
        commit('SET_TOKEN', token)
        commit('SET_USERID', userId)

        // 存儲cookie
        setToken(token)
        setUserId(userId)
        resolve()
      }).catch(error => {
        reject(error)
      })
    })
  },

而其中 login({ username: username.trim(), password: password }) 操作，是通過API封裝處理的調用，使用前在Store模塊中先引入API模塊，如下所示。

import { login, logout, getInfo } from '@/api/user'

 而其中 API模塊代碼如下所示。

export function login(data) {
  return request({
    url: '/abp/TokenAuth/Authenticate',
    method: 'post',
    data: {
      UsernameOrEmailAddress: data.username,
      password: data.password
    }
  })
}

這裏我們用了一個/abp的前綴，用來給WebProxy的處理，實現地址的轉義，從而可以實現跨站的處理，讓前端調用外部地址就和調用本地地址一樣，無縫對接。

我們來看看vue.config.js裏面對於這個代理的轉義操作代碼。

 而 http://localhost:21021/api 地址指向的項目，是我們本地使用ABP開發的一個後端Web API項目，我們可以通過地址 http://localhost:21021/swagger/index.html 進行接口的查看。

 我們打開獲取授權令牌的Authenticate接口，查看它的接口定義內容

通過標註的1,2，我們可以看到這個接口的輸入參數和輸出JSON信息，從而為我們封裝Web API的調用提供很好的參考。

ABP框架統一返回的結果是result，這個result裏面才是返回對應的接口內容，如上面的輸出JSON信息裏面的定義。

所以在登陸返回結果后，我們要返回它的result對象，然後在進行數據的處理。

const { result } = response // 獲取返回對象的 result

然後通過result來訪問其他屬性即可。

var token = result.accessToken // 用戶令牌
var userId = result.userId // 用戶id

用戶登錄成功后，並獲取到對應的數據，我們就可以把必要的數據，如token和userid存儲在State和Cookie裏面了。

// 修改State對象，記錄令牌和用戶Id
commit('SET_TOKEN', token)
commit('SET_USERID', userId)

// 存儲cookie
setToken(token)
setUserId(userId)

有了這些信息，我們就可以進一步獲取用戶的相關信息，如用戶名稱、介紹，包含角色列表和權限列表等內容了。

例如對應用戶信息獲取接口的ABP後端地址是 http://localhost:21021//api/services/app/User/Get 

 那麼我們前端就需要在API模塊裏面構建它的訪問地址（/abp/services/app/User/Get）和接口處理了。

export function getInfo(id) {
  return request({
    url: '/abp/services/app/User/Get',
    method: 'get',
    params: {
      id
    }
  })
}

如上所示，在Store模塊里引入API模塊，如下所示。

import { login, logout, getInfo } from '@/api/user'

然後在Store模塊中封裝一個Action用來處理用戶信息的獲取的。

  // 獲取用戶信息
  getInfo({ commit, state }) {
    return new Promise((resolve, reject) => {
      getInfo(state.userid).then(response => {
        const { result } = response
        console.log(result) // 輸出測試

        if (!result) {
          reject('Verification failed, please Login again.')
        }

        const { roles, roleNames, name, fullName } = result

        // 角色非空提醒處理
        if (!roles || roles.length <= 0) {
          reject('getInfo: roles must be a non-null array!')
        }

        commit('SET_ROLES', { roles, roleNames })
        commit('SET_NAME', name)
        // commit('SET_AVATAR', avatar) //可以動態設置頭像
        commit('SET_INTRODUCTION', fullName)
        resolve(result)
      }).catch(error => {
        reject(error)
      })
    })
  },

Vue + Element前端項目的視圖、Store模塊、API模塊、Web API之間關係如下所示。

 登錄后我們獲取用戶身份信息，在控制台中記錄返回對象信息，可以供參考，如下所示

有了token信息，我們就可以繼續其他接口的數據請求或者提交了，從而可以實現更多的管理功能了。

後續隨筆將基於ABP接口對接的基礎上進行更多界面功能的開發和整合。 

列出一下前面幾篇隨筆的連接，供參考：

循序漸進VUE+Element 前端應用開發(1）— 開發環境的準備工作

循序漸進VUE+Element 前端應用開發(2）— Vuex中的API、Store和View的使用

循序漸進VUE+Element 前端應用開發(3）— 動態菜單和路由的關聯處理

循序漸進VUE+Element 前端應用開發(4）— 獲取後端數據及產品信息頁面的處理

循序漸進VUE+Element 前端應用開發(5）— 表格列表頁面的查詢，列表展示和字段轉義處理

循序漸進VUE+Element 前端應用開發(6）— 常規Element 界面組件的使用

循序漸進VUE+Element 前端應用開發(7）— 介紹一些常規的JS處理函數

循序漸進VUE+Element 前端應用開發(8）— 樹列表組件的使用

循序漸進VUE+Element 前端應用開發(9）— 界面語言國際化的處理

循序漸進VUE+Element 前端應用開發(11）— 圖標的維護和使用

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

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

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

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

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

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

※聚甘新

一 OpenShift網絡實現

1.1 軟件定義網絡(SDN)

默認情況下，Docker網絡使用僅使用主機虛機網橋bridge，主機內的所有容器都連接至該網橋。連接到此橋的所有容器都可以彼此通信，但不能與不同主機上的容器通信。通常，這種通信使用端口映射來處理，其中容器端口綁定到主機上的端口，所有通信都通過物理主機上的端口路由。

當有大量主機和容器時，使用此模式，需要手動管理所有端口綁定非常不現實。

為了支持跨集群的容器之間的通信，OpenShift容器平台使用了軟件定義的網絡(SDN)方法。軟件定義的網絡是一種網絡模型，它通過幾個網絡層的抽象來管理網絡服務。SDN將處理流量的軟件(稱為控制平面)和路由流量的底層機制(稱為數據平面)解耦。SDN支持控制平面和數據平面之間的通信。

在OpenShift Container Platform 3.9中（之後簡稱OCP），管理員可以為pod網絡配置三個SDN插件:

1. ovs-subnet：默認插件，子網提供了一個flat pod網絡，其中每個pod可以與其他pod和service通信。
2. ovs-multitenant：該為pod和服務提供了額外的隔離層。當使用此插件時，每個project接收一個惟一的虛擬網絡ID (VNID)，該ID標識來自屬於該project的pod的流量。通過使用VNID，來自不同project的pod不能與其他project的pod和service通信。
3. ovs-networkpolicy：此插件允許管理員使用NetworkPolicy對象定義自己的隔離策略。

cluster network由OpenShift SDN建立和維護，它使用Open vSwitch創建overlay網絡，master節點不能通過集群網絡訪問容器，除非master同時也為node節點。

注意：VNID為0的project可以與所有其他pod通信，在OpenShift容器平台中，默認項目的VNID為0。

1.2 Kubernetes SDN Pod

在默認的OpenShift容器平台安裝中，每個pod都有一個惟一的IP地址。pod中的所有容器都對外表現在相同的主機上。給每個pod提供自己的IP地址意味着，在端口分配、網絡、DNS、負載平衡、應用程序配置和遷移方面，pod被視為物理主機或虛擬機的獨立節點（僅從網絡層面看待）。

Kubernetes提供了service的概念，在任何OpenShift應用程序中，service都是必不可少的資源。service充當一個或多個pod前的負載平衡器。該service提供一個固定的IP地址，並且允許與pod通信，而不必跟蹤單獨的pod IP地址。



大多數實際應用程序都不是作為單個pod運行的。它們需要水平伸縮，這樣應用程序就可以在許多pod上運行，以滿足不斷增長的用戶需求。在OpenShift集群中，pod不斷地在集群中的節點之間創建和銷毀。每次創建pod時，它們都會獲得一個不同的IP地址。一個service提供一個單獨的、惟一的IP地址供其他pod使用，而不依賴於pod運行的節點，因此一個pod不必一定需要發現另一個pod的IP地址。客戶端通過service的請求在不同pod之間實現負載均衡。

1.3 Kubernetes SDN Service

service背後運行的一組pod由OpenShift容器平台自動管理。每個service都被分配了一個唯一的IP地址供客戶端連接。這個IP地址也來自OpenShift SDN，它與pod的內部網絡不同，也只在集群中可見。每個與selector匹配的pod都作為endpoint添加到service資源中。當創建和銷毀pods時，service後面的endpoint將自動更新。

service yaml語法：

  1 - apiVersion: v1
  2   kind: Service			#聲明資源類型
  3   metadata:
  4     labels:
  5       app: hello-openshift
  6       name: hello-openshift	#服務的唯一名稱
  7   spec:
  8     ports:，
  9     - name: 8080-tcp
 10       port: 8080		#服務對外公開的端口客戶機連接到服務端口
 11       protocol: TCP
 12       targetPort: 8080		#targetPort屬性必須匹配pod容器定義中的containerPort，服務將數據包轉發到pod中定義的目標端口。
 13     selector:			#該服務使用selector屬性查找要轉發數據包的pod。目標pod的元數據中需要有匹配的標籤。如果服務發現多個具有匹配標籤的pod，它將在它們之間實現負載
 14       app: hello-openshift
 15       deploymentconfig: hello-openshift

1.4 service對外暴露

默認情況下，pod和service IP地址不能從OpenShift集群外部訪問。對於需要從OpenShift集群外部訪問服務的應用程序，可以通過以下三種方式。

HostPort/HostNetwork：在這種方法中，client可以通過主機上的網絡端口直接訪問集群中的應用程序pod。應用程序pod中的端口被綁定到運行該pod的主機上的端口。這種方法在集群中運行大量pod時，存在端口衝突的風險。

NodePort：這是一種較老的基於Kubernetes的方法，通過綁定到node主機上的可用端口，將service公開給外部客戶端，然後node主機代理到service IP地址的連接。使用oc edit svc命令編輯服務屬性，指定NodePort的類型，併為NodePort屬性提供端口值。OpenShift然後通過node主機的公共IP地址和nodePort中設置的端口值代理到服務的連接。這種方法支持非http通信。

OpenShift routes：OpenShift中的推薦方式。它使用唯一的URL公開服務。使用oc expose命令公開用於外部訪問的服務，或者從OpenShift web控制台公開服務。在這種方法中，目前只支持HTTP、HTTPS、TLS whit SNI和WebSockets。

附圖：显示了NodePort服務如何允許外部訪問Kubernetes服務。



service nodeport yaml語法：

  1 apiVersion: v1
  2 kind: Service
  3 metadata:
  4 ...
  5 spec:
  6   ports:
  7   - name: 3306-tcp
  8     port: 3306
  9     protocol: TCP
 10     targetPort: 3306	#pod目標端口，即需要和pod定義的端口匹配
 11     nodePort: 30306	#OpenShift集群中主機上的端口，暴露給外部客戶端
 12   selector:
 13     app: mysqldb
 14     deploymentconfig: mysqldb
 15     sessionAffinity: None
 16   type: NodePort	#服務的類型，如NodePort
 17 ...

OpenShift將服務綁定到服務定義的nodePort屬性中定義的值，併為集群中所有node（包括master）上的流量打開該端口。外部客戶端可以連接到node端口上的任何節點的公共IP地址來訪問服務。請求會在服務後面的各個pod之間實現輪詢的負載平衡。

OpenShift route主要限於HTTP和HTTPS流量，但是節點端口可以處理非HTTP流量，當設置好公開的端口后，客戶機可以使用TCP或UDP的協議連接到該端口。

提示：缺省情況下，NodePort屬性的端口號限制在30000-32767之間，可通過在OpenShift主配置文件中配置範圍。

node port在集群中的所有node上都是打開的，包括master節點。如果沒有提供node端口值，OpenShift將自動在配置範圍內分配一個隨機端口。

1.5 pod訪問外部網絡

pod可以使用其主機的地址與外部網絡通信。只要主機能夠解析pod需要到達的服務器，pod就可以使用網絡地址轉換(network address translation, NAT)機制與目標服務器通信。

二 OpenShift SDN練習

2.1 前置準備

[student@workstation ~]$ lab install-prepare setup

[student@workstation ~]$ cd /home/student/do280-ansible

[student@workstation do280-ansible]$ ./install.sh

提示：以上準備為部署一個正確的OpenShift平台。

2.2 本練習準備

[student@workstation ~]$ lab openshift-network setup #準備本實驗環境

2.3 創建應用

[student@workstation ~]$ oc login -u developer -p redhat https://master.lab.example.com

[student@workstation ~]$ oc new-project network-test #創建project

[student@workstation ~]$ oc new-app –name=hello -i php:7.0 http://registry.lab.example.com/scaling

[student@workstation ~]$ oc get pods

NAME READY STATUS RESTARTS AGE

hello-1-build 1/1 Running 0 8s

2.4 擴展應用

[student@workstation ~]$ oc scale –replicas=2 dc hello

[student@workstation ~]$ oc get pods -o wide

NAME READY STATUS RESTARTS AGE IP NODE

hello-1-kszfh 1/1 Running 0 11m 10.128.0.21 node1.lab.example.com

hello-1-q7wk2 1/1 Running 0 11m 10.129.0.37 node2.lab.example.com

2.5 測試訪問

[student@workstation ~]$ curl http://10.128.0.21:8080

curl: (7) Failed connect to 10.128.0.21:8080; Network is unreachable

[root@node1 ~]# curl http://10.128.0.21:8080

  1 <html>
  2  <head>
  3   <title>PHP Test</title>
  4  </head>
  5  <body>
  6  <br/> Server IP: 10.128.0.21
  7  </body>
  8 </html>
  9 [root@node1 ~]# curl http://10.129.0.37:8080
 10 <html>
 11  <head>
 12   <title>PHP Test</title>
 13  </head>
 14  <body>
 15  <br/> Server IP: 10.129.0.37
 16  </body>
 17 </html>

提示：默認情況下，pod的ip屬於內部，集群內部節點可以使用pod ip訪問，集群外部（如workstation）無法訪問。

[student@workstation ~]$ oc get svc hello

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

hello ClusterIP 172.30.253.212 <none> 8080/TCP 14m

[student@workstation ~]$ curl http://172.30.253.212:8080

curl: (7) Failed connect to 172.30.253.212:8080; Network is unreachable

[root@node1 ~]# curl http://172.30.253.212:8080 #驗證負載均衡

  1 <html>
  2  <head>
  3   <title>PHP Test</title>
  4  </head>
  5  <body>
  6  <br/> Server IP: 10.128.0.21
  7  </body>
  8 </html>
  9 [root@node1 ~]# curl http://172.30.253.212:8080		#驗證負載均衡
 10 <html>
 11  <head>
 12   <title>PHP Test</title>
 13  </head>
 14  <body>
 15  <br/> Server IP: 10.129.0.37
 16  </body>
 17 </html>

提示：默認情況下，cluster的ip屬於內部，集群內部節點可以使用cluster ip訪問，集群外部（如workstation）無法訪問。

2.6 檢查服務

[student@workstation ~]$ oc describe svc hello

Name: hello

Namespace: network-test

Labels: app=hello

Annotations: openshift.io/generated-by=OpenShiftNewApp

Selector: app=hello,deploymentconfig=hello

Type: ClusterIP

IP: 172.30.253.212

Port: 8080-tcp 8080/TCP

TargetPort: 8080/TCP

Endpoints: 10.128.0.21:8080,10.129.0.37:8080

Session Affinity: None

Events: <none>

解釋：

endpoint：显示請求路由到的pod IP地址列表。當pod有更新后，endpoint將自動更新。

Selector：OpenShift使用為pods定義的選擇器和標籤來使用給定的集群IP，以便實現應用的負載均衡。如上所示為OpenShift將此服務的請求路由到所有標記為app=hello和deploymentconfig=hello的pod。

2.7 檢查pod

[student@workstation ~]$ oc describe pod hello-1-kszfh

2.8 設置外部訪問

使用NodePort方式設置外部訪問。

[student@workstation ~]$ oc edit svc hello

  1 apiVersion: v1
  2 kind: Service
  3 metadata:
  4   annotations:
  5     openshift.io/generated-by: OpenShiftNewApp
  6   creationTimestamp: 2019-07-19T15:50:09Z
  7   labels:
  8     app: hello
  9   name: hello
 10   namespace: network-test
 11   resourceVersion: "24496"
 12   selfLink: /api/v1/namespaces/network-test/services/hello
 13   uid: e348e2a3-aa3c-11e9-b230-52540000fa0a
 14 spec:
 15   clusterIP: 172.30.253.212
 16   ports:
 17   - name: 8080-tcp
 18     port: 8080
 19     protocol: TCP
 20     targetPort: 8080
 21     nodePort: 30800
 22   selector:
 23     app: hello
 24     deploymentconfig: hello
 25   sessionAffinity: None
 26   type: NodePort
 27 status:

[student@workstation ~]$ oc describe svc hello

Name: hello

Namespace: network-test

Labels: app=hello

Annotations: openshift.io/generated-by=OpenShiftNewApp

Selector: app=hello,deploymentconfig=hello

Type: NodePort #驗證是否為NodePort

IP: 172.30.253.212

Port: 8080-tcp 8080/TCP

TargetPort: 8080/TCP

NodePort: 8080-tcp 30800/TCP

Endpoints: 10.128.0.21:8080,10.129.0.37:8080

Session Affinity: None

External Traffic Policy: Cluster

Events: <none>

2.9 驗證外部訪問

[student@workstation ~]$ curl http://node1.lab.example.com:30800

  1 <html>
  2  <head>
  3   <title>PHP Test</title>
  4  </head>
  5  <body>
  6  <br/> Server IP: 10.128.0.21
  7  </body>
  8 </html>

[student@workstation ~]$ curl http://node2.lab.example.com:30800

  1 <html>
  2  <head>
  3   <title>PHP Test</title>
  4  </head>
  5  <body>
  6  <br/> Server IP: 10.129.0.37
  7  </body>
  8 </html>

2.10 使用pod shell

[student@workstation ~]$ oc rsh hello-1-kszfh #使用pod的shell

sh-4.2$ curl http://services.lab.example.com

三 OpenShift router

3.1 OpenShift route概述

OpenShift service允許在OpenShift中的pod之間進行網絡訪問；

OpenShift routes允許從OpenShift外部對pods進行網絡訪問。



路由概念上是通過連接公網IP和DNS主機名訪問內網service IP。在實踐中，為了提高性能和減少延遲，OpenShift route通過OpenShift創建的網絡直接連接到pod，使用該服務只查找endpoint，service只是協助查詢Pod地址。

OpenShift 路由功能由router service提供，該服務在OpenShift實例中作為一個pod運行，可以像任何其他常規pod一樣伸縮和複製。router service基於開源軟件HAProxy實現。

OpenShift route配置的公共DNS主機名需要指向運行router的節點的公共IP地址。route pod與常規應用程序pod不同，它綁定到節點的公共IP地址，而不是內部pod網絡。這通常使用DNS通配符配置。

  1 - apiVersion: v1
  2   kind: Route				#聲明為route類型
  3   metadata:
  4     creationTimestamp: null
  5     labels:
  6       app: quoteapp
  7     name: quoteapp				#路由器名字
  8   spec:
  9     host: quoteapp.apps.lab.example.com	#與route關聯的FQDN，必須預先配置，以解析到OpenShift route pod運行的節點的IP地址
 10     port:
 11       targetPort: 8080-tcp
 12   to:					#一個對象，該對象聲明此route指向的資源類型(在本例中是OpenShift service)，以及該資源的名稱(quoteapp)
 13     kind: Service
 14     name: quoteapp

提示：不同資源類型可以使用相同的名稱，如一個名為quoteapp的route可以指向一個名為quoteapp的service。

service通過selector與pod的label進行匹配，router通過name與service的name匹配。

3.2 創建route

創建route最簡單和推薦的方法是使用oc expose命令，將service資源名稱作為輸入參數。–name選項可用於控制route資源的名稱，–hostname選項可用於為route提供自定義主機名。

示例：

[user@demo ~]$ oc expose service quote \

–name quote –hostname=quoteapp.apps.lab.example.com

從模板或不帶–hostname參數的oc expose命令創建的路由，命名方式為：

<route-name>-<project-name>.<default-domain>

解釋

route-name：route的名稱，或原始資源的名稱；

project-name：包含資源的項目的名稱；

default-domain：該值是在OpenShift master上配置的，它對應於作為安裝OpenShift先決條件列出的通配符DNS域。

例如，在OpenShift集群中名為test的project中創建一條名為quote的路由，其中子域為apps.example.com，則FQDN為quote-test.apps.example.com

注意：承載通配符域的DNS服務器不知道任何route的主機名，它只將任何名稱解析為已配置的ip。只有OpenShift route知道route主機名，將每個主機都當作HTTP虛擬主機。無效的通配符域主機名，即不與任何route對應的主機名，將被OpenShift路由器阻塞。

通過向oc create提供JSON或YAML資源定義文件，也可以像其他OpenShift資源一樣創建route資源。

oc new-app命令在從容器映像、Dockerfiles或應用程序源代碼構建pod時不創建route資源。

oc new-app命令不知道pod是否打算從OpenShift實例外部訪問。當oc new-app命令從模板創建一組pod時，沒有什麼可以阻止模板將路由資源包含到應用程序中。

3.3 查找默認subdomain

默認路由子域是在OpenShift配置文件master-config.yaml中的routingConfig字段中定義，使用關鍵字subdomain。

routingConfig:

subdomain: apps.example.com

默認情況下，OpenShift HAProxy route綁定到主機端口80 (HTTP)和443 (HTTPS)。route必須放置在這些端口不使用的節點上。或者，可以通過設置ROUTER_SERVICE_HTTP_PORT和ROUTER_SERVICE_HTTPS_PORT環境變量來配置路由器監聽其他端口.

路由器支持以下協議：

• HTTP

• HTTPS with SNI
• WebSockets
• TLS with SNI

3.4 routing類型和選項

路由可以是安全的，也可以是非安全的。安全route提供了使用幾種類型的TLS方式來向客戶端提供證書的能力。不安全路由是最容易配置的，因為它們不需要密鑰或證書，但是安全路由會加密進出pod的流量。

在創建安全路由之前，需要生成TLS證書。

示例：如下步驟創建名為test.example.com的路由創建一個簡單的自簽名證書。

• 使用openssl命令創建私鑰：

[user@demo ~]$ openssl genrsa -out example.key 2048

• 使用生成的私鑰創建證書籤名請求(CSR)：

[user@demo ~]$ openssl req -new -key example.key -out example.csr -subj “/C=US/ST=CA/L=Los Angeles/O=Example/OU=IT/CN=test.example.com”

• 使用密鑰和CSR生成證書

[user@demo ~]$ openssl x509 -req -days 366 -in example.csr -signkey example.key -out example.crt

• 當證書準備好時，創建一個edge-terminated的路由

[user@demo ~]$ oc create route edge –service=test \

–hostname=test.example.com \

–key=example.key –cert=example.crt

3.5 通配符子域

wildcard policy允許用戶定義domain中所有主機的route。route可以使用wildcardPolicy字段將wildcard policy指定為其配置的一部分。OpenShift路由器支持通配符路由，通過設置路由器部署配置中的ROUTER_ALLOW_WILDCARD_ROUTES環境變量為true，從而可將wildcardPolicy屬性設置為子域的任何route都由路由器提供服務。路由器根據route的通配符策略暴露相關的service。

示例：如下下示例表示對於三個不同的路由，a.lab.example.com、b.lab.example.com和c.lab.example.com，它們應該路由到一個名為test的OpenShift服務，可以使用通配符策略配置路由。

• 將路由器作為集群管理用戶處理通配符路由

[user@demo ~]$ oc scale dc/router –replicas=0

[user@demo ~]$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

[user@demo ~]$ oc scale dc/router –replicas=1

• 使用通配符策略創建新路由

[user@demo ~]$ oc expose svc test –wildcard-policy=Subdomain \

–hostname=’www.lab.example.com’

3.6 管理route

在master節點上，在default中查找router

[root@master]# oc project default

[root@master]# oc get pods

在master節點上，檢查路由器環境變量，以找到運行在pod中的HAProxy進程的連接參數

[root@master]# oc env pod router-1-32toa –list | tail -n 6

提示：當創建路由器時，STATS_PASSWORD變量中的密碼是隨機生成的。STATS_USERNAME和STATS_PORT變量有固定的默認值，但是它們都可以在路由器創建時更改。

在router運行的節點上，配置firewall-cmd以打開STATS_PORT變量指定的端口。

[root@node ~]# firewall-cmd –permanent –zone=public –add-port=1936

[root@node ~]# firewall-cmd –reload

打開web瀏覽器並訪問HAProxy statistics URL 為 http://nodeIP:STATS_PORT/。

在User Name字段中輸入STATS_USERNAME的值，在Password字段中輸入STATS_PASSWORD的值，然後單擊OK。則會显示的HAProxy metrics頁面。

四 創建Route練習

4.1 前置準備

準備完整的OpenShift集群，參考《003.OpenShift網絡》2.1。

4.2 本練習準備

[student@workstation ~]$ lab secure-route setup #準備本實驗環境

4.3 創建應用

[student@workstation ~]$ oc login -u developer -p redhat https://master.lab.example.com

[student@workstation ~]$ oc new-project secure-route #創建project

[student@workstation ~]$ oc new-app –docker-image=registry.lab.example.com/openshift/hello-openshift –name=hello

[student@workstation ~]$ oc get pods -o wide

NAME READY STATUS RESTARTS AGE IP NODE

hello-1-wwgkr 1/1 Running 0 20s 10.129.0.38 node2.lab.example.com

4.4 創建TLS證書

[student@workstation ~]$ cd /home/student/DO280/labs/secure-route/ #使用環境中的腳本快速創建TLS自簽名證書

[student@workstation secure-route]$ ./create-cert.sh

4.5 創建route

[student@workstation secure-route]$ ll

-rw-r–r–. 1 student student 550 Aug 7 2018 commands.txt

-rwxr-xr-x. 1 student student 506 Jul 19 2018 create-cert.sh

-rw-rw-r–. 1 student student 1224 Jul 20 10:43 hello.apps.lab.example.com.crt

-rw-rw-r–. 1 student student 1017 Jul 20 10:43 hello.apps.lab.example.com.csr

-rw-rw-r–. 1 student student 1679 Jul 20 10:43 hello.apps.lab.example.com.key

[student@workstation secure-route]$ oc create route edge \

> –service=hello –hostname=hello.apps.lab.example.com \

> –key=hello.apps.lab.example.com.key \

> –cert=hello.apps.lab.example.com.crt

4.6 確認驗證

[student@workstation secure-route]$ oc get route

NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD

hello hello.apps.lab.example.com hello 8080-tcp edge None

[student@workstation secure-route]$ oc get route hello -o yaml #以yaml格式查看route

4.7 測試訪問

[student@workstation ~]$ curl http://hello.apps.lab.example.com #以http形式訪問會無法轉發至後端任何pod

  1 ……
  2       <h1>Application is not available</h1>
  3       <p>The application is currently not serving requests at this endpoint. It may not have been started or is still starting.</p>
  4 ……

[student@workstation ~]$ curl -k -vvv https://hello.apps.lab.example.com #以https形式訪問

  1 ……
  2 Hello OpenShift!
  3 * Connection #0 to host hello.apps.lab.example.com left intact
  4 ……

4.8 非安全形式訪問

由於加密的通信在路由器上終止，並且請求使用不安全的HTTP轉發到pods，所以可以使用pod IP地址通過普通HTTP訪問應用程序。為此，請使用oc get pods -o命令中指定的IP地址。

[student@workstation secure-route]$ oc get pod -o wide

NAME READY STATUS RESTARTS AGE IP NODE

hello-1-wwgkr 1/1 Running 0 21m 10.129.0.38 node2.lab.example.com

[root@node1 ~]# curl -vvv http://10.129.0.38:8080

五 OpenShift網絡綜合實驗

5.1 前置準備

準備完整的OpenShift集群，參考《003.OpenShift網絡》2.1。

5.2 本練習準備

[student@workstation ~]$ lab network-review setup

5.3 驗證所需資源

[student@workstation ~]$ oc login -u developer -p redhat \

https://master.lab.example.com

[student@workstation ~]$ oc get pod -o wide

NAME READY STATUS RESTARTS AGE IP NODE

hello-openshift-1-6ls8z 1/1 Running 0 2m 10.128.0.23 node1.lab.example.com

[student@workstation ~]$ oc get svc

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

hello-openshift ClusterIP 172.30.124.237 <none> 8080/TCP,8888/TCP 2m

[student@workstation ~]$ oc get route

NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD

hello-openshift hello.apps.lab.example.com hello-opensift 8080-tcp None

5.4 測試訪問

[student@workstation ~]$ curl http://hello.apps.lab.example.com #測試http訪問

  1 ……
  2       <h1>Application is not available</h1>
  3       <p>The application is currently not serving requests at this endpoint. It may not have been started or is still starting.</p>
  4 ……

[root@node1 ~]# curl http://10.128.0.23:8080 #測試使用pod ip訪問

Hello OpenShift!

[root@node1 ~]# curl http://172.30.124.237:8080 #測試使用cluster ip訪問

curl: (7) Failed connect to 172.30.124.237:8080; Connection refused

5.5 TS cluster故障

[student@workstation ~]$ oc describe svc hello-openshift -n network-review



提示：由上可知，沒有endpoint，endpoint是使用selector對pod的label進行匹配。

[student@workstation ~]$ oc describe pod hello-openshift-1-6ls8z #查看pod詳情



故障點：由上可知，Selector的label不一致，則沒有標記為hello_openshift的pod能進行匹配。

[student@workstation ~]$ oc edit svc hello-openshift

  1 ……
  2   selector:
  3     app: hello-openshift
  4     deploymentconfig: hello-openshift
  5   sessionAffinity: None
  6 ……

5.6 測試訪問

[root@node1 ~]# curl http://10.128.0.23:8080 #測試使用pod ip訪問

Hello OpenShift!

[root@node1 ~]# curl http://172.30.124.237:8080 #再次測試

Hello OpenShift!

[student@workstation ~]$ curl http://hello.apps.lab.example.com #測試http訪問

  1 ……
  2       <h1>Application is not available</h1>
  3       <p>The application is currently not serving requests at this endpoint. It may not have been started or is still starting.</p>
  4 ……

5.7 TS route故障

[student@workstation ~]$ oc describe route hello-openshift



故障點：由上可知，此路由沒有endpoint。即對route的URL請求沒有後端endpoint進行響應。路由器查詢service的endpoint，並註冊有效的endpoint來實現負載平衡。同時發現service名稱中有一個拼寫錯誤，它應該是hello-openshift。

[student@workstation ~]$ oc edit route hello-openshift

  1 ……
  2 spec:
  3   host: hello.apps.lab.example.com
  4   port:
  5     targetPort: 8080-tcp
  6   to:
  7     kind: Service
  8     name: hello-openshift
  9     weight: 100
 10   wildcardPolicy: None
 11 ……

[root@node1 ~]# curl http://hello.apps.lab.example.com #再次測試

Hello OpenShift!

5.8 確認驗證

[student@workstation ~]$ lab network-review grade #使用腳本判斷 本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

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

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

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

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

※聚甘新

電源管理及散熱解決方案廠商台達電10日宣布，BMW台灣總代理汎德選定台達的電動車充電解決方案，並捐贈給台北市政府，將在今年3月底前，為台北市20處公用停車場設置40台具有網路通訊功能、IP55防塵防水與時尚精巧的外型設計的台達智能電動車交流充電機，為越來越多的BMW i系列以及搭配J1772 Type1規格的電動車提供更便捷的充電服務，同時也強化了台達在台灣的充電站普及率。

台達副總裁暨電源系統事業群總經理鄭安強調，台達十分樂意與夥伴攜手實現智能綠生活，很榮幸可以滿足BMW台灣總代理汎德對充電站的嚴謹要求，包括其高度可靠度以及智能化。事實上，台達電動車充電解決方案已獲得許多國家的肯定，並且在歐洲、台灣以及大中華區累積不少成功案例。

台達電指出，台達智能電動車交流充電機擁有網路通訊功能、內建RFID讀卡機與7kW電源容量，能協助系統管理廠商為電動車車主提供更便利的服務。另外，這款通過台灣CNS標準認證的交流充電機具有IP55防塵防水與防破壞(IK8)機體設計，除了相當堅固外，時尚精巧的外型設計更能節省空間，而台達充電站管理系統(Site Management System, SMS)能進行遠端支援及能源管理的功能，提升充電基地營運效率。

台達電並表示，台達電動車充電解決方案逐步於全球協助夥伴建立住宅及商業應用的高效、快速與方便的電動車充電設備。例如，台達的120kW直流超快速電動車充電機於挪威及瑞典的高速公路能夠同時提供四台電動車快充的服務。台達其它直流與交流技術也於香港國際機場、上海的商業大樓與台灣的日月潭旅客租車服務支援電動交通。

（本文內容由授權使用。）

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

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

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

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

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

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

在鋰電池電動車發展趨穩定的現階段，也有另一派人支持發展氫動力燃料電動車。美國本田汽車（Honda）和通用汽車（GM）宣布將攜手發展氫動力燃料電池新系統，預計2020 年投產。

美國加州政策規定，自2018年起，各家汽車製造商要銷售一定比例之「零排放車」。看準美國對電動車需求將增加，兩公司於1月30日宣布，將共同出資成立公司，合作發展氫動力電池系統，廠址將設於通用美國密西根州的工廠內。而本田汽車目前於日本櫪木縣高根澤町的工廠，之後將逐步停產。

鋰電池電動車和氫燃料電動車各有其擁護者與利弊。雖然兩者都被列為「零汙染」汽車，但實際上鋰電池電動車環保與否還要追溯到發電的來源，而氫動力燃料電池則有甲烷和一氧化碳排放的疑慮。充電方面，電動車充電耗時；氫燃料補充速度和油槍一般，只是日後加氫站的設點還有待規劃，安全性的需求也更高。

本田和通用自2013年就已展開合作。本次協議各出資一半資金成立新公司，目標是降低氫燃料電池成本較高的難題，並在環保車競爭市場保有優勢。

（首圖來源：General Motors）

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

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

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

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

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

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

昶洧控股公司（Thunder Power Holdings Ltd）於 6 日與摩根大通公司亞太區簽署融資代理合約，摩根大通將擔任昶洧本次全球 A 輪融資的獨家代理，目標於六個月內完成 1.5 億美元之資金籌集，折合新台幣約 46 億元。昶洧指出，未來該筆資金的注入將可為加速於歐洲市場開發添翼。

昶洧表示，該資金將用於全面展開昶洧控股於歐洲開發生產商用轎車基地，及意大利超級跑車等兩個投資項目；此輪融資將是繼與贛卅發改委產業基金成立合資公司，啟動中國大陸電動汽車生產事業後，針對開啟歐洲及國際電動車市場的重大戰略計劃。

昶洧指出，旗下電動車研發已進入路測階段，因其技術深獲西班牙巴塞隆納區及蘇格蘭政府看中，並積極提出合作的方案，故於歐洲開發生產基地與完成各項測試作業已刻不容緩。

（本文內容由授權使用）

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

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

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

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

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

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