PHEV（插電式混合動力汽車）

Posted on 2020-09-102020-09-10 by admin

插電式混合動力汽車(Plug-in hybrid electric vehicle, PHEV)的是一種混合動力車輛。其充電電池可以使用外部電源充電，而電池容量比電動車小、但大多大於普通油電混合動力車。

插電式混合動力車輛是針對通勤族設計的，多數通勤族通勤距離在十幾公里內，插電式混合動力車輛的電池續航力只要有二三十公里即可以滿足多數通勤需求（通勤時不需啟動內燃機）。

在長途駕駛的情況下，既使是續航力數百公里的電動車也可能沒電，此時插電式混合動力車輛則使用內燃機提供能量，方便性與傳統汽柴油車輛相近；引擎運轉模式更接近最高效率的定速運轉，因此也很省油，甚至可以讓轉子引擎、渦輪引擎達到低油耗低污染的目標；有些車輛使用小型引擎、且不使用複雜的傳動系統，可以抵銷電池所增加的重量跟成本。

但混合動力車的缺點，插電式混合動力車輛可能更嚴重，例如鋰礦問題、電池成本、製造電池的環境成本。

發售中的插電式混合動力車輛有：比亞迪F3DM（比亞迪汽車）、雪佛蘭伏特（通用汽車）、普銳斯III PHEV（豐田汽車）等。

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

介紹

先說一下什麼是循環依賴，Spring在初始化A的時候需要注入B，而初始化B的時候需要注入A，在Spring啟動后這2個Bean都要被初始化完成

Spring的循環依賴有兩種場景

構造器的循環依賴
屬性的循環依賴

構造器的循環依賴，可以在構造函數中使用@Lazy註解延遲加載。在注入依賴時，先注入代理對象，當首次使用時再創建對象完成注入

屬性的循環依賴主要是通過3個map來解決的

構造器的循環依賴

@Component
public class ConstructorA {

	private ConstructorB constructorB;

	@Autowired
	public ConstructorA(ConstructorB constructorB) {
		this.constructorB = constructorB;
	}
}

@Component
public class ConstructorB {

	private ConstructorA constructorA;

	@Autowired
	public ConstructorB(ConstructorA constructorA) {
		this.constructorA = constructorA;
	}
}

@Configuration
@ComponentScan("com.javashitang.dependency.constructor")
public class ConstructorConfig {
}

public class ConstructorMain {

	public static void main(String[] args) {
		AnnotationConfigApplicationContext context =
				new AnnotationConfigApplicationContext(ConstructorConfig.class);
		System.out.println(context.getBean(ConstructorA.class));
		System.out.println(context.getBean(ConstructorB.class));
	}
}

運行ConstructorMain的main方法的時候會在第一行就報異常，說明Spring沒辦法初始化所有的Bean，即上面這種形式的循環依賴Spring無法解決。

我們可以在ConstructorA或者ConstructorB構造函數的參數上加上@Lazy註解就可以解決

@Autowired
public ConstructorB(@Lazy ConstructorA constructorA) {
	this.constructorA = constructorA;
}

因為我們主要關注屬性的循環依賴，構造器的循環依賴就不做過多分析了

屬性的循環依賴

先演示一下什麼是屬性的循環依賴

@Component
public class FieldA {

	@Autowired
	private FieldB fieldB;
}

@Component
public class FieldB {

	@Autowired
	private FieldA fieldA;
}

@Configuration
@ComponentScan("com.javashitang.dependency.field")
public class FieldConfig {
}

public class FieldMain {

	public static void main(String[] args) {
		AnnotationConfigApplicationContext context =
				new AnnotationConfigApplicationContext(FieldConfig.class);
		// com.javashitang.dependency.field.FieldA@3aa9e816
		System.out.println(context.getBean(FieldA.class));
		// com.javashitang.dependency.field.FieldB@17d99928
		System.out.println(context.getBean(FieldB.class));
	}
}

Spring容器正常啟動，能獲取到FieldA和FieldB這2個Bean

屬性的循環依賴在面試中還是經常被問到的。總體來說也不複雜，但是涉及到Spring Bean的初始化過程，所以感覺比較複雜，我寫個demo演示一下整個過程

Spring的Bean的初始化過程其實比較複雜，為了方便理解Demo，我就把Spring Bean的初始化過程分為2部分

bean的實例化過程，即調用構造函數將對象創建出來
bean的初始化過程，即填充bean的各種屬性

bean初始化過程完畢，則bean就能被正常創建出來了

下面開始寫Demo，ObjectFactory接口用來生產Bean，和Spring中定義的接口一樣

public interface ObjectFactory<T> {
	T getObject();
}

public class DependencyDemo {

	// 初始化完畢的Bean
	private final Map<String, Object> singletonObjects =
			new ConcurrentHashMap<>(256);

	// 正在初始化的Bean對應的工廠，此時對象已經被實例化
	private final Map<String, ObjectFactory<?>> singletonFactories =
			new HashMap<>(16);

	// 存放正在初始化的Bean，對象還沒有被實例化之前就放進來了
	private final Set<String> singletonsCurrentlyInCreation =
			Collections.newSetFromMap(new ConcurrentHashMap<>(16));

	public  <T> T getBean(Class<T> beanClass) throws Exception {
		// 類名為Bean的名字
		String beanName = beanClass.getSimpleName();
		// 已經初始化好了，或者正在初始化
		Object initObj = getSingleton(beanName, true);
		if (initObj != null) {
			return (T) initObj;
		}
		// bean正在被初始化
		singletonsCurrentlyInCreation.add(beanName);
		// 實例化bean
		Object object = beanClass.getDeclaredConstructor().newInstance();
		singletonFactories.put(beanName, () -> {
			return object;
		});
		// 開始初始化bean，即填充屬性
		Field[] fields = object.getClass().getDeclaredFields();
		for (Field field : fields) {
			field.setAccessible(true);
			// 獲取需要注入字段的class
			Class<?> fieldClass = field.getType();
			field.set(object, getBean(fieldClass));
		}
		// 初始化完畢
		singletonObjects.put(beanName, object);
		singletonsCurrentlyInCreation.remove(beanName);
		return (T) object;
	}

	/**
	 * allowEarlyReference參數的含義是Spring是否允許循環依賴，默認為true
	 * 所以當allowEarlyReference設置為false的時候，當項目存在循環依賴，會啟動失敗
	 */
	public Object getSingleton(String beanName, boolean allowEarlyReference) {
		Object singletonObject = this.singletonObjects.get(beanName);
		if (singletonObject == null 
				&& isSingletonCurrentlyInCreation(beanName)) {
			synchronized (this.singletonObjects) {
				if (singletonObject == null && allowEarlyReference) {
					ObjectFactory<?> singletonFactory =
							this.singletonFactories.get(beanName);
					if (singletonFactory != null) {
						singletonObject = singletonFactory.getObject();
					}
				}
			}
		}
		return singletonObject;
	}

	/**
	 * 判斷bean是否正在被初始化
	 */
	public boolean isSingletonCurrentlyInCreation(String beanName) {
		return this.singletonsCurrentlyInCreation.contains(beanName);
	}

}

測試一波

public static void main(String[] args) throws Exception {
	DependencyDemo dependencyDemo = new DependencyDemo();
	// 假裝掃描出來的對象
	Class[] classes = {A.class, B.class};
	// 假裝項目初始化所有bean
	for (Class aClass : classes) {
		dependencyDemo.getBean(aClass);
	}
	// true
	System.out.println(
			dependencyDemo.getBean(B.class).getA() == dependencyDemo.getBean(A.class));
	// true
	System.out.println(
			dependencyDemo.getBean(A.class).getB() == dependencyDemo.getBean(B.class));
}

是不是很簡單？我們只用了2個map就搞定了Spring的循環依賴

2個Map就能搞定循環依賴，那為什麼Spring要用3個Map呢？

原因其實也很簡單，當我們從singletonFactories中根據BeanName獲取相應的ObjectFactory，然後調用getObject()這個方法返回對應的Bean。在我們的例子中
ObjectFactory的實現很簡單哈，就是將實例化好的對象直接返回，但是在Spring中就沒有這麼簡單了，執行過程比較複雜，為了避免每次拿到ObjectFactory然後調用getObject()，我們直接把ObjectFactory創建的對象緩存起來不就行了，這樣就能提高效率了

比如A依賴B和C，B和C又依賴A，如果不做緩存那麼初始化B和C都會調用A對應的ObjectFactory的getObject()方法。如果做緩存只需要B或者C調用一次即可。

知道了思路，我們把上面的代碼改一波，加個緩存。

public class DependencyDemo {

	// 初始化完畢的Bean
	private final Map<String, Object> singletonObjects =
			new ConcurrentHashMap<>(256);

	// 正在初始化的Bean對應的工廠，此時對象已經被實例化
	private final Map<String, ObjectFactory<?>> singletonFactories =
			new HashMap<>(16);

	// 緩存Bean對應的工廠生產好的Bean
	private final Map<String, Object> earlySingletonObjects =
			new HashMap<>(16);

	// 存放正在初始化的Bean，對象還沒有被實例化之前就放進來了
	private final Set<String> singletonsCurrentlyInCreation =
			Collections.newSetFromMap(new ConcurrentHashMap<>(16));

	public  <T> T getBean(Class<T> beanClass) throws Exception {
		// 類名為Bean的名字
		String beanName = beanClass.getSimpleName();
		// 已經初始化好了，或者正在初始化
		Object initObj = getSingleton(beanName, true);
		if (initObj != null) {
			return (T) initObj;
		}
		// bean正在被初始化
		singletonsCurrentlyInCreation.add(beanName);
		// 實例化bean
		Object object = beanClass.getDeclaredConstructor().newInstance();
		singletonFactories.put(beanName, () -> {
			return object;
		});
		// 開始初始化bean，即填充屬性
		Field[] fields = object.getClass().getDeclaredFields();
		for (Field field : fields) {
			field.setAccessible(true);
			// 獲取需要注入字段的class
			Class<?> fieldClass = field.getType();
			field.set(object, getBean(fieldClass));
		}
		singletonObjects.put(beanName, object);
		singletonsCurrentlyInCreation.remove(beanName);
		earlySingletonObjects.remove(beanName);
		return (T) object;
	}

	/**
	 * allowEarlyReference參數的含義是Spring是否允許循環依賴，默認為true
	 */
	public Object getSingleton(String beanName, boolean allowEarlyReference) {
		Object singletonObject = this.singletonObjects.get(beanName);
		if (singletonObject == null
				&& isSingletonCurrentlyInCreation(beanName)) {
			synchronized (this.singletonObjects) {
				singletonObject = this.earlySingletonObjects.get(beanName);
				if (singletonObject == null && allowEarlyReference) {
					ObjectFactory<?> singletonFactory =
							this.singletonFactories.get(beanName);
					if (singletonFactory != null) {
						singletonObject = singletonFactory.getObject();
						this.earlySingletonObjects.put(beanName, singletonObject);
						this.singletonFactories.remove(beanName);
					}
				}
			}
		}
		return singletonObject;
	}
}

我們寫的getSingleton的實現和org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String, boolean)的實現一模一樣，這個方法幾乎所有分析Spring循環依賴的文章都會提到，這次你明白工作原理是什麼了把

總結一波

拿bean的時候先從singletonObjects（一級緩存）中獲取
如果獲取不到，並且對象正在創建中，就從earlySingletonObjects（二級緩存）中獲取
如果還是獲取不到就從singletonFactories（三級緩存）中獲取，然後將獲取到的對象放到earlySingletonObjects（二級緩存）中，並且將bean對應的singletonFactories（三級緩存）清除
bean初始化完畢，放到singletonObjects（一級緩存）中，將bean對應的earlySingletonObjects（二級緩存）清除

歡迎關注

參考博客

[1]https://mp.weixin.qq.com/s/gBr3UfC1HRcw4U-ZMmtRaQ
[2]https://mp.weixin.qq.com/s/5mwkgJB7GyLdKDgzijyvXw
比較詳細
[1]https://zhuanlan.zhihu.com/p/84267654
[2]https://juejin.im/post/5c98a7b4f265da60ee12e9b2

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

【其他文章推薦】

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

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

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

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

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

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

一起玩轉微服務（10）——spring boot介紹

Posted on 2020-09-092020-09-09 by admin

對於Spring，相信大家都非常熟悉，從出現開始，一直是企業級開發的主流。但是隨着軟件的發展和應用開發的不斷演化，它的一些缺點也逐漸胡暴露了出來，下面，我們就一起看一下Spring的發展歷程並且認識一下Spring Boot。

由來

在Spring 1.x的時候，所有的配置都通過XML，隨着項目的擴大，需要頻繁的在java和XML之間切換。在Spring 2.x的時候，已經開始逐步替換掉XML配置。在Spring 3.x的時候，已經開始提供java的配置方式，在4.x的時候，已經全部推薦使用java配置的方式。隨着動態語言的流行，java的開發顯得格外的繁瑣，體現在配置的複雜、開發效率低下、部署以及與第三方的集成繁雜，這個時候Spring Boot應運而生。

Spring Boot 是由 Pivotal 團隊提供的全新框架，其設計目的是用來簡化新 Spring 應用的初始搭建以及開發過程。該框架使用了特定的方式來進行配置，從而使開發人員不再需要定義樣板化的配置。簡化了基於 Spring 的應用開發，通過少量的代碼就能創建一個獨立的、產品級別的 Spring 應用。Spring Boot 為 Spring 平台及第三方庫提供開箱即用的設置，減少與第三方庫集成的複雜度。 Spring Boot 的核心思想就是約定大於配置，多數 Spring Boot 應用只需要很少的 Spring 配置。採用 Spring Boot 可以大大的簡化你的開發模式，所有你想集成的常用框架，它都有對應的組件支持。

特性

1.方便地創建獨立的Spring應用，為基於Spring的開發提供更快的入門體驗。2.內置嵌入tomcat，無需生成war文件。3.簡化maven配置。4.自動配置Spring，更快、更方便的與第三方應用整合，比如消息隊列、緩存等在企業級開發中常用的組件。5.提供大型項目中的非功能特性。如：指標、安全、健康檢查及外部配置。6.開箱即用，無需代碼生成，也無需XML配置，同時也能夠通過修改默認值來滿足待定的需求。

四大神器

自動配置

Spring Boot 的自動配置功能可基於類路徑檢測自動為運行中的應用配置依賴關係，不需要提供額外的XML配置。

Starters

Spring Boot 可提供一系列稱為 POM Starters 的精細依賴關係。Spring Boot 熟知如何配置這些依賴關係，同時讓組織能夠擴展 Spring Boot 來配置自定義的依賴關係。

Actuator

Actuator 可提供運行狀況檢查和指標等生產就緒型功能。這些功能通過 Spring Boot 應用內的 REST 終端提供。只需要簡單的配置就可以實現強大的監控和檢查。

開發工具

這些工具旨在縮短開發和測試周期，其中包括一個可在資源變更時觸發瀏覽器刷新的嵌入式 LiveReload 服務器。這些工具還提供了應用自動重啟功能，只要類路徑上的文件發生更改，該功能更即可啟動。重啟技術使用兩種類加載器。未更改的分類（例如來自第三方 JAR 的類）被加載到基礎類加載器，而開發中的分類則被加載到重啟類加載器。當應用重啟時，重啟類加載器會被丟棄，同時創建一個新的類加載器。這種方法意味着應用重啟的速度通常要比“冷啟動”的速度快得多，因為基礎類加載器已準備就緒且已填充完畢。從而快速實現應用的熱部署，對於簡單的修改這種場景能夠非常有效的提高效率。

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

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

※新北清潔公司,居家、辦公、裝潢細清專業服務

※推薦評價好的iphone維修中心

009.OpenShift管理及監控

Posted on 2020-09-092020-09-09 by admin

一資源限制

1.1 pod資源限制

pod可以包括資源請求和資源限制:

資源請求

用於調度，並控制pod不能在計算資源少於指定數量的情況下運行。調度程序試圖找到一個具有足夠計算資源的節點來滿足pod請求。

資源限制

用於防止pod耗盡節點的所有計算資源，基於pod的節點配置Linux內核cgroups特性，以執行pod的資源限制。

儘管資源請求和資源限制是pod定義的一部分，但通常建議在dc中設置。OpenShift推薦的實踐規定，不應該單獨創建pod，而應該由dc創建。

1.2 應用配額

OCP可以執行跟蹤和限制兩種資源使用的配額:

對象的數量：Kubernetes資源的數量，如pod、service和route。

計算資源：物理或虛擬硬件資源的數量，如CPU、內存和存儲容量。

通過避免master的Etcd數據庫的無限制增長，對Kubernetes資源的數量設置配額有助於OpenShift master服務器的穩定性。對Kubernetes資源設置配額還可以避免耗盡其他有限的軟件資源，比如服務的IP地址。

同樣，對計算資源的數量施加配額可以避免耗盡OpenShift集群中單個節點的計算能力。還避免了一個應用程序使用所有集群容量，從而影響共享集群的其他應用程序。

OpenShift通過使用ResourceQuota對象或簡單的quota來管理對象使用的配額及計算資源。

ResourceQuota對象指定項目的硬資源使用限制。配額的所有屬性都是可選的，這意味着任何不受配額限制的資源都可以無限制地使用。

注意：一個項目可以包含多個ResourceQuota對象，其效果是累積的，但是對於同一個項目，兩個不同的 ResourceQuota 不會試圖限制相同類型的對象或計算資源。

1.3 ResourceQuota限制資源

下錶显示 ResourceQuota 可以限制的主要對象和計算資源：

對象名	描述
pods	總計的pod數量
replicationcontrollers	總計的rc數量
services	總計的service數量
secrets	總計的secret數量
persistentvolumeclaims	總計的pvc數量
cpu	所有容器的CPU使用總量
memory	所有容器的總內存使用
storage	所有容器的磁盤總使用量

Quota屬性可以跟蹤項目中所有pod的資源請求或資源限制。默認情況下，配額屬性跟蹤資源請求。要跟蹤資源限制，可以在計算資源名稱前面加上限制，例如limit.cpu。

示例一：使用YAML語法定義的ResourceQuota資源，它為對象計數和計算資源指定了配額：

  1 $ cat
  2 apiVersion: v1
  3 kind: ResourceQuota
  4 metadata:
  5   name: dev-quota
  6 spec:
  7   hard:
  8     services: "10"
  9     cpu: "1300m"
 10     memory: "1.5Gi"
 11 $ oc create -f dev-quota.yml

示例二：使用oc create quota命令創建：

  1 $ oc create quota dev-quota \
  2 --hard=services=10 \
  3 --hard=cpu=1300m \
  4 --hard=memory=1.5Gi
  5 $ oc get resourcequota				#列出可用的配額
  6 $ oc describe resourcequota NAME		#查看與配額中定義的任何與限制相關的統計信息
  7 $ oc delete resourcequota compute-quota		#按名稱刪除活動配額

提示：若oc describe resourcequota命令不帶參數，只显示項目中所有resourcequota對象的累積限制集，而不显示哪個對象定義了哪個限制。

當在項目中首次創建配額時，項目將限制創建任何可能超出配額約束的新資源的能力，然後重新計算資源使用情況。在創建配額和使用數據統計更新之後，項目接受新內容的創建。當創建新資源時，配額使用量立即增加。當一個資源被刪除時，在下一次對項目的 quota 統計數據進行全面重新計算時，配額使用將減少。

ResourceQuota 應用於整個項目，但許多 OpenShift 過程，例如 build 和 deployment，在項目中創建 pod，可能會失敗，因為啟動它們將超過項目 quota。

如果對項目的修改超過了對象數量的 quota，則服務器將拒絕操作，並向用戶返回錯誤消息。但如果修改超出了計算資源的quota，則操作不會立即失敗。OpenShift 將重試該操作幾次，使管理員有機會增加配額或執行糾正操作，比如上線新節點，擴容節點資源。

注意：如果設置了計算資源的 quota，OpenShift 拒絕創建不指定該計算資源的資源請求或資源限制的pod。

1.3 應用限制範圍

LimitRange資源，也稱為limit，定義了計算資源請求的默認值、最小值和最大值，以及項目中定義的單個pod或單個容器的限制，pod的資源請求或限制是其容器的總和。

要理解limit rang和resource quota之間的區別，limit rang為單個pod定義了有效範圍和默認值，而resource quota僅為項目中所有pod的和定義了最高值。

通常可同時定義項目的限制和配額。

LimitRange資源還可以為image、is或pvc的存儲容量定義默認值、最小值和最大值。如果添加到項目中的資源不提供計算資源請求，那麼它將接受項目的limit ranges提供的默認值。如果新資源提供的計算資源請求或限制小於項目的limit range指定的最小值，則不創建該資源。同樣，如果新資源提供的計算資源請求或限制高於項目的limit range所指定的最大值，則不會創建該資源。

OpenShift 提供的大多數標準 S2I builder image 和 templabe 都沒有指定。要使用受配額限制的 template 和 builder，項目需要包含一個 limit range 對象，該對象為容器資源請求指定默認值。

如下為描述了一些可以由LimitRange對象指定的計算資源。

類型	資源名稱	描述
Container	cpu	每個容器允許的最小和最大CPU。
Container	memory	每個容器允許的最小和最大內存
Pod	cpu	一個pod中所有容器允許的最小和最大CPU
Pod	memory	一個pod中所有容器允許的最小和最大內存
Image	storage	可以推送到內部倉庫的圖像的最大大小
PVC	storage	一個pvc的容量的最小和最大容量

示例一：limit rang的yaml示例：

  1 $ cat dev-limits.yml
  2 apiVersion: "v1"
  3 kind: "LimitRange"
  4 metadata:
  5   name: "dev-limits"
  6 spec:
  7   limits:
  8     - type: "Pod"
  9       max:
 10         cpu: "2"
 11         memory: "1Gi"
 12       min:
 13         cpu: "200m"
 14         memory: "6Mi"
 15     - type: "Container"
 16       default:
 17         cpu: "1"
 18         memory: "512Mi"
 19 $ oc create -f dev-limits.yml
 20 $ oc describe limitranges NAME		#查看項目中強制執行的限制約束
 21 $ oc get limits				#查看項目中強制執行的限制約束
 22 $ oc delete limitranges name		#按名稱刪除活動的限制範圍

提示：OCP 3.9不支持使用oc create命令參數形式創建limit rang。

在項目中創建limit rang之後，將根據項目中的每個limit rang資源評估所有資源創建請求。如果新資源違反由任何limit rang設置的最小或最大約束，則拒絕該資源。如果新資源沒有聲明配置值，且約束支持默認值，則將默認值作為其使用值應用於新資源。

所有資源更新請求也將根據項目中的每個limit rang資源進行評估，如果更新后的資源違反了任何約束，則拒絕更新。

注意：避免將LimitRange設的過高，或ResourceQuota設的過低。違反LimitRange將阻止pod創建，並清晰保存。違反ResourceQuota將阻止pod被調度，狀態轉為pending。

1.4 多項目quota配額

ClusterResourceQuota資源是在集群級別創建的，創建方式類似持久卷，並指定應用於多個項目的資源約束。

可以通過以下兩種方式指定哪些項目受集群資源配額限制:

使用openshift.io/requester標記，定義項目所有者，該所有者的所有項目均應用quota；
使用selector，匹配該selector的項目將應用quota。

示例1：

  1 $ oc create clusterquota user-qa \
  2 --project-annotation-selector openshift.io/requester=qa \
  3 --hard pods=12 \
  4 --hard secrets=20			#為qa用戶擁有的所有項目創建集群資源配額
  5 $ oc create clusterquota env-qa \
  6 --project-label-selector environment=qa \
  7 --hard pods=10 \
  8 --hard services=5			#為所有具有environment=qa標籤的項目創建集群資源配額
  9 $ oc describe QUOTA NAME		#查看應用於當前項目的集群資源配額
 10 $ oc delete clusterquota NAME		#刪除集群資源配額

提示：不建議使用一個集群資源配額來匹配超過100個項目。這是為了避免較大的locking開銷。當創建或更新項目中的資源時，在搜索所有適用的資源配額時鎖定項目需要較大的資源消耗。

二限制資源使用

2.1 前置準備

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

2.2 本練習準備

  1 [student@workstation ~]$ lab monitor-limit setup

2.3 查看當前資源

  1 [student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com
  2 [student@workstation ~]$ oc describe node node1.lab.example.com | grep -A 4 Allocated
  3 [student@workstation ~]$ oc describe node node2.lab.example.com | grep -A 4 Allocated

2.4 創建應用

  1 [student@workstation ~]$ oc new-project resources
  2 [student@workstation ~]$ oc new-app --name=hello \
  3 --docker-image=registry.lab.example.com/openshift/hello-openshift
  4 [student@workstation ~]$ oc get pod -o wide
  5 NAME            READY     STATUS    RESTARTS   AGE       IP            NODE
  6 hello-1-znk56   1/1       Running   0          24s       10.128.0.16   node1.lab.example.com

2.5 刪除應用

  1 [student@workstation ~]$ oc delete all -l app=hello

2.6 添加資源限制

作為集群管理員，向項目quota和limit range，以便為項目中的pod提供默認資源請求。

  1 [student@workstation ~]$ cd /home/student/DO280/labs/monitor-limit/
  2 [student@workstation monitor-limit]$ cat limits.yml		#創建limit range
  3 apiVersion: "v1"
  4 kind: "LimitRange"
  5 metadata:
  6   name: "project-limits"
  7 spec:
  8   limits:
  9     - type: "Container"
 10       default:
 11         cpu: "250m
 12 [student@workstation monitor-limit]$ oc create -f limits.yml	#創建limit range
 13 [student@workstation monitor-limit]$ oc describe limitrange	#查看limit range

  1 [student@workstation monitor-limit]$ cat quota.yml		#創建配額
  2 apiVersion: v1
  3 kind: ResourceQuota
  4 metadata:
  5   name: project-quota
  6 spec:
  7   hard:
  8     cpu: "900m"
  9 [student@workstation monitor-limit]$ oc create -f quota.yml
 10 [student@workstation monitor-limit]$ oc describe quota		#確保創建了resource限制

2.7 授權項目

  1 [student@workstation monitor-limit]$ oc adm policy add-role-to-user edit developer

2.8 驗證資源限制

  1 [student@workstation ~]$ oc login -u developer -p redhat https://master.lab.example.com
  2 [student@workstation ~]$ oc project resources			#選擇項目
  3 Already on project "resources" on server "https://master.lab.example.com:443".
  4 [student@workstation ~]$ oc get limits				#查看limit
  5 NAME             AGE
  6 project-limits   14m
  7 [student@workstation ~]$ oc delete limits project-limits	#驗證限制是否有效，但developer用戶不能刪除該限制
  8 Error from server (Forbidden): limitranges "project-limits" is forbidden: User "developer" cannot delete limitranges in the namespace "resources": User "developer" cannot delete limitranges in project "resources"
  9 [student@workstation ~]$ oc get quota
 10 NAME            AGE
 11 project-quota   15m

2.9 創建應用

  1 [student@workstation ~]$ oc new-app --name=hello \
  2 --docker-image=registry.lab.example.com/openshift/hello-openshift
  3 [student@workstation ~]$ oc get pod
  4 NAME            READY     STATUS    RESTARTS   AGE
  5 hello-1-t7tfn   1/1       Running   0          35s

2.10 查看quota

  1 [student@workstation ~]$ oc describe quota
  2 Name:       project-quota
  3 Namespace:  resources
  4 Resource    Used  Hard
  5 --------    ----  ----
  6 cpu         250m  900m

2.11 查看節點可用資源

  1 [student@workstation ~]$ oc login -u admin -p redhat \
  2 https://master.lab.example.com
  3 [student@workstation ~]$ oc get pod -o wide -n resources
  4 [student@workstation ~]$ oc describe node node1.lab.example.com | grep -A 4 Allocated
  5 [student@workstation ~]$ oc describe pod hello-1-t7tfn | grep -A2 Requests

2.12 擴容應用

  1 [student@workstation ~]$ oc scale dc hello --replicas=2		#擴容應用
  2 [student@workstation ~]$ oc get pod				#查看擴容后的pod
  3 [student@workstation ~]$ oc describe quota			#查看擴容后的quota情況
  4 [student@workstation ~]$ oc scale dc hello --replicas=4		#繼續擴容至4個
  5 [student@workstation ~]$ oc get pod				#查看擴容的pod
  6 [student@workstation ~]$ oc describe dc hello | grep Replicas	#查看replaces情況

結論：由於超過了配額規定，會提示控制器無法創建第四個pod。

2.13 添加配額請求

  1 [student@workstation ~]$ oc scale dc hello --replicas=1
  2 [student@workstation ~]$ oc get pod
  3 [student@workstation ~]$ oc set resources dc hello --requests=memory=256Mi	#設置資源請求
  4 [student@workstation ~]$ oc get pod
  5 [student@workstation ~]$ oc describe pod hello-2-4jvpw | grep -A 3 Requests
  6 [student@workstation ~]$ oc describe quota					#查看quota

結論：由上可知從項目的配額角度來看，沒有什麼變化。

2.14 增大配額請求

  1 [student@workstation ~]$ oc set resources dc hello --requests=memory=8Gi	#將內存請求增大到超過node最大值
  2 [student@workstation ~]$ oc get pod						#查看pod
  3 [student@workstation ~]$ oc logs hello-3-deploy					#查看log
  4 [student@workstation ~]$ oc status

結論：由於資源請求超過node最大值，最終显示一個警告，說明由於內存不足，無法將pod調度到任何節點。

三 OCP升級

3.1 升級OPENSHIFT

當OCP的新版本發布時，可以升級現有集群，以應用最新的增強功能和bug修復。這包括從以前的次要版本(如從3.7升級到3.9)升級，以及對次要版本(3.7)應用更新。

提示：OCP 3.9包含了Kubernetes 1.8和1.9的特性和補丁的合併。由於主要版本之間的核心架構變化，OpenShift Enterprise 2環境無法升級為OpenShift容器平台3，必須需要重新安裝。

通常，主版本中不同子版本的node是向前和向後兼容的。但是，運行不匹配的版本的時間不應超過升級整個集群所需的時間。此外，不支持使用quick installer將版本3.7升級到3.9。

3.2 升級方式

有兩種方法可以執行OpenShift容器平台集群升級，一種為in-place升級(可以自動升級或手動升級)，也可以使用blue-green部署方法進行升級。

in-place升級：使用此方式，集群升級將在單個運行的集群中的所有主機上執行。首先升級master，然後升級node。在node升級開始之前，Pods被遷移到集群中的其他節點。這有助於減少用戶應用程序的停機時間。

注意：對於使用quick和高級安裝方法安裝的集群，可以使用自動in-place方式升級。

當使用高級安裝方法安裝集群時，您可以通過重用它們的庫存文件執行自動化或手動就地升級。

blue-green部署：blue-green部署是一種旨在減少停機時間同時升級環境的方法。在blue-green部署中，相同的環境與一個活動環境一起運行，而另一個環境則被更新。OpenShift升級方法標記了不可調度節點，並將pod調度到可用節點。升級成功后，節點將恢復到可調度狀態。

3.3 執行自動化集群升級

使用高級安裝方法，可以使用Ansible playbook自動化執行OpenShift集群升級過程。用於升級的劇本位於/usr/share/ansible/openshift-ansible/Playbooks/common/openshift-cluster/updates/中。該目錄包含一組用於升級集群的子目錄，例如v3_9。

注意：將集群升級到 OCP 3.9 前，集群必須已經升級到 3.7。集群升級一次不能跨越一個以上的次要版本，因此，如果集群的版本早於3.6，則必須先漸進地升級，例如從3.5升級到3.6，然後從3.6升級到3.7

要執行升級，可以使用ansible-playbook命令運行升級劇本，如使用v3_9 playbook將運行3.7版本的現有OpenShift集群升級到3.9版本。

自動升級主要執行以下任務:

應用最新的配置更改；
保存Etcd數據；
將api從3.7更新到3.8，然後從3.8更新到3.9；
如果存在，將默認路由器從3.7更新到3.9；
如果存在，則將默認倉庫從3.7更新到3.9；
更新默認is和Templates。

注意：在繼續升級之前，確保已經滿足了所有先決條件，否則可能導致升級失敗。

如果使用容器化的GlusterFS，節點將不會從pod中撤離，因為GlusterFS pod作為daemonset的一部分運行。要正確地升級運行容器化GlusterFS的集群，需要:

1：升級master服務器、Etcd和基礎設施服務(route、內部倉庫、日誌記錄和metric)。

2：升級運行應用程序容器的節點。

3：一次升級一個運行GlusterFS的節點。

注意：在升級之前，使用oc adm diagnostics命令驗證集群的健康狀況。這確認節點處於ready狀態，運行預期的啟動版本，並且沒有診斷錯誤或警告。對於離線安裝，使用–network-pod-image=’REGISTRY URL/ IMAGE參數指定要使用的image。

3.4 準備自動升級

下面的過程展示了如何為自動升級準備環境，在執行升級之前，Red Hat建議檢查配置Inventory文件，以確保對Inventory文件進行了手動更新。如果配置沒有修改，則使用默認值覆蓋更改。

如果這是從OCP 3.7升級到3.9，手動禁用3.7存儲庫，並在每個master節點和node節點上啟用3.8和3.9存儲庫：

  1 [root@demo ~]# subscription-manager repos \
  2 --disable="rhel-7-server-ose-3.7-rpms" \
  3 --enable="rhel-7-server-ose-3.9-rpms" \
  4 --enable="rhel-7-server-ose-3.8-rpms" \
  5 --enable="rhel-7-server-rpms" \
  6 --enable="rhel-7-server-extras-rpms" \
  7 --enable="rhel-7-server-ansible-2.4-rpms" \
  8 --enable="rhel-7-fast-datapath-rpms"
  9 [root@demo ~]# yum clean all

確保在每個RHEL 7系統上都有最新版本的atom-openshift-utils包，它還更新openshift-ansible-*包。

  1 [root@demo ~]# yum update atomic-openshift-utils

在OpenShift容器平台的以前版本中，安裝程序默認將master節點標記為不可調度，但是，從OCP 3.9開始，master節點必須標記為可調度的，這是在升級過程中自動完成的。

如果沒有設置默認的節點選擇器(如下配置)，它們將在升級過程中添加。則master節點也將被標記為master節點角色。所有其他節點都將標記為compute node角色。

  1 openshift_node_labels="{'region':'infra', 'node-role.kubernetes.io/compute':'true'}

如果將openshift_disable_swap=false變量添加到的Ansible目錄中，或者在node上手動配置swap，那麼在運行升級之前禁用swap內存。

3.5 升級master節點和node節點

在滿足了先決條件(如準備工作)之後，則可以按照如下步驟進行升級：

在清單文件中設置openshift_deployment_type=openshift-enterprise變量。
如果使用自定義Docker倉庫，則必須顯式地將倉庫的地址指定為openshift_web_console_prefix和template_service_broker_prefix變量。這些值由Ansible在升級過程中使用。

  1 openshift_web_console_prefix=registry.demo.example.com/openshift3/ose-
  2 template_service_broker_prefix=registry.demo.example.com/openshift3/ose-

如果希望重啟service或重啟node，請在Inventory文件中設置openshift_rolling_restart_mode=system選項。如果未設置該選項，則默認值表明升級過程在master節點上執行service重啟，但不重啟系統。
可以通過運行一個Ansible Playbook (upgrade.yml)來更新環境中的所有節點，也可以通過使用單獨的Playbook分多個階段進行升級。
重新啟動所有主機，重啟之後，如果沒有部署任何額外的功能，可以驗證升級。

3.6 分階段升級集群

如果決定分多個階段升級環境，根據Ansible Playbook (upgrade_control_plan .yml)確定的第一個階段，升級以下組件:

master節點；
運行master節點的節點services；
Docker服務位於master節點和任何獨立Etcd主機上。

第二階段由upgrade_nodes.yml playbook，升級了以下組件。在運行此第二階段之前，必須已經升級了master節點。

node節點的服務；
運行在獨立節點上的Docker服務。

兩個階段的升級過程允許通過指定自定義變量自定義升級的運行方式。例如，要升級總節點的50%，可以運行以下命令:

  1 [root@demo ~]# ansible-playbook \
  2 /usr/share/ansible/openshift-ansible/playbooks/common/openshift-cluster/upgrades/
  3 v3_9/upgrade_nodes.yml \
  4 -e openshift_upgrade_nodes_serial="50%"

若要在HA region一次升級兩個節點，請運行以下命令：

  1 [root@demo ~]# ansible-playbook \
  2 /usr/share/ansible/openshift-ansible/playbooks/common/openshift-cluster/upgrades/
  3 v3_9/upgrade_nodes.yml \
  4 -e openshift_upgrade_nodes_serial="2"
  5 -e openshift_upgrade_nodes_label="region=HA"

要指定每個更新批處理中允許有多少節點失敗，可使用openshift_upgrade_nodes_max_fail_percent選項。當故障百分比超過定義的值時，Ansible將中止升級。

使用openshift_upgrade_nodes_drain_timeout選項指定中止play前等待的時間。

示例：如下所示一次升級10個節點，以及如果20%以上的節點(兩個節點)失敗，以及終止play執行的等待時間。

  1 [root@demo ~]# ansible-playbook \
  2 /usr/share/ansible/openshift-ansible/playbooks/common/openshift-cluster/upgrades/
  3 v3_9/upgrade_nodes.yml \
  4 -e openshift_upgrade_nodes_serial=10 \
  5 -e openshift_upgrade_nodes_max_fail_percentage=20 \
  6 -e openshift_upgrade_nodes_drain_timeout=600

3.7 使用Ansible Hooks

可以通過hook為特定的操作執行定製的任務。hook允許通過定義在升級過程中特定點之前或之後執行的任務來擴展升級過程的默認行為。例如，可以在升級集群時驗證或更新自定義基礎設施組件。

提示：hook沒有任何錯誤處理機制，因此，hook中的任何錯誤都會中斷升級過程。需要修復hook並重新運行升級過程。

使用Inventory文件的[OSEv3:vars]部分來定義hook。每個hook必須指向一個.yaml文件，該文件定義了可能的任務。該文件是作為include語句的一部分集成的，該語句要求定義一組任務，而不是一個劇本。Red Hat建議使用絕對路徑來避免任何歧義。

以下hook可用於定製升級過程：

1. openshift_master_upgrade_pre_hook：hook在更新每個master節點之前運行。

2. openshift_master_upgrade_hook：hook在每個master節點升級之後、主服務或節點重新啟動之前運行。

3.openshift_master_upgrade_post_hook：hook在每個master節點升級並重啟服務或系統之後運行。

示例：在庫存文件中集成一個鈎子。

  1 [OSEv3:vars]
  2 openshift_master_upgrade_pre_hook=/usr/share/custom/pre_master.yml
  3 openshift_master_upgrade_hook=/usr/share/custom/master.yml
  4 openshift_master_upgrade_post_hook=/usr/share/custom/post_master.yml

如上示例，引入了一個pre_master.yml，包括了以下任務：

  1 ---
  2 - name: note the start of a master upgrade
  3 debug:
  4 msg: "Master upgrade of {{ inventory_hostname }} is about to start"
  5 - name: require an operator agree to start an upgrade pause:
  6 prompt: "Hit enter to start the master upgrade"

3.8 驗證升級

升級完成后，應該執行以下步驟以確保升級成功。

  1 [root@demo ~]# oc get nodes		#驗證node處於ready
  2 [root@demo ~]# oc get -n default dc/docker-registry -o json | grep \"image\"
  3 #驗證倉庫版本
  4 [root@demo ~]# oc get -n default dc/router -o json | grep \"image\
  5 #驗證image版本
  6 [root@demo ~]# oc adm diagnostics	#使用診斷工具

3.9 升級步驟匯總

確保在每個RHEL 7系統上都有atom-openshift-utils包的最新版本。
如果使用自定義Docker倉庫，可以選擇將倉庫的地址指定為openshift_web_console_prefix和template_service_broker_prefix變量。
禁用所有節點上的swap。
重新啟動所有主機，重啟之後，檢查升級。
可選地：檢查Inventory文件中的節點選擇器。
禁用3.7存儲庫，並在每個master主機和node節點主機上啟用3.8和3.9存儲庫。
通過使用合適的Ansible劇本集，使用單個或多個階段策略進行更新。
在清單文件中設置openshift_deployment_type=openshift-enterprise變量。

四使用probes監視應用

4.1 OPENSHIFT探針介紹

OpenShift應用程序可能會因為臨時連接丟失、配置錯誤或應用程序錯誤等問題而異常。開發人員可以使用探針來監視他們的應用程序。探針是一種Kubernetes操作，它定期對正在運行的容器執行診斷。可以使用oc客戶端命令或OpenShift web控制台配置探針。

目前，可以使用兩種類型的探測:

Liveness探針

Liveness探針確定在容器中運行的應用程序是否處於健康狀態。如果Liveness探針返回檢測到一個不健康的狀態，OpenShift將殺死pod並試圖重新部署它。開發人員可以通過配置template.spec.container.livenessprobe來設置Liveness探針。

Readiness探針

Readiness探針確定容器是否準備好為請求服務，如果Readiness探針返回失敗狀態，OpenShift將從所有服務的端點刪除容器的IP地址。開發人員可以使用Readiness探針向OpenShift發出信號，即使容器正在運行，它也不應該從代理接收任何流量。開發人員可以通過配置template.spec.containers.readinessprobe來設置Readiness探針。

OpenShift為探測提供了許多超時選項，有五個選項控制支持如上兩個探針:

initialDelaySeconds：強制性的。確定容器啟動后，在開始探測之前要等待多長時間。

timeoutSeconds：強制性的確定等待探測完成所需的時間。如果超過這個時間，OpenShift容器平台會認為探測失敗。

periodSeconds：可選的，指定檢查的頻率。

successThreshold：可選的，指定探測失敗后被認為成功的最小連續成功數。

failureThreshold：可選的，指定探測器成功后被認為失敗的最小連續故障。

4.2 檢查應用程序健康

Readiness和liveness probes可以通過三種方式檢查應用程序的健康狀況：

HTTP檢查：當使用HTTP檢查時，OpenShift使用一個webhook來確定容器的健康狀況。如果HTTP響應代碼在200到399之間，則認為檢查成功。

示例：演示如何使用HTTP檢查方法實現readiness probe 。

  1 ...
  2 readinessProbe:
  3   httpGet:
  4     path: /health			#檢測的URL
  5     port: 8080				#端口
  6   initialDelaySeconds: 15		#在容器啟動后多久才能檢查其健康狀況
  7   timeoutSeconds: 1			#要等多久探測器才能完成
  8 ...

4.3 容器執行檢查

當使用容器執行檢查時，kubelet agent在容器內執行命令。退出狀態為0的檢查被認為是成功的。

示例：實現容器檢查。

  1 ...
  2 livenessProbe:
  3   exec:
  4     command:
  5     - cat
  6     - /tmp/health
  7   initialDelaySeconds: 15
  8   timeoutSeconds: 1
  9 ...

4.4 TCP Socket檢查

當使用TCP Socket檢查時，kubelet agent嘗試打開容器的socket。如果檢查能夠建立連接，則認為容器是健康的。

示例：使用TCP套接字檢查方法實現活動探測。

  1 ...
  2 livenessProbe:
  3   tcpSocket:
  4     port: 8080
  5   initialDelaySeconds: 15
  6   timeoutSeconds: 1
  7 ...

4.5 使用Web管理probes

開發人員可以使用OpenShift web控制台管理readiness和liveness探針。對於每個部署，探針管理都可以從Actions下拉列表中獲得。

對於每種探針類型，開發人員可以選擇該類型，例如HTTP GET、TCP套接字或命令，併為每種類型指定參數。web控制台還提供了刪除探針的選項。

web控制台還可以用於編輯定義部署配置的YAML文件。在創建探針之後，將一個新條目添加到DC的配置文件中。使用DC編輯器來檢查或編輯探針。實時編輯器允許編輯周期秒、成功閾值和失敗閾值選項。

五使用探針監視應用程序實驗

5.1 前置準備

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

5.2 本練習準備

  1 [student@workstation ~]$ lab probes setup

5.3 創建應用

  1 [student@workstation ~]$ oc login -u developer -p redhat \
  2 https://master.lab.example.com
  3 [student@workstation ~]$ oc new-project probes
  4 [student@workstation ~]$ oc new-app --name=probes \
  5 http://services.lab.example.com/node-hello
  6 [student@workstation ~]$ oc status

  1 [student@workstation ~]$ oc get pods -w
  2 NAME             READY     STATUS      RESTARTS   AGE
  3 probes-1-build   0/1       Completed   0          1m
  4 probes-1-nqpwh   1/1       Running     0          12s

5.4 暴露服務

  1 [student@workstation ~]$ oc expose svc probes --hostname=probe.apps.lab.example.com
  2 [student@workstation ~]$ curl http://probe.apps.lab.example.com
  3 Hi! I am running on host -> probes-1-nqpwh

5.5 檢查服務

  1 [student@workstation ~]$ curl http://probe.apps.lab.example.com/health
  2 OK
  3 [student@workstation ~]$ curl http://probe.apps.lab.example.com/ready
  4 READY

5.6 創建readiness探針

使用Web控制台登錄。並創建readiness探針。

Add readiness probe

參考5.5存在的用於檢查健康的鏈接添加probe。

5.7 創建Liveness探針

使用Web控制台登錄。並創建Liveness探針。

參考5.5存在的用於檢查健康，特意使用healtz錯誤的值而不是health創建，從而測試相關報錯。這個錯誤將導致OpenShift認為pod不健康，這將觸發pod的重新部署。

提示：由於探針更新了部署配置，因此更改將觸發一個新的部署。

5.8 確認探測

通過單擊側欄上的Monitoring查看探測的實現。觀察事件面板的實時更新。此時將標記為不健康的條目，這表明liveness探針無法訪問/healtz資源。

view details查看詳情。

[student@workstation ~]$ oc get events –sort-by=’.metadata.creationTimestamp’ | grep ‘probe failed’ #查看probe失敗事件

5.9 修正probe

修正healtz為health。

5.10 再次確認

  1 [student@workstation ~]$ oc get events \
  2 --sort-by='.metadata.creationTimestamp'

#從終端重新運行oc get events命令，此時OpenShift在重新部署DC新版本，以及殺死舊pod。同時將不會有任何關於pod不健康的信息。

六 Web控制台使用

6.1 WEB控制台簡介

OpenShift web控制台是一個可以從web瀏覽器訪問的用戶界面。它是管理和監視應用程序的一種方便的方法。儘管命令行界面可以用於管理應用程序的生命周期，但是web控制台提供了額外的優勢，比如部署、pod、服務和其他資源的狀態，以及

關於系統範圍內事件的信息。

可使用Web查看基礎設施內的重要信息，包括:

pod各種狀態；
volume的可用性；
通過使用probes獲得應用程序的健康行；

登錄並選擇項目之後，web控制台將提供項目項目的概述。

項目允許在授權訪問的項目之間切換。
Search Catalog：瀏覽image目錄。
Add to project：向項目添加新的資源和應用程序。可以從文件或現有項目導入資源。
Overview：提供當前項目的高級視圖。它显示service的名稱及其在項目中運行的相關pod。
Applications：提供對部署、pod、服務和路由的訪問。它還提供了對Stateful set的訪問，Kubernetes hat特性為pod提供了一個惟一的標識，用於管理部署的順序。
build：提供對構建和IS的訪問。
Resources：提供對配額管理和各種資源(如角色和端點)的訪問。
Storage：提供對持久卷和存儲請求的訪問。
Monitoring選項卡提供對構建、部署和pod日誌的訪問。它還提供了對項目中各種對象的事件通知的訪問。
Catalog選項卡提供對可用於部署應用程序包的模板的訪問。

6.2 使用HAWKULAR管理指標

Hawkular是一組用於監控環境的開源項目。它由各種組件組成，如Hawkular services、Hawkular Application Performance Management (APM)和Hawkular metrics。Hawkular可以通過Hawkular OpenShift代理在OpenShift集群中收集應用程序指標。通過在OpenShift集群中部署Hawkular，可以訪問各種指標，比如pod使用的內存、cpu數量和網絡使用情況。

在部署了Hawkular代理之後，web控制台可以查看各種pod的圖表了。

6.3 管理Deployments和Pods

·Actions按鈕可用於pod和部署，允許管理各種設置。例如，可以向部署添加存儲或健康檢查(包括準備就緒和活動探測)。該按鈕還允許訪問YAML編輯器，以便通過web控制台實時更新配置。

6.4 管理存儲

web控制台允許訪問存儲管理，可以使用該接口創建卷聲明，以使用向項目公開的卷。注意，該接口不能用於創建持久卷，因為只有管理員才能執行此任務。管理員創建持久性卷之後，可以使用web控制台創建請求。該接口支持使用選擇器和標籤屬性。

定義卷聲明之後，控制台將显示它所使用的持久性卷，這是由管理員定義的。、

七 Web控制台監控指標

7.1 前置準備

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

同時安裝OpenShift Metrics，參考《008.OpenShift Metric應用》3.1

7.2 本練習準備

  1 [student@workstation ~]$ lab web-console setup

7.3 創建項目

  1 [student@workstation ~]$ oc login -u developer -p redhat \
  2 https://master.lab.example.com
  3 [student@workstation ~]$ oc new-project load
  4 [student@workstation ~]$ oc new-app --name=load http://services.lab.example.com/node-hello

7.4 ·暴露服務

  1 [student@workstation ~]$ oc expose svc load
  2 [student@workstation ~]$ oc get pod
  3 NAME           READY     STATUS    RESTARTS   AGE
  4 load-1-build   1/1       Running   0          48s

7.5 壓力測試

  1 [student@workstation ~]$ sudo yum install httpd-tools
  2 [student@workstation ~]$ ab -n 3000000 -c 20 \
  3 http://load-load.apps.lab.example.com/

7.6 控制台擴容pod

workstation節點上登錄控制填，並擴展應用。

查看概覽頁面，確保有一個pod在運行。單擊部署配置load #1，所显示的第一個圖，它對應於pod使用的內存。並指示pod使用了多少內存，突出显示第二張圖，該圖表示pods使用的cpu數量。突出显示第三個圖，它表示pod的網絡流量。

單擊pod視圖圈旁的向上指向的箭頭，將此應用程序的pod數量增加到兩個。

導航到應用程序→部署以訪問項目的部署

注意右側的Actions按鈕，單擊它並選擇Edit YAML來編輯部署配置。

檢查部署的YAML文件，確保replicas條目的值為2，該值與為該部署運行的pod的數量相匹配。

7.7 查看metric

單擊Metrics選項卡訪問項目的度量，可以看到應用程序的四個圖：使用的內存數量、使用的cpu數量、接收的網絡數據包數量和發送的網絡數據包數量。對於每個圖，有兩個圖，每個圖被分配到一個pod。

7.8 查看web控制監視

在側窗格中，單擊Monitoring以訪問Monitoring頁面。Pods部分下應該有兩個條目，deployment部分下應該有一個條目。

向下滾動以訪問部署，並單擊部署名稱旁邊的箭頭以打開框架。日誌下面應該有三個圖表：一個表示pod使用的內存數量，一個表示pod使用的cpu數量，一個表示pod發送和接收的網絡數據包。

7.9 創建PV

為應用程序創建PVC，此練習環境已經提供了聲明將綁定到的持久卷。

單擊Storage創建持久卷聲明，單擊Create Storage來定義聲明。輸入web-storage作為名稱。選擇Shared Access (RWX)作為訪問模式。輸入1作為大小，並將單元保留為GiB

單擊Create創建持久卷聲明。

7.10 嚮應用程序添加存儲

導航到應用程序——>部署來管理部署，單擊load條目以訪問部署。單擊部署的Actions，然後選擇Add Storage選項。此選項允許將現有的持久卷聲明添加到部署配置的模板中。選擇web-storage作為存儲聲明，輸入/web-storage作為掛載路徑，web-storage作為卷名。

7.11 檢查存儲

從deployment頁面中，單擊由(latest)指示的最新部署。等待兩個副本被標記為活動的。確保卷部分將卷web存儲作為持久卷。從底部的Pods部分中，選擇一個正在運行的Pods。單擊Terminal選項卡打開pod的外殼。

也可在任何一個pod中運行如下命令查看:

八管理和監控OpenShift

8.1 前置準備

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

8.2 本練習準備

  1 [student@workstation ~]$ lab review-monitor setup

8.3 創建項目

  1 [student@workstation ~]$ oc login -u developer -p redhat https://master.lab.example.com、
  2 [student@workstation ~]$ oc new-project load-review

8.4 創建limit range

  1 [student@workstation ~]$ oc login -u admin -p redhat
  2 [student@workstation ~]$ oc project load-review
  3 [student@workstation ~]$ cat /home/student/DO280/labs/monitor-review/limits.yml
  4 apiVersion: "v1"
  5 kind: "LimitRange"
  6 metadata:
  7   name: "review-limits"
  8 spec:
  9   limits:
 10     - type: "Container"
 11       max:
 12         memory: "300Mi"
 13       default:
 14         memory: "200Mi"
 15 [student@workstation ~]$ oc create -f /home/student/DO280/labs/monitor-review/limits.yml
 16 [student@workstation ~]$ oc describe limitrange
 17 Name:       review-limits
 18 Namespace:  load-review
 19 Type        Resource  Min  Max    Default Request  Default Limit  Max Limit/Request Ratio
 20 ----        --------  ---  ---    ---------------  -------------  -----------------------
 21 Container   memory    -    300Mi  200Mi            200Mi          -

8.5 創建應用

  1 [student@workstation ~]$ oc login -u developer -p redhat
  2 [student@workstation ~]$ oc new-app --name=load http://services.lab.example.com/node-hello
  3 [student@workstation ~]$ oc get pods
  4 NAME           READY     STATUS      RESTARTS   AGE
  5 load-1-6szhm   1/1       Running     0          6s
  6 load-1-build   0/1       Completed   0          43s
  7 [student@workstation ~]$ oc describe pod load-1-6szhm

8.6 擴大資源請求

  1 [student@workstation ~]$ oc set resources dc load --requests=memory=350M
  2 [student@workstation ~]$ oc get events | grep Warning

結論：請求資源超過limit限制，則會出現如上告警。

  1 [student@workstation ~]$ oc set resources dc load --requests=memory=200Mi

8.7 創建ResourceQuota

  1 [student@workstation ~]$ oc status ; oc get pod

  1 [student@workstation ~]$ oc login -u admin -p redhat
  2 [student@workstation ~]$ cat /home/student/DO280/labs/monitor-review/quotas.yml
  3 apiVersion: "v1"
  4 kind: "LimitRange"
  5 metadata:
  6   name: "review-limits"
  7 spec:
  8   limits:
  9     - type: "Container"
 10       max:
 11         memory: "300Mi"
 12       default:
 13         memory: "200Mi"
 14 [student@workstation ~]$ oc create -f /home/student/DO280/labs/monitor-review/quotas.yml
 15 [student@workstation ~]$ oc describe quota
 16 Name:            review-quotas
 17 Namespace:       load-review
 18 Resource         Used  Hard
 19 --------         ----  ----
 20 requests.memory  200M  600Mi   -

8.8 創建應用

  1 [student@workstation ~]$ oc login -u developer -p redhat
  2 [student@workstation ~]$ oc scale --replicas=4 dc load
  3 [student@workstation ~]$ oc get pods
  4 NAME           READY     STATUS      RESTARTS   AGE
  5 load-1-build   0/1       Completed   0          7m
  6 load-3-577fc   1/1       Running     0          5s
  7 load-3-nnncf   1/1       Running     0          4m
  8 load-3-nps4w   1/1       Running     0          5s
  9 [student@workstation ~]$  oc get events | grep Warning

結論：當前已應用配額規定會阻止創建第四個pod。

  1 [student@workstation ~]$ oc scale --replicas=1 dc load

8.9 暴露服務

  1 [student@workstation ~]$ oc expose svc load --hostname=load-review.apps.lab.example.com

8.10 創建探針

Web控制台創建。

Applications ——> Deployments ——> Actions ——> Edit Health Checks。

9.11 確認驗證

導航到Applications ——> Deployments，選擇應用程序的最新部署。

在Template部分中，找到以下條目：

  1 [student@workstation ~]$ lab review-monitor grade #腳本判斷結果
  2

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

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

※回頭車貨運收費標準

架構設計 | 高併發流量削峰，共享資源加鎖機制

Posted on 2020-09-092020-09-09 by admin

本文源碼：GitHub·點這裏 || GitEE·點這裏

一、高併發簡介

在互聯網的業務架構中，高併發是最難處理的業務之一，常見的使用場景：秒殺，搶購，訂票系統；高併發的流程中需要處理的複雜問題非常多，主要涉及下面幾個方面：

流量管理，逐級承接削峰；
網關控制，路由請求，接口熔斷；
併發控制機制，資源加鎖；
分佈式架構，隔離服務和數據庫；

高併發業務核心還是流量控制，控制流量下沉速度，或者控制承接流量的容器大小，多餘的直接溢出，這是相對複雜的流程。其次就是多線程併發下訪問共享資源，該流程需要加鎖機制，避免數據寫出現錯亂情況。

二、秒殺場景

1、預搶購業務

活動未正式開始，先進行活動預約，先把一部分流量收集和控制起來，在真正秒殺的時間點，很多數據可能都已經預處理好了，可以很大程度上削減系統的壓力。有了一定預約流量還可以提前對庫存系統做好準備，一舉兩得。

場景：活動預約，定金預約，高鐵搶票預購。

2、分批搶購

分批搶購和搶購的場景實現的機制是一致的，只是在流量上緩解了很多壓力，秒殺10W件庫存和秒殺100件庫存系統的抗壓不是一個級別。如果秒殺10W件庫存，系統至少承擔多於10W幾倍的流量衝擊，秒殺100件庫存，體系可能承擔幾百或者上千的流量就結束了。下面流量削峰會詳解這裏的策略機制。

場景：分時段多場次搶購，高鐵票分批放出。

3、實時秒殺

最有難度的場景就是準點實時的秒殺活動，假如10點整準時搶1W件商品，在這個時間點前後會湧入高併發的流量，刷新頁面，或者請求搶購的接口，這樣的場景處理起來是最複雜的。

首先系統要承接住流量的湧入；
頁面的不斷刷新要實時加載；
高併發請求的流量控制加鎖等；
服務隔離和數據庫設計的系統保護；

場景：618準點搶購，雙11準點秒殺，電商促銷秒殺。

三、流量削峰

1、Nginx代理

Nginx是一個高性能的HTTP和反向代理web服務器，經常用在集群服務中做統一代理層和負載均衡策略，也可以作為一層流量控制層，提供兩種限流方式，一是控制速率，二是控制併發連接數。

基於漏桶算法，提供限制請求處理速率能力；限制IP的訪問頻率，流量突然增大時，超出的請求將被拒絕；還可以限制併發連接數。

高併發的秒殺場景下，經過Nginx層的各種限制策略，可以控制流量在一個相對穩定的狀態。

2、CDN節點

CDN靜態文件的代理節點，秒殺場景的服務有這樣一個操作特點，活動倒計時開始之前，大量的用戶會不斷的刷新頁面，這時候靜態頁面可以交給CDN層面代理，分擔數據服務接口的壓力。

CDN層面也可以做一層限流，在頁面內置一層策略，假設有10W用戶點擊搶購，可以只放行1W的流量，其他的直接提示活動結束即可，這也是常用的手段之一。

話外之意：平時參与的搶購活動，可能你的請求根本沒有到達數據接口層面，就極速響應商品已搶完，自行意會吧。

3、網關控制

網關層面處理服務接口路由，一些校驗之外，最主要的是可以集成一些策略進入網關，比如經過上述層層的流量控制之後，請求已經接近核心的數據接口，這時在網關層面內置一些策略控制：如果活動是想激活老用戶，網關層面快速判斷用戶屬性，老用戶會放行請求；如果活動的目的是拉新，則放行更多的新用戶。

經過這些層面的控制，剩下的流量已經不多了，後續才真正開始執行搶購的數據操作。

話外之意：如果有10W人參加搶購活動，真正下沉到底層的搶購流量可能就1W，甚至更少，在分散到集群服務中處理。

4、併發熔斷

在分佈式服務的接口中，還有最精細的一層控制，對於一個接口在單位之間內控制請求處理的數量，這個基於接口的響應時間綜合考慮，響應越快，單位時間內的併發量就越高，這裏邏輯不難理解。

言外之意：流量經過層層控制，數據接口層面分擔的壓力已經不大，這時候就是面對秒殺業務中的加鎖問題了。

四、分佈式加鎖

1、悲觀鎖

機制描述

所有請求的線程必須在獲取鎖之後，才能執行數據庫操作，並且基於序列化的模式，沒有獲取鎖的線程處於等待狀態，並且設定重試機制，在單位時間后再次嘗試獲取鎖，或者直接返回。

過程圖解

Redis基礎命令

SETNX：加鎖的思路是，如果key不存在，將key設置為value如果key已存在，則 SETNX 不做任何動作。並且可以給key設置過期時間，過期后其他線程可以繼續嘗試鎖獲取機制。

藉助Redis的該命令模擬鎖的獲取動作。

代碼實現

這裏基於Redis實現的鎖獲取和釋放機制。

import org.springframework.stereotype.Component;
import redis.clients.jedis.Jedis;
import javax.annotation.Resource;
@Component
public class RedisLock {

    @Resource
    private Jedis jedis ;

    /**
     * 獲取鎖
     */
    public boolean getLock (String key,String value,long expire){
        try {
            String result = jedis.set( key, value, "nx", "ex", expire);
            return result != null;
        } catch (Exception e){
            e.printStackTrace();
        }finally {
            if (jedis != null) jedis.close();
        }
        return false ;
    }

    /**
     * 釋放鎖
     */
    public boolean unLock (String key){
        try {
            Long result = jedis.del(key);
            return result > 0 ;
        } catch (Exception e){
            e.printStackTrace();
        }finally {
            if (jedis != null) jedis.close();
        }
        return false ;
    }
}

這裏基於Jedis的API實現，這裏提供一份配置文件。

@Configuration
public class RedisConfig {

    @Bean
    public JedisPoolConfig jedisPoolConfig (){
        JedisPoolConfig jedisPoolConfig = new JedisPoolConfig() ;
        jedisPoolConfig.setMaxIdle(8);
        jedisPoolConfig.setMaxTotal(20);
        return jedisPoolConfig ;
    }

    @Bean
    public JedisPool jedisPool (@Autowired JedisPoolConfig jedisPoolConfig){
        return new JedisPool(jedisPoolConfig,"127.0.0.1",6379) ;
    }

    @Bean
    public Jedis jedis (@Autowired JedisPool jedisPool){
        return jedisPool.getResource() ;
    }
}

問題描述

在實際的系統運行期間可能出現如下情況：線程01獲取鎖之後，進程被掛起，後續該執行的沒有執行，鎖失效后，線程02又獲取鎖，在數據庫更新后，線程01恢復，此時在持有鎖之後的狀態，繼續執行后就會容易導致數據錯亂問題。

這時候就需要引入鎖版本概念的，假設線程01獲取鎖版本1，如果沒有執行，線程02獲取鎖版本2，執行之後，通過鎖版本的比較，線程01的鎖版本過低，數據更新就會失敗。

CREATE TABLE `dl_data_lock` (
	`id` INT (11) NOT NULL AUTO_INCREMENT COMMENT '主鍵ID',
	`inventory` INT (11) DEFAULT '0' COMMENT '庫存量',
	`lock_value` INT (11) NOT NULL DEFAULT '0' COMMENT '鎖版本',
	PRIMARY KEY (`id`)
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '鎖機製表';

說明：lock_value就是記錄鎖版本，作為控制數據更新的條件。

<update id="updateByLock">
    UPDATE dl_data_lock SET inventory=inventory-1,lock_value=#{lockVersion}
    WHERE id=#{id} AND lock_value &lt;#{lockVersion}
</update>

說明：這裏的更新操作，不但要求線程獲取鎖，還會判斷線程鎖的版本不能低於當前更新記錄中的最新鎖版本。

2、樂觀鎖

機制描述

樂觀鎖大多是基於數據記錄來控制，在更新數據庫的時候，基於前置的查詢條件判斷，如果查詢出來的數據沒有被修改，則更新操作成功，如果前置的查詢結果作為更新的條件不成立，則數據寫失敗。

過程圖解

代碼實現

業務流程，先查詢要更新的記錄，然後把讀取的列，作為更新條件。

@Override
public Boolean updateByInventory(Integer id) {
    DataLockEntity dataLockEntity = dataLockMapper.getById(id);
    if (dataLockEntity != null){
        return dataLockMapper.updateByInventory(id,dataLockEntity.getInventory())>0 ;
    }
    return false ;
}

例如如果要把庫存更新，就把讀取的庫存數據作為更新條件，如果讀取庫存是100，在更新的時候庫存變了，則更新條件自然不能成立。

<update id="updateByInventory">
    UPDATE dl_data_lock SET inventory=inventory-1 WHERE id=#{id} AND inventory=#{inventory}
</update>

五、分佈式服務

1、服務保護

在處理高併發的秒殺場景時，經常出現服務掛掉場景，常見某些APP的營銷頁面，出現活動火爆頁面丟失的提示情況，但是不影響整體應用的運行，這就是服務的隔離和保護機制。

基於分佈式的服務結構可以把高併發的業務服務獨立出來，不會因為秒殺服務掛掉影響整體的服務，導致服務雪崩的場景。

2、數據庫保護

數據庫保護和服務保護是相輔相成的，分佈式服務架構下，服務和數據庫是對應的，理論上秒殺服務對應的就是秒殺數據庫，不會因為秒殺庫掛掉，導致整個數據庫宕機。

六、源代碼地址

GitHub·地址
https://github.com/cicadasmile/data-manage-parent
GitEE·地址
https://gitee.com/cicadasmile/data-manage-parent

推薦閱讀：《架構設計系列》，蘿蔔青菜，各有所需

序號	標題
00	架構設計：單服務.集群.分佈式，基本區別和聯繫
01	架構設計：分佈式業務系統中，全局ID生成策略
02	架構設計：分佈式系統調度，Zookeeper集群化管理
03	架構設計：接口冪等性原則，防重複提交Token管理
04	架構設計：緩存管理模式，監控和內存回收策略
05	架構設計：異步處理流程，多種實現模式詳解

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

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

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

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

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

※超省錢租車方案

深入淺出PyTorch（算子篇）

Posted on 2020-09-092020-09-09 by admin

Tensor

自從張量（Tensor）計算這個概念出現后，神經網絡的算法就可以看作是一系列的張量計算。所謂的張量，它原本是個數學概念，表示各種向量或者數值之間的關係。PyTorch的張量（torch.Tensor）表示的是N維矩陣與一維數組的關係。

torch.Tensor的使用方法和numpy很相似（https://pytorch.org/…tensor-tutorial-py），兩者唯一的區別在於torch.Tensor可以使用GPU來計算，這就比用CPU的numpy要快很多。

張量計算的種類有很多，比如加法、乘法、矩陣相乘、矩陣轉置等，這些計算被稱為算子（Operator），它們是PyTorch的核心組件。

算子的backend一般是C/C++的拓展程序，PyTorch的backend是稱為”ATen”的C/C++庫，ATen是”A Tensor”的縮寫。

Operator

PyTorch所有的Operator都定義在Declarations.cwrap和native_functions.yaml這兩個文件中，前者定義了從Torch那繼承來的legacy operator（aten/src/TH），後者定義的是native operator，是PyTorch的operator。

相比於用C++開發的native code，legacy code是在PyTorch編譯時由gen.py根據Declarations.cwrap的內容動態生成的。因此，如果你想要trace這些code，需要先編譯PyTorch。

legacy code的開發要比native code複雜得多。如果可以的話，建議你盡量避開它們。

MatMul

本文會以矩陣相乘–torch.matmul()為例來分析PyTorch算子的工作流程。

我在深入淺出全連接層（fully connected layer）中有講在GPU層面是如何進行矩陣相乘的。Nvidia、AMD等公司提供了優化好的線性代數計算庫–cuBLAS/rocBLAS/openBLAS，PyTorch只需要調用它們的API即可。

Figure 1是torch.matmul()在ATen中的function flow。可以看到，這個flow可不短，這主要是因為不同類型的tensor（2d or Nd, batched gemm or not，with or without bias，cuda or cpu）的操作也不盡相同。

at::matmul()主要負責將Tensor轉換成cuBLAS需要的格式。前面說過，Tensor可以是N維矩陣，如果tensor A是3d矩陣，tensor B是2d矩陣，就需要先將3d轉成2d；如果它們都是>=3d的矩陣，就要考慮batched matmul的情況；如果bias=True，後續就應該交給at::addmm()來處理；總之，matmul要考慮的事情比想象中要多。

除此之外，不同的dtype、device和layout需要調用不同的操作函數，這部分工作交由c10::dispatcher來完成。

Dispatcher

dispatcher主要用於動態調用dtype、device以及layout等方法函數。用過numpy的都知道，np.array()的數據類型有：float32, float16，int8，int32，…. 如果你了解C++就會知道，這類程序最適合用模板（template）來實現。

很遺憾，由於ATen有一部分operator是用C語言寫的（從Torch繼承過來），不支持模板功能，因此，就需要dispatcher這樣的動態調度器。

類似地，PyTorch的tensor不僅可以運行在GPU上，還可以跑在CPU、mkldnn和xla等設備，Figure 1中的dispatcher4就根據tensor的device調用了mm的GPU實現。

layout是指tensor中元素的排布。一般來說，矩陣的排布都是緊湊型的，也就是strided layout。而那些有着大量0的稀疏矩陣，相應地就是sparse layout。

Figure 2是strided layout的演示實例，這裏創建了一個2行2列的矩陣a，它的數據實際存放在一維數組（a.storage）里，2行2列只是這個數組的視圖。

stride充當了從數組到視圖的橋樑，比如，要打印第2行第2列的元素時，可以通過公式：$1 * stride(0) + 1 * stride(1)$來計算該元素在數組中的索引。

除了dtype、device、layout之外，dispatcher還可以用來調用legacy operator。比如說addmm這個operator，它的GPU實現就是通過dispatcher來跳轉到legacy::cuda::_th_addmm。

END

到此，就完成了對PyTorch算子的學習。如果你要學習其他算子，可以先從aten/src/ATen/native目錄的相關函數入手，從native_functions.yaml中找到dispatch目標函數，詳情可以參考Figure 1。

更多精彩文章，歡迎掃碼關注下方的公眾號, 並訪問我的簡書博客：https://www.jianshu.com/u/c0fe8671254e

歡迎轉發至朋友圈，工作號轉載請後台留言申請授權～

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

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

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

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

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

※網頁設計最專業,超強功能平台可客製化

MyBatis入門學習-連接oracle實現CURD基本操作

Posted on 2020-09-092020-09-09 by admin

前言
導入oracle庫
配置
- 環境配置
- 配置引用
- 配置映射
查詢
- 單條件查詢
- 多條件查詢
  - 通過類字段傳遞參數
  - 通過Map接口傳參
  - Param註解
插入
更新
刪除
字段映射
參考文獻

前言

本篇記錄使用mybatis連接oracle數據庫實現基本的CURD操作。

導入oracle庫

由於oracle收費，因此maven沒有oracle庫包，需要我們自己導入，可以手工導入外部包，也可以將oracle的jar導入到maven庫種。具體導入步驟可以查看Maven添加Oracle的依賴及驅動

導入mybatis庫包，我本地使用的是3.5.5版本。最後的配置如下所示


<dependency>
  <groupId>org.mybatis</groupId>
  <artifactId>mybatis</artifactId>
  <version>3.5.5</version>
</dependency>

<dependency>
  <groupId>com.oracle.jdbc</groupId>
  <artifactId>ojdbc6</artifactId>
  <version>11.2.0.1.0</version>
</dependency>

配置

準備mybatis的配置，在resources目錄下新建一個mybatis-config.xml文件，配置如下

 <?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE configuration
        PUBLIC "-//mybatis.org//DTD Config 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-config.dtd">
<!-- 根標籤 -->
<configuration>
    <properties>
        <property name="driver" value="oracle.jdbc.driver.OracleDriver" />
        <property name="url" value="jdbc:oracle:thin:@10.60.45.239:1521:devdb" />
        <property name="username" value="fgmain10001" />
        <property name="password" value="test1" />
    </properties>

    <!-- 環境，可以配置多個，default：指定採用哪個環境 -->
    <environments default="test">
        <!-- id：唯一標識 -->
        <environment id="test">
            <!-- 事務管理器，JDBC類型的事務管理器 -->
            <transactionManager type="JDBC" />
            <!-- 數據源，池類型的數據源 -->
            <dataSource type="POOLED">
                <property name="driver" value="oracle.jdbc.driver.OracleDriver" />
                <property name="url" value="jdbc:oracle:thin:@10.60.45.239:1521:devdb" />
                <property name="username" value="fgmain10001" />
                <property name="password" value="test1" />
            </dataSource>
        </environment>
        <environment id="development">
            <!-- 事務管理器，JDBC類型的事務管理器 -->
            <transactionManager type="JDBC" />
            <!-- 數據源，池類型的數據源 -->
            <dataSource type="POOLED">
                <property name="driver" value="${driver}" /> <!-- 配置了properties，所以可以直接引用 -->
                <property name="url" value="${url}" />
                <property name="username" value="${username}" />
                <property name="password" value="${password}" />
            </dataSource>
        </environment>
    </environments>
    <mappers>
        <mapper resource="singleTransMapper.xml" />
    </mappers>
</configuration>

環境配置

 <environment id="test">
      <!-- 事務管理器，JDBC類型的事務管理器 -->
      <transactionManager type="JDBC" />
      <!-- 數據源，池類型的數據源 -->
      <dataSource type="POOLED">
          <property name="driver" value="oracle.jdbc.driver.OracleDriver" />
          <property name="url" value="jdbc:oracle:thin:@10.60.45.239:1521:devdb" />
          <property name="username" value="fgmain10001" />
          <property name="password" value="test1" />
      </dataSource>
  </environment>

其中environments可以配置多個環境的oracle數據源。

id是環境變量的編號，在<environments>的default中可以設置當前的環境值。
dataSource中設置數據源。類型有3種。包括：POOLED池化，UNPOOLED非池化和JNDI從其他配置元加載。
driver配置的類名，oracle填寫oracle.jdbc.driver.OracleDriver。
url為配置的數據源，使用239測試庫jdbc:oracle:thin:@10.60.45.239:1521:devdb。
username是用戶名。
password是密碼。

配置引用

在value中可以填寫如${變量名}的配置引用，通過在properties/propertie添加對應的實際的配置值。

<configuration>
    <properties>
        <property name="driver" value="oracle.jdbc.driver.OracleDriver" />
    </properties>
    
    <environments default="test">
        ...
        <environment id="test">
            ...
            <dataSource type="POOLED">
                <property name="driver" value="${driver}" /> <!-- 配置了properties，所以可以直接引用 -->
                ...
            </dataSource>
        </environment>
    </environments>
</configuration>

配置映射

配置好數據源后，需要添加對應的表映射，映射包括CRUD對應的SQL語句以及與類之間的映射關係。


<configuration>
  ...
    <mappers>
        <mapper resource="singleTransMapper.xml" />
    </mappers>
</configuration>

在resources目錄下新建一個singleTransMapper.xml文件，MyBatis會將singleTransMapper.xml映射到對應的類

除了resources以外MyBatis還支持class、url和package共四種配置

class可以配置具體類名,如com.mybatistest.DAO.SingleTransMapper。
url可以配置完整的文件路徑，如file:///var/mappers/PostMapper.xml。
package可以配置package名稱，註冊所有接口。

查詢


public class SingletransDTO {

    public String EnterpriseNum;

    public String TransNo;

    public String CommandCode;

    public int State;
}

單條件查詢

增加一個查詢單筆的語句，通過輸入流水號，返回查詢到的單筆信息。

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
        PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="DAO.SingleTransMapper">
    <select id="selectSingle" parameterType="String" resultType="DTO.SingletransDTO">
    select * from se_singletrans where transno = #{transno}
  </select>
</mapper>

namespace需要對應到java中的類,參數和返回類型也需要一致。

在mapper節點下添加select表示select語句
parameterType為輸入的參數
resultType為返回的類型，返回類型需要對應java中的類


public interface SingleTransMapper {
    SingletransDTO selectSingle(String transNo);
}


String resource = "mybatis-config.xml";
//加載資源
InputStream inputStream = Resources.getResourceAsStream(resource);
//創建session
SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream);
try (SqlSession session = sqlSessionFactory.openSession()) {
  //獲取單筆映射對象
    SingleTransMapper mapper = session.getMapper(SingleTransMapper.class);
    //根據流水號查詢
    SingletransDTO blog = mapper.selectSingle("642EHDCS899XKF8P");

    if(blog != null) {
        System.out.println(blog.ENTERPRISENUM);
        System.out.println(blog.TRANSNO);
        System.out.println(blog.COMMANDCODE);
    }else{
        System.out.println("not found");
    }

}catch (Exception exception)
{
    System.out.println(exception.getMessage());
}

多條件查詢

通過類字段傳遞參數

添加一個查詢配置selectSingleByParam

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
        PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="DAO.SingleTransMapper">
   
   ...
    <select id="selectSingleByClass" resultType="DTO.SingletransDTO">
    select * from se_singletrans where transno = #{TransNo} and commandCode= #{CommandCode}
  </select>
</mapper>

對應的映射類添加方法對應的方法，MyBatis可以通過反射將類的字段映射到SQL的參數，需要注意的是類的字段名和sql中配置的大小寫需要一致。


public interface SingleTransMapper {
  ...
  SingletransDTO selectSingleByClass(SingleCondition singleCondition);
}
public class SingleCondition {
    /**
     * 流水號
     */
    public String TransNo;

    /**
     * 指令類型
     */
    public String CommandCode;

    public SingleCondition(String transNo, String commandCode)
    {
        TransNo = transNo;
        CommandCode = commandCode;
    }
}

調用構造函數類的多條件查詢方案

...
SingleTransMapper mapper = session.getMapper(SingleTransMapper.class);
SingletransDTO blog = mapper.selectSingleByClass(new SingleCondition( "642EHDCS899XKF8P","10009"));

通過Map接口傳參

另一種方案可以通過傳入HashMap，MayBatis會根據key自動映射到對應的參數。
下面實現通過流水號和指令類型查詢。
添加一個查詢配置selectSingleByMultCondition

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
        PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="DAO.SingleTransMapper">
    ...
    <select id="selectSingleByMultCondition" resultType="DTO.SingletransDTO">
    select * from se_singletrans where transno = #{transNo} and commandCode= #{commandCode}
  </select>
</mapper>

添加對應的方法，傳入參數為HashMap<String,Object> param

public interface SingleTransMapper {
  ...
    SingletransDTO selectSingleByMultCondition(HashMap<String,Object> param);
}

修改調用新的多條件查詢方法

...
//獲取單筆映射對象
SingleTransMapper mapper = session.getMapper(SingleTransMapper.class);
//根據流水號查詢
HashMap<String,Object> param = new HashMap<String,Object>();
param.put("transNo","642EHDCS899XKF8P");
param.put("commandCode","10009");
SingletransDTO blog = mapper.selectSingle2(param);
...

需要注意的是，由於HashMap的key是不區分大小寫的，因此需要和配置文件sql的參數大小寫一致。

Param註解

通過類參數和Map進行多條件查詢都需要創建額外的對象，另一種比較好的方式可以通過在方法參數上添加Param註解的方式配置方法參數和SQL參數的映射關係。

添加一個查詢配置selectSingleByParam

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
        PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="DAO.SingleTransMapper">
   
   ...
    <select id="selectSingleByParam" resultType="DTO.SingletransDTO">
    select * from se_singletrans where transno = #{param1} and commandCode= #{param2}
  </select>
</mapper>

對應的映射類添加方法對應的方法，這樣MyBatis就知道參數映射規則，就會自動映射，需要注意的數參數和sql中配置的大小寫也需要一致。


public interface SingleTransMapper {
    SingletransDTO selectSingle(String transNo);
    SingletransDTO selectSingleByMultCondition(HashMap<String,Object> param);
    SingletransDTO selectSingleByParam(@Param("param1")String transNo, @Param("param2") String commandCode);
}

調用註解傳參方法

...
//獲取單筆映射對象
SingleTransMapper mapper = session.getMapper(SingleTransMapper.class);
SingletransDTO blog = mapper.selectSingleByParam("642EHDCS899XKF8P","10009");
...

插入

在mapper下添加insert表示插入的sql映射。

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
        PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="DAO.SingleTransMapper">
  
  ...
  <insert id="insert" parameterType="DTO.SingletransDTO">
    insert into se_singletrans(ENTERPRISENUM,TRANSNO,COMMANDCODE,STATE) values(#{EnterpriseNum},#{TransNo},#{CommandCode},#{State})
  </insert>
</mapper>

添加類對應的insert方法


public interface SingleTransMapper {

    ...
    int insert(SingletransDTO singletransDTO);
}

SqlSession默認會開啟事務，在insert完成后需要調用SqlSession的commit()方法提交事務。


try (SqlSession session = sqlSessionFactory.openSession()) {
    SingleTransMapper mapper = session.getMapper(SingleTransMapper.class);
    SingletransDTO singletransDTO = new     SingletransDTO();
    singletransDTO.EnterpriseNum  = "QT330001";
    singletransDTO.TransNo = "MYBATIS.INSERT";
    singletransDTO.CommandCode = "10009";
    int count = mapper.insert(singletransDTO);
    session.commit();
    System.out.println("insert result:" +count);
}catch (Exception exception)
{
    System.out.println(exception.getMessage());
}

我們也可以調用SqlSession openSession(boolean autoCommit)傳入參數，自動提交。

更新

在mapper下添加update節點表示插入，插入時可以對插入的字段設置條件，達成某條件是該字段才需要更新。

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
        PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="DAO.SingleTransMapper">
  
  ...
   <update id="update" parameterType="DTO.SingletransDTO">
    update se_singletrans
    <set>
        <if test="State != null and State!=''"></if>
        STATE=#{State}
    </set>
    where transno = #{TransNo} and commandCode= #{CommandCode}
  </update>
</mapper>

添加類對應的update方法


public interface SingleTransMapper {

    ...
    int update(SingletransDTO singletransDTO);
}

SqlSession默認會開啟事務，和insert一樣，在update完成后需要調用SqlSession的commit()方法提交事務。


try (SqlSession session = sqlSessionFactory.openSession()) {
    SingleTransMapper mapper = session.getMapper(SingleTransMapper.class);
    SingletransDTO singletransDTO = new SingletransDTO();
    singletransDTO.EnterpriseNum = "QT330001";
    singletransDTO.TransNo = "MYBATIS.INSERT";
    singletransDTO.CommandCode = "10009";
    singletransDTO.State = 2;
    int count = mapper.update(singletransDTO);
    session.commit();
    System.out.println("update result:" +count);
}catch (Exception exception)
{
    System.out.println(exception.getMessage());
}

刪除

在mapper下添加delete節點表示刪除。

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
        PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="DAO.SingleTransMapper">
  
  ...
   
  <delete id="delete">
    delete from se_singletrans where transno = #{TransNo} and commandCode= #{CommandCode}
  </delete>
</mapper>

添加類對應的delete方法，可以通過參數註解的方式指定參數。


public interface SingleTransMapper {

    ...
    int delete(@Param("TransNo")String transNo, @Param("CommandCode") String commandCode);
}

SqlSession默認會開啟事務，在delete完成后需要調用SqlSession的commit()方法提交事務。


try (SqlSession session = sqlSessionFactory.openSession()) {
    SingleTransMapper mapper = session.getMapper(SingleTransMapper.class);
    int count = mapper.delete("MYBATIS.INSERT","10009");
    session.commit();
    System.out.println("delete result:" +count);
}catch (Exception exception)
{
    System.out.println(exception.getMessage());
}

字段映射

若字段名和數據庫的字段名不一致，可以通過配置進行映射。添加resultMap節點，配置類字段和數據庫字段的映射關係，若沒有配置的字段，則根據默認MyBatis的映射關係處理，即字段名一樣的自動映射，MyBatis會嘗試進行類型轉換，若轉換異常，則可能拋錯。我們也可以通過typeHandler自定義自己的類型處理器。

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
        PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="DAO.SingleTransMapper">

  <resultMap id="singleResultMap" type="DTO.SingletransDTO">
    <result property="TransNo"  column="transNo" />
    <result property="CommandCode" column="commandCode"/>
    <result property="SpecialProperty" typeHandler="CustomTypeHandle" column="SpecialColumn"/>
  </resultMap>
  <select id="selectSingleToReusltMap" resultMap="singleResultMap">
    select * from se_singletrans where transno = #{param1} and commandCode= #{param2}
  </select>
</mapper>

關於TypeHandle這裏不做具體闡述，有興趣的可以看下MyBatis自定義類型處理器 TypeHandler

參考文獻

Maven添加Oracle的依賴及驅動
MyBatis自定義類型處理器 TypeHandler

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

【其他文章推薦】

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

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

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

※南投搬家公司費用需注意的眉眉角角，別等搬了再說!

※新北清潔公司,居家、辦公、裝潢細清專業服務

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

【asp.net core 系列】12 數據加密算法

Posted on 2020-09-092020-09-09 by admin

0. 前言

這一篇我們將介紹一下.net core 的加密和解密。在Web應用程序中，用戶的密碼會使用MD5值作為密碼數據存儲起來。而在其他的情況下，也會使用加密和解密的功能。

常見的加密算法分為對稱加密和非對稱加密。所謂的對稱加密是指加密密鑰和解密密鑰是同一個，非對稱加密是值加密密鑰和解密迷藥不同。而我們常應用在保存用戶登錄密碼這個過程中的MD5本質上並不是加密算法，而是一種信息摘要算法。不過MD5盡量保證了每個字符串最後計算出來的值都不一樣，所以在密碼保存中常用MD5做為保密值。

1. 常見對稱加密算法

對稱加密算法，簡單的說就是加密和解密使用相同的密鑰進行運算。對於大多數加密算法，解密和加密是一個互逆的運算。對稱加密算法的安全性取決於密鑰的長度，密鑰越長越安全。當然，不建議使用過長的密鑰。

那麼，我們來看看常見的對稱加密算法有哪些吧，以及C#該如何實現。

1.1 DES 和 DESede 算法

DES算法和DESede算法（又稱三重DES算法）統稱DES系列算法。DES全稱為Data Encryption Standard，即數據加密標準，是一種使用密鑰加密的塊算法。而DESede就是針對同一塊數據做三次DES加密。這裏就不對原理做過多的介紹了，來看看.net core里如何實現DES加/解密吧。

在Utils項目里，創建目錄Security：

在Security目錄下，創建DESHelper類：

namespace Utils.Security
{
    public class DesHelper
    {
        
    }
}

加密解密實現：

using System;
using System.IO;
using System.Security.Cryptography;
using System.Text;

namespace Utils.Security
{
    public static class DesHelper
    {
        static DesHelper()
        {
            DesHandler =  DES.Create("DES");
            DesHandler.Key = Convert.FromBase64String("L1yzjGB2sI4=");
            DesHandler.IV = Convert.FromBase64String("uEcGI4JSAuY=");
        }

        private static DES DesHandler { get; }

        /// <summary>
        /// 加密字符
        /// </summary>
        /// <param name="source"></param>
        /// <returns></returns>
        public static string Encrypt(string source)
        {
            try
            {
                using (var memStream = new MemoryStream())
                using (var cryptStream = new CryptoStream(memStream, DesHandler.CreateEncryptor(DesHandler.Key, DesHandler.IV),
                    CryptoStreamMode.Write))
                {
                    var bytes = Encoding.UTF8.GetBytes(source);
                    cryptStream.Write(bytes, 0, bytes.Length);
                    cryptStream.FlushFinalBlock();
                    
                    return Convert.ToBase64String(memStream.ToArray());
                }
            }
            catch (Exception e)
            {
                Console.WriteLine(e);
                return null;
            }
        }

        /// <summary>
        /// 解密
        /// </summary>
        /// <param name="source"></param>
        /// <returns></returns>
        public static string Decrypt(string source)
        {
            try
            {
                using (var mStream = new MemoryStream(Convert.FromBase64String(source)))
                using (var cryptoStream =
                    new CryptoStream(mStream, DesHandler.CreateDecryptor(DesHandler.Key, DesHandler.IV), CryptoStreamMode.Read))
                using (var reader = new StreamReader(cryptoStream))
                {
                    return reader.ReadToEnd();
                }
            }
            catch (Exception e)
            {
                Console.WriteLine(e);
                return null;
            }
        }
    }
}

每次調用DesHandler = DES.Create("DES"); 都會重新獲得一個DES算法實現實例，這樣每次獲取的實例中Key、IV這兩個屬性的值也會發生變化。如果直接使用會出現這次加密的數據下次就沒法解密了，為了減少這種情況，所以代碼處手動賦值了Key、IV這兩個屬性。

1.2 AES 加密算法

AES算法（Advanced Encryption Standard）也就是高級數據加密標準算法，是為了解決DES算法中的存在的漏洞而提出的算法標準。現行的AES算法核心是Rijndael算法。當然了，這個不用太過於關心。我們直接看看是如何實現吧：

同樣，在Security目錄創建一個AesHelper類：

namespace Utils.Security
{
    public static class AesHelper
    {
        
    }
}

具體的加解密實現：

using System;
using System.IO;
using System.Security.Cryptography;

namespace Utils.Security
{
    public static class AesHelper
    {
        static AesHelper()
        {
            AesHandler = Aes.Create();
            AesHandler.Key = Convert.FromBase64String("lB2BxrJdI4UUjK3KEZyQ0obuSgavB1SYJuAFq9oVw0Y=");
            AesHandler.IV = Convert.FromBase64String("6lra6ceX26Fazwj1R4PCOg==");
        }

        private static Aes AesHandler { get; }

        public static string Encrypt(string source)
        {
            using (var mem = new MemoryStream())
            using (var stream = new CryptoStream(mem, AesHandler.CreateEncryptor(AesHandler.Key, AesHandler.IV),
                CryptoStreamMode.Write))
            {
                using (var writer = new StreamWriter(stream))
                {
                    writer.Write(source);
                }   
                return Convert.ToBase64String(mem.ToArray());
            }
            
        }

        public static string Decrypt(string source)
        {
            var data = Convert.FromBase64String(source);
            using (var mem = new MemoryStream(data))
            using (var crypto = new CryptoStream(mem, AesHandler.CreateDecryptor(AesHandler.Key, AesHandler.IV),
                CryptoStreamMode.Read))
            using (var reader = new StreamReader(crypto))
            {
                return reader.ReadToEnd();
            }
        }
    }
}

2. 常見非對稱加密算法

非對稱加密算法，指的是加密密鑰和解密密鑰並不相同。非對稱加密算法的秘鑰通常成對出現，分為公開密鑰和私有密鑰。公開密鑰可以以公開的形式發給數據交互方，而不會產生泄密的風險。因為非對稱加密算法，無法通過公開密鑰推算私有密鑰，反之亦然。

通常，非對稱加密算法是用公鑰進行加密，使用私鑰進行解密。

2.1 RSA算法

RSA算法是標準的非對稱加密算法，名字來源是三位發明者的姓氏首字母。RSA公開密鑰密碼體制是一種使用不同的加密密鑰與解密密鑰，“由已知加密密鑰推導出解密密鑰在計算上是不可行的”密碼體制。其安全性取決於密鑰的長度，1024位的密鑰幾乎不可能被破解。

同樣，在Utils.Security下創建RSAHelper類：

namespace Utils.Security
{
    public static class RsaHelper
    {
        
    }
}

具體實現：

using System;
using System.Security.Cryptography;

namespace Utils.Security
{
    public static class RsaHelper
    {
        public static RSAParameters PublicKey { get; private set; }
        public static RSAParameters PrivateKey { get; private set; }

        static RsaHelper()
        {
            
        }

        public static void InitWindows()
        {
            var parameters = new CspParameters()
            {
                KeyContainerName = "RSAHELPER" // 默認的RSA保存密鑰的容器名稱
            };
            var handle = new RSACryptoServiceProvider(parameters);
            PublicKey = handle.ExportParameters(false);
            PrivateKey = handle.ExportParameters(true);
        }

        public static void ExportKeyPair(string publicKeyXmlString, string privateKeyXmlString)
        {
            var handle  = new RSACryptoServiceProvider();
            handle.FromXmlString(privateKeyXmlString);
            PrivateKey = handle.ExportParameters(true);
            handle.FromXmlString(publicKeyXmlString);
            PublicKey = handle.ExportParameters(false);
        }
        public static byte[] Encrypt(byte[] dataToEncrypt)
        {
            try
            {
                byte[] encryptedData;
                using (RSACryptoServiceProvider RSA = new RSACryptoServiceProvider())
                {
                    RSA.ImportParameters(PublicKey);
                    encryptedData = RSA.Encrypt(dataToEncrypt, true);
                }

                return encryptedData;
            }
            catch (CryptographicException e)
            {
                Console.WriteLine(e.Message);
                return null;
            }
        }

        public static byte[] Decrypt(byte[] dataToDecrypt)
        {
            try
            {
                byte[] decryptedData;
                using (var rsa = new RSACryptoServiceProvider())
                {
                    rsa.ImportParameters(PrivateKey);
                    decryptedData = rsa.Decrypt(dataToDecrypt, true);
                }
                return decryptedData;
            }
            catch (CryptographicException e)
            {
                Console.WriteLine(e.ToString());
                return null;
            }
        }
    }
}

因為RSA的特殊性，需要預先設置好公鑰和私鑰。C# 支持多種方式導入密鑰，這裏就不做過多介紹了。

3. 信息摘要算法

這種算法嚴格意義上並不是加密算法，因為它完全不可逆。也就是說，一旦進行使用該類型算法加密后，無法解密還原出數據。當然了，也正是因為這種特性常常被用來做密碼的保存。因為這樣可以避免某些人拿到數據庫與代碼后，可以簡單反推出用戶的密碼。

3.1 MD5算法

最常用的信息摘要算法就是MD5 加密算法，MD5信息摘要算法（英語：MD5 Message-Digest Algorithm），一種被廣泛使用的密碼散列函數，可以產生出一個128位（16字節）的散列值（hash value），用於確保信息傳輸完整一致。

原理不解釋，我們看下如何實現，照例現在Security下創建MD5Helper：

namespace Utils.Security
{
    public static class Md5Helper
    {
        
    }
}

具體實現：

using System.Security.Cryptography;
using System.Text;

namespace Utils.Security
{
    public static class Md5Helper
    {
        private static MD5 Hanlder { get; } = new MD5CryptoServiceProvider();

        public static string GetMd5Str(string source)
        {
            var data = Encoding.UTF8.GetBytes(source);
            var security = Hanlder.ComputeHash(data);
            var sb = new StringBuilder();
            foreach (var b in security)
            {
                sb.Append(b.ToString("X2"));
            }

            return sb.ToString();
        }
    }
}

4 總結

這一篇簡單介紹了四種常用的加密算法的實現，當然最常用的就是 MD5，因為這個是大多數系統用來做密碼保存的加密算法。

更多內容煩請關注我的博客《高先生小屋》

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

【其他文章推薦】

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

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※幫你省時又省力,新北清潔一流服務好口碑

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

※產品缺大量曝光嗎?你需要的是一流包裝設計!

圖解leetcode5-10 | 和233醬一起刷leetcode系列(2)

Posted on 2020-09-092020-09-09 by admin

本周我們繼續來看5道磨人的小妖精，圖解leetcode6-10～

多說一句，leetcode10 殺死了233醬不少腦細胞…

另：

沉迷算法，無法自拔。快來加入我們吧！

別忘了233醬的一條龍服務：

公眾號文章題解 -> 私信答疑 -> 刷題群答疑 -> 視頻講解

我們的目的是成為套路王～

嘿嘿，廣告完畢 , Let’s go!

leetcode6: Z 字形變換

題目描述：

將一個給定字符串根據給定的行數，以從上往下、從左到右進行 Z 字形排列。

題目示例:

輸入: s = "LEETCODEISHIRING", numRows = 4
輸出: "LDREOEIIECIHNTSG"

解釋:

L     D     R
E   O E   I I
E C   I H   N
T     S     G

解題思路:

相信小夥伴看到這道題目，也和233一樣覺得Z字形排列的字符串冥冥中有些規律。為了方便解釋，我們假設輸入：

字符串s=”0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15″
numRows=4
注意： s中的輸入字符依次為：為0-15，中間的空格是我為了展示清楚額外加的。

那麼s的Z字形排列如下：

需要輸出的結果是：“0 6 12 15 7 11 13 2 4 8 10 14 3 9 15”

假設我們將Z字形排列后的字符串每一行i 用一個數組arr[i]存起來，最後按行數i的順序輸出arr[i]中的值，那麼就可以得到最終的輸出結果。

如何知道字符串s中的各個字符在哪個arr數組的哪個索引位置呢？這就是我們用数字字符的字符串來舉例子的好處了，因為数字的值就對應着字符在字符串s中的下標。當我們遍歷字符串s時，是我們可以用pointer表示當前遍歷的字符所對應的行數i，代表這個字符是要放到arr[i]中的。

我們可以發現每當遍歷numRows=4 個字符，pointer就從 0->3 轉化為 3->0。所以我們可以用一個flag記錄pointer的變化量。

思路有了，我們來看一下時間空間複雜度：

時間複雜度：遍歷一遍字符串s: O(n)。
空間複雜度：數組arr的存儲：O(n)。

可以寫出代碼嗎：）

Java版本

class Solution {
    public String convert(String s, int numRows) {
        if(numRows <= 1){
            return s;
        }
        List<StringBuilder> arr = new ArrayList<>();
        for(int i = 0 ;i< numRows;i++){
            arr.add(new StringBuilder());
        }
        int flag = -1;
        int pointer = 0;
        for(int i =0;i<s.length();i++){
           char ch = s.charAt(i);
           arr.get(pointer).append(ch);
           if(pointer == 0 || pointer == numRows -1) flag = - flag;
            pointer += flag;
            
        }
        StringBuilder res = new StringBuilder();
        for(StringBuilder row : arr) res.append(row);
        return res.toString();
    }
}

leetcode7: 整數反轉

題目描述：

給出一個 32 位的有符號整數，你需要將這個整數中每位上的数字進行反轉。

題目示例:

輸入: 123
輸出: 321

輸入: -123
輸出: -321

輸入: 120
輸出: 21

注意:
假設我們的環境只能存儲得下 32 位的有符號整數，則其數值範圍為 [−231, 231 − 1]。請根據這個假設，如果反轉后整數溢出那麼就返回 0。

解題思路:
這道題考的還是 數學運算。

Step1:需要分別取出十進制数字的個位，十位，百位..一直到最高位的数字。

阿姨來教你小學數學的除法運算：

所以當我們取余再取模就可以得到高位的数字。

Step2:將取出來的個位，十位，百位..一直到最高位的数字依次放到最高位,…,百位，十位，個位。

阿姨來教你小學數學的乘法運算：

至於示例中列舉的幾個邊界條件，Java中的整數是帶有符號的。剛好符合我們的乘除運算。

另外，需要判斷乘法計算時正負数字的越界問題。當然如果res用long表示，也就不需要考慮這個問題了。代碼如下：

Java版本

class Solution {
    public int reverse(int x) {
        int res = 0;
        while(x!=0){
            if(x>0 && res > ((Integer.MAX_VALUE-x%10)/10)) return 0;
            if(x<0 && res < ((Integer.MIN_VALUE-x%10)/10)) return 0;
            res = res*10 + x%10;
            x/=10;
        }
        return res;
    }
}

leetcode8: 字符串轉換整數(atoi)

題目描述：

請你來實現一個 atoi 函數，使其能將字符串轉換成整數。

首先，該函數會根據需要丟棄無用的開頭空格字符，直到尋找到第一個非空格的字符為止。接下來的轉化規則如下：

如果第一個非空字符為正或者負號時，則將該符號與之後面盡可能多的連續数字字符組合起來，形成一個有符號整數。
假如第一個非空字符是数字，則直接將其與之後連續的数字字符組合起來，形成一個整數。
該字符串在有效的整數部分之後也可能會存在多餘的字符，那麼這些字符可以被忽略，它們對函數不應該造成影響。
注意：假如該字符串中的第一個非空格字符不是一個有效整数字符、字符串為空或字符串僅包含空白字符時，則你的函數不需要進行轉換，即無法進行有效轉換。

在任何情況下，若函數不能進行有效的轉換時，請返回 0 。

提示：

本題中的空白字符只包括空格字符 ‘ ‘ 。
假設我們的環境只能存儲 32 位大小的有符號整數，那麼其數值範圍為 [−231, 231 − 1]。如果數值超過這個範圍，請返回 INT_MAX (231 − 1) 或 INT_MIN (−231) 。

題目示例:

示例 1:
輸入: "42"
輸出: 42

示例 2:
輸入: "   -42"
輸出: -42
解釋: 第一個非空白字符為 '-', 它是一個負號。
     我們盡可能將負號與後面所有連續出現的数字組合起來，最後得到 -42 。

示例 3:
輸入: "4193 with words"
輸出: 4193
解釋: 轉換截止於数字 '3' ，因為它的下一個字符不為数字。

示例 4:
輸入: "words and 987"
輸出: 0
解釋: 第一個非空字符是 'w', 但它不是数字或正、負號。
     因此無法執行有效的轉換。

示例 5:
輸入: "-91283472332"
輸出: -2147483648
解釋: 数字 "-91283472332" 超過 32 位有符號整數範圍。 
     因此返回 INT_MIN (−231) 。

解題思路:
放這麼多題目示例阿姨並不是為了湊字數，而是這類問題就是屬於考邊界情況的問題，邊界情況拎清了，就不會被磨到了～

假設輸入一個字符串 ” -4193 with words” ，我們可以從左到右遍歷這個字符串，用k 表示當前遍歷到的字符：

另外，我們還需要注意示例5的情況，當乘法計算時的值超過INT_MAX or INT_MIN時，結束並返回 INT_MAX or INT_MIN.

Java版本

class Solution {
    public int myAtoi(String str) {
        int res = 0;
        int k = 0;

        while(k< str.length() &&  ' ' == str.charAt(k))k++;
        int minus = 1;
        if(str.length() == k) return res;
        if('-' == str.charAt(k)) {
            minus = -1;
            k++;
        }else if('+' == str.charAt(k)){
            k++;
        }

        while(k<str.length() && str.charAt(k) >= '0' && str.charAt(k) <='9'){
            int x = str.charAt(k) - '0';
            if(minus >0 && res> (Integer.MAX_VALUE - x)/ 10){
                return Integer.MAX_VALUE;
            }
            //-res * 10 - str.charAt(k) < Integer.MIN_VALUE
            if(minus <0 && -res < (Integer.MIN_VALUE + x)/10) 
                return Integer.MIN_VALUE;
            //最大的負數是存不下來的
            if((-res * 10 - x) == Integer.MIN_VALUE ) {
                return Integer.MIN_VALUE;
            }
            res = res* 10 + x;
            k++;
        }
        res *= minus;
        return res;

    }
}

leetcode9: 迴文數

題目描述：

判斷一個整數是否是迴文數。迴文數是指正序（從左向右）和倒序（從右向左）讀都是一樣的整數。

題目示例:

示例 1:

輸入: 121
輸出: true
示例 2:

輸入: -121
輸出: false
解釋: 從左向右讀, 為 -121 。 從右向左讀, 為 121- 。因此它不是一個迴文數。
示例 3:

輸入: 10
輸出: false
解釋: 從右向左讀, 為 01 。因此它不是一個迴文數。

解題思路:

上篇文章中我們講過最長迴文子串的查找。再來看這道題就很easy了。這道題的解法也很多：
比如我們可以把它變為字符串。然後reverse一下，判斷前後兩個字符串是否相等。

但是我們用一種更簡單的方式，只需要反轉整數，然後判斷兩個整數是否相等，就可以確定是不是迴文整數。又回到leetcode7了，有沒有覺得阿姨的乘除法運算還是有幫助的：）

Java版本

class Solution {
    public boolean isPalindrome(int x) {
        
        if(x<0) return false;
        if(x<=9) return true;
        int oringin = x;
        int res = 0;
        while(x>0){
            //如果越界了說明不對稱
            res = res*10 + x%10;
            x/=10;
        }
        return oringin == res;
    }
}

leetcode10: 正則表達式匹配

題目描述：

給你一個字符串 s 和一個字符規律 p，請你來實現一個支持 ‘.’ 和 ‘*’ 的正則表達式匹配。

‘.’ 匹配任意單個字符
‘*’ 匹配零個或多個前面的那一個元素
所謂匹配，是要涵蓋整個字符串 s的，而不是部分字符串。

說明:

s 可能為空，且只包含從 a-z 的小寫字母。
p 可能為空，且只包含從 a-z 的小寫字母，以及字符 . 和 *。

題目示例:

示例 1:
輸入:
s = "aa"
p = "a*"
輸出: true
解釋: 因為 '*' 代表可以匹配零個或多個前面的那一個元素, 在這裏前面的元素就是 'a'。因此，字符串 "aa" 可被視為 'a' 重複了一次。

示例 2:
輸入:
s = "ab"
p = ".*"
輸出: true
解釋: ".*" 表示可匹配零個或多個（'*'）任意字符（'.'）。

神奇的.*來了，Hard模式，大家坐好～

判斷字符串s 是否與一個可能還有“.” or “*” 的字符規律 p 匹配，其實就是從 p 代表的所有的字符串中枚舉出一個匹配值。簡單暴力枚舉的時間複雜度是指數級的。我們需要考慮對於求解一個最優解或匹配解的類似問題，有哪些可以降低時間複雜度的方案？

好了，不饒彎子了，動態規劃 要來了。

溫馨後記：寫着寫着就列舉了一堆動態規劃的理論，比較了解的朋友可以直接翻過這段看後面這一題的圖解。

解題之前，我們先了解下：動態規劃是什麼？為什麼動態規劃能降低時間複雜度？什麼類型的問題又能用動態規劃去解決？如何構造解題步驟？

動態規劃是什麼

動態規劃與分治方法相似，都是通過組合子問題的解來求解原問題。

分治算法將問題劃分為互不相交的子問題，遞歸地求解子問題，再將他們的解組合起來，求出原問題的解。如歸併排序，劃分的左右排序子問題是對不同的数字序列進行排序的，最後再把他們合併起來。

而動態規劃應用於子問題重疊的情況，即不同的子問題具有公共的子子問題。這種情況下分治算法需要對子子問題反覆求解，而動態規劃算法只對子子問題求解一次，將其結果保存到備忘錄中 or 按照自底向下的順序求解每個子問題（也就是保證在求解子問題時，它所依賴的子子問題的解已經求出來了）這兩種方式，避免不必要的計算工作，降低時間複雜度。

舉一個簡單的斐波那契數列的例子：

斐波那契數列指的是這樣一個數列：
1、1、2、3、5、8…

相信小夥伴們都知道，它的遞推規律是：

假設求f(10),則遞推公式展開為：

可以看到其中有大量的重複子問題：f(6),f(5) 等。

動態規劃的兩種做法就是：
1.用 遞歸的代碼求解時，將第一次計算的f(6)保存起來，如f(8)中的f(6). 這樣再求解f(7)中的f(6)就可以直接獲取到結果了
2.按照求f(3), ->(4)->…->f(10)的自底向下的順序求解，這樣再求 f(8)時，只需要保存下來 f(7) 和 f(6)的值，就可以求出了，f(10)同理。這種方式大多是循環的寫法。

動態規劃解決的問題類型

初步明白后，我們再來看下動態規劃解決問題的類型：

極客時間的王爭大佬概括為： 一個模型，三個特徵。

一個模型：多階段決策最優解模型
我們一般是用動態規劃來解決最優問題。而解決問題的過程，需要經歷多個決策階段。每個決策階段都對應着一組狀態。然後我們尋找一組決策序列，經過這組決策序列，能夠產生最終期望求解的最優值。
特徵1:最優子結構

指的是，問題的最優解包含子問題的最優解。反過來說就是，我們可以通過子問題的最優解，推導出問題的最優解。如果我們把最優子結構，對應到我們前面定義的動態規劃問題模型上，那我們也可以理解為，後面階段的狀態可以通過前面階段的狀態推導出來。

特徵2:無後效性

無後效性有兩層含義，第一層含義是，在推導後面階段的狀態的時候，我們只關心前面階段的狀態值，不關心這個狀態是怎麼一步一步推導出來的。第二層含義是，某階段狀態一旦確定，就不受之後階段的決策影響。無後效性是一個非常“寬鬆”的要求。只要滿足前面提到的動態規劃問題模型，其實基本上都會滿足無後效性。

特徵3. 重複子問題
這個就是我們前面提到的，不同的決策序列，到達某個相同的階段時，可能會產生重複的狀態。

動態規劃的解題步驟

Step1.刻畫一個最優解的結構特徵
也就是能夠把問題抽象轉化為一種數學描述，通俗說就是狀態的定義。如上述斐波那契數列中 f(n）就是狀態的定義。

Step2.遞歸地定義最優解的值。
就是問題與子問題之間的遞推表達式是什麼，通俗說就是狀態轉移方程的定義。如上述斐波那契數列中的f(n) = f(n-1) + f(n-2)

Step3.計算最優解的值
就是採用的動態規劃具體計算的做法，包括遞歸+備忘錄 or 循環+自底向下求解兩種方式。

Step4.利用計算出的信息構造一個最優解
因為我們步驟一定義的狀態有時並不是我們直接要求的最優解，所以這一步就是利用狀態和狀態轉移方式表達出我們最終要求的最優解怎麼得到。

我們會根據leetcode10來理解這些理論知識。

解題思路:

Step1.抽象出狀態

這個問題實際求的是字符串s能否從字符規律p代表的所有字符串集合中找出一個匹配值。一般求兩個字符串的匹配問題的狀態用二維的數組來定義，為什麼。。聽大佬說：靠經驗，靠悟。我們定義：
dp[i,j] : 代表所有字符串s[0,i-1] (前i個字符) 和字符規律p[0,j-1] （前j個字符）的匹配方案集合。
dp[i,j] 的值： 代表是否存在一種方案使得字符規律p 匹配字符串s。這個值就是我們這個問題的解。true：存在。false：不存在。

Step2.遞歸地定義最優解的值。

這一步其實就是求狀態遞推式，找出問題dp[i,j] 和子問題之間的關係。

對於字符串s[i] 和 p[j] 是否匹配，因為p[j] 可能是* or . 。我們需要枚舉出p所代表的所有字符串。我們我們可以從最後的字符 s[i] 和 p[j]來考慮。

可分為p[j] == * or p[j] != * 兩種情況。因為 ‘*’ 代表着0-多個字符，會影響p的枚舉數。’.’ 我們只需要把它當成一個萬能字符就好，’.’ 不會影響p的枚舉數量。

當p[j] != '*' 時，則 s 與 p 是否匹配取決於 s[i] 是否等於 p[j] && dp[i][j] 是否為true
當p[j] == '*' 時，我們需要枚舉* 代表的從0-多個字符的字符序列集合中，s 是否與他們其中之一匹配。

如圖所示，考慮p[j] == '*' 所代表的字符數，我們需要列舉出組成dp[i+1,j+1] 的所有可能情況，同時我們其實靠yy也能推斷出：
dp[i+1,j+1] 和它的子問題：dp[i,j+1] 的關係，圖中我也有列舉出公式推導來源。

這裡有一點需要注意： dp[i+1,j+1]才表示s[0,i] 和 p[0,j] 匹配。因為s[0]就代表了第一個字符。而我們也需要表示 s長度為0的dp[0,..]的值。不然會影響到我們遞推公式的求值。

好了，到這裏我們先總結下這個問題動態規劃解法的狀態和狀態轉移方程：

Step3.計算最優解的值。
這個步驟就是具體計算遞推公式dp[i+1,j+1]的過程了，我們可以採用循環+ 自底向下的方式來求解，也就是對於二維數組先填第0行的值，再填第0列的值，以此類推。
假設s=”aa”, p=”a*” 。則它的二維填狀態表的順序和結果為：

Step4.利用計算出的信息構造一個最優解

在Step1的時候，我們其實就定義了。 s與p是否匹配等價於 dp[i+1][j+1] 的值是否為 true。所以我們只需要返回 dp[i+1][j+1]的值就是這道題的結果。

徹底完了，看懂了沒，上代碼吧。

Java版本

class Solution {
    public boolean isMatch(String s, String p) {
        int slen = s.length();
        int plen = p.length();
        //需要分別取出s和p為空的情況，所以dp數組大小+1
        boolean[][] dp = new boolean[slen + 1][plen + 1];
        //初始化dp[0][0]=true,dp[0][1]和dp[1][0]~dp[s.length][0]默認值為false所以不需要顯式初始化
        dp[0][0] = true;
        //填寫第一行dp[0][2]~dp[0][p.length]
        for (int k = 2; k <= plen; k++) {
            //p字符串的第2個字符是否等於'*',此時j元素需要0個，所以s不變p減除兩個字符
            dp[0][k] = p.charAt(k - 1) == '*' && dp[0][k - 2];
        }
        //填寫dp數組剩餘部分
        for (int i = 0; i < slen; i++) {
            for (int j = 0; j < plen; j++) {
                //p第j個字符是否為*
                if (p.charAt(j) == '*') {
                    //兩種情況:1.s不變[i+1],p移除兩個元素[j+1-2]。
                    // 2.比較s的i元素和p的j-1(因為此時j元素為*)元素,相等則移除首元素[i+1-1],p不變。
                    dp[i + 1][j + 1] = dp[i + 1][j - 1] ||
                            (dp[i][j + 1] && headMatched(s, p, i, j - 1));
                } else {
                    //s的i元素和p的j元素是否相等,相等則移除s的i元素[i+1-1]和p的j元素[j+1-1]
                    dp[i + 1][j + 1] = dp[i][j] && headMatched(s, p, i, j);
                }
            }
        }
        return dp[slen][plen];
    }

    //判斷s第i個字符和p第j個字符是否匹配
    public boolean headMatched(String s, String p, int i, int j) {
        return s.charAt(i) == p.charAt(j) || p.charAt(j) == '.';
    }

}

能看到這裏看來是真愛了，233醬都要對你豎起大拇指，要不要也在看，轉發 對233醬豎起大拇指 …… ^ _ ^。不管對文章是否有疑問，都歡迎可愛的你加入我們的刷題群，有疑問233醬會在群里答疑哦～

參考資料：
[1].《算法導論》
[2].https://time.geekbang.org/column/article/75702

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

【其他文章推薦】

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

※新北清潔公司,居家、辦公、裝潢細清專業服務

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

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

※超省錢租車方案

※FB行銷專家,教你從零開始的技巧

也來聊聊 HTTPS.

Posted on 2020-09-092020-09-09 by admin

前言： 網上聊 HTTPS 的文章已經數都數不過來了吧，厚着臉皮，整理下讀書筆記，結合平常項目的實踐，也來聊聊 HTTPS。

一、為什麼需要 HTTPS？

眾所周知，HTTP 協議具有無連接、不可靠、盡最大努力的特點，這也為 HTPP 協議帶來信息竊聽或身份偽裝等安全問題。主要體現在幾個方面：

通信使用明文（不加密），內容可能會被竊聽。
不驗證通信方的身份，因此有可能遭遇偽裝。
無法證明報文的完整性，所以有可能已遭篡改。

那要如何做到防止竊聽保護信息呢？最為普及的就是加密技術。

通信的加密：用 SSL（Secure Socket Layer，安全套接層）或 TLS（Transport Layer Security，安全層傳輸協議）建立安全通信線路之後，就可以在這條線路上進行 HTTP 通信了。與 SSL/TLS 組合使用的 HTTP 就是 HTTPS，通常 HTTP 直接和 TCP 通信，當使用 SSL 時，則演變成先與 SSL 通信，再由 SSL 和 TCP 通信了，所以 HTTPS 並不是一種新的協議。
內容的加密: 對 HTTP 協議傳輸的內容本身加密，即把 HTTP 報文里所含的內容進行加密處理。

SSL 協議最初是由瀏覽器開發商網景通信公司率先倡導的，開發過 SSL3.0 之前的版本。IETF 以 SSL3.0 為基準，后又制定了 TLS1.0、TLS1.1 和 TLS1.2。TSL 是以 SSL為原型開發的協議，有時會統一稱該協議為 SSL。當前主流的版本是 SSL3.0 和 TLS1.0。

SSL 不僅提供加密處理，而且還使用了一種被稱為證書的手段，可用於確定通信方。

二、HTTPS 怎麼來保障通信安全的？

HTTPS 具有加密、認證以及完整性保護的功能。

1. 加密

客戶端和服務端想要進行安全的通信，首先想到的就是對通信雙方的內容進行加密處理。客戶端利用“密鑰”加密內容，服務端利用“密鑰”解密內容，反之亦然。這種方式稱為對稱（共享密鑰）加密。

對稱加密客戶端和服務端的“密鑰”是一致的，因此，客戶端和服務端之間的“密鑰”傳輸不可避免，如果“密鑰”在傳輸途中被盜用，那麼加密處理就沒有意義了。

那麼如何保護“密鑰”的傳輸安全呢？實踐的思路是非對稱（公開密鑰）加密，服務端擁有公鑰（public key）+ 私鑰（private key）的密鑰對，公鑰任何人都可以獲取，私鑰只保存在服務端。以下是 SSL 建立安全通信線路的過程。

服務端將公鑰傳輸給客戶端。
客戶端通過公鑰加密“密鑰”（客戶端生成）得到一個加密串並傳輸給服務端。
服務端根據私鑰解密加密串得到“密鑰”。
雙方通過“密鑰”加密傳輸。

非對稱加密“密鑰”的方式很好的保障了“密鑰”的安全傳輸，因為即使傳輸過程中加密串被盜用了，由於盜用者沒有私鑰信息，也無法得到加密串中的“密鑰”信息。

HTTPS 採用對稱（共享密鑰）加密和非對稱（公開密鑰）加密兩者並用的混合加密機制。之所以要這麼複雜，是因為非對稱加密的處理速度相較於對稱加密要慢，因此，我們一般在交換“密鑰”環節使用非對稱加密，之後的建立通信交換報文階段則使用對稱加密方式。

2. 認證

遺憾的是，非對稱加密傳輸“密鑰”的方式仍然有缺陷，那就是無法證明服務器公鑰本身就是貨真價實的公鑰。比如，接收到某台服務器的公鑰，如何證明公鑰就是原本預想的那台服務器發行的公鑰呢？或許在公鑰傳輸途中，真正的公鑰已經被攻擊者替換掉了。

計算機科學領域的任何問題都可以通過增加一個間接的中間層來解決。

這裏我們引入的中間層就是数字證書認證機構（CA，Certificate Authority），数字證書認證機構處於客戶端與服務器雙方都可信賴的第三方機構的立場上，以下是数字證書認證機構的業務流程。

服務器的運營人員向数字證書認證機構提出公開密鑰的申請。
数字證書認證機構在判明提出申請者的身份之後，會對已申請的公開密鑰做数字簽名，然後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書。
服務器將公鑰證書下發給客戶端。
客戶端使用公鑰證書的公開密鑰，對那張證書上的数字簽名進行驗證，一旦驗證通過，客戶端便可明確兩件事：一，認證服務器的公開密鑰的是真實有效的数字證書認證機構頒發的。二，服務器的公開密鑰是值得信賴的。

HTTPS 中還可以使用客戶端證書，以客戶端證書進行客戶端認證，證明服務器正在通信的對方始終是預料之內的客戶端，其作用跟服務器證書如出一轍。

使用 OpenSSL 這套開源程序，每個人都可以構建一套屬於自己的認證機構，從而自己給自己頒發服務器證書，但該服務器證書在互聯網上不可作為證書使用，因為個人並不是可信任的三方機構。

3. 完整性保護

基於 SSL 進行 HTTP 通信時，應用層發送數據會附加一種叫做 MAC（Message Authentication Code）的報文摘要，MAC 能夠查知報文是否遭到篡改，從而保護報文的完整性。

三、HTTPS 的通信過程

CBC 模式（Cipher Block Chaining）又名密碼分組鏈接模式。在此模式下，將前一個明文塊加密處理后和下一個明文塊做 XOR 運算，使之重疊，然後再對運算結果做加密處理。對第一個明文塊做加密時，要麼使用前一段密文的最後一塊，要麼利用外部生成的初始向量（initial vector， IV）。

四、HTTPS 的缺點？

處理速度上，由於 HTTPS 還需要做服務器、客戶端雙方加密及解密過程，因此會消耗 CPU 和內存等硬件資源。

通信上，和單純 HTTP 通信相比，SSL 通信會消耗部分網絡資源。

綜上所述，相較於 HTTP 通信來說，HTTPS 通信速度會變慢。針對速度變慢這一問題，並沒有根本性的解決方案，我們會使用 SSL 加速器這種（專用服務器）硬件來改善該問題。該硬件為 SS通信專用硬件，相對軟件來講，能夠提高數倍 SSL 的計算速度。

另外，SSL 證書的費用開銷也是使用 HTTPS 的考慮因素之一（阿里雲/騰訊雲有免費的 SSL 證書可以申請使用）。

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

【其他文章推薦】

※新北清潔公司,居家、辦公、裝潢細清專業服務

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

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

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

※網頁設計最專業,超強功能平台可客製化

介紹

構造器的循環依賴

屬性的循環依賴

總結一波

歡迎關注

參考博客

由來

特性

四大神器

自動配置

Starters

Actuator

開發工具

一 資源限制

1.1 pod資源限制

1.2 應用配額

1.3 ResourceQuota限制資源

1.3 應用限制範圍

1.4 多項目quota配額

二 限制資源使用

2.1 前置準備

2.2 本練習準備

2.3 查看當前資源

2.4 創建應用

2.5 刪除應用

2.6 添加資源限制

2.7 授權項目

2.8 驗證資源限制

2.9 創建應用

2.10 查看quota

2.11 查看節點可用資源

2.12 擴容應用

2.13 添加配額請求

2.14 增大配額請求

三 OCP升級

3.1 升級OPENSHIFT

3.2 升級方式

3.3 執行自動化集群升級

3.4 準備自動升級

3.5 升級master節點和node節點

3.6 分階段升級集群

3.7 使用Ansible Hooks

3.8 驗證升級

3.9 升級步驟匯總

四 使用probes監視應用

4.1 OPENSHIFT探針介紹

4.2 檢查應用程序健康

4.3 容器執行檢查

4.4 TCP Socket檢查

4.5 使用Web管理probes

五 使用探針監視應用程序實驗

5.1 前置準備

5.2 本練習準備

5.3 創建應用

5.4 暴露服務

5.5 檢查服務

5.6 創建readiness探針

5.7 創建Liveness探針

5.8 確認探測

5.9 修正probe

5.10 再次確認

六 Web控制台使用

6.1 WEB控制台簡介

6.2 使用HAWKULAR管理指標

6.3 管理Deployments和Pods

6.4 管理存儲

七 Web控制台監控指標

7.1 前置準備

7.2 本練習準備

7.3 創建項目

7.4 ·暴露服務

7.5 壓力測試

7.6 控制台擴容pod

7.7 查看metric

7.8 查看web控制監視

7.9 創建PV

7.10 嚮應用程序添加存儲

7.11 檢查存儲

八 管理和監控OpenShift

8.1 前置準備

一資源限制

二限制資源使用

四使用probes監視應用

五使用探針監視應用程序實驗

八管理和監控OpenShift