python2安装

安装python2

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
linux上编译安装python2.7.5
1. 下载python2.7.5,保存到 /data/qtongmon/software
http://www.python.org/ftp/python/
2. 解压文件
tar xvf Python-2.7.5.tar.bz2
3. 创建安装目录
mkdir /usr/local/python27
4. 安装python
./configure --prefix=/usr/local/python27
make
make install
5. 修改老版本的ln指向(注意:这里修改后,可能会影响yum的使用)
mv /usr/bin/python /usr/bin/python2.4.3
ln -s /usr/local/python27/bin/python /usr/bin/python
参考:
http://www.cnblogs.com/yuechaotian/archive/2013/06/03/3115482.html

安装pip及相关包

1
2
3
4
5
官方:
https://pypi.python.org/pypi/pip
参考:
http://blog.csdn.net/my2010sam/article/details/18315687

python3安装

安装python35

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
linux上编译安装python3.5
1、CentOS6.5 安装Python 的依赖包
yum groupinstall "Development tools"
yum install zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gdbm-devel db4-devel libpcap-devel xz-devel
2、下载Python3.5的源码包并编译
wget https://www.python.org/ftp/python/3.5.0/Python-3.5.0.tgz
tar xf Python-3.5.0.tgz
cd Python-3.5.0
./configure --prefix=/usr/local --enable-shared
make
make install
ln –s /usr/local/bin/python3 /usr/bin/python3
3、在运行Python之前需要配置库:
echo /usr/local/lib >> /etc/ld.so.conf.d/local.conf
ldconfig
4、运行演示:
python3 --version
Python 3.5.0
5、删除编译Python时所需要的库
yum groupremove "Development tools" --remove-leaveas
yum remove zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gdbm-devel db4-devel libpcap-devel xz-devel --remove-leaves
6、设置别名方便使用
alias py=python3
7、CentOS 安装easy_install、pip的方法
CentOS 安装easy_install的方法:
wget -q http://peak.telecommunity.com/dist/ez_setup.py
python ez_setup.py
8、CentOS安装python包管理安装工具pip的方法如下:
wget --no-check-certificate https://github.com/pypa/pip/archive/1.5.5.tar.gz
注意:wget获取https的时候要加上:--no-check-certificate
tar zvxf 1.5.5 #解压文件
cd pip-1.5.5/
python3 setup.py install
OK,这样就安装好pip了,
下面来安装 requests吧。
pip3 install requests
参考:
http://blog.csdn.net/shaobingj126/article/details/50290359

问题

1
2
3
4
5
6
1.Python3.5 installation fails: cannot open libpython3.5m.so.1.0
export LD_LIBRARY_PATH=/usr/lib/
http://stackoverflow.com/questions/38256696/python3-5-installation-fails-cannot-open-libpython3-5m-so-1-0

系统(功能)设计的一些思考——方法篇

  • 说明:本文讨论的系统设计侧重于需求已经明确下的系统功能设计。

上一篇文章,我根据系统设计的实践,列举了系统设计过程中存在的一些问题。众所周知,在工业生产中,采用成熟的方法制造产品一般来说质量会更可靠。系统设计到了现在也与工业生产类似,采用成熟规则的设计方法才能保证系统的质量,避免跟着感觉走所带来的风险。我一直相信做任何事情之前一定要有方法论,根据方法论来做事,事情做成的可能性才更高。

这里我抛砖引玉,简述我所习得的系统设计的方法,一起探讨有什么好的办法能够提高系统设计质量。

一般来说系统设计过程可以分为以下5个过程。

1. 列举场景


拿到一个设计需求,我们首先应该要列举所有用例,并且根据业务需求重要性进行排序,最终确认最核心的1-2个CASE。

1
2
3
4
5
6
7
8
9
10
以音乐电台为例,列举其用例:
注册/登陆
播放音乐
音乐推荐
通过对业务进行分析不难得出,播放音乐是其最核心的需求,
对播放音乐需求进行拆分,播放音乐步骤如下:
获取频道列表
选择频道
播放音乐

2. 分析限制条件


限制条件主要是指一些非功能需求的约束,比如说用户量,日活跃用户量,性能要求等。

对于限制条件的分析,我们需要评估它对系统功能的影响。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
接上面的例子,我们首先需要了解需求的一些关键信息,然后据此来进行评估。
假定电台的日活跃用户为100,000
那我们据此就可以进行 用户量,流量,内存使用量的评估
用户量:
并发用户量:100,000/5 = 20,000
峰值用户量:20,000 * 3 = 60,000
一段时间后峰值用户:60,000*10 = 600,000
流量:
每个用户请求播放音乐量:1首/分钟
音乐平均大小:3MB
峰值流量:600,000 * 3MB/60 = 30GB每秒
内存:
每个用户内存量:10KB
每日最大内存量:100,000 * 10 * 10 = 10GB

3. 应用服务设计


应用服务设计主要方法是根据用例,进行服务的概要设计,并对服务进行整合。

1
2
3
4
5
6
接上例
注册/登陆,播放音乐,音乐推荐这3个用例,
我们可以需要设计3个不同的服务。
分别叫User Service, Channel Service, Music Sevice,
同时我们对服务进行整合,提供一个接待/代理的服务,对用户的请求进行路由,过滤等。

4. 设计数据结构与存储


根据应用服务设计进行数据存储与结构的设计。此阶段主要对数据存储进行选择与明细,同时具体设计数据存储结构。

1
2
3
4
5
6
7
接上例子
User Service由于存储的是用户信息,需要持久保持,更新、修改比较频繁且强调一致性,原子性,
所以我们选用关系型数据库Mysql存储。
Channel Service 对一致性的要求没有那么高,且经常需要查询读取,
我们考虑用No-sql数据库如MongoDB进行存储。
Music Service存储的是音乐的文件数据,我们直接用文件系统进行存储即可。

5. 扩展优化


扩展优化主要是根据业务的发展需求,在系统设计质量,广度,深度三个方面进行扩展。

质量主要提现在更好的性能等,在用户更多,或者文件更大的情况下,通过设计保证性能

广度体现在更多的功能需求需要进行满足

深度体现在更加复杂的业务逻辑进行处理

根据设计与需求进行评估,重复上面的步骤达到扩展优化的目标。

系统(功能)设计的一些思考——问题篇

  • 说明:本文讨论的系统设计侧重于需求已经明确下的系统功能设计。

1. 系统设计概述


按照百度百科的定义,系统设计是新系统的物理设计阶段,是指按照需求分析阶段输出的系统功能需求、逻辑模型,在用户环境条件下设计出一个可以实施的方案。

根据一般的业务实践,系统设计的过程中需要定义系统架构、组件、模块、接口和数据来满足特定需求。其中所指的系统架构主要是指系统的技术架构,是广义上所讲的架构中一个部分,关于架构的内容在这里就不展开了。

概括一下,系统设计处于需要分析与系统开发阶段中间,是连接两者的纽带,关系到需求的满足与实施。通常来讲,好的设计需要满足,分阶段开发、易用性、可扩展性、业务完整性、业务规范性等原则。

2. 系统设计产出


系统设计有这么丰富的内容,也需要有相应的产出,用于指导系统开发过程。通常来讲,产出主要包括系统概要设计和系统详细设计二部分的内容,有时候我们也会合二为一。

3.系统设计实践


系统设计需要有这么多的产出,那我们通过怎样来获得这些产出呢,又是如何来确认这些产出是合适的呢。根据笔者的不算丰富的工作经验(主要在业务系统领域),对大多数程序研发人员来说,我们会根据公司的要求的产出物进行交付,简单点说就是公司QA或者领导要求有什么产出,我们就给出相应的东西,通常是文档。实际上写文档的过程就是一个思考设计的过程,但每个人可能是根据自己的经验、习惯以及对需求的认知来进行设计。

我们仔细想一想,上面这种模式下,存在哪些问题?这里我大致列举了几点:

1
2
3
4
1)根据设计人员本身的经验,产出交付物质量参差不齐,影响开发
2)依赖公司QA或者领导对于交付物的定义,目的不是为了用于开发,而是交差
3)每个人甚至每次的设计方法都不一样,容易有所遗漏,影响交付
4)对于一些业务上看似简单的部分,通常会忽略设计,往往会出现问题

以上几点,都会影响系统设计结果好坏。系统研发实践表明,在整个系统生命周期中,越到后期纠偏改动的成本越高。系统设计相对来说处于整个生命周期的早期,提高系统设计质量具有重大的意义。

那么有没有什么办法能够提高系统设计质量,是否系统设计质只量能依赖设计人员的经验与能力呢?

git flow应用规范说明

git flow应用规范说明

我们前段时间从SVN切换到Git,经过培训与一段时间的使用,大家对git的基本使用比较熟悉,但对git flow还是不太熟练。下面就简单介绍一下各分支意义,以及开发过程中的应用场景。

常用分支(流程默认)

  • Master 分支(Production)

    最近发布到生产环境的代码,最近发布的Release, 这个分支只能从其他分支合并,不能在这个分支直接修改

  • Develop 分支

    开发分支,包含所有要发布到下一个Release的代码,这个主要合并与其他分支,比如Feature分支

  • Feature 分支

    新的功能分支,开发完成后,合并回Develop分支进入下一个Release

  • Release 分支

    发布一个新Release的时,我们基于Develop分支创建一个Release分支,完成Release后,我们合并到Master和Develop分支

  • Hotfix 分支

    生产上发现新的Bug时候,我们需要创建一个Hotfix, 完成Hotfix后,我们合并回Master和Develop分支,所以Hotfix的改动会进入下一个Release

实际项目阶段应用

1. 初始项目

  • 建立Master,Develop分支。
  • Master分支为锁定状态,开发人员无权限操作。从服务器上clone之后,默认切换到Develop分支。
  • 此步由Master管理员完成。

2. 功能开发(相对独立,较大功能)

  • 开发功能时,在本地建立Feature分支,完成功能开发测试后,合并加Develop分支。
  • 此步为开发人员自行完成。

3. 生产发布(正常版本)

  • 基本完成所有功能开发,准备交付测试时。建立Release分支,在此分支上进行bug的修改与少量小功能的增加优化。
  • 到版本发布前,所有修改在此分支进行,不属于此版本的功能增加,切换回Develop分支参考第2种情况进行。
  • 版本发布后,合并分支到Develop和Master,并在Master分支打tag为release-v1.x.x
  • 合并与tag建立由Master管理员完成。

4. 生产紧急bug修复(包括紧急功能增加)

  • 从Master分支创建Hotfix分支。
  • 完成问题修改后,合并回Master和Develop分支,建议删除此分支并做tag。
  • 合并与tag建立由Master管理员完成。

参考:
git flow guide

设计模式之单例模式

设计模式之单例模式

模式介绍


单例模式,顾名思义用于保证类只有单独的实例,当然是在同一jvm与classloader前提下。

模式应用


通常最常见的单例模式应该在配置文件的读取,内存缓存的使用以及new 对象开销很大的情况。

1
2
3
4
5
6
通常,在应用中,配置文件的读取是一次性获取配置文件中所有的key/value对并放入对象中
,我们获取单独的一个配置项,从对象中通过key获取即可。
这个对象只需要一个实例就好了,
如果每次获取一个配置项都需要new 一个对象,
那所有的配置信息都会随着对象的创建加载到内存中,
这势必会导致内存的不必要开支,浪费。

模式的类图


模式的实现


单例模式的java实现一般有3种形式

  • 饿汉式
  • 懒汉式
  • 双重检查式

3种形式各有特色与优势。

  1. 饿汉式

利用static关键字与jvm的特性,在类实例化之前就已经产生类变量(final)存储类自己的对象。getInstance方法直接返回此对象即可

存在的问题:不管有没有用到对象都会被实例化,可能造成一定的浪费

1
2
3
4
5
6
7
8
9
public class IvyTower {
private IvyTower() { }
private final static IvyTower instance = new IvyTower();
public static IvyTower getInstance() {
return instance;
}
}
  1. 懒汉式

所谓懒汉其实应该叫延迟加载(lazy load)比较恰当,这种用法也经常在编码中被使用到,用于节约系统资源,只有在需要时才会被实例化。

存在问题:在并发的情况下,需要使用synchroized关键字对方法进行同步,降低了性能

1
2
3
4
5
6
7
8
9
10
11
12
13
public class ThreadSafeLazyLoadIvyTower {
private static ThreadSafeLazyLoadIvyTower instance;
private ThreadSafeLazyLoadIvyTower(){ }
public static synchronized ThreadSafeLazyLoadIvyTower getInstance() {
if(instance == null) {
instance = new ThreadSafeLazyLoadIvyTower();
}
return instance;
}
}
  1. 双重检查式

双重检查double-check,我的理解是在懒汉式的基础上进行了一些性能的改进,让整个方法不再属于同步块中,提升了一定的性能。

由于低版本JVM对于volatile关键字的实现有问题,此方法只有在jdk1.5以上版本可行

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class DoubleCheckIvyTower {
private DoubleCheckIvyTower() { }
private static volatile DoubleCheckIvyTower instance;
public static DoubleCheckIvyTower getInstance() {
DoubleCheckIvyTower result = instance;
if(result == null) {
synchronized (DoubleCheckIvyTower.class) {
result = instance;
if(result == null) {
result = instance = new DoubleCheckIvyTower();
}
}
}
return result;
}
}

模式扩展

单例模式看似简单,但其中涉及到知识点,特别是和语言相关的特性还是比较多, 需要我们仔细的去揣摩,应用,理解。

参考:
https://my.oschina.net/xianggao/blog/616385

架构设计原则概述

架构设计原则概述

什么是架构设计


  • 架构设计是连接业务需求与研发的纽带,业务的需求需要经过抽象的架构设计之后才能进行后续的研发工作。
  • 架构设计的主要职责,将业务需求转换为规范的开发计划及文本,并产生项目的总体架构,指导整个团队完成这个计划。架构设计是软件设计过程的早期阶段,它把需求分析与设计流程连接在一起。

架构设计的主要产出


  • 根据业务需求的理解,产生顶层的架构设计图

架构设计图,类比于建筑设计中的蓝图指导后续工作
架构设计图需要清晰表达架构师头脑中的清晰的设计目标

  • 优秀的架构设计是随着技术进步,需求完善逐步演进而来。

架构设计的一些原则


  • 软件项目的最终目标是要产生一个可维护的系统,架构设计就是要保障这种可维护性。

在架构设计中,着重需要考虑以下个方面:
安全性、可靠性、可维护性、易用性、可扩展性、市场因素

  • “高内聚,低耦合”是保障可维护性的重要途径,同时也是在顶层架构设计,系统模块设计,系统编码时应该遵守的原则。
  • 在顶层架构设计中,通过以下方式来保证:

1.异步解耦,降低整个系统复杂性
2.分布式服务提高内聚性与复用性
3.微服务设计降低耦合性
4.按功能划分子系统,降低子系统的复杂性,提高子系统可复用性
5.分层架构清晰,增加可维护性与可复用性
6.利用中间件技术,降低复杂性,提高复用性

|