穹灵科技

Tiff图像处理1_Python

读、写、显示Tiff图像
*近在处理Landsat的遥感影像。.tif格式的图像，与之前接触的.jpg，.png不太一样，在读写上面有更多的要求和规范。学习了好久，尤其是在显示上。由于之前并不是很懂数据类型的转换(后续已解决），在自己的电脑上怎么样都点不开，会显示：

所以经常因为，看不到图像长什么样，所以会陷入一种麻烦，不够直接，每次看还得打开ArcGIS等软件才能，太难顶了。再加上懒得整理笔记和做过的东西，走过的坑，就发奋来记录一下吧。
这一部分现在看来还是比较简单的，方便以后自己查阅，所以基本上写了很多乱七八糟的注释，就直接放代码了。

import os
import numpy as np
from PIL import Image
from osgeo import gdal
import cv2
# 不一定所有库都用上了，只是方便

# 读取tif图像的数据（只是读取数据，不是显示）
def readTiff(img_path):
dataset = gdal.Open(img_path)
if dataset == None:
print(img_path + “文件无法打开”)
return
im_width = dataset.RasterXSize # 栅格矩阵的列数
im_height = dataset.RasterYSize # 栅格矩阵的行数
im_bands = dataset.RasterCount # 波段数
band1 = dataset.GetRasterBand(1)
# print(im_bands)
# print(‘Band Type=’, gdal.GetDataTypeName(band1.DataType)) # 输出band的类型
im_data = dataset.ReadAsArray(0, 0, im_width, im_height) # 获取数据，将数据写成数组，对应栅格矩阵,前两个参数是偏移量
im_geotrans = dataset.GetGeoTransform() # 获取仿射矩阵信息
im_proj = dataset.GetProjection() # 获取地图投影信息
# print(im_data.shape)
return im_data, im_geotrans, im_proj

# 将数据写成tif格式图像保存
def writeTiff(im_data, im_geotrans, im_proj, img_path):
# 判断数据类型
if ‘int8’ in im_data.dtype.name:
datatype = gdal.GDT_Byte
elif ‘int16’ in im_data.dtype.name:
datatype = gdal.GDT_UInt16
else:
datatype = gdal.GDT_Float32
# 判断数据的波段数
if len(im_data.shape) == 3: # 三个参数，波段数，H，W
im_bands, im_height, im_width = im_data.shape
# elif len(im_data.shape) == 2: # 两个参数，一般只有灰度图，band为1，不显示，只有H,W，相当于直接是二维矩阵了
# im_data = np.array([im_data])
else:
im_bands, (im_height, im_width) = 1, im_data.shape # 同上，没有band值的返回值，就手动给band赋值
# 创建tif文件
driver = gdal.GetDriverByName(“GTiff”) # 读取某一类型的数据，需要先载入数据驱动，初始化一个对象
dataset = driver.Create(img_path, im_width, im_height, im_bands, datatype) # 在路径处创建空文件，并确定开辟多大内存；每个像素都有一个对应的值，这个值得类型用数据类型指定。这里的数据类型是gdal数据类型。
# 设置头文件信息
if (dataset != None):
dataset.SetGeoTransform(im_geotrans) # 写入仿射变换参数
dataset.SetProjection(im_proj) # 写入投影
# 写入数据体
if im_bands == 1:
dataset.GetRasterBand(1).WriteArray(im_data) # 单通道无需循环赋值
else:
for i in range(im_bands): # i从0开始，数组是从0开始，但是获取波段是从1开始
dataset.GetRasterBand(i + 1).WriteArray(im_data[i]) # 写入数组数据
# 释放内存空间
del dataset

# 使用CV2，显示tif图像
def showTiff(img_path):
img = cv2.imread(img_path,4)
# 第二个参数是通道数和位深的参数，
# IMREAD_UNCHANGED = -1 # 不进行转化，比如保存为了16位的图片，读取出来仍然为16位。
# IMREAD_GRAYSCALE = 0 # 进行转化为灰度图，比如保存为了16位的图片，读取出来为8位，类型为CV_8UC1。
# IMREAD_COLOR = 1 # 进行转化为RGB三通道图像，图像深度转为8位
# IMREAD_ANYDEPTH = 2 # 保持图像深度不变，进行转化为灰度图。
# IMREAD_ANYCOLOR = 4 # 若图像通道数小于等于3，则保持原通道数不变；若通道数大于3则只取取前三个通道。图像深度转为8位
# print(img) # 输出图像的数据
# print(img.shape) # 输出图像的三维
# print(img.dtype) # 输出图像的编码类型
# print(img.min()) # 输出图像的*小值
# print(img.max()) # 输出图像的*大值
# 创建窗口并显示图像
cv2.namedWindow(“Image”) # 创建一个窗口
cv2.imshow(“Image”, img) # 显示图像
cv2.waitKey(0) # 设置显示图像的延迟
# 释放窗口
cv2.destroyAllWindows()

使用的GDAL版本是：
GDAL-3.1.3-cp38-cp38-win_amd64.whl
在实验室的电脑上好像安装别的版本，cmd里用pip安装会报错，pycharm里install也会报错(command error)，应该是要找一个*符合的才行。下载GDAL的whl链接：
https://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal

*初接触tif图像，带地理坐标和投影信息，不是很懂。以为打不开的原因是有地理坐标和投影信息等其他参数，所以写代码去show。但其实这个show的条件是，图像本身就是能打开的。我之前使用的GID数据集，那个本来就是能直接点开的，所以用这个代码没问题。后面找到了更好的办法，就没有测试这个show的代码是否也能适用，大概率是不适用的。图像能不能在计算机中直接显示，取决于的是图像本身的数据类型，如果是uint8的类型，就是能直接双击打开的，其他比如float32或者别的，可能就会出现打不开的提示。

python编写函数的计时器（计算函数的执行时间）

python函数计时器（计算函数的执行时间）
编写一个计时器，在函数调用时，查看函数执行的时间

import time

def cal_time(func):
def wrapper(*args, **kwargs):
t1 = time.time()
result = func(*args, **kwargs)
t2 = time.time()
print(“%s running time: %s secs.” % (func.__name__, t2 – t1))
return result

return wrapper

该计时器使用方法

@cal_time
1
在要查看执行的函数前加上@cal_time语句
以冒泡排序算法为例

@cal_time
def bubble_sort(li):
for i in range(len(li) – 1): # 无序区范围
exchange = False
for j in range(len(li) – i – 1): # 箭头的范围
if li[j] < li[j + 1]:
li[j], li[j + 1] = li[j + 1], li[j]
exchange = True
if not exchange:
return

当调用被查看的函数时，即可自动输出执行时间

bubble_sort(li) # 调用冒泡排序函数

输出：当前列表li使用冒泡排序执行的时间

12 python之文件操作

12 python之文件操作
本模块讲解了:
1 获取电脑系统名称
2 获取电脑cpu个数
3 获取电脑文件的*对路径
4 os库的相关使用
4.1 创建目录
4.2 递归创建多级目录
4.3 删除目录
4.4 递归删除多级目录
4.5 文件重命名

#!/usr/bin/env python
# -*- coding:utf-8 -*-
import os
# 获取cpu的个数,cpu个数越多,运行速度越快,
# 根据cpu的个数来决定创建几个进程更加合适
count = os.cpu_count()
print(f’cpu的个数为:{count}’)

# 获取当前文件的所在路径
cwd = os.getcwd()
print(f’当前文件的所在路径为:{cwd}’)

# 获取本电脑的操作系统名称
name = os.name
print(f’此电脑的操作系统名称为:{name}’)

# 返回该文件的*对路径
result = os.path.abspath(’01 文件操作.py’)
print(result)
“””
*对路径:带盘符,例如C盘,D盘等等
相对路径:不带盘符,例如 ./表示当前目录下
“””

# 获取路径的*后一部分
result = os.path.basename(r’C:\Users\LIJIE\Desktop\联科数据\联科数据21-03-29\*周\03 第三天\01 文件操作.py’)
print(result)

# 获取路径的公共部分
result = os.path.commonpath([‘C:/a/b’,’C:/a/c’,’C:/a/d’,])
print(result)

# os对文件的相关操作
# 创建单个目录
# os.mkdir(‘新建文件夹’)
# 递归创建目录
# os.makedirs(‘111/222/333’)

# 删除目录,只能删除空目录，否则会报错
# os.rmdir(‘新建文件夹’)

# 删除已经创建的333目录(文件夹)
# os.rmdir(‘111/222/333’)

# 删除多级目录
# os.removedirs(‘111/222’)

# 文件重命名
# os.rename(‘新建文件夹’,’文件夹1′)
# 删除掉文件夹1
# os.rmdir(‘文件夹1’)

# 获取目录列表
os.listdir()

 

matplotlib条形堆积图并添加

 

 

#!/usr/bin/env python

# -*- coding: utf-8 -*-

# @Time        :2021/4/8 14:35

# @Author      :weiz

# @ProjectName :autoLabeling

# @File        :111.py

# @Description :

import matplotlib.pyplot as plt

import numpy as np

 

labels = [‘G1’, ‘G2’, ‘G3’, ‘G4’, ‘G5′]

men_means = [20, 35, 30, 35, 27]

women_means = [25, 32, 34, 20, 25]

width = 0.35  # the width of the bars: can also be len(x) sequence

fig, ax = plt.subplots(figsize=(5, 3), dpi=200)

ax.bar(labels, men_means, width, label=’Men’, color=’green’)

ax.bar(labels, women_means, width, bottom=men_means, label=’Women’, color=’red’)

ax.set_ylabel(‘Scores’)

ax.set_title(‘Scores by group and gender’)

ax.legend()

for a, b in zip(np.arange(len(labels)), men_means):

plt.text(a, b / 2, ‘%.0f’ % b, ha=’center’, va=’bottom’, fontsize=7)

 

for a, b, c in zip(np.arange(len(labels)), men_means, women_means):

plt.text(a, b + c / 2, ‘%.0f’ % c, ha=’center’, va=’bottom’, fontsize=7)

 

plt.show()

效果如下：

 

 

 

在 Android 虚拟设备上运行程序

在通过上述方法创建 Android 项目后，就可以直接运行查看效果了。

1）左键选中项目，点击“Run”的图标（红色类似播放的按钮），选择 Android Application。

2）如果还没有建立 Android 虚拟程序（AVD），并且也没有连接待调试的 Android 真机设备，那么 Eclipse 将会弹出提示错误的对话框：没有可匹配的运行目标，是否需要添加一台新的 Android 虚拟设备？选择“Yes”。

3）在 Android Virtual Device （AVD）Manager，即 AVD 管理器创建 AVD，在 Android Virtual Devices 选项卡中点击“Create”。

3）接下来对待创建的 AVD 进行配置。

• AVD Name （AVD 名称）
• Device （设备型号，包含尺寸、分辨率、机型）
• Target （目标运行平台，Android 系统版本）
• CPU/ABI （CPU 的应用程序二进制接口）
• Skin （AVD 的皮肤）
• Front Camera （前置摄像头）
• Back Camera （后置摄像头）
• Memory Options （运行内存选项）
• Internal Storage （内置存储空间）
• SD Card （SD 卡配置）
• Emulation Options （仿真器选项）

Device 一项，如果是希望在手机上模拟运行，选择“4” WVGA（Nexus S）（480 × 800: hdpi）”比较适合在电脑显示；Target 则可根据 Android SDK 所下载的平台支持来选择；CPU/ABI 首选 ARM；Skin 选择“skin with dynamic hardware controls”；Front Camera 和 Back Camera 在电脑上运行基本没有必要，选择“None”；Memory Options 的 RAM，条件允许的话选择 768 *为合适，因为在Windows上，模拟超过 768M 内存时可能在系统启动时失败，VM Heap 32；Internal Storage 和 SD Card 设定 200 和 512 就好了，点击 OK 完成创建。

参考：https://www.cnblogs.com/yangmingyu/p/6928084.html

4）创建好的 AVD 会在管理器中显示，选中新建的模拟器，点击“Start”并“Launch”。

5）Eclipse 弹出提示询问是否要在 Logcat 自动监控 ADT 时，可选择“监控并显示 logcat 视图以便显示此工作空间中优先级高于 error 的程序信息”，方便程序调试，确定后 Eclipse 控制台将会出现一个 Logcat 窗体。

5）耐心等待 AVD 启动，Android 程序自动运行，首栏显示 app 名称，并在界面布局中显示“Hello world!”，说明项目已成功运行。

参考：https://blog.csdn.net/yym373872996/article/details/50757658

遇到问题：

1、创建AVD错误 no cpu/abi system image available for this target

http://blog.sina.com.cn/s/blog_54aee4a80102vfvt.html

2、http://dl-ssl.google.com/android上不去（无法连接Google下载API）

https://blog.csdn.net/wangcheng52/article/details/72854342

3、解决 Android ：Your project contains error(s),please fix them before running your application.错误

https://yq.aliyun.com/articles/333940

Error parsing D:\sdkforas\android-sdk-windows\system-images\android-24\android-wear\x86\devices.xml

https://blog.csdn.net/yang5726685/article/details/53067319

https://www.jianshu.com/p/1652505c87b7

前言
*近在社区多次看到CMDB的分享，大多是在探讨CMDB如何建设（How）的问题，虽然如何建设的问题非常重要，但在当今人人谈云的云化时代下，究竟该建立一个什么样（What）的CMDB更为重要。

首先要说明的是，今天在这里的分享都建立在传统企业存量环境中，暂时不考虑互联网企业。这种假设的考虑主要基于两个方面：

本人相对于传统行业更为熟悉

传统企业的运维理念和组织架构设定和互联网不同，进而导致了运维工具架构、选择、以及IT标准化策略等方面的不同

CMDB发展史
我先简要回顾一下十几年来CMDB的建设历程。

2004年
我从04年开始参与国内某银行的CMDB建设，这时CMDB的典型场景是资产信息的电子化。配置信息的采集主要采用Excel导入的方式，CMDB模型需要提前预设，不具备动态扩展能力，暂且称之为CMDB1.0。

2006年
到了06年，我在某银行主导实施了国内*个基于BMC Atrium CMDB架构的CMDB项目，这时的CMDB开始侧重于与其他ITSM (IT Service Management，IT服务管理 )流程的协同以及故障、变更影响分析等诊断场景。

但由于配置数据的初始化工作仍然需要手工Excel导入，同时配置信息的更新也不及时（无法在一个变更窗口内更新完成），导致上层场景没有发挥作用。这个阶段我们称之为CMDB2.0。

2007年
从07年开始，配置自动化发现工具的引入，帮助企业*大简化了配置数据初始化工作。

2008年
紧接着，08年左右业界提出变更闭环的概念，即在变更结束后重新进行配置自动发现并更新配置信息。相比CMDB2.0阶段，配置信息更新实时性有一定程度提高。

2012年
12年一些银行开始尝试通过配置自动发现工具实现配置比对场景，尤其是灾备与生产环境配置比对，以及集群环境内任意两节点间的配置比对。

近几年
应 该说，配置自动发现工具一定程度上降低了配置数据初始化和维护的难度，但限于配置自动发现工具的技术局限，发现时间往往较长，发现的信息也存在一定盲区， 同时还需使用root等管理员账号，这些约束一定程度上影响了自动发现工具的实际使用效果。这个阶段我们称之为CMDB3.0。

云化CMDB时代
随着云计算在10年国内的兴起，大约在12年后逐步在大型企业内部落地。落地过程中，我们发现云化资源的管理是一件比CMDB管理更为棘手的事情。

为此我们帮助国内一些银行实施了云化资源管理平台，除了管理以往CMDB中常见的物理配置外，进一步丰富了LPAR、端口、HBA卡、LV、VG等逻辑配置。这个阶段我暂且称之为云化CMDB1.0。

从CMDB在国内发展的历程看，随着客户对于CMDB认知不断深化，CMDB的场景已经从传统的资产台账管理逐步演化到流程协同管理、影响分析、配置比对、云化资源管理等方面，但在CMDB的技术架构上，无论是开源产品还是商业化产品都没有一个明显的改进，发展比较缓慢。这在一定程度上也影响了CMDB场景的拓展。

为了便于大家有更为直观的认识，我整理了下表罗列了不同阶段CMDB的特点

0?wx_fmt=png

需要说明的是，云化CMDB2.0是我现阶段设定的一个目标，未来也希望通过开源的方式实现的一个项目。

CMDB建设常见问题
回顾十几年的CMDB建设，大家普遍的反映是CMDB建设很困难，下面我有必要分析一下当前CMDB建设遇到的一些常见问题。

1. 缺乏合理化、整体化的规划
需求不清晰，定义了不合理的配置广度和深度。

在大而全? 还是小而深? 方面犹豫不决：
这种决策机制在项目初期往往耗费了大量时间，但随着新技术的不断涌现，这种方式已经无法适应越来越敏捷的IT环境，我们发现一种相对静态的CMDB模型已经不能满足纳管新IT组件的要求。

如何解决？
用一种更为灵活的CMDB模型扩展机制。

采用了不正确的管控策略：
按照经典ITIL的管控和项目实施机制，配置管理规划，尤其是CMDB模型的规划往往由项目组承担，一旦规划完成后整个模型也就变得很难再进行扩展，应该说这里采用的是一种集中管控的策略。

但在实际IT运维工作中，我们发现对于CMDB使用*多的是各个二线团队，不同团队之间对于CMDB 深度和广度的要求，以及管控方式都有较大差别。

如何解决？
基于集中分布式的理念建立CMDB管控体系

2. 配置管理人员职责定义不清晰
配置经理、配置管理员、配置Owner之间职责不清晰：

按照ITIL或ISO20000中对于这三类角色的定义往往过于宽泛，没有进一步考虑实际运维人员的运维场景，以及使用的运维工具，导致职责定义和实际做事方式脱节。

如何解决？
结合运维场景、运维工具、流程角色职责，对于各角色的职责进行重定义。

角色职责和岗位的对应不明晰：

在没有ITIL以前，在企业IT部门或数据中心往往找到不到一个现成岗位对于IT配置信息进行集中管理，而是每个人各管一摊。

实施ITIL后，究竟由哪个部门的哪个岗位承担配置经理这一职责往往是*让人伤脑筋的，*后往往是赶鸭子上架。这种角色定义方式*终导致体系无法运转。

如何解决？
基于集中分布式的理念设定角色和岗位的对应关系

3. 配置管理成了IT运维的负担
这其实是CMDB在企业落地所面临的*大挑战，无法充分调动运维人员的积*性，主要体现在：

初始数据收集工作量大：
存量的配置数据往往基数很大，一般配置的量级在5000以上，考虑到云化环境的海量运维场景，这个基数还会更大。

随着分布式应用架构以及微服务架构的兴起，未来一套新应用系统上线引入新的配置项数量也无法简单通过手工输入的方式来完成。

如何解决？
借助自动化手段进行数据采集

单一的自动化配置发现工具只是一种幻想：
如前所说，约从2007年开始，业内引入了自动发现工具用以解决配置数据的初始化问题，但由于这类工具往往由某个厂商提供，导致了配置发现的局限性，企业往往也要付出较大成本。

如何解决？
建立适配多类自动化工具的CMDB架构，将企业现有的脚本、监控工具、自动化工具、云平台都转化为配置数据的提供方。

投产后由于变更频繁，数据无法保证及时准确：
以往企业一般采用变更操作驱动配置修改（人工修改、或自动化发现修改）的方式以确保配置数据的准确性，这种方式往往出现了配置信息的不一致。

如何解决？
建立基于配置基线驱动的IT环境变更（操作）架构，即建立通过配置修改事件触发变更操作的事件响应模型。
对于未来软件定义环境，这种架构是一种必然选择。

如何让人人“乐于”参与：
这里的参与主要体现在二个方面：
1）需要使用与自己相关的配置数据时，CMDB可以立即提供；
2）遇到CMDB无法提供的数据时，IT部门可自行在一定标准和约束下扩展满足本部门运维CMDB模型，支撑部门级的运维场景。

如何解决？
建立小、快、灵的CMDB架构，支撑快速扩展、快速纳管、快速交付数据。

4. 配置数据的价值无法呈现
缺乏清晰的场景定义，包括流程价值、监控价值、BSM价值、云价值等：
单一流程驱动CMDB的场景，无法让CMDB中的数据流动起来，随着时间的推移CMDB中的数据就逐渐腐败—不及时也不准确。

同时，CMDB在技术上作为一个“数据库”，要让其中的数据能够流动起来，必须明确与之匹配的运维场景。

场景是用来描述与CMDB中某些配置项交互的一组活动，满足IT部门某一方面的运维管理目标，这一目标可以被度量、跟踪、改进、可视化，与此同时，CMDB的价值也随之呈现。

如何解决？
建立基于场景驱动的CMDB解决方案集合;

缺乏有效、明确的配置数据集成策略：
如前所述，CMDB是一个逻辑上的数据库，其中的数据需要和企业现有IT环境中的多类数据源进行整合，一套行之有效的数据集成策略和ETL（数据抽取、转换、转载）工具也必不可少。

如何解决？
建立数据集成策略，引入ETL。

通过以上分析，我们回顾了CMDB的历史发展过程，以及建设过程中遇到的挑战。接下来我们看看云化环境下CMDB又将面临什么新问题。

云化时代的特点以及带来的挑战
0?wx_fmt=png

应该说动态变化是云化环境下*大的挑战，无论对于配置模型还是配置数据的更新都提出了全新要求。我们势必不能再参考现有CMDB产品架构去定义或满足云化CMDB的要求。

对于互联网或互联网业务而言，海量会是一个比较大的问题，这里的关键可能不是海量存储的问题，而是如何在海量配置信息中快速配置定位、查找和可视化。

对于传统企业而言，异构永远是首要解决的问题，针对这个特点，以往厂商提出过联邦的技术，但一直没有找到可行的落地方法。这里我尝试借助类似于ETL的机制，实现多数据源的整合。

云化CMDB应具备的典型特征和范式
下面我们进入今天讨论的第三部分：云化CMDB应具备的典型特征和范式

在云化时代，CMDB需要从原有的单一工具转变为一种企业IT服务能力，即CMDB As A Service（以下为了便于叙述，使用云化CMDB代替）。

云化CMDB：是指 CMDB消费者可以通过网络随时随地获取、维护、管理CMDB。

服务要素
如IaaS中服务要素是指IT基础架构，在云化中的服务要素包括三个层面：

配置模型：用以描述CMDB的深度和广度，在技术上体现为一组配置标签（如服务器、网络、应用等，或生产环境、测试环境等）、与配置标签相关联的配置对象、以及用于描述配置对象的属性集合。

配置模型是用以描述配置项的元数据，其描述了某一配置项应该具备的属性，以及该配置项与其他配置项之间的逻辑关系，以及与配置项相关的一组操作。

配置项：用以描述某一配置对象的具体实例。如对于Server这个配置对象，其具体的IT环境中可能表现为IBM Server01，IBM Server02，IBM Server03等服务器实例。

配置项的关联操作：这个层面是对ITIL的补充。操作用来描述某个配置项在实际特定的IT环境中允许进行的一组行为集合。

举例来说，对于IBM Server01配置项来说，可能有的操作包括启动、停止；对于比较复杂的应用系统APP 01来说，可能有的操作就包括启动、停止、重启、配置等。

如果说配置项属性是对配置项的静态描述，那么配置项操作就是对配置项的动态描述，其描述了消费者可以对当前配置项施加的动作。

上述服务要素并不能单独存在，这就像数据库管理系统中的数据一样，在没有被业务系统使用前，都只是一堆0和1组成的数据，必须放到某个特定的上下文中才具备其特定的含义。

这里说的业务系统其实说的就是场景。配置场景描述CMDB与某个具体运维活动或业务活动之间的关系，在一个场景中可能同时触发一组关联操作。

在没有JDBC或ODBC标准接口前，存放在数据库管理系统中的数据只能通过特定的数据库管理平台才能进行增、删、查、改操作，这种方式严重制约了数据库中的数据对外提供服务和消费，给业务系统的开发带来了*大的不便利性。

同理，在CMDB As A Service理念中，我们也需要通过把服务要素API化，将CMDB的服务能力真正暴露出去，以便于场景进行调用。

CMDB API与服务要素一一对应，包括三个层次：

配置模型的增、删、查、改（类似于DML）；

配置数据的增、删、查、改；配置项关系建立、移除（类似于DDL）；

配置操作的增、删、查、改；并建立配置操作与特定的IT运维自动化工具的关联（包括脚本、专业自动化运维工具、云平台、监控平台等等）；

注：其实Puppet、Chef在架构上已经采取了类似的理念，这里我们希望再往上抽象一个层次

0?wx_fmt=png

通过上述要素的组合，我给出云化CMDB的定义：

云化CMDB=模型 + 操作 + 数据 + API + 场景
云化CMDB的基本架构
下面我们进入今天分享的*后一部分内容：云化CMDB的基本架构。

0?wx_fmt=jpeg

整个云化CMDB平台自下而上分为四个层次，分别是：

系统管理层：该层为系统的使用提供了*基本的支持，包括组织、人员、角色、权限的管理。支持定义各类角色和权限的管理，有完整的角色管理和权限管理功能，权限配置支持组嵌套。并通过与外部IT管理云平台集成实现用户的统一认证功能

CMDB服务要素层：按照云化CMDB的理念，服务要素包括模型、数据和操作，与之对应的分别是模型维护、配置项维护和操作维护功能。

API层：通过封装底层CMDB服务要素层的功能要素，对外提供模型管理API、配置项管理API和操作API

场景层：场景层采用了一种可扩展的方式进行设计，CMDB ETL和配置可视化是CMDB的两个基本场景：

场景一：其中CMDB ETL主要实现对于多外部配置数据源的数据抽取、转化和处理，并将处理的结果通过API层的配置项API进行数据录入，并记录配置数据的变化，建立配置基线，并围绕基线形成基线比对等功能；

场景二：配置可视化主要针对配置数据提供一种展示（图形、声音、文字等）手段，包括配置拓扑展现（以图形化方式展现配置项间的关联关系）、配置项多维度查询、配置报表以及预警功能。

除了基本场景外，开发人员可以通过API层的功能，并结合基本场景实现自定义场景，比如在本次项目中实现架构标准配置比对功能就是一种基于配置比对功能基础上的新场景应用。

除了以上层次，平台提供了CMDB管理门户的GUI界面，便于系统管理员和配置管理相关用户对于模型、配置项进行维护、查询。

目前已经参考上述架构启动开源云化CMDB项目，并实现了模型动态扩展，模型/配置数据API、配置基线、配置比对、ETL和可视化场景，预计7月份开源*个版本。

今天就分享这些内容，请大家多多指教！谢谢大家！还有一些具体细节，今天由于时间的原因就不展开了，欢迎具体探讨。

精彩互动
Q1：云平台下运维与传统运维的*大差异包括哪个方面？从而导致运维平台进入一个新的发展时期。
A：云化环境下*大的挑战是配置信息的动态变化，以往在配置手工更新往往需要几个小时甚至几天时间，等更新后其实CMDB中已经是脏数据了。

Q2：海量配置对比的实现原理和准确性程度如何？
A：基本思路是将数据库记录级比对（传统CMDB技术实现）转变为文本级比对。比对过程中可以识别新增、修改、删除属性、配置项等信息。

Q3：如果已经有一个偏资产管理流程数据的cmdb了，那么想用这个云化cmdb思路落地是不是只能重构了？
A：是。

Q4：配置主动发现这个*重要。怎么去区分逻辑属性，物理属性，动态属性，静态属性，关联配置项目，怎么与资产关联？
A：应该说配置主动发现采用的是一种轮询查找机制，我希望在新的云化CMDB中采用的思路是配置事件驱动的模式进行配置更新。

比如在IaaS中，我们要申请一台VM，在申请的过程中已经收集了VM相关信息，以及安装的数据库、中间件实例等配置信息，从这个例子中我们发现变更-配置更新是一体的，也就不需要配置自动发现工具。

当然在实际环境中，我们要两者结合。配置自动发现工具也不局限于特定的如ADDM、TADDM这类工具，可以扩展到监控、脚本等工具。

Q5：cmdb etl如何解释？我知道etl但和cmdb一起完全没有概念，请解释，谢谢！
A： CMDB从本质来说就是一个数据库，我们要解决的是如何允许多个外部数据源同时录入配置数据，那么数据源之间会出现冲突，这就需要一个合理的技术去解决。

ETL其实在数仓里应用多年，我们完全可以借鉴过来加以利用。这个方案在三个大行已经得到了应用。当时我们用的是Kettl。

Q6:怎么区分模型还是场景？
A：模型其实简单说就是数据库的表结构，场景其实就是使用数据库的应用程序。

Q7:我觉得cmdb到后面就是个aws的json格式的api接口，殊途同归，不晓得老师怎么看？
A：这个问题比较有意思，从接口的发展趋势看，类似于RestFul的API目前已经是事实标准，在云化CMDB中所有API也将通过这种方式提供。

Q8：例如不管是阿里云还是aws，所有的运维活动都是围绕资源天然集成，似乎已经失去了传统环境下配置驱动流程的意义了？
A：这个是个好问题。一个非常有意思的是无论是AWS、还是Openstack都没有集中存放配置的管理组件。

前不久，AWS发布了AWSConfig，这个组件其实就是负责AWS上所有配置信息的集中管理，并已经和20多个软件厂商实现了整合，同时我们Netflix上也看到了类似的项目。

所以，答案已经比较明显了，配置管理的这类需求还很普遍。

Q9：在云环境下，资源都是服务，运维服务和资源服务天然的联动集成，我个人感觉云环境下cmdb的功能更多是一个ci全景的可视查询，还有其他场景吗？
A：可视查询是从配置消费角度看到的一个典型场景，从配置提供的角度看，由于云化环境涉及了计算、网络、存储虚拟化，以及大量自动化运维工具，因此比较复杂的是配置数据提供场景。例如，如何在一个VM的交付过程中，实时的更新配置信息。

Q10：cmdb在建设初期怎么发挥价值？或者说，如何在运维工作中发挥更大作用，而不只是一个电子台帐？
A：

建立场景驱动理念，确保配置数据有人去使用；

通过技术手段提升配置数据的自动化率，确保CI项中的属性*大多数都能被某种自动化工具覆盖。

Q11：请问下CMDB里的数据准确性是怎么保证的？
A：非云化环境，一般通过事后审计的方式，识别有问题的配置项，然后进行手工修正。

云化环境，由于环境都是软件定义的，基础架构的变更和配置更新是同时发生的，理论上来说CMDB中的数据是云化环境的快照。今天分享的内容主要侧重在云化环境。

Q12:逻辑关联信息，可以定义吗？如何进行关联关系的维护？
A：这个问题涉及模型定义问题。如果你有Puppet和Chef的经验，我们就可以看到这种关系的定义。关系是一种特殊的CI属性，在设计时，必须确保可以通过自动化工具提供数据。
0?wx_fmt=png
0?wx_fmt=png
在实际项目中，我们会形成上面的两个表格。

Q13：如何将cmdb1.0和2.0合并在一起实现？自动发现配置方面有没有成型的解决方案？
A：上面只是处于表述的原因，将CMDB分为1.0和2.0，从实现角度看是可以同时考虑的。自动发现配置方面常见的商业方案有BMC ADDM和IBM TADDM，开源的暂时没有找到类似的解决方案，一般功能都比较散。

Q14:老师,你好.能讲讲你们Apache kylin主要拿来做什么吗？
A：可参考http://www.oschina.net/p/kylin-olap

2016年12月13日，优维科技与亚马逊AWS将逐一为您解答，并向您展示传统企业上云之旅及落地思路，介绍实际案例，协助您加速企业数字化转型，进一步激发企业潜力与创新。届时，大咖齐聚，为大家带来精彩纷呈的干货分享！

在产业互联网化的今天，云计算扮演着十分重要的角色，成为传统企业启动变革的引擎。同时，为了使IT系统管理更高效，优维科技率先推出了EASYOPS，实现从产品生产到产品交付的全流程自动化闭环，全面提升企业效率。

高效管理之路

在大数据和人工智能高速发展的变革环境下，云计算作为一种资源高效和灵活的调度管理方案，快速的统治和替代了传统的硬件资源管理方案。

以DevOps为理论基础的IT体系，不但能够缓解云计算技术所带来的风险，还能将运维能力进一步向前推动，在打通IT价值链的同时进行企业应用的运营疏导，这样才能有效专业的肩负起云计算真正落地的使命。能力向前迁移，使得运维尤其是指软件应用方面的维护不得不主动进行自动化乃至“一键式”变革。业务则亟待优维科技EASYOPS那样的平台从CMDB、IT资源管理、持续交付、自动化运维、应用智能监控和IT运营分析平台等多个纬度对业务体系进行全方位管理和落实。

运维的价值
当业务面向互联网和互联网+，业务形态借助互联网渠道传递整个企业内部的业务能力，业务形态一旦跟用户距离缩短之后，整个公司业务的敏捷性和迭代性就会变得越来越快，ITIL体系无论是对互联网企业，还是对传统转型的企业，都将不适用，运维行业必须拥抱变化，走向DevOps。同时基础设施不会继续采用商业集中式架构，可能采用X86的架构，但更有可能采用基于云架构。

再者，随着微服务逐渐做大，运维行业的挑战越来越大，这里面运维的价值也就被引申出来了，不仅仅是提供服务简单的基础保障、资源交付、成本管理的能力，更多是带着服务优化的能力，怎样把IT运营能力反向作用于业务部门，让运维的作用更加凸显。

上云之旅

而现实是：诸多企业，尤其是传统型企业对互联网云计算，以及整个运维的理解，无论从理念，还是技术，还是平台化、思维的完备性上差别都非常大……

> 到底应该如何快速响应市场需求?

> 如何玩转混合云？

> 如何做到传统数据中心与私有和公共云服务之间无缝对接和管理？
————————————————

原文链接：https://blog.csdn.net/liaozhiyi6214/article/details/53462666

工程目录结构

1. Src：该目录中存放的是该项目的源代码，这个目录包含了你即将创建的Java源代码文件，这个目录里的文件是根据package结构管理的，它与普通java项目中的/src目录很相似。

2.Gen：自动生成的文件目录。该目录下的文件全部都是ADT自动生成的，一般并不需要去修改，实际上该目录下只定义了一个R.java文件，该文件相当于项目的字典，为项目中用户界面、字符串、图片等资源都会在该类中创建其惟一的ID，当项目中使用这些资源时，会通过该ID得到资源的引用。

3.Android {版本号}：这个目录包含了项目需要的库文件（Jar文件），这和普通Java项目中的/lib目录很相似。同时其中还包含项目打包时需要的META-INF目录.

4.Android Private Libraries： 所有的第三方JAR包引入都被放入了Android Private Libraries中

5.assets：资源路径，不会在R文件注册。该目录用于存放项目相关的资源文件，这个目录和res包含的xml文件差不多，也是应用中引用到的一些外部资源。但主要区别在于这些资源是以原始格式保存，且只能用编程方式读取。例如文本文件，视频文件，MP3音频等媒体文件。

6.bin：编译生成目录。二进制文件，包括class、资源文件、dex、apk等

7.res：该目录用于存放应用程序中经常使用的资源文件，其中包括图片、布局文件以及参数描述文件等，其中包括多个目录

（1)其中以drawable开头的三个文件夹用于存储.png、.9.png、.jpg等图片资源（.9.png是Android特有的图片格式，可以根据情况进行拉伸，达到不变形的效果），他们的分变率从高到低，如果你打算在android应用中包含一个图片或者图标，就应该把它们放在这个目录。

（2）layout文件夹存放的是应用程序的布局文件，这些layout是以xml形式保存的，关于layout的进一步信息，你可以参考android文档中的UI layout。

（3）raw用于存放应用程序所用到的声音等资源。raw中的文件会被映射到R.java文件中，访问的时候直接使用资源ID即R.id.filename；相比较assets文件夹下的文件不会被映射到R.java中，访问的时候需要AssetManager类。

（4）values 这个目录也包含了一些xml文件，但主要是应用中要引用的key-value对。这些XML文件声明了数组（Array）、颜色（color）、度量(Dimension)、字符串。之所以把这些东西分别放在单独的xml文件中主要是考虑到这些值能够在不更改源代码的情况下用于多语言环境。例如，根据用户语言的不同应用程序中的信息可以有多种语言版本。

8.AndroidManifest.xml：安卓清单文件 这个XML文件包含了android应用中的元信息，是每个android项目中的重要文件。在软件安装的时候被读取 ，Android中的四大组件（Activity、ContentProvider、BroadcastReceiver、Service）都需要在该文件中，以及运行这个android应用程序需要的用户权限列表，例如：电话、短信、互联网、访问SD卡，同时也详细描述了android应用的项目结构。

9. proguard-project.txt：代码混淆相关文件

10.project.properties：工程属性的配置文件，配置编译的版本等。ADT14 以后， project.properties和default.properties合并成了project.properties。供Eclipse使用，读取该项目使用Android版本号

创建 Android 工程

1）启动 Eclipse，菜单栏选择 File -> New -> Project…。

2）在 New Project 窗口的列表中找到 Android，选择 Android Application Project。

3）填写创建 Android 项目所需的基本信息。

• Application Name （Android 应用的名称）
• Project Name （在 Eclipse 中的项目名称）
• Package Name （存放 Java 类的包名称，其实质是存放的文件夹路径，“.”号为文件分隔符，编写的 Java 文件都会放在项目的 src 目录下，com.example.firstandroidapp 表示类放在 src/com/tencent/helloworld 文件夹中）
• Minimum Required SDK （应用程序所支持*低的 SDK 版本及所对应的 Android 平台版本）
• Target SDK （应用程序的目标 SDK 版本及所对应的 Android 平台版本，即测试过的*高版本）
• Compile SDK （表示在编译时的应用程序的 SDK 版本及所对应的 Android 平台版本， 这个一般为默认或者同 Target SDK）
• Theme （指定适用于该应用程序的 Android UI 风格）

输入前三项项目信息，之后选项可根据需要修改，本文操作中保持默认选项，点击 Next。

4）进行项目配置。

• Create custom launcher icon （用户自定义应用图标）
• Create Activity （创建主程序 Activity 的 Java 类）
• Mark this project as a library （将该项目作为其他项目的引用库）
• Create Project in Workspace （创建项目到 Eclipse 工作区）
• Add project to working sets （添加项目到 Eclipse 工作集）

保持默认选项，点击 Next。

5）由于在之前勾选了 Create custom launcher icon，这里需要进行应用程序的图标配置，在这里可以选择原图库的备选图标，也可以选择目标文件目录下的图片，并能对图标进行样式的调整。

保持默认选项，点击 Next。

6）由于在之前勾选了 Craete Activity，这里可以对 Activity 创建，在勾选”Craete Activity“的状态下可以选择一种界面风格进行自动创建。

保持默认选项，点击 Next。

7）接着上一步，定义 Activity 相关文件名。

• Activity Name （应用程序主界面所对应 Activity 的 Java 文件名）
• Layout Name （应用程序主界面界面布局的 xml 文件名）

保持默认配置，点击 Finish 完成工程的创建。

 

在iOS开发中，针对不同网络状况做一下测试处理是很有必要的。但是我发现还是有一些iOS开发者不太注意到不同网络环境下的调试问题，或者说不清楚如何调试这种情况。

下面我将针对真机和模拟器分别做简单的说明。告诉大家如何模拟不同的网络状况。

1.真机情况下

其实Apple在iOS系统中预置了网络调试工具，但是只有添加过测试设备，并使用XCode连接下设备才能激活.

注意中间的那行NETWORK LINK CONDITIONER

上图中的Status是表示网络限制是否开启，点击进去就可看到详细设置

可以看到系统默认配置的网络条件还是很多的，其中：

100%Loss是全丢包,

3G这个就不用说了吧

DSL是电话线上网,

Edge是2G网络，

High Latency DNS是高延迟，

Very Bad Network是网络状况不稳定。

并且底部还有一个添加额外配置的选项可以自定义网络状况。

2.模拟器

由于模拟器是在电脑上的，mac上也有和iOS设备中一样的调试工具，并且在Apple官网工具中有哦。

该工具的Apple官方地址：https://developer.apple.com/downloads/index.action?q=Network%20Link%20Conditioner#
输入搜索：Hardware IO Tools for Xcode 下载自己需要的版本就好了

打开DMG文件，里面包含了许多调试工具，其他的工具有兴趣的可以自己去看一下。这里我们只打开Network Link Conditioner.prefPane这个文件

在系统偏好中出现了工具：

打开工具，看一下。

几乎和手机一样。可以看到系统默认配置的网络条件还是很多的，其中：

100%Loss是全丢包,

3G这个就不用说了吧

DSL是电话线上网,

Edge是2G网络，

High Latency DNS是高延迟，

Very Bad Network是网络状况不稳定。