• nodejs模塊語法與開閉原則
• nodejs模塊的底層實現

 一、nodejs模塊語法與開閉原則

關於nodejs模塊我在之前的兩篇博客中都有涉及，但都沒有對nodejs模塊的底層做做任何探討，但是為了使相關內容更方便查看比對理解，這裏還是先引入一下之前兩篇博客的連接：

1.1 exports、module.exports、require()實現模塊導出導入：

 1 //示例一：導出原始值數據
 2 //a.js--用於導出數據
 3 let a = 123;
 4 module.exports.a=a;
 5 //inde.js--用於導入a模塊的數據
 6 let aModule = require('./a.js');
 7 console.log(aModule.a); //123
 8 
 9 //示例二：導出引用值數據
10 //a.js--同上
11 function foo(val){ 
12     console.log(val);
13 }
14 module.exports.foo = foo;
15 //index.js--同上
16 let aModule = require('./a.js');
17 let str = "this is 'index' module"
18 aModule.foo(str); //this is 'index' module
19 
20 //示例三：導出混合數據
21 a.js--同上
22 let a = 123;
23 function foo(val){ 
24     console.log(val);
25 }
26 module.exports = {
27     a:a,
28     foo:foo
29 }
30 //inde.js--同上
31 let aModule = require('./a.js');
32 let str = "this is 'index' module"
33 console.log(aModule.a);//123
34 aModule.foo(str); //this is 'index' module

在上面這些示例中，沒有演示exports的導出，暫時可以把它看作與同等於module.exports，例如：

 1 //a.js -- 導出模塊
 2 let a = 123;
 3 function foo(val){ 
 4     console.log(val);
 5 }
 6 exports.a = a;
 7 exports.foo = foo;
 8 
 9 //inde.js -- 引用模塊a
10 let aModule = require('./a.js');
11 let str = "this is 'index' module"
12 console.log(aModule.a);//123
13 aModule.foo(str); //this is 'index' module

但是使用exports導出模塊不能這麼寫：

 1 //a.js
 2 let a = 123;
 3 function foo(val){ 
 4     console.log(val);
 5 }
 6 exports = {
 7     a:a,
 8     foo:foo
 9 }
10 
11 //index.js
12 let aModule = require('./a.js');
13 let str = "this is 'index' module"
14 console.log(aModule);// {} -- 一個空對象

至於為什麼不能這麼寫，暫時不在這裏闡述，下一節關於nodejs模塊底層實現會具體的分析介紹，這裏先來介紹nodejs模塊的一個設計思想。

1.2 nodejs模塊的開閉原則設計實現

1 //a.js -- 導出模塊
2 let num = 123;
3 let str = "this is module 'a'";
4 exports.a = a;
5 
6 //index.js -- 引用模塊a
7 let aModule = require('./a.js');
8 console.log(aModule.num);//123
9 console.log(aModule.str);//undefined

這裏你會發現只有被exports執行了導出的num成員才能被正常導出，而str成員沒有被執行導出，在依賴a.js模塊的index.js中是不能引用到a.js模塊中的str成員。可能你會說這不是很正常嗎？都沒有導出怎麼引用呢？

不錯，這是一個非常正常情況，因為語法就告訴了我們，要想引用一個模塊的成員就必須先在被引用的模塊中導出該成員。然而這裏要討論的當然不會是導出與引用這個問題，而是模塊給我實現了一個非常友好的設計，假設我現在在a.js中有成員str，在index.js模塊中也有成員str，這回衝突嗎？顯然是不會的，即使在a.js中導出str並且在index.js中引用a.js模塊，因為index.js要使用a.js模塊的成員str，需要使用接收模塊變量aModule.str來使用。

 1 //a.js
 2 let num = 123;
 3 let str = "this is module 'a'";
 4 exports.num = num;
 5 exports.str = str;
 6 
 7 //index.js
 8 let aModule = require('./a.js');
 9 let str = "this is module 'index'"
10 console.log(aModule.num);//123
11 console.log(aModule.str);//this is module 'a'
12 console.log(str);//this is module 'index'

基於開閉原則的設計方式，封閉可以讓模塊的內部實現隱藏起來，開放又可以友好的實現模塊之間的相互依賴，這相對於之前我們常用的回調函數解決方案，程序設計變得更清晰，代碼復用變得更靈活，更關鍵的是還解決了js中一個非常棘手的問題——命名衝突問題，上面的示例就是最好的證明。這裏需要拋出一個問題，看示例：

1 //下面這種寫法有什麼問題？
2 //a.js
3 let num = 123;
4 module.exports = num;
5 
6 //index.js
7 let aModule = require('./a.js');
8 let str = "this is module 'index'"
9 console.log(aModule);//123

這種寫法不會報錯，也能正常達到目前的需求，如果從能解決目前的功能需求角度來說，它沒錯。但是開閉原則的重要思想就是讓模塊保持相對封閉，又有更好的拓展性，這樣寫顯然不合適，比如就上面的代碼寫完上線以後，業務又出現了一個新的需求需要a.js模塊導出一個成員str，這時候顯然需要同時更改a.js模塊和index.js模塊，即使新需求不需要index.js來實現也是需要改的。所以維持模塊的開閉原則是良好的編碼風格。

 二、nodejs模塊的底層實現原理

2.1 module.exports與exports的區別：

//a.js
console.log(module.exports == exports);//true

//然後在控制台直接執行a.js模塊
node a.js

實際上它們是沒有區別的，那為什麼在之前的exports不能直接等於一個對象，而module.exports可以呢？這關乎於js的引用值指向問題：

 當export被賦值一個對象時，就發生了一下變化：

這時候我們可以確定node不會導出exports，因為前面的示例已經說明了這一點，但是值得我們繼續思考的是，node模塊是依據module.exports、exports、還是它們指向的初始對象呢？這裏你肯定會說是module.exports，因為前面已經有示例是module.exports指向一個新的對象被成功導出，但是我並不覺得前面那些示例能說服我，比如下面這種情況：

 1 //a.js模塊
 2 let num = 123;
 3 function foo(val){
 4     console.log(val);
 5 }
 6 module.exports = {
 7     num:num
 8 }
 9 exports = {
10     foo:foo
11 }
12 //index.js模塊
13 let aModule = require('./a.js');
14 console.log(aModule);//這裡會打印出什麼？

我們現不測試也不猜測，先通過下面的示圖來看下現在的a.js模塊中module.exports、exports、以及它們兩初始指向的空對象的關係圖：

 這時候我們來看一下index.js執行會輸出什麼？

{ num: 123 }

所以從這個結果可以看出，最後require()最後導入的是被引用模塊的module.exports。探討到這裏的時候並沒有到達node模塊的終點，我們這裏module.exports、exports、require()是從哪裡來的？node系統內置變量？還是別的？

2.2 node模塊的底層實現原理

這部分的內容其實也沒有太多可以說的，就前面提出來的問題其實有一個方式就可以讓你一目瞭然，只需要在一個js文件中編寫以下代碼，然後使用node執行這個js文件就可以了：

1 console.log(require);      // 一個方法
2 console.log(module);       //  一個對象
3 console.log(exports);      //  一個空對象
4 console.log(__dirname);    //  當前模塊所在路徑
5 console.log(__filename);   //  當前文件的路徑

 這時因為node模塊實際上底層是被放到一個立即執行函數內（不要在乎xyz這個名稱，因為我也不知道node底層到底用的什麼名稱），這些變量其實就是這個函數的參數，這個函數大概是一下形式：

1 function xyz(module.exports,require,module,__filename,__dirname){
2     //...
3     //  這裏就是我們在模塊中寫入的代碼
4     //...
5     return module.exports;
6 }

通過上面的推斷就可以得到下面這樣的結果：

1 console.log(module.exports == arguments[0]);//true
2 console.log(require == arguments[1]);//true
3 console.log(module == arguments[2]);//true
4 console.log(__filename == arguments[3]);//true
5 console.log(__dirname == arguments[4]);//true

通過執行這段打印代碼也確實可以得到這樣的結果，到這裏又有一個值得我們關注的內容，就是每個模塊的module參數：

 1 console.log(module);
 2 Module {
 3     id: '.',//當前模塊的id都是'.'，在後面的parent和children裏面的模塊對象上的id就是的對應模塊的filename
 4     exports: {},//這裡是模塊導出對象
 5     parent: null,//這裡是當前模塊被那些模塊引用的模塊對象列表，意思是當前模塊作為那些模塊的父級模塊
 6     filename:''，//這裡是當前文件路徑的絕對路徑
 7     loaded: false,//模塊加載狀態，如果在模塊內部輸出module對象它永遠都會是false，因為只有這個模塊加載完成之後才會被修改成true
 8     children: [
 9         // 這裡是引用模塊module對象列表，意思是當前模塊作為了那些模塊的子模塊
10     ],
11     paths:[ 
12         // 這裡是外部模塊包的路徑列表，從最近的路徑（模塊所在同級路徑）到系統盤路徑所有的node_modules文件夾路徑
13      ] 
14     }

到這裡有可能你還會問為什麼底層實現裏面只有module.exports，沒有export，這個解釋起來真的費勁，下面這一行代碼幫你搞定：

let exports = module.exports;

這篇博客主要介紹了node模塊的內部內容，並未就node模塊基於commonjs規範做任何介紹，是因為在之前的博客中已經有了非常全面的解析，詳細參考博客開始時的連接，關於node模塊加載相關內容也是在那篇博客。

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

【其他文章推薦】

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

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

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

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

充電慢、交換電池麻煩，這是全電動車的兩難，尤其是若要發展大眾運輸，全電動公車可不能總是停在路邊充電，為了解決這個問題，機電大廠ABB 推出以超級電容（Supercapacitors）「閃充」技術，如今已經接到第一筆訂單。

2016 年7 月中，美國政府期望推動讓未來的電動車能在10 分鐘內充電完成，不過，其實不用等到未來，ABB 現有的技術就已經讓10 分鐘看起來顯得落伍，因為超級電容可以600kW，在15 秒內閃充，提供電動公車行駛到下一個充電站的電力，而若是需完全充飽電池，也只需要幾分鐘。ABB 已經小規模測試此技術數年。

如今，ABB 接到第一筆商業訂單，來自於公車營運商Tosa，將於日內瓦市郊到機場的公車路線上行駛。這款全電動公車行駛時與一般公車無異，不過總共50 個公車站中，有13 個公車站是充電站，當公車進站時，車頂上會伸出接收器，與車站的充電裝置接觸，在15 秒內閃充，取得可行駛到下一個充電站的電力，而在公車總站，則有200kW充電器，以3~5 分鐘時間將電池完全充飽。

充電站採用超級電容，超級電容的能源密度雖然不如鋰電池，但可緩緩充能，於短時間內一次釋放，除了縮短電動公車的充電時間，使得公車能在靠站時閃充以外，也能減輕電網負擔，因為用電量是平均分攤在緩緩充能的階段，而不是一接上充電座時就突然大增電力需求，充完又需求突降，造成電網調度上的困擾。另一方面，由於分散了負擔，整個充電站可以用較低成本的低電流規劃打造。

這種方式也利於應用太陽能，公車站可設置太陽能發電，為超級電容緩緩充能，充電時間之中萬一有雲飄過，一時中斷供電，也不會產生太大影響。而由於公車班次最多時間是在白天，因此太陽能可發揮相當效用。

ABB 先前將超級電容應用於電車煞車回電，2013 年起，ABB 與Tosa 測試超級電容應用於全電動公車，目前測試結果，其成本已經與柴油車相當，未來隨著相關技術成熟，電池價格進一步下降，將有可能比柴油車更便宜，除了價格以外，全電動公車還有無碳排放、無廢氣空氣污染、噪音低的好處，有助於改善市區生活品質。

這款全電動巴士預定於2018 年全面營運。

來源：

（本文授權轉載自《》──〈〉。圖片來源：）

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

【其他文章推薦】

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

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

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

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

一 deploymentPod升級和回滾

1.1 deployment升級

若Pod是通過Deployment創建的，可以在運行時修改Deployment的Pod定義（spec.template）或鏡像名稱，並應用到Deployment對象上，系統即可完成Deployment的自動更新操作。 如果在更新過程中發生了錯誤， 則還可以通過回滾操作恢復Pod的版本。

示例：

  1 [root@uk8s-m-01 study]# vi nginx-deployment.yaml
  2 apiVersion: apps/v1beta1
  3 kind: Deployment
  4 metadata:
  5   name: nginx-deployment
  6 spec:
  7   replicas: 3
  8   template:
  9     metadata:
 10       labels:
 11         app: nginx
 12     spec:
 13       containers:
 14       - name: nginx
 15         image: nginx:1.7.9
 16         ports:
 17         - containerPort: 80
 18 
 19 [root@uk8s-m-01 study]# kubectl create -f nginx-deployment.yaml
 20 [root@uk8s-m-01 study]# kubectl get pods

  1 [root@uk8s-m-01 study]# kubectl get deployment			#查看deployment
  2 [root@uk8s-m-01 study]# kubectl set image deployment/nginx-deployment nginx=nginx:1.8.1	#命令更新
  3 [root@uk8s-m-01 study]# kubectl get pods			        #查看升級后的pod

  1 [root@uk8s-m-01 study]# kubectl edit deployment/nginx-deployment			#直接編輯deployment

  1 [root@uk8s-m-01 study]# kubectl rollout status deployment/nginx-deployment		#查看升級情況

  1 [root@uk8s-m-01 study]# kubectl get pods
  2 [root@uk8s-m-01 study]# kubectl describe pod nginx-deployment-7448597cd5-8sng2 | grep Image

1.2 deployment升級原理

  1 [root@uk8s-m-01 study]# kubectl describe deployments/nginx-deployment		#觀察Deployment的更新過程

初始創建Deployment時，系統創建了一個ReplicaSet（nginx-deployment-5754944d6c），並按用戶的需求創建了3個Pod副本。

當更新Deployment時，系統創建了一個新的ReplicaSet（nginx-deployment-b5f766d54），並將其副本數量擴展到1，然後將舊ReplicaSet縮減為2。

之後，系統繼續按照相同的更新策略對新舊兩個ReplicaSet進行逐個調整。

最後，新的ReplicaSet運行了3個新版本Pod副本，舊的ReplicaSet副本數量則縮減為0。

  1 [root@uk8s-m-01 study]# kubectl get rs			#查看多次升級的結果

注意：在整個升級的過程中，系統會保證至少有兩個Pod可用，並且最多同時運行4個Pod，這是Deployment通過複雜的算法完成的。Deployment需要確保在整個更新過程中只有一定數量的Pod可能處於不可用狀態。在默認情況下，Deployment確保可用的Pod總數至少為所需的副本數量（DESIRED）減1，也就是最多1個不可用（maxUnavailable=1）。

1.3 deployment升級策略

在Deployment的定義中，可以通過spec.strategy指定Pod更新的策略，目前支持兩種策略：Recreate（重建）和RollingUpdate（滾動更新），默認值為RollingUpdate。

• Recreate：設置spec.strategy.type=Recreate，表示Deployment在更新Pod時，會先殺掉所有正在運行的Pod，然後創建新的Pod。
• RollingUpdate：設置spec.strategy.type=RollingUpdate，表示Deployment會以滾動更新的方式來逐個更新Pod。同時，可以通過設置spec.strategy.rollingUpdate下的兩個參數（maxUnavailable和maxSurge）來控制滾動更新的過程。

• spec.strategy.rollingUpdate.maxUnavailable：用於指定Deployment在更新過程中不可用狀態的Pod數量的上限。 該maxUnavailable的數值可以是絕對值（例如5）或Pod期望的副本數的百分比（例如10%），如果被設置為百分比，那麼系統會先以向下取整的方式計算出絕對值（整數）。而當另一個參數maxSurge被設置為0時，maxUnavailable則必須被設置為絕對數值大於0。舉例來說，當maxUnavailable被設置為30%時，舊的ReplicaSet可以在滾動更新開始時立即將副本數縮小到所需副本總數的70%。一旦新的Pod創建並準備好，舊的ReplicaSet會進一步縮容，新的ReplicaSet又繼續擴容。整個過程中系統在任意時刻都可以確保可用狀態的Pod總數至少佔Pod期望副本總數的70%。
• spec.strategy.rollingUpdate.maxSurge：用於指定在Deployment更新Pod的過程中Pod總數超過Pod期望副本數部分的最大值。該maxSurge的數值可以是絕對值（例如5）或Pod期望副本數的百分比（例
• 如10%）。如果設置為百分比，那麼系統會先按照向上取整的方式計算出絕對數值（整數）。舉例來說，當maxSurge的值被設置為30%時，新的ReplicaSet可以在滾動更新開始時立即進行副本數擴容，只需要保證新舊ReplicaSet的Pod副本數之和不超過期望副本數的130%即可。一旦舊的Pod被殺掉，新的ReplicaSet就會進一步擴容。在整個過程中系統在任意時刻都能確保新舊ReplicaSet的Pod副本總數之和不超過所需副本數的130%。

1.4 deployment回滾

默認情況下，所有Deployment的發布歷史記錄都被保留在系統中，以便於我們隨時進行回滾（可以配置歷史記錄數量）。

  1 [root@uk8s-m-01 study]# kubectl rollout history deployment/nginx-deployment	#查看部署歷史
  2 [root@uk8s-m-01 study]# kubectl rollout history deployment/nginx-deployment  --revision=3	#查看對應的部署歷史版本
  3 [root@uk8s-m-01 study]# kubectl rollout history deployment/nginx-deployment  --revision=2	#查看對應的部署歷史版本

提示：Deployment的更新操作是在Deployment進行部署（Rollout）時被觸發的，即當且僅當Deployment的Pod模板（即spec.template）被更改時才會創建新的修訂版本，例如更新模板標籤或容器鏡像。其他更新操作（如擴展副本數）將不會觸發Deployment的更新操作，因此將Deployment回滾到之前的版本時，只有Deployment的Pod模板部分會被修改。

  1 [root@uk8s-m-01 study]# kubectl rollout undo deployment/nginx-deployment --to-revision=2	#回滾版本
  2 [root@uk8s-m-01 study]# kubectl describe deployment/nginx-deployment

1.5 暫停和恢復deployment

對於一次複雜的Deployment配置修改，為了避免頻繁觸發Deployment的更新操作，可以先暫停Deployment的更新操作，然後進行

配置修改，再恢復Deployment，一次性觸發完整的更新操作，從而避免不必要的Deployment更新操作了。

  1 [root@uk8s-m-01 study]# kubectl get deployments				#查看deployment
  2 [root@uk8s-m-01 study]# kubectl get rs					#查看rs
  3 [root@uk8s-m-01 study]# kubectl rollout pause deployment/nginx-deployment	#暫停deployment
  4 [root@uk8s-m-01 study]# kubectl set image deployment/nginx-deployment nginx=nginx:1.10.3	#升級操作，但由於暫停deployment，因此不會觸發更新
  5 [root@uk8s-m-01 study]# kubectl rollout history deployment/nginx-deployment	#查看歷史版本
  6 [root@uk8s-m-01 study]# kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
  7 [root@uk8s-m-01 study]# kubectl rollout resume deployment/nginx-deployment	#恢復deployment
  8 [root@uk8s-m-01 study]# kubectl get rs
  9 NAME                          DESIRED   CURRENT   READY   AGE
 10 nginx-deployment-7448597cd5   0         0         0       52m
 11 nginx-deployment-84bc94dcb7   1         1         0       6s
 12 nginx-deployment-b5f766d54    3         3         3       55m

  1 [root@uk8s-m-01 study]# kubectl describe deployment/nginx-deployment
  2 [root@uk8s-m-01 study]# kubectl describe pods nginx-deployment-84bc94dcb7-hqxkk | grep Image
  3     Image:          nginx:1.10.3

二 RC升級和回滾

2.1 RC滾動升級

， Kubernetes提供了kubectl rolling-update命令進行對於RC的滾動升級。該命令創建了一個新的RC，然後自動控制舊的RC中的Pod副本數量逐漸減少到0，同時新的RC中的Pod副本數量從0逐步增加到目標值，來完成Pod的升級。

注意：該方式要求新的RC與舊的RC都在相同的命名空間內。

示例：

  1 [root@uk8s-m-01 study]# vi redis-master-controller-v1.yaml
  2 apiVersion: v1
  3 kind: ReplicationController
  4 metadata:
  5   name: redis-master-v1
  6   labels:
  7     name: redis-master
  8 spec:
  9   replicas: 1
 10   selector:
 11     name: redis-master
 12   template:
 13     metadata:
 14       labels:
 15         name: redis-master
 16     spec:
 17       containers:
 18       - name: master
 19         image: kubeguide/redis-master:1.0
 20         ports:
 21         - containerPort: 6379
 22 
 23 [root@uk8s-m-01 study]# kubectl create -f redis-master-controller-v1.yaml

  1 [root@uk8s-m-01 study]# vi redis-master-controller-v2.yaml		#RC升級配置文件
  2 apiVersion: v1
  3 kind: ReplicationController
  4 metadata:
  5   name: redis-master-v2
  6   labels:
  7     name: redis-master
  8     version: v2
  9 spec:
 10   replicas: 1
 11   selector:
 12     name: redis-master
 13     version: v2
 14   template:
 15     metadata:
 16       labels:
 17         name: redis-master
 18         version: v2
 19     spec:
 20       containers:
 21       - name: master
 22         image: kubeguide/redis-master:2.0
 23         ports:
 24         - containerPort: 6379

注意：使用此方式升級的時候需要注意以下兩點：

1. RC的名字（name） 不能與舊RC的名字相同。
2. 在selector中應至少有一個Label與舊RC的Label不同， 以標識其為新RC。如上所示新增了一個名為version的Label，以與舊RC進行區分。

  1 [root@uk8s-m-01 study]# kubectl rolling-update redis-master-v1 -f redis-master-controller-v2.yaml
  2 [root@uk8s-m-01 study]# kubectl rolling-update redis-master-v1 --image=kubeguide/redis-master:2.0	#也可直接命令中升級

kubectl通過新建一個新版本Pod， 停掉一箇舊版本Pod，如此逐步迭代來完成整個RC的更新。

2.2 RC回滾

  1 [root@uk8s-m-01 study]# kubectl rolling-update redis-master-v1 --rollback

提示：RC的滾動升級不具有Deployment在應用版本升級過程中的歷史記錄、新舊版本數量的精細控制等功能，RC將逐漸被RS和Deployment所取代，建議用戶優先考慮使用Deployment完成Pod的部署和升級操作。

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

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

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

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

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