機器學習之決策樹原理和sklearn實踐

1. 場景描述

時間:早上八點,地點:婚介所

‘閨女,我有給你找了個合適的對象,今天要不要見一面?’

‘多大?’ ‘26歲’

‘長的帥嗎?’ ‘還可以,不算太帥’

‘工資高嗎?’ ‘略高於平均水平’

‘會寫代碼嗎?’ ‘人家是程序員,代碼寫的棒着呢!’

‘好,把他的聯繫方式發過來吧,我抽空見一面’

上面的場景描述摘抄自 ,是一個典型的決策樹分類問題,通過年齡、長相、工資、是否會編程等特徵屬性對介紹對象進行是否約會進行分類

決策樹是一種自上而下,對樣本數據進行樹形分類的過程,由結點和有向邊組成,每個結點(恭弘=恭弘=恭弘=叶 恭弘 恭弘 恭弘結點除外)便是一個特徵或屬性,恭弘=恭弘=恭弘=叶 恭弘 恭弘 恭弘結點表示類別。從頂部根結點開始,所有樣本聚在儀器,經過根結點的劃分,樣本被分到不同的子結點中。再根據子結點的特徵進一步劃分,直至樣本都被分到某一類別(恭弘=恭弘=恭弘=叶 恭弘 恭弘 恭弘子結點)中

2. 決策樹原理

決策樹作為最基礎、最常見的有監督學習模型,常被用於分類問題和回歸問題,將決策樹應用集成思想可以得到隨機森林、梯度提升決策樹等模型。其主要優點是模型具有可讀性,分類速度快。決策樹的學習通常包括三個步驟:特徵選擇、決策樹的生成和決策樹的修剪,下面對特徵選擇算法進行描述和區別

2.1 ID3—最大信息增益

在信息論與概率統計中,熵(entropy)是表示隨機變量不確定性的度量,設X是一個取有限個值的隨機變量,其概率分佈為:\[P(X=X_i)=P_i (i = 1,2,…,n)\],則隨機變量X的熵定義為:\[H(X) = -\sum_{i=1}^np_i\log{p_i}\]表達式中的對數以2為底或以e為底,這時熵的單位分別稱作bit或nat,從表達式可以看出X的熵與X的取值無關,所以X的熵也記作\(H(p)\),即\[H(p) = -\sum_{x=1}^np_i\log{p_i}\]熵取值越大,隨機變量的不確定性越大

條件熵:

條件熵H(Y|X)表示在已知隨機變量X的條件下,隨機變量Y的不確定性,隨機變量X給定的條件下隨機變量Y的條件熵定義為X給定條件下Y的條件概率分佈的熵對X的數學期望\[H(Y|X) = \sum_{i=1}^nP(X=X_i)H(Y|X=X_i)\]

信息增益:\[g(D,A) = H(D) – H(D|A)\]

import pandas as pd
data = {
        '年齡':['老','年輕','年輕','年輕','年輕'],
        '長相':['帥','一般','丑','一般','一般'],
        '工資':['高','中等','高','高','低'],
        '寫代碼':['不會','會','不會','會','不會'],
        '類別':['不見','見','不見','見','不見']}
frame = pd.DataFrame(data,index=['小A','小B','小C','小D','小L'])
print(frame)
    年齡  長相  工資 寫代碼  類別
小A   老   帥   高  不會  不見
小B  年輕  一般  中等   會   見
小C  年輕   丑   高  不會  不見
小D  年輕  一般   高   會   見
小L  年輕  一般   低  不會  不見
import math
print(math.log(3/5))
print('H(D):',-3/5 *math.log(3/5,2) - 2/5*math.log(2/5,2))
print('H(D|年齡)',1/5*math.log(1,2)+4/5*(-1/2*math.log(1/2,2)-1/2*math.log(1/2,2)))
print('以同樣的方法計算H(D|長相),H(D|工資),H(D|寫代碼)')
print('H(D|長相)',0.551)
print('H(D|工資)',0.551)
print('H(D|寫代碼)',0)
-0.5108256237659907
H(D): 0.9709505944546686
H(D|年齡) 0.8
以同樣的方法計算H(D|長相),H(D|工資),H(D|寫代碼)
H(D|長相) 0.551
H(D|工資) 0.551
H(D|寫代碼) 0

計算信息增益:g(D,寫代碼)=0.971最大,可以先按照寫代碼來拆分決策樹

2.2 C4.5—最大信息增益比

以信息增益作為劃分訓練數據集的特徵,存在偏向於選擇取值較多的問題,使用信息增益比可以對對着問題進行校正,這是特徵選擇的另一標準
信息增益比定義為其信息增益g(D,A)與訓練數據集D關於特徵A的值的熵\(H_A(D)\)之比:\[g_R(D,A) = \frac{g(D,A)}{H_A(D)}\]

\[H_A(D) = -\sum_{i=1}^n\frac{|D_i|}{|D|}\log\frac{|D_i|}{|D|}\]

拿上面ID3的例子說明:
\[H_年齡(D) = -1/5*math.log(1/5,2)-4/5*math.log(4/5,2)\]

\[g_R(D,年齡) = H_{年齡}(D)/g(D,年齡) = 0.171/0.722 = 0.236 \]

2.3 CART—-最大基尼指數(Gini)

Gini描述的是數據的純度,與信息熵含義類似,分類問題中,假設有K個類,樣本點數據第k類的概率為\(P_k\),則概率分佈的基尼指數定義為:
\[Gini(p) = 1- \sum_{k=1}^Kp_k(1-p_k) = 1 – \sum_{k=1}^Kp_{k}^2\]
對於二分類問題,弱樣本點屬於第1個類的概率是p,則概率分佈的基尼指數為\[Gini(p) = 2p(1-p)\],對於給定的樣本幾何D,其基尼指數為\[Gini(D) = 1 – \sum_{k=1}^K[\frac{|C_k|}{|D|}]^2\]注意這裏\(C_k\)是D種屬於第k類的樣本子集,K是類的個數,如果樣本幾個D根據特徵A是否取某一可能指a被分割成D1和D2兩部分,則在特徵A的條件下,集合D的基尼指數定義為\[Gini(D,A) = \frac{|D_1|}{|D|}Gini(D_1)+\frac{|D_2|}{|D|}Gini(D_2)\]
\[Gini(D|年齡=老)=1/5*(1-1)+4/5*[1-(1/2*1/2+1/2*1/2)] = 0.4\]

CART在每一次迭代種選擇基尼指數最小的特徵及其對應的切分點進行分類

2.4 ID3、C4.5與Gini的區別

2.4.1 從樣本類型角度

從樣本類型角度,ID3隻能處理離散型變量,而C4.5和CART都處理連續性變量,C4.5處理連續性變量時,通過對數據排序之後找到類別不同的分割線作為切割點,根據切分點把連續型數學轉換為bool型,從而將連續型變量轉換多個取值區間的離散型變量。而對於CART,由於其構建時每次都會對特徵進行二值劃分,因此可以很好地適合連續性變量。

2.4.2 從應用角度

ID3和C4.5隻適用於分類任務,而CART既可以用於分類也可以用於回歸

2.4.3 從實現細節、優化等角度

ID3對樣本特徵缺失值比較敏感,而C4.5和CART可以對缺失值進行不同方式的處理,ID3和C4.5可以在每個結點熵產生出多叉分支,且每個特徵在層級之間不會復用,而CART每個結點只會產生兩個分支,因此會形成一顆二叉樹,且每個特徵可以被重複使用;ID3和C4.5通過剪枝來權衡樹的準確性和泛化能力,而CART直接利用全部數據發現所有可能的樹結構進行對比。

3. 決策樹的剪枝

3.1 為什麼要進行剪枝?

對決策樹進行剪枝是為了防止過擬合

根據決策樹生成算法通過訓練數據集生成了複雜的決策樹,導致對於測試數據集出現了過擬合現象,為了解決過擬合,就必須考慮決策樹的複雜度,對決策樹進行剪枝,剪掉一些枝恭弘=恭弘=恭弘=叶 恭弘 恭弘 恭弘,提升模型的泛化能力

決策樹的剪枝通常由兩種方法,預剪枝和后剪枝

3.2 預剪枝

預剪枝的核心思想是在樹中結點進行擴展之前,先計算當前的劃分是否能帶來模型泛化能力的提升,如果不能,則不再繼續生長子樹。此時可能存在不同類別的樣本同時存於結點中,按照多數投票的原則判斷該結點所屬類別。預剪枝對於何時停止決策樹的生長有以下幾種方法

  • (1)當樹達到一定深度的時候,停止樹的生長
  • (2)當恭弘=恭弘=恭弘=叶 恭弘 恭弘 恭弘結點數到達某個閾值的時候,停止樹的生長
  • (3)當到達結點的樣本數量少於某個閾值的時候,停止樹的生長
  • (4)計算每次分裂對測試集的準確度提升,當小於某個閾值的時候,不再繼續擴展

預剪枝思想直接,算法簡單,效率高特點,適合解決大規模問題。但如何準確地估計何時停止樹的生長,針對不同問題會有很大差別,需要一定的經驗判斷。且預剪枝存在一定的局限性,有欠擬合的風險

3.3 后剪枝

后剪枝的核心思想是讓算法生成一顆完全生長的決策樹,然後從底層向上計算是否剪枝。剪枝過程將子樹刪除,用一個恭弘=恭弘=恭弘=叶 恭弘 恭弘 恭弘結點代替,該結點的類別同樣按照多數投票原則進行判斷。同樣地,后剪枝恭弘=恭弘=恭弘=叶 恭弘 恭弘 恭弘可以通過在測試集上的準確率進行判斷,如果剪枝過後的準確率有所提升,則進行剪枝,后剪枝方法通常可以得到泛化能力更強的決策樹,但時間開銷更大

損失函數

\[C_a(T) = \sum_{t=1}^{|T|}N_tH_t(T) + a|T|\]

\(其中|T|為恭弘=恭弘=恭弘=叶 恭弘 恭弘 恭弘結點個數,N_t為結點t的樣本個數,H_t(T)為結點t的信息熵,a|T|為懲罰項,a>=0\)

\[C_a(T) = \sum_{t=1}^{|T|}N_tH_t(T) + a|T| = -\sum_{t=1}^{|T|}\sum_{k=1}^KN_{tk}\log \frac{N_{tk}}{N_t} + a|T|\]

注意:上面的公式中是\(N_{tk}\log \frac{N_{tk}}{N_t}\),而不是\(\frac{N_{tk}}{N_t} \log \frac{N_{tk}}{N_t}\)

令:\[C_a(T) = C(T) + a|T|\]

\(C(T)\)表示模型對訓練數據的預測誤差,即模型與訓練數據的擬合程度,|T|表示模型複雜度,參數a>=0控制兩者的影響力,較大的a促使選擇較簡單的模型,較小的a促使選擇複雜的模型,a=0意味着只考慮模型與訓練數據的擬合程度,不考慮模型的複雜度

4. 使用sklearn庫為衛星數據集訓練並微調一個決策樹

4.1 需求

  • a.使用make_moons(n_samples=10000,noise=0.4)生成一個衛星數據集
  • b.使用train_test_split()拆分訓練集和測試集
  • c.使用交叉驗證的網格搜索為DecisionTreeClassifier找到合適的超參數,提示:嘗試max_leaf_nodes的多種值
  • d.使用超參數對整個訓練集進行訓練,並測量模型測試集上的性能

代碼實現

from sklearn.datasets import make_moons
import numpy as np
import pandas as pd
dataset = make_moons(n_samples=10000,noise=0.4)
print(type(dataset))
print(dataset)
<class 'tuple'>
(array([[ 0.24834453, -0.11160162],
       [-0.34658051, -0.43774172],
       [-0.25009951, -0.80638312],
       ...,
       [ 2.3278198 ,  0.39007769],
       [-0.77964208,  0.68470383],
       [ 0.14500963,  1.35272533]]), array([1, 1, 1, ..., 1, 0, 0], dtype=int64))
dataset_array = np.array(dataset[0])
label_array = np.array(dataset[1])
print(dataset_array.shape,label_array.shape)
(10000, 2) (10000,)
# 拆分數據集
from sklearn.model_selection import train_test_split
x_train,x_test = train_test_split(dataset_array,test_size=0.2,random_state=42)
print(x_train.shape,x_test.shape)
y_train,y_test = train_test_split(label_array,test_size=0.2,random_state=42)
print(y_train.shape,y_test.shape)
(8000, 2) (2000, 2)
(8000,) (2000,)
# 使用交叉驗證的網格搜索為DecisionTreeClassifier找到合適的超參數
from sklearn.tree import DecisionTreeClassifier
from sklearn.model_selection import GridSearchCV

decisionTree = DecisionTreeClassifier(criterion='gini')
param_grid = {'max_leaf_nodes': [i for i in range(2,10)]}
gridSearchCV = GridSearchCV(decisionTree,param_grid=param_grid,cv=3,verbose=2)
gridSearchCV.fit(x_train,y_train)
Fitting 3 folds for each of 8 candidates, totalling 24 fits
[CV] max_leaf_nodes=2 ................................................
[CV] ................................. max_leaf_nodes=2, total=   0.0s
[CV] max_leaf_nodes=2 ................................................
[CV] ................................. max_leaf_nodes=2, total=   0.0s
[CV] max_leaf_nodes=2 ................................................
[CV] ................................. max_leaf_nodes=2, total=   0.0s
[CV] max_leaf_nodes=3 ................................................
[CV] ................................. max_leaf_nodes=3, total=   0.0s
[CV] max_leaf_nodes=3 ................................................
[CV] ................................. max_leaf_nodes=3, total=   0.0s
[CV] max_leaf_nodes=3 ................................................
[CV] ................................. max_leaf_nodes=3, total=   0.0s
[CV] max_leaf_nodes=4 ................................................
[CV] ................................. max_leaf_nodes=4, total=   0.0s
[CV] max_leaf_nodes=4 ................................................
[CV] ................................. max_leaf_nodes=4, total=   0.0s
[CV] max_leaf_nodes=4 ................................................
[CV] ................................. max_leaf_nodes=4, total=   0.0s
[CV] max_leaf_nodes=5 ................................................
[CV] ................................. max_leaf_nodes=5, total=   0.0s
[CV] max_leaf_nodes=5 ................................................
[CV] ................................. max_leaf_nodes=5, total=   0.0s
[CV] max_leaf_nodes=5 ................................................
[CV] ................................. max_leaf_nodes=5, total=   0.0s
[CV] max_leaf_nodes=6 ................................................
[CV] ................................. max_leaf_nodes=6, total=   0.0s
[CV] max_leaf_nodes=6 ................................................
[CV] ................................. max_leaf_nodes=6, total=   0.0s
[CV] max_leaf_nodes=6 ................................................
[CV] ................................. max_leaf_nodes=6, total=   0.0s
[CV] max_leaf_nodes=7 ................................................
[CV] ................................. max_leaf_nodes=7, total=   0.0s
[CV] max_leaf_nodes=7 ................................................
[CV] ................................. max_leaf_nodes=7, total=   0.0s
[CV] max_leaf_nodes=7 ................................................
[CV] ................................. max_leaf_nodes=7, total=   0.0s
[CV] max_leaf_nodes=8 ................................................
[CV] ................................. max_leaf_nodes=8, total=   0.0s
[CV] max_leaf_nodes=8 ................................................
[CV] ................................. max_leaf_nodes=8, total=   0.0s
[CV] max_leaf_nodes=8 ................................................
[CV] ................................. max_leaf_nodes=8, total=   0.0s
[CV] max_leaf_nodes=9 ................................................
[CV] ................................. max_leaf_nodes=9, total=   0.0s
[CV] max_leaf_nodes=9 ................................................
[CV] ................................. max_leaf_nodes=9, total=   0.0s
[CV] max_leaf_nodes=9 ................................................
[CV] ................................. max_leaf_nodes=9, total=   0.0s


[Parallel(n_jobs=1)]: Using backend SequentialBackend with 1 concurrent workers.
[Parallel(n_jobs=1)]: Done   1 out of   1 | elapsed:    0.0s remaining:    0.0s
[Parallel(n_jobs=1)]: Done  24 out of  24 | elapsed:    0.0s finished

GridSearchCV(cv=3, error_score='raise-deprecating',
       estimator=DecisionTreeClassifier(class_weight=None, criterion='gini', max_depth=None,
            max_features=None, max_leaf_nodes=None,
            min_impurity_decrease=0.0, min_impurity_split=None,
            min_samples_leaf=1, min_samples_split=2,
            min_weight_fraction_leaf=0.0, presort=False, random_state=None,
            splitter='best'),
       fit_params=None, iid='warn', n_jobs=None,
       param_grid={'max_leaf_nodes': [2, 3, 4, 5, 6, 7, 8, 9]},
       pre_dispatch='2*n_jobs', refit=True, return_train_score='warn',
       scoring=None, verbose=2)
print(gridSearchCV.best_params_)
decision_tree = gridSearchCV.best_estimator_
{'max_leaf_nodes': 4}
# 使用測試集對模型進行評估
from sklearn.metrics import accuracy_score
y_prab = gridSearchCV.predict(x_test)
print('accuracy_score:',accuracy_score(y_test,y_prab))
accuracy_score: 0.8455
# 可視化模型
from sklearn.tree import export_graphviz

export_graphviz(decision_tree,
               out_file='./tree.dot',
               rounded = True,
               filled = True)

生成tree.dot文件,然後使用dot命令\[dot -Tpng tree.dot -o decisontree_moons.png\]

5. 附錄

5.1 sklearn.tree.DecisionTreeClassifier類說明

5.1.1 DecsisionTreeClassifier類參數說明

  • criterion: 特徵選擇方式,string,(‘gini’ or ‘entropy’),default=’gini’
  • splitter: 每個結點的拆分策略,(‘best’ or ‘random’),string,default=’best’
  • max_depth: int,default=None
  • min_samples_split: int,float,default=2,分割前所需的最小樣本數
  • min_samples_leaf:
  • min_weight_fraction_leaf:
  • max_features:
  • random_state:
  • max_leaf_nodes:
  • min_impurity_decrease:
  • min_impurity_split:
  • class_weight:
  • presort: bool,default=False,對於小型數據集(幾千個以內)設置presort=True通過對數據預處理來加快訓練,但對於較大訓練集而言,可能會減慢訓練速度

5.1.2 DecisionTreeClassifier屬性說明

  • classes_:
  • feature_importances_:
  • max_features_:
  • n_classes_:
  • n_features_:
  • n_outputs_:
  • tree_:

5.2 GridSearchCV類說明

5.2.1 GridSearchCV參數說明

  • estimator: 估算器,繼承於BaseEstimator
  • param_grid: dict,鍵為參數名,值為該參數需要測試值選項
  • scoring: default=None
  • fit_params:
  • n_jobs: 設置要并行運行的作業數,取值為None或1,None表示1 job,1表示all processors,default=None
  • cv: 交叉驗證的策略數,None或integer,None表示默認3-fold, integer指定“(分層)KFold”中的摺疊數
  • verbose: 輸出日誌類型

5.2.2 GridSearchCV屬性說明

  • cv_results_: dict of numpy(masked) ndarray
  • best_estimator_:
  • best_score_: Mean cross-validated score of the best_estimator
  • best_params_:
  • best_index_: int,The index (of the “cv_results_“ arrays) which corresponds to the best candidate parameter setting
  • scorer_:
  • n_splits_: The number of cross-validation splits (folds/iterations)
  • refit_time: float

參考資料:

  • (1)
  • (2)
  • (3)李航

【精選推薦文章】

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

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

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

可落地的DDD(5)-戰術設計

摘要

本篇是DDD的戰術篇,也就是關於領域事件、領域對象、聚合根、實體、值對象的討論。也是DDD系列的完結篇。
這一部分在我們團隊爭論最多的,也有很多月經貼,比如對資源庫的操作應該放在領域服務還是領域對象中。
聚合根應不應該暴露給外部,還是要轉成DTO。這些問題我們討論了大半年,最後大家基本達成了共識,在當前的業務規模下,
這些問題沒那麼重要,可東可西。不會對代碼的質量有啥大的影響。關於DDD的實踐,與團隊的水平、業務複雜度息息相關。我們的經驗並不一定就適用你們團隊。我將戰術篇的這麼多的內容放在了一篇文章中,並且大部分都是引用之前的討論、總結。
原因還是在於我內心深處並沒有覺得戰術篇的實踐給我們團隊帶來多麼大的改變。戰略篇的是我認為更重要的。

DDD系列文章斷斷續續也有十來篇了,主要是總結我們團隊落地過程遇到的問題和解決方案,算是DDD從學習到落地實踐的一個完整的閉環鏈路,希望對你有所啟發。當然這個過程受益最大的肯定是我本人。系統性的思考問題、總結問題、闡述問題是非常有助於提升個人思維能力,朋友們你們也可以嘗試一下。

建模

DDD的出現,是大家對於事務性編程,面向數據庫表編程的一個反思,明明軟件設計是一個面向對象的設計,需要考慮對象之間的繼承、多態、組合。
為什麼到實際編碼過程中成了過程性的編程,為什麼對象只有屬性沒有方法了,也就是失血模型。

關於這幾種編程的詳細介紹可以參考Martin的《Patterns of Enterprise Application Architecture》Page110

所以我個人覺得,DDD的作用有兩個,一個是面向業務的,幫助分析業務模型,進行業務建模。另外一個是面向解決域,即代碼落地。
即使用一個規範能夠反映對象之間的關係,即OO編程。

目前對DDD研究主要有以下類別

  1. 關於業務分析層面,如何進行概念層面的抽象和設計的方法論
  2. 關於服務劃分、代碼分層、職責定義的方法論
  3. DDD框架的討論,比如jdon

第3點基本上沒怎麼廣泛的討論。我認為未來也不會出現什麼牛逼的DDD框架能夠流行起來。DDD是一種建模方法,是針對不同的業務領域的,
在不同的團隊有不同的落地方案,是沒辦法靠一種框架來約束,來把一件不統一的事情來統一起來。就好比我們面向對象的設計針對問題域,抽象出來了
20多種設計模式。這些設計模式都是指導思想,你不能搞出一種框架,來約束大家使用某種設計模式就基於這種框架擴展,以此來達到代碼統一或者降低
編程難度的目的。

前面的文章主要是比較大的方面,比較適合做整體業務分析。也就是第一個點。今天主要討論第二點。

OO 編程

DDD的代碼分層、職責定義本質上就是OO編程。OO的三大基本要素就是繼承、多態、組合。這三個是深度抽象的結果。沒法指導具體的編程。
於是我們有了設計模式,前輩們針對問題域,總結除了24種設計模式,這樣遇到類似的問題時,我們可以使用對應的設計模式去解決問題。
而這些設計模式底層使用到還是繼承、多態、組合。

那有了設計模式了,為什麼還要DDD呢?為什麼很少看到開源軟件用DDD呢?
個人的理解DDD還是面向企業應用架構的,是在眾多不確定的業務,系統中提煉出來的一套規範,這樣必然是高度抽象的。而開源軟件大多是領域比較確定的,比如數據庫領域,中間件領域。解決這類問題的系統架構通常會更加複雜以及具有擴展性。

DDD的工程架構網上有很多,我在之前的文章也提到過,這裏不再贅述,看下老馬的這個,我覺得非常清晰的展現出來了職責分離
https://martinfowler.com/articles/microservice-testing/#conclusion-summary

我們重點看領域一層。
領域包含3點

領域服務

領域對象與領域服務

領域對象

敢於聚合根的激烈討論

領域事件

CQRS能解什麼問題

基礎設施層

為各層提供資源服務(如數據庫、緩存等),實現各層的解耦,降低外部資源變化對業務邏輯的影響。

總結

  • DDD中國
    http://ddd-china.com/look-back-2017.html 視頻去網站看

  • 美團的實踐
    https://tech.meituan.com/2017/12/22/ddd-in-practice.html

  • 盒馬的實踐
    https://zhuanlan.zhihu.com/p/42565478

  • cnblog博客園有很多.net DDD實踐的文章

    https://www.cnblogs.com/zhili/category/603514.html
    http://www.cnblogs.com/daxnet/archive/2012/12/27/2836372.html

  • jdon上面的系列
    https://www.jdon.com/ddd.html

  • 框架方面(個人覺得沒啥用,參考看看)

    rafy框架:http://zgynhqf.github.io/Rafy/articles/%E9%A2%86%E5%9F%9F%E5%AE%9E%E4%BD%93%E6%A1%86%E6%9E%B6.html

    jdon https://github.com/banq/jivejdon

  • 一些相關的書籍pdf上傳到百度網盤,需要的自取。

    鏈接: https://pan.baidu.com/s/1kGYk1dHbTAjBS4kd9s1VWw
    提取碼: 36w4

關注公眾號【方丈的寺院】,第一時間收到文章的更新,與方丈一起開始技術修行之路

【精選推薦文章】

智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

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

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

廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

RPC – 麻雀雖小,五臟俱全

說起 RPC (遠程過程調用),大家應該不陌生。隨着微服務、分佈式越來越流行,RPC 應用越來越普遍。常見的 RPC 框架如:Dubbo、gRPC、Thrift 等。本篇文章不是介紹各種 RPC 的使用和對比。而是深入剖析一個 RPC 包含哪些內容。我最近在 Hadoop 的源碼,正好把 Hadoop RPC 看完了。感覺 Hadoop 的 RPC 框架設計的還是比價優秀的。Hadoop 作為大數據技術的基石,如果沒有一個高性能、高可靠的 RPC 框架,很難支撐上千台服務器規模的集群。因此,本篇文章就以 Hadoop RPC 為例,介紹一個 RPC 框架會涉及的技術。

架構設計

RPC 的架構涉及客戶端、網絡、服務端三大組件。網絡一般使用 socket ,更多的是基於現有的網絡框架進行參數的設置達到最優的目的。但是客戶端和服務端需要我們自己設計,並且對於分佈式框架來說,設計的架構應該有高性能、高可用以及可擴展的特點。

  • 高性能:由於客戶端同時發起多個請求,這就要求系統能夠快速處理,降低響應延遲。也就是高吞吐、低延遲。從客戶端角度來說,由於創建客戶端到服務端的連接成本較高。因此可以緩存連接資源,從而實現多個客戶端復用相同的連接資源,避免每個客戶端都來創建而降低性能;從服務端角度來說,可以啟動多線程來併發處理客戶端請求。除了多線程,可以採用 Reactor 編程模式,提高多線程併發的性能。
  • 高可用:當我們的服務端掛了,能不能有備用節點繼續提供服務。Hadoop 2.x 實現了 NameNode 的高可用。當客戶端需要通過 RPC 調用 NameNode 服務的過程中,如果主 NameNode 宕機,那麼備用 NameNode 會升級成活動節點。同時會將 RPC 的請求發送的當前活躍的 NameNode,從而繼續提供可用的服務,而這個過程對客戶端來說是透明的。
  • 可擴展性:一個框架需要不斷地優化、不斷升級。需要在架構設計時明確不變的需求點,以及可變的需求點,對於可變的需求需要能夠有良好的可擴展性。以 RPC 涉及的序列化為例。由於不同序列化框架適用場景不同,因此這需要被當成可變的需求點,應該將其設計成可擴展的,能夠容易地支持不同的序列化框架。目前,Hadoop RPC 支持自身的序列化框架(Writable)和 Protoc Buffer。

設計模式

設計模式更多地與上面提到的可擴展性相呼應。良好的設計模式可以提高代碼復用性、增強可擴展性,同時能夠降低 BUG 數量。Hadoop RPC 中涉及的設計模式比較多,大概包括:工廠模式、代理模式、適配器模式、裝飾者模式和命令模式等。以代理模式為例,當客戶端調用遠程方法時,實際上是通過代理,將方法名和參數通過網絡發送到服務端。但這個過程對客戶端是透明的,對於客戶端來說就像調用本地方法一樣。

除了設計模式,在工程實踐中還應該注意遵循常見的設計原則。

多線程

在任何一個系統中多線程都比較常見。通過多線程併發處理,提高系統的吞吐量。在 Hadoop RPC 中,客戶端與服務端都用到了多線程技術。客戶端開啟多線程,每個線程處理一類請求,並且緩存連接資源。服務端也是多線程併發處理客戶端的請求,使用 Reactor 編程模式提高併發性能。

談到多線程就不得不提另一個話題 —— 線程安全。Hadoop RPC 中用了不少的技術來保證線程安全,包括:synchronized、concurrent併發包、atomic併發包和 nio 工具包。從優秀框架中學習線程安全,對我們以後併發編程有不少好處。

序列化與反序列化

由於 RPC 涉及數據在網絡上傳輸,因此需要一個優秀的序列化框架,既能夠高效的編碼與解碼,且編碼后的數據大小又盡可能小。不同的序列化框架主要是在編解碼效率和編碼大小兩個主要方面做權衡。Hadoop RPC 目前支持兩種序列化框架,一個是 Hadoop 自己實現的 Writable 框架,另一個是 Protocol Buffer。Hadoop RPC 雖然支持 Writable 序列化框架,但還是以 Protocol Buffer 為主。因為 Protocol Buffer 從編解碼效率和編碼大小方便都是比較優秀的。當然常見的序列化包括 Avro、Kryo 等,有興趣的讀者可以查一下它們之間的性能對比。

其他

一個 RPC 框架,除了包含上面提到比較主要的方面。還有一些其他的方面

  • 語言層面:利用好 Java 語言的繼承、組合、封裝、多態等特性。甚至包括泛型、註解等。
  • 代碼規範:良好的工程實現應該有一個良好的代碼規範。在 Hadoop 中,代碼風格比較統一,且每個重要的類都有詳細的註釋,在關鍵的方法或者屬性上也有明確的註釋。我在自己的工程中會使用阿里的 Java 代碼規約插件,也會為了讓自己的代碼更規範。
  • 異常處理:對於一個優秀的框架異常處理很關鍵,什麼時候需要拋出異常、拋出什麼樣的異常以及什麼時候需要處理異常。在 RPC 中除了需要處理本地異常還要處理遠程服務的異常。因此,在程序中如何優雅的處理異常也是體現一個程序員能力的地方。
  • 網絡編程:RCP 中涉及的網絡編程一般用 socket,Hadoop RPC 使用的 Reactor 模式的網絡編程,並且 Netty 也在使用這種框架。我們有必要會用並且掌握它。

 這一段寫的比較雜,想到哪寫到哪。最近有跟朋友聊過在看 RPC 相關的東西,朋友說:“一個 RPC 能夠涉及多少東西?值得研究?”。其實我一開始也是這樣想的,無非就是客戶端將請求序列化,通過網絡發給服務端,服務端反序列化調用函數后再返回。但是看了 Hadoop RPC 代碼后,我發現這樣框架涉及的知識還是特別多的,並且還比較系統,基本上包含了我們平時編程涉及的方方面面。同時它不再是一個單機程序,而是一個 C/S 架構的程序。如果我們有興趣還可以繼續研究他的高可用,從而對分佈式應用有更深入的了解。

我覺得 RPC 是麻雀雖小五臟俱全。由於它涉及了我們編程的方方面面,所以我想基於 Hadoop RPC 做一個詳細的教程,把它涉及的每個重要部分都進行詳細的分析,上面提到的內容基本都會涵蓋。對於想了解 RPC 的讀者,能夠感受到一個 RPC 框架更清晰的面貌。對於僅有 Java 基礎的讀者來說,能夠學到編寫一個框架所涉及的具體編程技術,同時能夠從世界頂級開源項目學到優秀設計和工程經驗。

小結 

本篇文章主要介紹了 RPC 框架涉及的知識。包括:架構設計、設計模式以及設計原則、多線程併發以及線程安全、序列化框架和一些其他的內容。我覺得學習最好的方式就是從優秀的框架中學習、模仿。好比我們練書法基本都要經過臨摹這一步。當然直接看別人的代碼確實需求花費更多的時間和經歷,並且有時候投入與產出並不成正比。所以,我想把我在 Hadoop RPC 框架中學到的優秀的設計和實現能夠整理成教程,以便有興趣的讀者學習。如果有任何建議歡迎與我交流。公眾號有福利

公眾號「渡碼」

 

【精選推薦文章】

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

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

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

膨脹、驕傲,程序員轉項目經理的原罪

目錄

  • 一、前言:謙卑與狂妄
  • 二、尊重:遠與近
  • 三、原罪:膨脹與驕傲

作者簡介:妖生。 坐標合肥,一個普通程序員。十年職業生涯,8年編程。經歷了許多事,也有點想法,現在將它們變成文字,書於紙上。如果能幫助到你,那將不勝榮幸。

膨脹、驕傲,程序員轉項目經理的原罪

一、前言:謙卑與狂妄

突然就想到這麼個主題,回想我在2016下、2017上的時候,確實好像有那麼一段時間,有點膨脹,感覺自己無所不能,又太過驕傲,表面謙虛、內心傲氣,似乎誰都不放在眼裡。

做管理的沒我技術好,做技術的沒我會管理。

現在想想,真是可笑啊。

由己及彼,會不會也有不少做了三五年程序員,做了小組長,突然成為管理者,有了團隊里的一些話語權,然後膨脹的呢?

那麼我這樣去總結下,能不能給一些正在經歷這個階段的程序員們,甚至非程序員們的小夥伴們,予以一點點啟發呢?

嗯,晚上想就這個話題寫篇長文,回憶下我當年的情景,復盤當年,說一說我一些錯誤的做法,和之後怎樣警醒與走出來的。

二、尊重:遠與近

2.1 近之則不遜

2015年,金三大潮席捲而來,全國的稅務系統都要升級,我也有幸參與了這樣的歷史性進程。

我代表安徽的大集中征管稅務系統承建商,與金三征管中標商中軟公司進行系統對接。趕赴深圳南海,在國家稅務總局的信息中心進行征管數據的遷移工作。

在深圳南海的時候,我帶領的小組負責為數據遷移工作作數據校驗、數據確認、遷移腳本編寫等工作。

在這樣的時刻,安徽基地突然打電話過來,也是當時的項目經理——老趙,打電話對我說,要我負責金三本地保留系統的改造工作。

我當時一頭霧水,滿心不爽,不知道為什麼這樣的工作就落到了我的頭上。並且人在深圳,有心無力。所以說話有點沖,說我不知道怎麼做,直接就懟了幾句。

老趙忽然說了一句:“如果是XX你會這樣跟他說嗎?”XX是我們的項目總監。

我腦子里突然有一道電閃了一下。

是啊,如果是XX這樣跟我說,給我安排這樣的任務。我會這樣去懟嗎?
我是不是就默默接受了?

我突然想起來,2014年,我與老趙坐在一塊,因為某件事,我引用了孔子的一句話:“女子與小人難養也。遠之則怨,近之則不遜”。

老趙讚賞地說,很有道理。

可是這樣的話,我為何說了,卻不記得,做不到,無法知行合一呢?

我對老趙,就是近之則不遜了。

我沉默了大概十秒鐘,隨後對他說:“你放心,我肯定完成任務。沒有什麼完不成的。”
在轉變態度與思路后,我對怎麼解決金三本地保留的改造有了切實可行的思路與方法。

我在電話中將我的想法與老趙溝通后,老趙對我表示了讚賞,“就是要有這種舍我其誰的氣勢。除了你,沒人能搞定。”

這通電話很長,也在我以後的職業生涯中,對我做事做人的方法進行了一次很大的改造。

但是在這個故事里我卻還是有一點沒學到,也是我最近在反思的一個問題。

我為什麼對於別人,總是吝嗇於讚賞?

老趙在與我的相處中,一直對我進行鼓勵、讚賞,讓我有了一次次面對問題的自信,得到了極大的成長。

遇到這樣一個半師半友的領導,何其之幸也。

這段往事我總結了兩個點:

一是與上級相處時可以開玩笑、插科打諢,但是在工作上應該把上級當做上級,給予應有的尊重。

二是在與下級相處時,應該不吝嗇表揚,尤其在現在85后、90后當家的年代,表揚會比批評更能激發他們的工作激情,賦予他們超出當前能力的創造力。

2.2 遠之則怨

在2016年的時候,老趙罹患重疾,在長時間病情反覆、無法工作的情況下,拿了公司的補償金,主動離職。

誰來接替這個項目經理的位置?

當時其實是有三個人選,一個是運維經理Y,一個是技術經理H,還有一個就是我這個開發經理。

在H主動退出的情況下,我與Y開始競爭這個職位。

怎麼說呢?我其實一開始並不care這個項目經理的職位。我只想安安靜靜地做開發,不願意去做什麼項目管理。因為有權利的同時,意味着麻煩。

如果是技術經理H,也就是我在电子稅務局的老搭檔坐了項目經理這個職位,我是不想去競爭的。

但是現在是他退出,我倆競爭,而令我萬分不爽的是,在一開始,項目總監X便帶了濃烈的主觀傾向,他是屬意運維經理來坐這個職位的,這樣的傾向我後來的判斷是八二。

我直接去找了總監X,說出了這樣的話:“他何德何能,憑什麼做項目經理,拿什麼來領導我?”

我後來才知道,就在這個競爭的過程中,X找了項目組運維、開發的骨幹同事們,一一諮詢了對於項目經理這個職位人選的意見。

或許結果令他大失所望,90%的人都對他屬意的人選投了反對票。

真的是我牛逼?我人緣好嗎?我當時真的是這麼覺得。

後來細想,恐怕並不是如此。開發投我可以理解,為什麼運維的同事也投我呢?

我想,是因為這位Y先生不得手下人心吧。在對待客戶、對待上級方面,這位運維負責人把自己的工作幹得很出色,客戶關係維繫的很好。

但是在對待下屬方面,我則聽到了好幾次關於Y的抱怨。

一位同事說某個工作是他來解決的,處理的很出色,結果Y卻跟客戶說是Y來解決的,讓他心生怨懟。

另一位同事說他在處理某個線上的緊急問題,一時沒解決,結果總監X將Y調了過來,看着他處理,後來事情解決了,而Y在這個過程中什麼都沒幹。導致這位同事覺得 總監X 是不是太信任 Y 了,反而對 Y 敬謝不敏。

這兩位同事在16年已經成長為項目組的骨幹員工,也在這次競爭事件中投了 Y 的反對票。

有時候,其實不是你成功,而是對手打敗了自己。用現在流行的話來說,叫 同行襯托 吧。

我舉這兩個例子,是覺得這裏面有兩個點需要去反思和總結的。

一是遠之則怨,在對待下屬時如果為了保持上級的威嚴,而拉開了距離,則導致互相不了解,很容易產生芥蒂。

二是攬功諉過是領導者的大忌,其實團隊做好了事情就是你的功勞,至於是不是你個人解決的有什麼關係呢?作為領導者,個人成功,團隊失敗,其實都是失敗者。

在這裏面還有一點是我想提出的,就是在職場工作中,如果競爭的機會,要敢於競爭,競爭說明了你的決心。

我當時找 總監X 的談話中,還說了這樣一段話:

“我覺得如果我來選,我選自己做項目經理。”
“相比他,我肯定會做的更好。”
“如果他來帶這個團隊,那不用多久,這個團隊就要人心散了。”

是不是很狂妄?然而真的就是我內心的想法。你要麼空降一個項目經理過來,要麼就選我。

有時候在與上級的溝通中,沒必要遮掩自己內心的想法。當然,如果你的上級只愛聽阿諛諂媚的話,便保留意見,默默前行吧。

幸而,我覺得我一路遇到的都是貴人。從第一家公司的保總,到神碼的斌哥、蔡總、曹工、老趙、總監X,我覺得無比幸運,總是能遇到眼界比你高、願意提點你的老闆、導師、同事與朋友。

那麼回過頭來,我對 總監X 說的這番話到底有多大的影響呢?我相信在八二的傾向比重中,得到了兩分吧。再加上同事們的支持,最終是我勝出,成了【代】項目經理。

至於為什麼是【代】,呵呵,那便是另外一個故事了。

三、原罪:膨脹與驕傲

3.1 驕傲:無所不能與一天十會

在成為【代】項目經理后,我開始了馬不停蹄的開會生涯。最多的時候,一天十會,感覺什麼都要我來拍板。

2017年,政府開始提出“互聯網+”的概念,這便開始了我們開發項目爆發的一年。

智能辦公、大數據、移動APP、數據質量、統一門戶、短信平台、外部交換等等。

從需求到架構,全都是我來主導,業務人才的極度缺乏,導致我陷入了局方的會議大海。

後來有一位從別的區調過來幫助我的資深業務專家說了一句:

從技術人升上來的管理者可能都有一個毛病,凡事都要親力親為。何不放手讓下面的人乾乾呢?說不定干出的效果會超過你想象。

但是當時的我,並沒有把這話聽進去。

在前幾天看到雷軍的一篇文章,說為什麼小米手機干不過華為,甚至遠遜於OV呢?一是待遇問題,導致招不到行業最頂尖的人才;二是雷軍凡事親力親為,哪裡的業務不行了,就自己出山擼起袖子干。

很有感觸,何其相似。雷軍也是干技術出身的啊。同樣做技術出身,還是馬化騰夠瀟灑。

當然,我自然是比不了大佬的。可是反思下,我真的是這麼無所不能嗎?

或許只是我所在的位置,導致我接收的信息足夠多,而無法被下面的同事所取代?

或許並非我的能力太強,只是我的眼界、層次還不夠,還沒有做好一個管理者的轉變。

一個好的管理者,應該是大音希聲、大象無形,讓團隊在沒有你的情況下,也能按照預定計劃穩步前行。

3.2 膨脹:程序員的原罪

在無所不能的這一段時間中,因為開發項目的過多,還有大數據這樣新興技術的項目,從公司層面協調來了一位技術總監,也是我們安徽項目組以前出去的一位同事。暫且叫他 L 吧。

因為以前共在一個項目組,也算是半熟不生。而我並沒有充分意識到怎樣去尊敬這樣一位技術達人、前輩。

因為在這個公司,實行的是項目負責制,項目經理掌握着一票否決權。而我,這樣一位剛剛上任,新鮮熱乎着的【代】項目經理,開始膨脹了。

在這位 L 前輩研究spark + strom 解決實時倉庫問題時,我總是時不時打斷了他,喊他去參與大數據的需求會議、去解決APP的流量高峰問題、去參與統一門戶的架構設計。

誠然這一切,都應是技術總負責人應該去參與負責的事情。但是我在請求 L 去解決的時候,未免有些不夠尊重。

有時候,你外在不經意的一些表現其實正是你內心想法的一種體現。而人與人的相處,是奇妙而玄幻的。這種看不見、摸不着的氣氛是真的會影響彼此的心情與態度。

更何況,L 更是將技術人簡單、直接的性格放大到極致。

在某次赴地市的會議上,我與L一起討論確定了辦公系統與外部系統的對接與集成方式后,便借口項目組有事先走了,讓 L 留下參與後續與另一家公司的對接。

這件事直接導致 L 的不滿爆發,在幾天後的一次微信群的工作安排上直接懟了我,將我拉黑。

當然,這樣的過程都是我後來回憶、反思得出的結論,而我當時是懵逼的。

為什麼?會有這麼激烈的回應?我一臉懵逼地請求項目總監X的幫助,才讓 L 重新恢復參與了後續的工作。

我後來想想,這一切好像是偶然發生的,但卻也是必然會產生的,如果不是 L ,可能事情不會這麼激烈。然而其他沒有拉黑我的下屬和同事們,是不是其實心裏也在怨懟我呢?

在升上了項目經理之後,我是不是也開始遠離初心,“遠之則怨”了呢?

特別是在並非管理序列的上升通道中,突然從技術崗轉為了管理崗,從單純的管事變成了管人,有了財政、生殺大權,怎樣消去產生的膨脹與浮躁感呢?

有時候能力與眼界是位置帶來的,但是位置帶來的能力不是天生就來的,而是慢慢培養、逐漸形成的。

我回憶、反思這段往事的時候,覺得我在坐上項目經理的時候,缺失了一名老趙這樣的導師,想起他說的一句話:“扶上馬,再送一程”。

在很多公司,其實包括我當時所在的這家公司,也都有項目經理的培養與彙報機制,但是很多時候都淪為了背景色、走過程,是不是哪怕再忙,也該有這麼一課呢?

當然,有可能也並沒有什麼鳥用。因為紙上得來終覺淺,絕知此事要躬行。

我從這件事後,開始反思,重新整理人事,縮減彙報對象與被彙報對象。分離主要事務、次要事務。有意培養各開發組長的全棧能力。

當然,這一切其實都是不夠的,甚至在2017下2018上的時候,我開始怠惰,徹底放權,走入了另一個極端。

而在環境的演變下與艱難的掙扎中,我在2018下半年選擇重新投入了技術崗,但是在兩年已經極少碰代碼的情況下,我能重新拾起,並引領項目組前行嗎?

這是另一個故事了,但是最後想說的是:

沒做到技術總監、架構師,以後還想做技術,別去碰項目經理這個職位,繁雜瑣事,耗費精力,徒增煩惱。

嗯,這又可以寫篇文章了,下一篇就叫《技術人,別做項目經理,有毒!》,哈哈哈。

歡迎加入我的知識星球,掃一掃下方二維碼,目前免費哦。

【精選推薦文章】

智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

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

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

廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

Akka-CQRS(13)- SSL/TLS for gRPC and HTTPS:自簽名證書產生和使用

  到現在,我們已經完成了POS平台和前端的網絡集成。不過,還是那句話:平台系統的網絡安全是至關重要的。前一篇博客里我們嘗試實現了gRPC ssl/tls網絡連接,但測試時用的證書如何產生始終沒有搞清楚。現在akka-http開發的ws同樣面臨HTTPS的設置和使用問題。所以,特別抽出這篇博文討論一下数字證書的問題。

在正式的生產環境里数字證書應該是由第三方公證機構CA簽發的,我們需要向CA提出申請。数字證書的申請、簽發和驗證流程如下:

1) 服務⽅ S 向第三⽅方機構CA提交公鑰、組織信息、個⼈信息(域名)等資料提出認證申請 (不需要提供私鑰) 2) CA 通過各種手段驗證申請者所提供信息的真實性,如組織是否存在、 企業是否合法,是否擁有域名的所有權等 3) 如信息審核通過,CA 會向申請者簽發認證文件-證書。 證書包含以下信息:申請者公鑰、申請者的組織信息和個⼈信息、簽發機構 CA 信息、有效時間、證書序列號等信息的明⽂,同時包含一個簽名的產⽣生算法:首先,使用散列函數計算出證書中公開明文信息的信息摘要,然後, 採用 CA 的私鑰對信息摘要進⾏加密,這個密⽂就是簽名了 4) 客戶端 C 向服務器 S 發出請求時,S 返回證書文件 5) 客戶端 C 讀取證書中的相關的明⽂信息,采⽤相同的散列函數計算得到信息摘要, 然後,利用對應 CA 的公鑰解密簽名數據,對比證書的信息摘要,如果一致,則可以確認證書的合法性,即公鑰合法 6) 客戶端 C 然後檢驗證書相關的域名信息、有效時間等信息 7) 客戶端 C 應內置信任 CA 的證書信息(包含公鑰),如果 CA 不被信任,則找不到對應 CA 的證書,證書也會被判定非法 8) 內置 CA 對應的證書稱為根證書,頒發者和使⽤者相同,用 CA ⾃⼰的私鑰簽名,即⾃簽名證書(此證書中的公鑰即為 CA 的公鑰,可以使用這個公鑰對證書的簽名進行校驗,⽆需另外⼀份證書)

服務器端在通信中建立SSL加密渠道過程如下:

1)客戶端 C 發送請求到服務器端 S 2) 服務器端 S 返回證書和公開密鑰到 C,公開密鑰作為證書的一部分傳送 3)客戶端 C 檢驗證書和公開密鑰的有效性,如果有效,則⽣成共享密鑰並使⽤公開密鑰加密發送到服務器端 S 4) 服務器端 S 使⽤私有密鑰解密數據,並用收到的共享密鑰加密數據,發送到客戶端 C 5) 客戶端 C 使⽤用共享密鑰解密數據 6) SSL 加密通信渠道建立 ...

應該說,需要在客戶端進行認證的應用場景不多。這種情況需要在客戶端存放数字證書。像支付寶和一些銀行客戶端一般都需要安裝證書。

好了,還是回到如何產生自簽名證書示範吧。下面是一個標準的用openssl命令產生自簽名證書流程:

在產生證書和密鑰的過程中所有系統提問回答要一致。我們先假設密碼統一為:123456

1、生成根證書私鑰: rootCA.key:  openssl genrsa -des3 -out rootCA.key 2048 

2、根證書申請 rootCA.csr:openssl req -new -key rootCA.key -out rootCA.csr

3、用申請rootCA.csr生成根證書 rootCA.crt:openssl x509 -req -days 365 -sha256 -extensions v3_ca -signkey rootCA.key -in rootCA.csr -out rootCA.crt

4、pem根證書 rootCA.pem:openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem

5、創建⼀個v3.ext⽂件,目的是產生X509 v3證書,主要目的是指定subjectAltName選項:

  authorityKeyIdentifier=keyid,issuer basicConstraints=CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment subjectAltName = @alt_names [alt_names] DNS.1 = localhost IP.1 = "192.168.11.189" IP.5 = "192.168.0.189" IP.2 = "132.232.229.60" IP.3 = "118.24.165.225" IP.4 = "129.28.108.238"

注意subjectAltName,這些都是可以信任的域名或地址。

6、構建證書密鑰 server.key:openssl req -new -sha256 -nodes -out server.csr -newkey rsa:2048 -keyout server.key

7、用根證書rootCA產生自簽證書 server.crt:openssl x509 -req -in server.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out server.crt -days 500 -sha256 -extfile v3.ext

上面這個過程需要不斷重複回答同樣的問題,很煩。可以用配置文件來一次性產生:

先構建一個ssl.cnf文件:

  [req]
  prompt = no
  default_bits = 4096
  default_md = sha256
  distinguished_name = dn
  x509_extensions = v3_req
  [dn]
  C=CN
  ST=GuangDong
  L=ShenZhen
  O=Bayakala
  OU=POS
  CN=www.bayakala.com
  emailAddress=admin@localhost
  [v3_req]
  keyUsage=keyEncipherment, dataEncipherment
  extendedKeyUsage=serverAuth
  subjectAltName=@alt_names
  [alt_names]
  DNS.1 = localhost
  IP.1 = "192.168.11.189"  
  IP.5 = "192.168.0.189"
  IP.2 = "132.232.229.60"
  IP.3 = "118.24.165.225"
  IP.4 = "129.28.108.238"

然後:openssl req -new -newkey rsa:2048 -sha1 -days 3650 -nodes -x509 -keyout server.key -out server.crt -config ssl.cnf

一個指令同時產生需要的server.crt,server.key。

除aubjectAltName外還要關注CN這個字段,它就是我們經常會遇到系統提問:你確定信任“域名”嗎?中這個域名,也就是對外界開放的一個使用了数字證書的域名。

把crt,key抄寫到main/resources目錄下,然後在gRPC服務器配置證書:

trait gRPCServer { val serverCrtFile = new File(getClass.getClassLoader.getResource("server.crt").getPath) val serverKeyFile = new File(getClass.getClassLoader.getResource("server.key").getPath) def runServer(service: ServerServiceDefinition): Unit = { val server = NettyServerBuilder .forPort(50051) .addService(service) .useTransportSecurity(serverCrtFile,serverKeyFile) .build .start // make sure our server is stopped when jvm is shut down
    Runtime.getRuntime.addShutdownHook(new Thread() { override def run(): Unit = { server.shutdown() server.awaitTermination() } }) } }

啟動gRPC服務,運作正常。在看看客戶端代碼:

    val clientCrtFile = new File(getClass.getClassLoader.getResource("server.crt").getPath)
 //或者   val clientCrtFile = new File(getClass.getClassLoader.getResource("rootCA.pem").getPath)

//這樣也行 val clientCrtFile: InputStream = getClass.getClassLoader.getResourceAsStream("rootCA.pem")

    val sslContextBuilder = GrpcSslContexts.forClient().trustManager(clientCrtFile)

    //build connection channel
    val channel = NettyChannelBuilder
      .forAddress("192.168.11.189",50051)
      .negotiationType(NegotiationType.TLS)
      .sslContext(sslContextBuilder.build())
//      .overrideAuthority("192.168.1.3")
      .build()

測試連接,gRPC SSL/TLS成功!

現在開始了解一下https證書的配置使用方法吧。看了一下akka-http關於server端HTTPS設置的例子,證書是嵌在HttpsConnectionContext類型裏面的。還有就是akka-http使用的https證書格式只支持pkcs12,所以需要把上面用openssl產生的自簽名證書server.crt轉成server.p12。這個轉換又需要先產生證書鏈certificate-chain chain.pem:

1)產生certificate-chain:  cat server.crt rootCA.crt > chain.pem

2) server.crt轉換成server.p12: openssl pkcs12 -export -name servercrt -in chain.pem -inkey server.key -out server.p12

https server 測試代碼:

//#imports
import java.io.InputStream import java.security.{ SecureRandom, KeyStore } import javax.net.ssl.{ SSLContext, TrustManagerFactory, KeyManagerFactory } import akka.actor.ActorSystem import akka.http.scaladsl.server.{ Route, Directives } import akka.http.scaladsl.{ ConnectionContext, HttpsConnectionContext, Http } import akka.stream.ActorMaterializer import akka.http.scaladsl.Http import akka.http.scaladsl.server.Directives._ //#imports


object HttpsDemo extends App { implicit val httpSys = ActorSystem("httpSystem") implicit val httpMat = ActorMaterializer() implicit val httpEC = httpSys.dispatcher val password: Array[Char] = "123456".toCharArray // do not store passwords in code, read them from somewhere safe!
 val ks: KeyStore = KeyStore.getInstance("PKCS12") val keystore: InputStream = getClass.getClassLoader.getResourceAsStream("server.p12") ks.load(keystore, password) val keyManagerFactory: KeyManagerFactory = KeyManagerFactory.getInstance("SunX509") keyManagerFactory.init(ks, password) val tmf: TrustManagerFactory = TrustManagerFactory.getInstance("SunX509") tmf.init(ks) val sslContext: SSLContext = SSLContext.getInstance("TLS") sslContext.init(keyManagerFactory.getKeyManagers, tmf.getTrustManagers, new SecureRandom) val https: HttpsConnectionContext = ConnectionContext.https(sslContext) val route = get { complete("Hello world!") } val (port, host) = (50081,"192.168.11.189") val bindingFuture = Http().bindAndHandle(route,host,port,connectionContext = https) println(s"Https Server running at $host $port. Press any key to exit ...") scala.io.StdIn.readLine() bindingFuture.flatMap(_.unbind()) .onComplete(_ => httpSys.terminate()) }

用safari連接https://192.168.11.189:50081/, 彈出窗口一堆廢話后還是成功連接上了。

 

【精選推薦文章】

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

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

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

SpringBoot啟動流程分析(一):SpringApplication類初始化過程

SpringBoot系列文章簡介

SpringBoot源碼閱讀輔助篇:

  Spring IoC容器與應用上下文的設計與實現

SpringBoot啟動流程源碼分析:

  1. SpringBoot啟動流程分析(一):SpringApplication類初始化過程
  2. SpringBoot啟動流程分析(二):SpringApplication的run方法
  3. SpringBoot啟動流程分析(三):SpringApplication的run方法之prepareContext()方法
  4. SpringBoot啟動流程分析(四):IoC容器的初始化過程
  5. SpringBoot啟動流程分析(五):SpringBoot自動裝配原理實現
  6. SpringBoot啟動流程分析(六):IoC容器依賴注入

筆者註釋版Spring Framework與SpringBoot源碼git傳送門:請不要吝嗇小星星

  1. spring-framework-5.0.8.RELEASE
  2. SpringBoot-2.0.4.RELEASE

一、SpringApplication初始化過程

  1.1、SpringBoot項目的mian函數

  常規的這個主類如下圖所示,我們一般會這樣去寫。

 

  在這個類中需要關注的是

  • @SpringBootApplication
  • SpringApplication.run()

  關於 @SpringBootApplication 註解,在後面分析SpringBoot自動裝配的章節會展開去分析。

  本章節中我們需要關注的就是 SpringApplication.run() 方法。

  查看run()方法的實現,如下面代碼所示,我們發現其實其首先是創建了 SpringApplication 的實例,然後調用了 SpringApplication 的run()方法,那本章我們關注的就是 SpringApplication 創建實例的過程。

/**
     * Static helper that can be used to run a {@link SpringApplication} from the
     * specified sources using default settings and user supplied arguments.
     *
     * @param primarySources the primary sources to load
     * @param args           the application arguments (usually passed from a Java main method)
     * @return the running {@link ApplicationContext}
     */
    public static ConfigurableApplicationContext run(Class<?>[] primarySources,
                                                     String[] args) {
        return new SpringApplication(primarySources).run(args);
    }

   

  1.2、 SpringApplication() 構造方法

  繼續查看源碼, SpringApplication 實例化過程,首先是進入但參數的構造方法,最終回來到兩個參數的構造方法。

 1 public SpringApplication(Class<?>... primarySources) {
 2     this(null, primarySources);
 3 }
 4 
 5 @SuppressWarnings({"unchecked", "rawtypes"})
 6 public SpringApplication(ResourceLoader resourceLoader, Class<?>... primarySources) {
 7     this.resourceLoader = resourceLoader;
 8     Assert.notNull(primarySources, "PrimarySources must not be null");
 9     this.primarySources = new LinkedHashSet<>(Arrays.asList(primarySources));
10     //推斷應用類型,後面會根據類型初始化對應的環境。常用的一般都是servlet環境
11     this.webApplicationType = deduceWebApplicationType();//2.2.1
12     //初始化classpath下 META-INF/spring.factories中已配置的ApplicationContextInitializer
13     setInitializers((Collection) getSpringFactoriesInstances(ApplicationContextInitializer.class));//2.2.2
14     //初始化classpath下所有已配置的 ApplicationListener
15     setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class));//2.2.3
16     //根據調用棧,推斷出 main 方法的類名
17     this.mainApplicationClass = deduceMainApplicationClass();
18 }

 

   1.2.1、deduceWebApplicationType();該方法推斷應用的類型。 SERVLET REACTIVE NONE 

 1 //常量值
 2 private static final String[] WEB_ENVIRONMENT_CLASSES = {"javax.servlet.Servlet",
 3             "org.springframework.web.context.ConfigurableWebApplicationContext"};
 4 
 5 private static final String REACTIVE_WEB_ENVIRONMENT_CLASS = "org.springframework."
 6         + "web.reactive.DispatcherHandler";
 7 
 8 private static final String MVC_WEB_ENVIRONMENT_CLASS = "org.springframework."
 9         + "web.servlet.DispatcherServlet";
10 
11 private static final String JERSEY_WEB_ENVIRONMENT_CLASS = "org.glassfish.jersey.server.ResourceConfig";
12 
13 /**
14  * 判斷 應用的類型
15  * NONE: 應用程序不是web應用,也不應該用web服務器去啟動
16  * SERVLET: 應用程序應作為基於servlet的web應用程序運行,並應啟動嵌入式servlet web(tomcat)服務器。
17  * REACTIVE: 應用程序應作為 reactive web應用程序運行,並應啟動嵌入式 reactive web服務器。
18  * @return
19  */
20 private WebApplicationType deduceWebApplicationType() {
21     //classpath下必須存在org.springframework.web.reactive.DispatcherHandler
22     if (ClassUtils.isPresent(REACTIVE_WEB_ENVIRONMENT_CLASS, null)
23             && !ClassUtils.isPresent(MVC_WEB_ENVIRONMENT_CLASS, null)
24             && !ClassUtils.isPresent(JERSEY_WEB_ENVIRONMENT_CLASS, null)) {
25         return WebApplicationType.REACTIVE;
26     }
27     for (String className : WEB_ENVIRONMENT_CLASSES) {
28         if (!ClassUtils.isPresent(className, null)) {
29             return WebApplicationType.NONE;
30         }
31     }
32     //classpath環境下存在javax.servlet.Servlet或者org.springframework.web.context.ConfigurableWebApplicationContext
33     return WebApplicationType.SERVLET;
34 }

  返回類型是WebApplicationType的枚舉類型, WebApplicationType 有三個枚舉,三個枚舉的解釋如其中註釋

  具體的判斷邏輯如下:

  • WebApplicationType.REACTIVE  classpath下存在org.springframework.web.reactive.DispatcherHandler

  • WebApplicationType.SERVLET classpath下存在javax.servlet.Servlet或者org.springframework.web.context.ConfigurableWebApplicationContext

  • WebApplicationType.NONE 不滿足以上條件。

  

  1.2.2、 setInitializers((Collection) getSpringFactoriesInstances(ApplicationContextInitializer.class)); 

  初始化classpath下 META-INF/spring.factories中已配置的ApplicationContextInitializer。

 1 private <T> Collection<T> getSpringFactoriesInstances(Class<T> type) {
 2     return getSpringFactoriesInstances(type, new Class<?>[]{});
 3 }
 4 
 5 /**
 6  * 通過指定的classloader 從META-INF/spring.factories獲取指定的Spring的工廠實例
 7  * @param type
 8  * @param parameterTypes
 9  * @param args
10  * @param <T>
11  * @return
12  */
13 private <T> Collection<T> getSpringFactoriesInstances(Class<T> type,
14                                                       Class<?>[] parameterTypes, Object... args) {
15     ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
16     // Use names and ensure unique to protect against duplicates
17     //通過指定的classLoader從 META-INF/spring.factories 的資源文件中,
18     //讀取 key 為 type.getName() 的 value
19     Set<String> names = new LinkedHashSet<>(SpringFactoriesLoader.loadFactoryNames(type, classLoader));
20     //創建Spring工廠實例
21     List<T> instances = createSpringFactoriesInstances(type, parameterTypes,
22             classLoader, args, names);
23     //對Spring工廠實例排序(org.springframework.core.annotation.Order註解指定的順序)
24     AnnotationAwareOrderComparator.sort(instances);
25     return instances;
26 }

 

  看看 getSpringFactoriesInstances 都幹了什麼,看源碼,有一個方法很重要 loadFactoryNames() 這個方法很重要,這個方法是spring-core中提供的從META-INF/spring.factories中獲取指定的類(key)的同一入口方法。

在這裏,獲取的是key為 org.springframework.context.ApplicationContextInitializer 的類。

  debug看看都獲取到了哪些

 

  上面說了,是從classpath下 META-INF/spring.factories中獲取,我們驗證一下:

  發現在上圖所示的兩個工程中找到了debug中看到的6條結果。 ApplicationContextInitializer 是Spring框架的類, 這個類的主要目的就是在   ConfigurableApplicationContext 調用refresh()方法之前,回調這個類的initialize方法。通過  ConfigurableApplicationContext 的實例獲取容器的環境Environment,從而實現對配置文件的修改完善等工作。

  關於怎麼實現自定義的 ApplicationContextInitializer 請看我的另一篇專門介紹該類的博客。

 

  1.2.3、 setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class)); 

  初始化classpath下 META-INF/spring.factories中已配置的 ApplicationListener。

   ApplicationListener 的加載過程和上面的 ApplicationContextInitializer 類的加載過程是一樣的。不多說了,至於 ApplicationListener 是spring的事件監聽器,典型的觀察者模式,通過 ApplicationEvent 類和 ApplicationListener 接口,可以實現對spring容器全生命周期的監聽,當然也可以自定義監聽事件。為了梳理springboot的啟動流程在這裏先不說這個了。後面有時間的話再介紹。

   關於ApplicationContextInitializer的詳細介紹請看<SpringBoot之ApplicationContextInitializer的理解和使用>

 二、總結

  關於 SpringApplication 類的構造過程,到這裏我們就梳理完了。縱觀 SpringApplication 類的實例化過程,我們可以看到,合理的利用該類,我們能在spring容器創建之前做一些預備工作,和定製化的需求。

比如,自定義SpringBoot的Banner,比如自定義事件監聽器,再比如在容器refresh之前通過自定義 ApplicationContextInitializer 修改配置一些配置或者獲取指定的bean都是可以的。。。

  下一節開始分析SpringBoot容器的構建過程,也就是那個大家多少都看過的run();方法。

   

  原創不易,轉載請註明出處。

  如有錯誤的地方還請留言指正。

【精選推薦文章】

智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

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

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

廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

如何從現在開始寫博客?

  • 《構建之法》讀書筆記四-關於寫博客的想法

  在前不久知名博主《純潔的微笑》在博客園分享了他寫博客的心得,獲得了讀者圈的廣泛共鳴,同時也引起了一些老生常談的爭議,這樣的討論在我們長沙.NET技術社區內部也經常發生。

1、寫博客的好處

  在《軟技能·代碼之外的生存指南》這本書中,作者提到作為軟件開發人員,最好的推銷自己的媒介就是博客,他認為每個在乎自己職業生涯的軟件開發人員都應該建立一個博客,他把他職業生涯的大部分成功都歸功於他的博客。

  在我之前寫過的一篇博客中,介紹了長沙.NET技術社區的優秀開發者,全棧工程師《ASP.NET企業級開發實戰》的作者鄒瓊俊老師的成長經歷,在他大學畢業後去找工作屢屢碰壁時,有幸加入了由長沙社區組織者周尹老師開設的學習班,並向老師請教如何才能提高自己的技能時,老師告訴他,你去寫博客,堅持寫博客,堅持五年,一定能獲得成功。果不其然,他筆耕不輟、堅持學習和記錄自己發現的問題,並成為了一位出版了兩本開發技能書籍的暢銷書作者。

  除了他之外,還有我在博客園結識的Java全棧工程師,《Web全棧開發進階之路》的作者,沉默王二,也是一位愛好寫博客的人,多年前他在蘇州的日企工作,偶爾會做一些筆記,但自從回到小城洛陽之後,就開始瘋狂的學習技術和寫博客,多年的堅持沒有白費,終於得以打造這本優秀的Java開發者們值得擁有的寶貴書籍。

  在技術社區有一次的閑談中,有人說起一個故事,說他以前有一次和他的同學一起去面試一份工作,然後面試官問你覺得你平時有什麼比較好的學習習慣么?他說基本上回家之後就是看看書,玩玩遊戲什麼的。而他的同學卻說:回家之後會看看書,逛逛博客園、寫寫博客。於是毫無疑問,他的同學得到了面試官的青睞並獲得了這份Offer。或許他的同學以前並沒有寫博客,但是相信得到這份Offer之後,他一定會開始寫博客、並培養自己寫博客的習慣的。

  在《軟技能》這本書裏面也說了,他去給軟件開發人員做演講,每當他問開發者有多少位開了博客並每周更新的請举手時,一百個開發者,頂多只有一位举手。他認為,堅持寫博客、持之以恆的撰寫優質內容,能讓你輕鬆在開發者中脫穎而出。

2、不要給自己太大的壓力、從小問題開始記錄

  許多人說曾經開過博客賬戶,甚至心血來潮使用wordpress\hexo等博客平台搭建過自己的博客網站,但是最終都無疾而終了,主要原因是不知道寫什麼內容,以及擔心自己寫的內容會被人吐槽說質量不好、自己忙於工作,根本沒有時間寫博客等。

  有時候開發者總是會給自己過大的壓力,其實這樣的壓力毫無必要,坦率而言,在大部分技術網站中活躍的優秀開發者,他們剛剛參加工作時,並非每個人都是學霸、一開始就能寫出優秀的博客,他們善於發現和記錄在工作中自己發現的一些點,並持之以恆,最終讓他們脫穎而出。

  每一位開發者本質上沒有那麼大的區別,並不是所有的開發者都有機會經歷大併發等互聯網的牛逼場景,但是我們總有機會發現或親歷一些只有自己才能看到的場景。在開發者這個包容心最強的社會群體中,只要你勇於寫下自己的博客,一定會獲得其他開發者的認同。(當然,有一些網絡噴子,請不要在意他們的說法)

  例如,我個人認為,我們可以這樣嘗試。

  1、不要擔心自己的文筆不夠好、不要過度在意別人的看法,只要寫博客,讓自己滿意,就是一個開端。

  2、學會記錄,形成素材。想到什麼,就記錄什麼,提前頭腦風暴出不同的想法,隨時更新在自己筆記中記錄的點子、並適當的進行擴展,就是一個非常不錯的話題。

  3、無需花費太多時間,每天花半個小時思考和總結問題,一周就有3個半小時,足夠寫出一篇千字以內的總結了。

  4、通過博客與其他人進行討論。如果遇到想不明白的問題,還可以通過博客的形式,分享出來,邀請大家進行討論,這樣的過程簡直不要太開心。

  在《構建之法》這本書中,將寫博客當成是開發者形成良好習慣的開始,並稱之為“做中學”,我們也可以在edu.cnblogs.com這個站點中,看到許多年輕的未來開發者們,他們通過博客園這個平台,將自己軟件工程學習過程中的問題、解決問題的方法和經驗分享出來,不同學校間還可以互相交流,形成了一個非常積極活躍的技術氛圍,我覺得這是一種令人愉悅的體驗。

  當然,我也很遺憾在我讀書的那些年沒有機會體驗這樣的機會,以至於走了一些彎路,到今天我的博客依然寫得比較少,所以這篇博客其實也是寫給自己的一種警醒,提醒自己應該堅持寫博客,不管年紀多大,只要今天開始堅持,堅持五年,總能取得不錯的成功,雖然不一定能像其他人一樣成功,但至少會比今天的自己成功。

3、寫博客的原則

  我曾經針對寫博客的問題,有幸請教過《構建之法》的作者鄒欣老師,我說我最近也寫了一些博客,但是總感覺都是一些毫無乾貨,讀起來感覺沒什麼意思,請問如何才能寫出有乾貨的內容呢?

  • 老師回答:說清楚一個具體問題,解決一個具體問題。

  這是一個充滿哲理的回答,讓我茅塞頓開。寫博客不是寫小說,不用長篇大論,不用引經據典,不用引用華麗的詞藻,只需講清楚一個問題即可。再簡單的問題,也是一個問題,每個人的理解都不一定相同,只需用鍵盤敲下你的理解,就可以成為一篇博客。

 

  在閱讀《浪潮之巔》第二卷的過程中,我看到了一樁關於博客的軼事,說甲骨文收購了Sun公司之後,甲骨文老闆 Ellison這樣吐槽:

  “Sun的工程師團隊是如此優秀,但是他們獲得的指引方向卻異常糟糕,這是導致他們無法成功的原因。花哨的博客並不能取代優秀的微處理器,也不能取代任何軟件,博客文章多頁無法帶來好的銷售業績。”

  Sun是一家曾經是一家優秀的互聯網公司,開創的許多領域時至今日依然讓開發者們收益,但是為什麼十年前卻突然死亡,最終賣身給Oracle?在《浪潮之巔》中有比較深入的闡述,而在Sun破產之前, Schwartz這位Sun的末代領袖,卻試圖通過博客來治理這麼大的公司,經常使用十餘種語言寫博客,實在是一位有意思的商界領袖。(還有那位喜好用推特治國的川普,也挺有意思的,嗯,川普和Schwartz應該是筆友。)

  ps:我是一位.NET開發者,在過去十年間,大概.NET是受Java衝擊最嚴重的開發技術吧,但是創造出Java如此優秀語言的Sun公司,究竟是什麼原因讓他被歷史的浪潮打翻的?真的只是因為CEO愛寫博客嗎?這是一個很有意思的故事,大家也可以去《浪潮之巔》中看看,正好《浪潮之巔》第四版新書也上市了,我已經買了一套了。哈哈。

【精選推薦文章】

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

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

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

上周熱點回顧(6.17-6.23)

熱點隨筆:

· 升維打擊,設計之道(Artech)
· 藉助FreeHttp為任意移動端web網頁添加vConsole調試(lulianqi15)
· 你為什麼有那麼多時間寫博客?(純潔的微笑)
· 看完此文,媽媽還會擔心你docker入不了門?(sullivan06)
· 我和 HelloGitHub(削微寒)
· 簡歷上如果出現過於高大上的項目,反而過猶不及:再論如何通過項目引出技術(hsm_computer)
· 程序員與醫生(道友留步`)
· 一個理想主義的程序員(沉默王二)
· 高考完?入門級的開源項目帶你開啟編程之旅(削微寒)
· 短信驗證碼“最佳實踐”(GUOKUN)
· .NET CORE下最快比較兩個文件內容是否相同的方法(WAKU)
· 從CLR GC到CoreCLR GC看.NET Core對雲原生的支持(艾心❤)

熱點新聞:

· “地震波還有61秒到達”,08年籌建的技術,在這次四川地震中立功了
· 微軟,奪回王位
· 我們從未見過它的真面目,直到一群科學家拍了張照片
· 華為自研SSD揭秘:國內唯一殺入全球TOP10
· 無需固態電池,一條假魚靠“血液”續航36小時
· 5G來了,需要更換SIM卡嗎?
· 屠呦呦團隊放“大招”:“青蒿素抗藥性”等研究獲新進展
· 羅永浩再談收購蘋果:還需要一點時間
· 國產最先進X86處理器KX-6000發布:8核3.0GHz 力壓酷睿i5
· 美國欲剝奪華為在美專利權,涉及至少 3195 件專利
· 四川發生強震 成都提前61秒收到預警
· 聯想 ThinkPad P 系列筆記本預裝 Ubuntu 系統

【精選推薦文章】

智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

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

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

廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

[WPF自定義控件庫]排序、篩選以及高亮

1. 如何讓列表的內容更容易查找

假設有這麼一個列表(數據源在本地),由於內容太多,要查找到其中某個想要的數據會比較困難。要優化這個列表,無非就是排序、篩選和高亮。

改造過的結果如上。

2. 排序

在WPF中要實現數據排序的功能有很多種,例如用Linq,但這種場景的標準做法是使用CollectionViewSource。

CollectionViewSource是一種數據集合的代理類。它有兩個很重要的屬性:

  • Source 是數據源的集合;

  • View 是經過處理后的數據視圖。

看上去感覺是不是很像數據庫里的Table和View的關係?

在這個例子里使用CollectionViewSource排序的代碼如下:

private readonly CollectionViewSource _viewSource;

public HighlightSample()
{
    InitializeComponent();
    _viewSource = new CollectionViewSource
    {
        Source = Employee.AllExecutives
    };

    _viewSource.View.Culture = new System.Globalization.CultureInfo("zh-CN");
    _viewSource.View.SortDescriptions.Add(new SortDescription(nameof(Employee.FirstName), ListSortDirection.Ascending));
    EmployeeElement.ItemsSource = _viewSource.View;
}

這段代碼為CollectionViewSource的Source賦值后,把CollectionViewSource的View作為ListBox的數據源。其中SortDescriptions用於描述View的排序方式。如果包含中文,別忘記將Culture設置為zh-cn

至此排序的功能就實現了。文檔中還提到CollectionViewSource的其它信息:

您可以將集合視圖作為綁定源集合,可用於導航和显示集合中基於排序、 篩選和分組查詢,而無需操作基礎源集合本身的所有頂層。 如果Source實現INotifyCollectionChanged接口,所做的更改引起CollectionChanged事件傳播到View。

由於View不會更改Source,因此每個Source都可以有多個關聯的View。 使用View,可以通過不同方式显示相同數據。 例如,可能希望在頁面左側显示按優先級排序的任務,而在頁面右側显示按區域分組的任務。

3. 篩選

CollectionViewSource的View屬性類型為ICollectionView接口,它提供了Filter屬性用於實現數據的過濾。在這個例子里實現如下:

_viewSource.View.Filter = (obj) => (obj as Employee).DisplayName.ToLower().Contains(FilterElement.Text);

private void OnFilterTextChanged(object sender, TextChangedEventArgs e)
{
    if (_viewSource != null)
        _viewSource.View.Refresh();
}

這段代碼實現了當輸入框的文字改變時刷新View的功能。其中Refresh方法用於重新創建View,也就是刷新視圖。

ICollectionView還提供了一個DeferRefresh函數,這個函數用於進入延遲循環,該循環可用於將更改合併到視圖並延遲自動刷新,在需要多次操作並刷新數據量大的集合時可以用這個函數。

4. 高亮

<TextBox x:Name="FilterElement"
         TextChanged="OnFilterTextChanged"/>
<ListBox Name="EmployeeElement"
         Grid.Row="1"
         Height="200"
         Margin="0,8,0,0">
    <ListBox.ItemTemplate>
        <DataTemplate>
            <StackPanel Orientation="Horizontal">
                <TextBlock Text="{Binding DisplayName}"
                           kino:TextBlockService.HighlightText="{Binding ElementName=FilterElement,Path=Text}" />
            </StackPanel>
        </DataTemplate>
    </ListBox.ItemTemplate>
</ListBox>

UWP的高亮可以使用TextHighlighter這個類,實現起來很簡單。WPF中的高亮則是使用自定義的TextBlockService.HighlightText附加屬性聲明要高亮的文字,然後將TextBlock的Text替換為處理過的Inlines,使用方式如上。

private static void MarkHighlight(TextBlock target, string highlightText)
{
    var text = target.Text;
    target.Inlines.Clear();
    if (string.IsNullOrWhiteSpace(text))
        return;

    if (string.IsNullOrWhiteSpace(highlightText))
    {
        target.Inlines.Add(new Run { Text = text });
        return;
    }

    while (text.Length > 0)
    {
        var runText = string.Empty;
        var index = text.IndexOf(highlightText, StringComparison.InvariantCultureIgnoreCase);
        if (index > 0)
        {
            runText = text.Substring(0, index);
            target.Inlines.Add(new Run { Text = runText, Foreground = _noHighlightBrush });
        }
        else if (index == 0)
        {
            runText = text.Substring(0, highlightText.Length);
            target.Inlines.Add(new Run { Text = runText });
        }
        else if (index == -1)
        {
            runText = text;
            target.Inlines.Add(new Run { Text = runText, Foreground = _noHighlightBrush });
        }

        text = text.Substring(runText.Length);
    }
}

這是實現代碼。其實用Regex.Split代碼會好看很多,但懶得改了。
本來應該是高亮匹配的文字,但實際使用中發覺把未匹配的文字置灰更好看,就這樣實現了。

5. 結語

這篇文章介紹了使用CollectionViewSource實現的排序、篩選功能,以及使用附加屬性和Inlines實現高亮功能。

不過這樣實現的高亮功能有個問題:不能定義高亮(或者低亮)的顏色,不管在代碼中還是在XAML中。一種可行的方法是參考ToolTipService定義一大堆附加屬性,例如這樣:

<TextBox x:Name="FilterElement" 
         ToolTipService.ToolTip="Filter Text"
         ToolTipService.HorizontalOffset="10"
         ToolTipService.VerticalOffset="10"
         TextChanged="OnFilterTextChanged"/>

這種方式的缺點是這一大堆附加屬性會導致代碼變得很複雜,難以維護。ToolTipService還可以創建一個ToolTip類,把這個類設置為附加屬性的值:

<TextBox x:Name="FilterElement" 
         TextChanged="OnFilterTextChanged">
    <ToolTipService.ToolTip>
        <ToolTip Content="Filter Text"
                 HorizontalOffset="10" 
                 VerticalOffset="10"/>
    </ToolTipService.ToolTip>
</TextBox>

這種方式比較容易維護,但有人可能不明白ToolTipService.ToolTip屬性的值為什麼既可以是文本(或圖片等其它內容),又可以是ToolTip類型,XAML如何識別。關於這一點我在下一篇文章會講解,並且重新實現高亮的功能以支持Style等功能。

也可以參考SearchableTextBlock寫一個高亮的文本框,一了百了,但我希望通過這個有趣的功能多介紹幾種知識。

6. 參考

CollectionViewSource Class (System.Windows.Data) Microsoft Docs

TextBlock.Inlines Property (System.Windows.Controls) Microsoft Docs

A WPF Searchable TextBlock Control with Highlighting WPF

7. 源碼

TextBlockService.cs at master

【精選推薦文章】

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

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

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

Jest — ElasticSearch Java 客戶端

1. 介紹

任何使用過Elasticsearch的人都知道,使用基於rest的搜索API構建查詢可能是單調乏味且容易出錯的。

在本教程中,我們將研究Jest,一個用於Elasticsearch的HTTP Java客戶端。Elasticsearch提供了自己原生的Java客戶端,然而 Jest提供了更流暢的API和更容易使用的接口。

2. Maven 依賴

我們需要做的第一件事是導入Jest庫到我們的POM文件中:

<dependency> <groupId>io.searchbox</groupId> <artifactId>jest</artifactId> <version>6.3.1</version> </dependency> 

Jest的版本是遵循Elasticsearch的主版本號的。
這將確保客戶端和服務端之間的兼容性。

通過包含Jest依賴項,相應的[Elasticsearch庫](https://search.maven.org/search?q=g:org.elasticsearch a:elasticsearch)將被包含為傳遞依賴項。

3. 使用Jest Client

在本節中,我們將研究如何使用Jest client執行Elasticsearch中的常見任務。

要使用Jest client,我們只需使用 JestClientFactory 創建一個 JestClient 對象。這些對象的創建開銷很高,而且是線程安全的,因此我們將創建一個可以在整個應用程序中共享的單例實例:

public JestClient jestClient() { JestClientFactory factory = new JestClientFactory(); factory.setHttpClientConfig( new HttpClientConfig.Builder("http://localhost:9200") .multiThreaded(true) .defaultMaxTotalConnectionPerRoute(2) .maxTotalConnection(10) .build()); return factory.getObject(); } 

這裏將創建一個Jest client,該客戶端連接到本地運行的Elasticsearch。雖然這個連接示例很簡單,但是Jest還完全支持代理、SSL、身份驗證,甚至節點發現。

JestClient 類是通用類,只有少數公共方法。我們將使用的一個主要方法是execute,它接受Action接口的一個實例。Jest客戶端提供了幾個構建器類來幫助創建與Elasticsearch交互的不同操作。

所有Jest調用的結果都是JestResult的一個實例。 我們可以通過調用 issucceeded 方法來檢查是否成功。對於失敗的操作,我們可以調用GetErrorMessage方法來獲取更多詳細信息:

JestResult jestResult = jestClient.execute(new Delete.Builder("1").index("employees").build()); if (jestResult.isSucceeded()) { System.out.println("Success!"); } else { System.out.println("Error: " + jestResult.getErrorMessage()); } 

3.1. 管理索引

檢查索引是否存在,我們使用IndicatesExists操作:

JestResult result = jestClient.execute(new IndicesExists.Builder("employees").build()) 

創建一個索引,我們使用CreateIndex操作:

jestClient.execute(new CreateIndex.Builder("employees").build()); 

這將創建一個具有默認設置的索引。我們可以在創建索引時覆蓋特定的設置:

Map<String, Object> settings = new HashMap<>(); settings.put("number_of_shards", 11); settings.put("number_of_replicas", 2); jestClient.execute(new CreateIndex.Builder("employees").settings(settings).build()); 

使用ModifyAliases操作創建或更改別名也很簡單:

jestClient.execute(new ModifyAliases.Builder( new AddAliasMapping.Builder("employees", "e").build()).build()); jestClient.execute(new ModifyAliases.Builder( new RemoveAliasMapping.Builder("employees", "e").build()).build()); 

3.2. 創建文檔

Jest client使用索引操作類索引或創建新文檔變得容易。Elasticsearch中的文檔只是JSON數據,有多種方法可以將JSON數據傳遞給Jest client 進行索引。

對於這個例子,讓我們使用一個虛構的僱員文檔:

{ "name": "Michael Pratt", "title": "Java Developer", "skills": ["java", "spring", "elasticsearch"], "yearsOfService": 2 } 

表示JSON文檔的第一種方法是使用Java字符串。雖然我們可以手動創建JSON字符串,但我們必須注意正確的格式、大括號和轉義引號字符。因此,更容易的方式是使用一個JSON庫(如Jackson)來構建我們的JSON結構,然後將其轉換為字符串:

ObjectMapper mapper = new ObjectMapper(); JsonNode employeeJsonNode = mapper.createObjectNode() .put("name", "Michael Pratt") .put("title", "Java Developer") .put("yearsOfService", 2) .set("skills", mapper.createArrayNode() .add("java") .add("spring") .add("elasticsearch")); jestClient.execute(new Index.Builder(employeeJsonNode.toString()).index("employees").build()); 

我們還可以使用Java Map 來表示JSON數據,並將其傳遞給索引操作:

Map<String, Object> employeeHashMap = new LinkedHashMap<>(); employeeHashMap.put("name", "Michael Pratt"); employeeHashMap.put("title", "Java Developer"); employeeHashMap.put("yearsOfService", 2); employeeHashMap.put("skills", Arrays.asList("java", "spring", "elasticsearch")); jestClient.execute(new Index.Builder(employeeHashMap).index("employees").build()); 

最後,Jest client 可以接受表示要索引的文檔的任何POJO。假設我們有一個Employee類:

public class Employee { String name; String title; List<String> skills; int yearsOfService; } 

我們可以把這個類的一個實例直接傳遞給Index builder:

Employee employee = new Employee(); employee.setName("Michael Pratt"); employee.setTitle("Java Developer"); employee.setYearsOfService(2); employee.setSkills(Arrays.asList("java", "spring", "elasticsearch")); jestClient.execute(new Index.Builder(employee).index("employees").build()); 

3.3. 讀取文檔

使用Jest client從Elasticsearch訪問文檔有兩種主要方法。首先,如果我們知道文檔ID,我們可以使用get操作直接訪問它:

jestClient.execute(new Get.Builder("employees", "17").build()); 

要訪問返回的文檔,我們必須調用其中一個getSource方法。我們可以將結果作為原始JSON獲取,或者將其反序列化為DTO:

Employee getResult = jestClient.execute(new Get.Builder("employees", "1").build()) .getSourceAsObject(Employee.class); 

訪問文檔的其他方法是使用搜索查詢,這種方式在Jest中是通過搜索操作實現的。

Jest client 支持全部的 Elasticsearch query DSL。 與索引操作一樣,查詢被表示為JSON文檔,並且有多種執行搜索的方法。

首先,我們可以傳遞一個表示搜索查詢的JSON字符串。提醒一下,我們必須確保字符串是正確轉義的,並且是有效的JSON:

String search = "{" + " \"query\": {" + " \"bool\": {" + " \"must\": [" + " { \"match\": { \"name\": \"Michael Pratt\" }}" + " ]" + " }" + " }" + "}"; jestClient.execute(new Search.Builder(search).build()); 

與上面的索引操作一樣,我們可以使用Jackson之類的庫來構建JSON查詢字符串。此外,我們還可以使用原生的Elasticsearch查詢操作API。這樣做的一個缺點是,我們的應用程序必須依賴於完整的Elasticsearch庫。

我們可以使用 getSource 方法來訪問搜索操作中匹配的文檔。然而,Jest還提供了Hit類,它包裝了匹配的文檔並提供有關結果的元數據。 使用Hit類,我們可以訪問每個結果的附加元數據:得分、路由和解釋結果,舉幾個例子:

List<SearchResult.Hit<Employee, Void>> searchResults = jestClient.execute(new Search.Builder(search).build()) .getHits(Employee.class); searchResults.forEach(hit -> { System.out.println(String.format("Document %s has score %s", hit.id, hit.score)); }); 

3.4. 更新文檔

Jest為更新文檔提供了一個簡單的Update操作:

employee.setYearOfService(3); jestClient.execute(new Update.Builder(employee).index("employees").id("1").build()); 

它接受與我們前面看到的索引操作相同的JSON表示,這使得在兩個操作之間共享代碼變得很容易。

3.5. 刪除文檔

從索引中刪除文檔是使用Delete操作完成的。它只需要索引名和文檔ID:

jestClient.execute(new Delete.Builder("17") .index("employees") .build()); 

4. 批量操作

Jest client 同樣支持批量操作。 這意味着我們可以通過同時發送多個操作來節省時間和帶寬。

使用批量操作,我們可以將任意數量的請求組合成單個調用。我們甚至可以將不同類型的請求組合在一起:

jestClient.execute(new Bulk.Builder() .defaultIndex("employees") .addAction(new Index.Builder(employeeObject1).build()) .addAction(new Index.Builder(employeeObject2).build()) .addAction(new Delete.Builder("17").build()) .build()); 

5. 異步操作

Jest client 同樣支持異步操作。 這意味着我們可以使用非阻塞I/O執行上述任何操作。

要異步調用操作,只需使用客戶端的executeAsync方法:

jestClient.executeAsync( new Index.Builder(employeeObject1).build(), new JestResultHandler<JestResult>() { @Override public void completed(JestResult result) { // handle result } @Override public void failed(Exception ex) { // handle exception } }); 

注意,除了(本例中是索引)操作之外,異步流還需要一個JestResultHandler。當操作完成時,Jest client 將調用該對象。該接口有兩個方法—完成和失敗—分別允許處理操作的成功或失敗。

6. 結論

在本教程中,我們簡要介紹了Jest client,一個用於Elasticsearch的RESTful Java客戶端。雖然我們只介紹了它的一小部分功能,但很明顯Jest是一個健壯的Elasticsearch客戶端。它的流暢的構建器類和RESTful接口使其易於學習,並且它對Elasticsearch接口的完全支持使其成為原生客戶端的一個有力的替代方案。

和往常一樣,本教程中的所有代碼示例都在我們的Github頁面上。

原文:https://www.baeldung.com/elasticsearch-jest

作者:Michael Pratt

譯者:huowolf/

【精選推薦文章】

智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

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

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

廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益