开发方案模板与Rest接口示例文档

2014/11/09 | 星期日 分类:系统架构 | 没有评论 标签: , | 作者: | 1,896 views

工作越久,愈感觉到方案文档的重要性,特别是人员流动大的公司中,在某些公司做开发工作就是帮人埋坑,自己偶尔亦挖坑~在说这话时,感觉自己挺二的(埋坑非自己所愿)。

写方案,能提高自己的语言表达能力,方案写出来条理清晰,让开发人员开得明白,可不单单是会编程那么简单:还要会,

  1. 方案需要做数据表设计;
  2. 表关系,UML图;
  3. 实施流程图;
  4. 实施步骤;

这,可花不少心思,不然怎么会有写方案的比Code拿得多呢?所以写开发方案的人,必定是一个Code人,不然写出来的东西不可用,么人看懂。(哈,其实无因果关系).

以上皆都是废话,重点在两张截图中.

——————– 废话分割线 ——————–

最近在项目中经常要写开发方案,文档,特地整理了开发方案文档,供往后项目中使用,word 文档需要上传下载,因此截图1:

方案模板

最近工作跟Rest接口比较多,既要开发又要完善接口文档,工作上由于信息安全缘故,不能发到Blog中,SO使用本博客资源 “WordPress Rest接口,获取Blog资源列表数据” 示例,在word文章中,直接贴内容样式不好控制,顾直接截图效果逼真写,请看如下截图2:.

restWordPress

Rest接口公私钥接口权限认证请查阅:Rest介绍与Rest接口权限认证概要

Rest介绍与Rest接口权限认证概要

2014/10/26 | 星期日 分类:系统架构 | 2 条评论 标签: | 作者: | 2,623 views

What is REST? 什么是REST? REST(Representational State Transfer 表述性状态转移)是一种轻量级的Web Service架构.

REST主旨是让事情尽量的简单化:

  1. 使用HTTP里的方法:GET、POST、DELETE、PUT,而不需要使用URL或请求的内容来指定这个方法;
  2. 使用URL来指明你将要操作什么对象;.
  3. 使用HTTP状态码作为返回值;
  4. 调用产生的HTTP请求内容只是用于服务数据——不是用来指明调用方法,目标对象或返回值的;
  5. 使用REST方法来开发Web Service的关键点是利用HTTP协议的简单性,而不是去扩展这个协议;

Web Service调用最终应该是非常的简单而且非常的易于理解。

REST架构让人们真正理解我们的网络协议HTTP本来面貌,对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法,因此REST把HTTP对一个URL资源的操作限制在GET、POST、PUT和DELETE这四个之内。

这种针对网络应用的设计和开发方式,可以降低开发的复杂性,提高系统的可伸缩性。

——————– 分割线 ——————–

既然REST宗旨主要是让事情简单化,那为啥还要做权限认证呢?

  • 想象一下支付接口,用户在购物网站上的每一个订单付款时调用支付宝接口、银行接口,就明白是啥问题啦?REST接口让事情尽量的简单,但也不能无限制开放给予调用,不然支付宝、银行系统早就瘫痪,或者被别有用心的搞瘫痪、宕机不能对外提供服务。.

因此就有了Rest接口权限认证。

REST接口地址,比如:
http://seedpaddy.com/rest/getBlogList?appkey={公钥}×tamp={时间戳}&signature={签名}

参数解释:
appkey               

  • 公钥,一般是默认是请求的 APPID ,唯一性:接口服务器提供方用来查询应用的私钥token

timestamp     

  • 当前时间戳,单位为秒(s),有效性:一般默认10分钟有效,当前请求10分钟内有效,支付宝,微信类接口时效性会更短。

signature      

  • 加密签名,signature结合了应用自动生成(或向开发者填写)的token参数和请求中的timestamp参数链接在一起做加密而成,用来鉴权。常规做法是:md5(token + timestamp) 或者 sh1(token + timestamp) 生成的加密串。.

token                 

  • 私钥,自动生成(或者开发者填写),32位无规则[a-z A-Z 0-9 ~-|]键盘上输入常用字符组合,申请应用的时候,自动生成(或者开发者填写)【此token注意保密,勿外泄,用来生成加密签名,做权限验证私钥】

接口服务器端:会根据请求的appkey,timestamp,signature 做判断,参数是否齐全,请求是否在有效时间内,signature 与服务器端的签名是否一致,来进行下一步操作,比如:获取接口数据,订单付款成功、更新订单状态等REST接口服务。

Mysql互为主从订单号数据冲突方案

2013/04/25 | 星期四 分类:系统架构 | 没有评论 标签: | 作者: | 1,936 views

本文研究的不是如下1所描述的一般解决方案,而是2说所描述的解决方案,重点说文中的PHP自动生成订单号函数:new_order_number();
1.Mysql数据库互为主从服务器A、B,解决数据冲突问题:只要保证两台服务器上插入的自增长数据不同就可以了。
比如:A插奇数ID,B插偶数ID,当然如果服务器多的话,可以定义算法,只要不同就可以了。.

在这里我们在A,B上加入参数,以实现奇偶插入

A:my.cnf上加入参数
auto_increment_offset = 1
auto_increment_increment = 2
这样A的auto_increment字段产生的数值是:1, 3, 5, 7, …等奇数ID了。

B:my.cnf上加入参数
auto_increment_offset = 2
auto_increment_increment = 2
这样B的auto_increment字段产生的数值是:2, 4, 6, 8, …等偶数ID了。

可以看出,当auto_increment字段在不同的服务器之间绝对不会重复,所以Master-Master结构就没有任何问题了。当然,你还可以使用3台,4台,或者N台服务器,只要保证auto_increment_increment = N 再设置一下auto_increment_offset为适当的初始值就可以了,那样,我们的MySQL可以同时有几十台主服务器,而不会出现自增长ID 重复。

2.但本文重点说的不是如上描述的,而是Mysql数据库互为主从,特别是非内外网的情况下,不是自增ID,数据经常出现延迟,怎么解决插入冲突问题!
场景:内网公司员工操作平台手工单,外网网站运营平台客户下单!其他平台数据订单导入到内网平台单.
#订单自增ID参考如上设置,而订单号处理则参考如下。

通过如上的函数,.
很好的解决了订单号冲突问题!或许有人说,订单号使用自增ID不就解决了?对单一平台当然可以,但需要对不同平台订单导入时,肯定不满足需求,比如运营下单、ebay、amazon平台的单要导到自己运营的平台,还有使用zen-cart、magento平台的单导入到自己运营的平台时,必须要有额外的订单号统一管理并做好数据对接。

也许这不是必须的,但如上函数的思路挺好的!可以引导处理相关冲突问题提供一种思路…

网站高并发处理

2013/04/23 | 星期二 分类:系统架构 | 没有评论 标签: | 作者: | 1,796 views

时下高并发的问题很Hot,面试中常常会提及到的。但个人认为高并发其实是最不需要考虑的东西,为何,他虚无缥缈,很少有网站真的需要这些东西,而且其中很多技术,其实在开发过程中很多的已经在用了,有这个意识就够了,不需要时刻盯着这个问题而纠结不放。

归纳:从低成本、高性能和高扩张性的角度来说有如下处理方案:
1.HTML静态化,优点不用额外陈述。
2.图片服务器分离,一般使用Lighttpd,.
3.数据库集群和库表散列,web一般用mysql,主从、集群,且数据库单表大于1千万必须分表。
4.缓存,页面缓存,数据查询缓存,比如memcached,图片缓存。
5.镜像,下载采用最多的技术。
6.负载均衡:一个典型的使用负载均衡的策略就是,在软件或者硬件四层交换的基础上搭建squid集群,这种思路在很多大型网站包括搜索引擎上被采用,这样的架构低成本、高性能还有很强的扩张性,随时往架构里面增减节点都非常容易。
阅读全文

B2C系统站群架构

2013/04/09 | 星期二 分类:系统架构 | 没有评论 标签: , | 作者: | 1,725 views

本文是一篇关于B2C网站系统站群架构的文章,笔者的经验之谈。

对于站群系统,在百度百科是这样描述的:站群系统就是一网站的集合,但是一定要统一,分级管理,信息共享,单点登录才可以。最初的站群由政府提出,现在已经应用领域范围很广,例如政府门户网站群、大型企事业网站群、行业网站群等。现在的站群准确的说就是黑豹站群。.

B2C为什么要做站群?对于电子商务网站来说,就是让百度、谷歌收录,一旦收录量上去了,排名上去了,自然盈利的方法就多了!对于电子商务外贸站点来说,主要是google收录与排名,这个类似在大都市繁华地段开了N多实体连锁店,所以就有了这套站群系统的开发,请看图架构:

先看站群架构流程图1:
zhanqun

站群架构商店配置流程图2:
zhanqun_shop
阅读全文

B2C产品属性逐层筛选模块架构

2013/04/07 | 星期日 分类:系统架构 | 没有评论 标签: , | 作者: | 1,606 views

本文简单介绍B2C产品属性逐层筛选模块架构,笔者的经验之谈。

产品属性筛选,适合中小型网站处理,效率不高,但至少实现了电商商品分类页属性逐层筛选功能,先看属性筛选截图1:.
attrbute

大型网站:京东jd.com 兰亭集序:lightinthebox.com 在这方面是这么处理的,2013年以前也是有数量逐层筛选消减的,可目前这两大网站是:属性可以逐层筛选,但不消减、对应属性亦没显示产品数量。
阅读全文

B2C后台权限控制模块架构

2013/04/04 | 星期四 分类:系统架构 | 没有评论 标签: , | 作者: | 1,851 views

B2C小型站点管理后台权限控制模块架构。

网站运营后台,员工登录后台只需要显示相关工作的模块,业务无关的他不需要看到或者普通员工不开放报表统计模块,一些商业信息等,所以有了权限控制功能需求的开发,而且是必须的,电商后台也注定了庞大而严谨,先看如下图1。.
chown

简单权限列表流程图2:
control

从图2可以看出,后台先控制着用户、用户组、角色……具体到用户的时候,分配权限如图1所示,需要什么权限打钩即可,权限可以细分到产品尺寸上下架、产品上下架!要多细就多细。.
阅读全文

B2C产品颜色尺寸SKU模块架构

2013/03/28 | 星期四 分类:系统架构 | 没有评论 标签: , | 作者: | 2,008 views

B2C小型站点产品颜色尺寸管理研究可行方案。产品流程图:

sku

流程图简要说明:
1.主要是对库存表goods_number做管理,.其中goods_id,color_id,size_id 对应唯一产品SKU。
2.颜色尺寸基本表,后台开发相应的增删改管理基本数据,一旦确定不建议经常改动。
3.出入库、盘点模块请看另外一个流程模块出入库盘点管理。
4.后台订单管理,必定关联到库存管理,但为在流程中标出,就是goods_numbers表的虚拟库存做增减。
5.有了这个模块的库存管理,.商品页的颜色、尺寸筛选模块即可以轻松实现。

站点管理产品:SKU、颜色、尺寸同时还涉及到库存管理!规划与数据存储都很重要,设计三个基本数据表:

阅读全文

架构大中型大流量解决方案

2013/03/24 | 星期日 分类:系统架构 | 没有评论 标签: , | 作者: | 1,324 views

架构大中型大流量解决方案,没有相应的环境无法从实战中去总结经验,主要参考文章:《高并发高流量网站架构》ITPUB论坛 转载文章,实际出处无法查证,来源网络整理,没有实战经验,如下纯属“忽悠”

1.负载均衡:DNS负载均衡早期被广泛使用,优点是简单易用。
a.将多个地址配置成同一个域名,负载均衡就完成了。
b.稍微复杂一点的负载均衡,是反向代理,当外部有请求到代理服务器,代理服务器再将该请求均匀的转发到内网的服务器上。
缺点:如果某一台服务器发生了故障,而DNS的下一个刷新周期又没到,这样就可能导致某些用户无法访问站点的情况发生。而另一个缺点在于DNS负载均衡随机性太强,比如一段时间内众多访问都被指向同一个地址,而另外的地址却闲置,就造成了局部繁忙的不良现象。而且有时某处服务器正在运行其他应用而处于繁忙状态,DNS负载均衡也无从得知,而依旧平均的解析域名。
阅读全文