浅析数据中心交换机的五项技术说明教程
1.高容量设备
数据中心的网络流量具有高密度应用调度、浪涌式突发缓冲的特点,而普通交换机以满足互连互通为主要目的,无法实现对业务精确识别与控制,在大业务情况无法做到快速响应和零丢包,无法保证业务的连续性,系统的可靠性主要依赖于设备的可靠性。所以普通交换机无法满足数据中心的需要,数据中心交换机需要具备高容量转发特点。
数据中心交换机必须支持高密万兆板卡,即48口万兆板卡,为使48口万兆板卡能够全线速转发,数据中心交换机只能采用CLOS分布式交换架构。除此之外,随着40G和100G的普及,支持8端口40G板卡和4端口的100G板卡也逐渐商用,数据中心交换机40G、100G的板卡早已出现进入市场,从而满足数据中心高密度应用的需求。
2.大缓存技术
数据中心交换机改变了传统交换系统的出端口缓存方式,采用分布式缓存架构,缓存比普通交换机也大许多,缓存能力可达1G以上,而一般的交换机只能达到2~4M。
对于每端口在万兆全线速条件下达到200毫秒的突发流量缓存能力。从而在突发流量的情况下,大缓存仍能保证网络转发零丢包,正好适应数据中心服务器量大,突发流量大的特点。
3.虚拟化技术
数据中心的网络设备需要具有高管理性和高安全可靠性的特点,因此数据中心的交换机也需要支持虚拟化,虚拟化就是把物理资源转变为逻辑上可以管理的资源,以打破物理结构之间的壁垒。
网络设备的虚拟化主要包括多虚一,一虚多技术,多虚多等技术。通过虚拟化技术,可以对多台网络设备统一管理,也可以对一台设备上的业务进行完全隔离,从而可以将数据中心管理成本减少40%,将IT利用率提高大约25%。
4.FCOE技术
传统的数据中心往往存在一张数据网和一张存储网络,而新一代的数据中心网络融合趋势越来越明显,FCOE技术的出现使网络融合成为可能,FCOE就是把存储网的数据帧封装在以太网帧内进行转发的技术。实现这一融合技术必然是在数据中心的交换机上,普通交换机一般都不支持FCOE功能。
5.TRILL技术
数据中心在构建二层网络方面,原先的标准是STP协议,但其故有的缺陷如:STP是通过端口阻止来工作的,所有冗余链路不进行数据转发,造成了带宽资源的浪费;
STP整网只有一颗生成树,数据报文都要经过根桥中转后才能到达,影响了整网的转发效率。所以STP将不再适合超大型数据中心的扩展,TRILL正是因应了STP的这些缺陷而产生的,是为数据中心应用而产生的技术。
TRILL协议把二层配置和灵活性与三层融合和规模有效结合在一起,大二层不需要配置的情况下,就可实现整网无环路转发。TRILL技术是数据中心交换机二层基本特性,这是普通交换机所不具备的。
以上的几种网络技术是普通交换机所不具备的,是数据中心交换机的主要技术,是为新一代数据中心,甚至云数据中心服务的网络技术。有了这些新的网络技术,才使得数据中心得到飞速发展。
godaddy空间算是一个在国内最受欢迎的国外空间了,小编为一朋友买了一个godaddy空间了,但绑定好域名与ftp之后发现数据库不知道如何创建了,下面经一朋友指点得到了解决办法,下面一起来看看godaddy数据库创建方法吧。1.我们登录空间之后可以,点击 web host后面的launch按钮
2.然后进入之后再点击 mangel按钮,如下图所示
3.进入到mangel界面我们找到下面的database,就是数据库了在这里有一个细节就是先不要点击phpmyadmin了,因为这个和国内有点区别,不能在此创建数据库只能查询数据操作,我们点击后面的mysql database 打开
4.然后在Create New Database填写数据库了,点击就可以创建了,但细节的朋友会发现没有数据库用户怎么管理数据库,那我们接着在当前页面向下拉找到Add New User,然后填写信息点击下面的 create user按钮
5.数据库用户与数据库创建好了,如果只有一个库与用户名会默认在下面的Add User To Database增加,我们只要点击下面的add按钮即可
6.好了最后一步就是导入数据了,现在我们返回到第3步,点击phpmyadmin进入就可以导入数据了
这样就成功在godaddy中创建了mysql数据库了
Yupoo!(又拍网) 是目前国内最大的图片服务提供商,整个网站构建于大量的开源软件之上。以下为其使用到的开源软件信息:
操作系统:CentOS、MacOSX、Ubuntu
服务器:Apache、Nginx、Squid
数据库:MySQLmochiweb、MySQLdb
服务器监控:Cacti、Nagios、
开发语言:PHP、Python、Erlang、Java、Lua
分布式计算:Hadoop、Mogilefs、
日志分析:AWStats
任务管理:Redmine
消息系统:RabbitMQ、php-amqp
前端框架:Mootools
缓存系统:Memcached、php-memcached、libmemcached、pylibmc、XCache、RedisRiak、Predis
图片处理:GraphicsMagick、gmagick
FTP工具:vsftpd
开发工具:VIM、Readline
调试工具:Firebug、Xdebug
版本控制:Mercurial
搜索服务:Solr
邮件服务:Postfix
网络编程:Twisted、cURL、libevent、Net-SNMP、NTP
可用性测试:ibrowse
集群系统:Heartbeat
并行开发:gevent
负载均衡:IPVS
Python框架:bottle
虚拟通道:OpenVPN
(信息来源:http://www.yupoo.com/info/about/)。
一、Yupoo的整体架构
二、程序语言的选择
Yupoo的服务器端开发语言主要是PHP和Python,其中PHP用于编写Web逻辑(通过HTTP和用户直接打交道), 而Python则主要用于开发内部服务和后台任务。在客户端则使用了大量基于MooTools框架的Javascript。 另外,Yupoo把图片处理过程从PHP进程里独立出来变成一个服务。这个服务基于nginx,作为nginx的一个模块开放REST API。
三、服务器的选用
选用Squid的原因是“目前暂时还没找到效率比 Squid 高的缓存系统,原来命中率的确很差,后来在 Squid 前又装了层 Lighttpd, 基于 url 做 hash, 同一个图片始终会到同一台 squid 去,所以命中率彻底提高了。”
同时Yupoo也使用Python开发了YPWS/YPFS:
YPWS–Yupoo Web Server 是用 Python开发的一个小型 Web 服务器,提供基本的 Web 服务外,可以增加针对用户、图片、外链网站显示的逻辑判断,可以安装于任何有空闲资源的服务器中,遇到性能瓶颈时方便横向扩展。
YPFS–Yupoo File System 与 YPWS 类似,也是基于这个 Web 服务器上开发的图片上传服务器。
有网友留言质疑 Python 的效率,Yupoo 老大刘平阳在 del.icio.us 上写到 “YPWS用Python自己写的,每台机器每秒可以处理294个请求, 现在压力几乎都在10%以下”
四、Yupoo的消息系统
由于PHP的单线程模型,Yupoo把耗时较久的运算和I/O操作从HTTP请求周期中分离出来, 交给由Python实现的任务进程来完成,以保证请求响应速度。这些任务主要包括:邮件发送、数据索引、数据聚合和好友动态推送等等。PHP通过消息队列 (Yupoo用的是RabbitMQ)来触发任务执行。这些任务的主要特点为:
由用户或者定时触发的
耗时比较长的
需要异步执行的
整个任务系统主要分为以消息分发、进程管理和工作进程组成。
五、数据库的设计
数据库一向是网站架构中最具挑战性的,瓶颈通常出现在这里。又拍网的照片数据量很大,数据库也几度出现严重的压力问题。和很多使用MySQL的 2.0站点一样,又拍网的MySQL集群经历了从最初的一个主库一个从库、到一个主库多个从库、 然后到多个主库多个从库的一个发展过程。
最初是由一台主库和一台从库组成,当时从库只用作备份和容灾,当主库出现故障时,从库就手动变成主库,一般情况下,从库 不作读写操作(同步除外)。随着压力的增加,加上了memcached,当时只用其缓存单行数据。 但是,单行数据的缓存并不能很好地解决压力问题,因为单行数据的查询通常很快。所以把一些实时性要求不高的Query放到从库去执行。后面又通过添加多个 从库来分流查询压力,不过随着数据量的增加,主库的写压力也越来越大。在参考了一些相关产品和其它网站的做法后,进了行数据库拆分。也就是将数据存放到不 同的数据库服务器中。
如何进行数据库拆分?
垂直拆分:是指按功能模块拆分,比如可以将群组相关表和照片相关表存放在不同的数据库中,这种方式多个数据库之间的表结构不同。
水平拆分:而水平拆分是将同一个表的数据进行分块保存到不同的数据库中,这些数据库中的表结构完全相同。
一般都会先进行垂直拆分,因为这种方式拆分方式实现起来比较简单,根据表名访问不同的数据库就可以了。但是垂直拆分方式并不能彻底解决所有压力问 题,另外,也要看应用类型是否合适这种拆分方式。如果合适的话,也能很好的起到分散数据库压力的作用。比如对于豆瓣我比较适合采用垂直拆分, 因为豆瓣的各核心业务/模块(书籍、电影、音乐)相对独立,数据的增加速度也比较平稳。不同的是,又拍网的核心业务对象是用户上传的照片,而照片数据的增 加速度随着用户量的增加越来越快。压力基本上都在照片表上,显然垂直拆分并不能从根本上解决我们的问题,所以,Yupoo采用水平拆分的方式。
水平拆分实现起来相对复杂,我们要先确定一个拆分规则,也就是按什么条件将数据进行切分。 一般2.0网站都以用户为中心,数据基本都跟随用户,比如用户的照片、朋友和评论等等。因此一个比较自然的选择是根据用户来切分。每个用户都对应一个数据 库,访问某个用户的数据时, 要先确定他/她所对应的数据库,然后连接到该数据库进行实际的数据读写。那么,怎么样对应用户和数据库呢?Yupoo有这些选择:
1、按算法对应
最简单的算法是按用户ID的奇偶性来对应,将奇数ID的用户对应到数据库A,而偶数ID的用户则对应到数据库B。这个方法的最大问题是,只能分成两 个库。另一个算法是按用户ID所在区间对应,比如ID在0-10000之间的用户对应到数据库A, ID在10000-20000这个范围的对应到数据库B,以此类推。按算法分实现起来比较方便,也比较高效,但是不能满足后续的伸缩性要求,如果需要增加 数据库节点,必需调整算法或移动很大的数据集, 比较难做到在不停止服务的前提下进行扩充数据库节点。
2、按索引/映射表对应
这种方法是指建立一个索引表,保存每个用户的ID和数据库ID的对应关系,每次读写用户数据时先从这个表获取对应数据库。新用户注册后,在所有可用 的数据库中随机挑选一个为其建立索引。这种方法比较灵活,有很好的伸缩性。一个缺点是增加了一次数据库访问,所以性能上没有按算法对应好。
比较之后,Yupoo采用的是索引表的方式,我们愿意为其灵活性损失一些性能,更何况我们还有memcached, 因为索引数据基本不会改变的缘故,缓存命中率非常高。所以能很大程度上减少了性能损失。
索引表的方式能够比较方便地添加数据库节点,在增加节点时,只要将其添加到可用数据库列表里即可。 当然如果需要平衡各个节点的压力的话,还是需要进行数据的迁移,但是这个时候的迁移是少量的,可以逐步进行。要迁移用户A的数据,首先要将其状态置为迁移 数据中,这个状态的用户不能进行写操作,并在页面上进行提示。 然后将用户A的数据全部复制到新增加的节点上后,更新映射表,然后将用户A的状态置为正常,最后将原来对应的数据库上的数据删除。这个过程通常会在临晨进 行,所以,所以很少会有用户碰到迁移数据中的情况。当然,有些数据是不属于某个用户的,比如系统消息、配置等等,把这些数据保存在一个全局库中。
分库带来的问题如何解决?
分库会给在应用的开发和部署上都带来很多麻烦。
1、不能执行跨库的关联查询
如果我们需要查询的数据分布于不同的数据库,没办法通过JOIN的方式查询获得。比如要获得好友的最新照片,不能保证所 有好友的数据都在同一个数据库里。一个解决办法是通过多次查询,再进行聚合的方式。所以需要尽量避免类似的需求。有些需求可以通过保存多份数据来解决,比 如User-A和User-B的数据库分别是DB-1和DB-2, 当User-A评论了User-B的照片时,我们会同时在DB-1和DB-2中保存这条评论信息,我们首先在DB-2中的photo_comments表 中插入一条新的记录,然后在DB-1中的user_comments表中插入一条新的记录。这两个表的结构如下图所示。这样我们可以通过查询 photo_comments表得到User-B的某张照片的所有评论, 也可以通过查询user_comments表获得User-A的所有评论。另外可以考虑使用全文检索工具来解决某些需求, 使用Solr来提供全站标签检索和照片搜索服务。
2、不能保证数据的一致/完整性
跨库的数据没有外键约束,也没有事务保证。比如上面的评论照片的例子, 很可能出现成功插入photo_comments表,但是插入user_comments表时却出错了。一个办法是在两个库上都开启事务,然后先插入 photo_comments,再插入user_comments, 然后提交两个事务。这个办法也不能完全保证这个操作的原子性。
3、所有查询必须提供数据库线索
比如要查看一张照片,仅凭一个照片ID是不够的,还必须提供上传这张照片的用户的ID(也就是数据库线索),才能找到它 实际的存放位置。因此,必须重新设计很多URL地址,而有些老的地址我们又必须保证其仍然有效。Yupoo把照片地址改成/photos /{username}/{photo_id}/的形式,然后对于系统升级前上传的照片ID, 又增加一张映射表,保存photo_id和user_id的对应关系。当访问老的照片地址时,通过查询这张表获得用户信息, 然后再重定向到新的地址。
4、自增ID重复的问题
如果要在节点数据库上使用自增字段,那么我们就不能保证全局唯一。这倒不是很严重的问题,但是当节点之间的数据发生关系 时,就会使得问题变得比较麻烦。再来看看上面提到的评论的例子。如果photo_comments表中的comment_id的自增字段,当我们在DB- 2.photo_comments表插入新的评论时, 得到一个新的comment_id,假如值为101,而User-A的ID为1,那么我们还需要在DB-1.user_comments表中插入(1, 101 …)。 User-A是个很活跃的用户,他又评论了User-C的照片,而User-C的数据库是DB-3。 很巧的是这条新评论的ID也是101,这种情况很用可能发生。那么我们又在DB-1.user_comments表中插入一行像这样(1, 101 …)的数据。 那么我们要怎么设置user_comments表的主键呢(标识一行数据)?可以不设啊,不幸的是有的时候(框架、缓存等原因)必需设置。那么可以以 user_id、 comment_id和photo_id为组合主键,但是photo_id也有可能一样(的确很巧)。看来只能再加上photo_owner_id了, 但是这个结果又让我们实在有点无法接受,太复杂的组合键在写入时会带来一定的性能影响,这样的自然键看起来也很不自然。所以,Yupoo放弃了在节点上使 用自增字段,想办法让这些ID变成全局唯一。为此增加了一个专门用来生成ID的数据库,这个库中的表结构都很简单,只有一个自增字段id。 当我们要插入新的评论时,我们先在ID库的photo_comments表里插入一条空的记录,以获得一个唯一的评论ID。 当然这些逻辑都已经封装在我们的框架里了,对于开发人员是透明的。 为什么不用其它方案呢,比如一些支持incr操作的Key-Value数据库。Yupoo还是比较放心把数据放在MySQL里。 另外,Yupoo会定期清理ID库的数据,以保证获取新ID的效率。
数据库优化的实现
前面提到的一个数据库节点为Shard,一个Shard由两个台物理服务器组成, 可以理解为Node-A和Node-B,Node-A和Node-B之间是配置成Master-Master相互复制的。 虽然是Master-Master的部署方式,但是同一时间还是只使用其中一个,原因是复制的延迟问题, 当然在Web应用里,可以在用户会话里放置一个A或B来保证同一用户一次会话里只访问一个数据库, 这样可以避免一些延迟问题。但是Python任务是没有任何状态的,不能保证和PHP应用读写相同的数据库。那么为什么不配置成Master-Slave 呢?Yupoo觉得只用一台太浪费了,所以在每台服务器上都创建多个逻辑数据库。 如下图所示,在Node-A和Node-B上我们都建立了shard_001和shard_002两个逻辑数据库, Node-A上的shard_001和Node-B上的shard_001组成一个Shard,而同一时间只有一个逻辑数据库处于Active状态。 这个时候如果需要访问Shard-001的数据时,我们连接的是Node-A上的shard_001, 而访问Shard-002的数据则是连接Node-B上的shard_002。以这种交叉的方式将压力分散到每台物理服务器上。 以Master-Master方式部署的另一个好处是,可以不停止服务的情况下进行表结构升级, 升级前先停止复制,升级Inactive的库,然后升级应用,再将已经升级好的数据库切换成Active状态, 原来的Active数据库切换成Inactive状态,然后升级它的表结构,最后恢复复制。 当然这个步骤不一定适合所有升级过程,如果表结构的更改会导致数据复制失败,那么还是需要停止服务再升级的。
前面提到过添加服务器时,为了保证负载的平衡,需要迁移一部分数据到新的服务器上。为了避免短期内迁移的必要,在实际部 署的时候,每台机器上部署了8个逻辑数据库, 添加服务器后,只要将这些逻辑数据库迁移到新服务器就可以了。最好是每次添加一倍的服务器, 然后将每台的1/2逻辑数据迁移到一台新服务器上,这样能很好的平衡负载。当然,最后到了每台上只有一个逻辑库时,迁移就无法避免了,不过那应该是比较久 远的事情了。
Yupoo把分库逻辑都封装在我们的PHP框架里了,开发人员基本上不需要被这些繁琐的事情困扰。下面是使用框架进行照片数据的读写的一些例子:
array('type' => 'long', 'primary' => true, 'global_auto_increment' => true),
'user_id' => array('type' => 'long'),
'title' => array('type' => 'string'),
'posted_date' => array('type' => 'date'),
));
$photo = $Photos->new_object(array('user_id' => 1, 'title' => 'Workforme'));
$photo->insert();
// 加载ID为10001的照片,注意第一个参数为用户ID
$photo = $Photos->load(1, 10001);
// 更改照片属性
$photo->title = 'Database Sharding';
$photo->update();
// 删除照片
$photo->delete();
// 获取ID为1的用户在2010-06-01之后上传的照片
$photos = $Photos->fetch(array('user_id' => 1, 'posted_date__gt' => '2010-06-01'));
?>
首先要定义一个ShardedDBTable对象,所有的API都是通过这个对象开放。第一个参数是对象类型名称, 如果这个名称已经存在,那么将返回之前定义的对象。你也可以通过get_table(‘Photos’)这个函数来获取之前定义的Table对象。 第二个参数是对应的数据库表名,而第三个参数是数据库线索字段,你会发现在后面的所有API中全部需要指定这个字段的值。 第四个参数是字段定义,其中photo_id字段的global_auto_increment属性被置为true,这就是前面所说的全局自增ID, 只要指定了这个属性,框架会处理好ID的事情。
如果我们要访问全局库中的数据,我们需要定义一个DBTable对象。
array('type' => 'long', 'primary' => true, 'auto_increment' => true),
'username' => array('type' => 'string'),
));
?>
DBTable是ShardedDBTable的父类,除了定义时参数有些不同(DBTable不需要指定数据库线索字段),它们提供一样的API。
六、缓存方案的选择
Yupoo使用的框架自带缓存功能,对开发人员是透明的。
load(1, 10001);
?>
比如上面的方法调用,框架先尝试以Photos-1-10001为Key在缓存中查找,未找到的话再执行数据库查询并放入缓存。当更改照片属性或删除照片时,框架负责从缓存中删除该照片。这种单个对象的缓存实现起来比较简单。稍微麻烦的是像下面这样的列表查询结果的缓存。
fetch(array('user_id' => 1, 'posted_date__gt' => '2010-06-01'));
?>
Yupoo把这个查询分成两步,第一步先查出符合条件的照片ID,然后再根据照片ID分别查找具体的照片信息。 这么做可以更好的利用缓存。第一个查询的缓存Key为Photos-list-{shard_key}-{md5(查询条件SQL语句)}, Value是照片ID列表(逗号间隔)。其中shard_key为user_id的值1。目前来看,列表缓存也不麻烦。 但是如果用户修改了某张照片的上传时间呢,这个时候缓存中的数据就不一定符合条件了。所以,需要一个机制来保证我们不会从缓存中得到过期的列表数据。我们 为每张表设置了一个revision,当该表的数据发生变化时(调用insert/update/delete方法), 我们就更新它的revision,所以我们把列表的缓存Key改为Photos-list-{shard_key}-{md5(查询条件SQL语 句)}-{revision}, 这样我们就不会再得到过期列表了。
revision信息也是存放在缓存里的,Key为Photos-revision。这样做看起来不错,但是好像列表缓 存的利用率不会太高。因为我们是以整个数据类型的revision为缓存Key的后缀,显然这个revision更新的非常频繁,任何一个用户修改或上传 了照片都会导致它的更新,哪怕那个用户根本不在我们要查询的Shard里。要隔离用户的动作对其他用户的影响,我们可以通过缩小revision的作用范 围来达到这个目的。 所以revision的缓存Key变成Photos-{shard_key}-revision,这样的话当ID为1的用户修改了他的照片信息时, 只会更新Photos-1-revision这个Key所对应的revision。
因为全局库没有shard_key,所以修改了全局库中的表的一行数据,还是会导致整个表的缓存失效。 但是大部分情况下,数据都是有区域范围的,比如帮助论坛的主题帖子, 帖子属于主题。修改了其中一个主题的一个帖子,没必要使所有主题的帖子缓存都失效。 所以在DBTable上增加了一个叫isolate_key的属性。
array('type' => 'long', 'primary' => true),
'post_id' => array('type' => 'long', 'primary' => true, 'auto_increment' => true),
'author_id' => array('type' => 'long'),
'content' => array('type' => 'string'),
'posted_at' => array('type' => 'datetime'),
'modified_at' => array('type' => 'datetime'),
'modified_by' => array('type' => 'long'),
), 'topic_id');
?>
注意构造函数的最后一个参数topic_id就是指以字段topic_id作为isolate_key,它的作用和shard_key一样用于隔离revision的作用范围。
ShardedDBTable继承自DBTable,所以也可以指定isolate_key。 ShardedDBTable指定了isolate_key的话,能够更大幅度缩小revision的作用范围。 比如相册和照片的关联表yp_album_photos,当用户往他的其中一个相册里添加了新的照片时, 会导致其它相册的照片列表缓存也失效。如果指定这张表的isolate_key为album_id的话, 我们就把这种影响限制在了本相册内。
缓存分为两级,第一级只是一个PHP数组,有效范围是Request。而第二级是memcached。这么做的原因是, 很多数据在一个Request周期内需要加载多次,这样可以减少memcached的网络请求。另外Yupoo的框架也会尽可能的发送memcached 的gets命令来获取数据, 从而减少网络请求。
MVC是一种web应用程序开发模式,他能够很好的管理代码,但是当mvc业务很复杂时,如果开发人员水平不齐,也会导致代码冗余,这时引入引入service Layer就是一个非常不错的解决方案。MVC是web开发中常见的程序结构。
简单的mvc结构如下:
view层:显示层。
control层:业务层,集合了各种action。
model层:模型层,一般和数据打交道。简单的sample:一个表对应一个model类。
其中control层调用model层的方法,实现对数据的访问。
采用这样的结构在一定程度上,可以做到代码清晰,较容易扩展,代码的管理复杂度较低。
但是如果是业务很多,逻辑又很复杂的网站,如果再加上开发人员的水平参差不齐,那必然会导致下面的情况:
1action中的代码越来越长,逻辑越来越复杂,不同action之间看起来有很多可以重用的代码, 但是真要进行重构的话,又非常困难。
2model层中包含的方法越来越多,有些方法也过于复杂。甚至在不少方法中还包含了业务逻辑。
3代码的修改,还是牵一发而动全身。
4代码难以进行自动化测试。
本来以为引入了mvc,程序的管理复杂度问题就高枕无忧了,但现在又面临了相同的问题了。
以我最近的所学看,在mvc中再引入service层,可以在很大程度上避免或者缓解上述问题。
原有的mvc结构改成如下:
1view层:显示层。
2control层:业务层,集合了各种action。
3service层。
4DAO层。
原来的model层不见了,增加了service层和DAO层。DAO,即Data Access Object,数据访问接口,数据访问:顾名思义就是与数据库打交道。
在这个结构中,control不直接和DAO联系,
需要操作数据的时候,通过service层访问DAO层来实现。
service层做的事情,不仅仅是调用DAO操作数据,还会包含了一定的业务逻辑。整个程序的设计,也变成了针对服务进行设计。
这样做的好处是:
1control层中的action得以精简,因为action中的一些逻辑,被重构成一个个的服务。而不同的action也可以重用服务了。
2只负责和数据打交道的DAO层,相比之前的model层,也得以精简(DAO层尽量只做最原子的数据操作,不同数据操作之间的联系,这边不考虑,那是service层的事情)。
3service层可以实现很大程度上的代码复用,程序的功能封装更清晰了。
4由于service层更加清晰的定义了应用程序的边界,那么对于各个service函数(对应某个服务/应用),要做到自动化测试就方便多了。WEB程序如何做到能方便的进行单元测试,这是一直困扰我的难题,这样的设计似乎真的可行了~
5开发人员的工作分配,理论上真的可以按层次划分了。只是理论上~
同时,这样的设计模式也是存在一定的缺点的:
层次太多,刚接触的开发人员理解起来比简单的mvc结构费时;
service层的设计需要一定的功力,因为action中和model层的逻辑在很大程度上转移到这里了。
但整体上看,service Layer的引入,更加清晰的定义了应用程序的边界,提供了一系列可以重用的操作集合。这对于网站的可扩展性和可维护性是非常有帮助的。
当然,如果网站的业务逻辑并不复杂,完全没必要用这样的设计。过度设计是万恶之源~
注意:只有获得sitemap权限的站长才可以进行这个操作,否则你没有access_token密私是无法提交的。
1.进入之后如下图所示我们会看到如下界面
下面有一个官方举例的一个curl推荐地址
代码如下 | 复制代码 |
将xml数据写入一个本地文件,比如thread.xml,然后调用curl命令: curl -H 'Expect:' --data-binary @thread.xml "http://ping.baidu.com/sitemap?site=www.111cn.net&resource_name=sitemap&access_token=你的key" 使用php、python、java等可以参照这个过程推送结构化数据。 |
返回结果为200,下面小编以php的curl实现post的为例子,代码如下
代码如下 | 复制代码 |
<? |
提交之后返回结果
代码如下 | 复制代码 |
<?xml version="1.0" encoding="UTF-8" ?> |
注意只有返回200状态代码才代码提交成功了,下面看看状态代码
200 无使用方式错误,需要进一步观察返回的内容是否正确
400 必选参数未提供
405 不支持的请求方式,我们只支持POST方式提交数据
411 HTTP头中缺少Content-Length字段
413 推送的数据过大,超过了10MB的限制
422 HTTP头中Content-Length声明的长度和实际发送的数据长度不一致
500 站长平台服务器内部错误
小编利用这个提交之后在sitemap中会有实时返回数据并且会返回数据错误与正确性。
经验总结
前面有一个说是xml文档,其实我们使用post可以是一个字符串效果也是一样的,小编的做法是发布文章成功之后自动推送文章给百度收录
注意:推送的文章必须为绝对地址,如http://www.111cn.net 而不是/aaa/b.htm要是完整的地址。
相关文章
- 本文给大家分享C#连接SQL数据库和查询数据功能的操作技巧,本文通过图文并茂的形式给大家介绍的非常详细,需要的朋友参考下吧...2021-05-17
- 最基础的对数据的增加删除修改操作实例,菜鸟们收了吧...2013-09-26
- 这篇文章主要介绍了解决Mybatis 大数据量的批量insert问题,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧...2021-01-09
Antd-vue Table组件添加Click事件,实现点击某行数据教程
这篇文章主要介绍了Antd-vue Table组件添加Click事件,实现点击某行数据教程,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧...2020-11-17- 这篇文章主要介绍了详解如何清理redis集群的所有数据,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧...2021-02-18
- 这篇文章主要介绍了vue 获取到数据但却渲染不到页面上的解决方法,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧...2020-11-19
- 在php中解析xml文档用专门的函数domdocument来处理,把json在php中也有相关的处理函数,我们要把数据xml 数据存到一个数据再用json_encode直接换成json数据就OK了。...2016-11-25
- 这篇文章主要介绍了mybatis-plus 处理大数据插入太慢的解决,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧...2020-12-18
- 这篇文章主要介绍了postgresql数据添加两个字段联合唯一的操作,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧...2021-02-04
Vue生命周期activated之返回上一页不重新请求数据操作
这篇文章主要介绍了Vue生命周期activated之返回上一页不重新请求数据操作,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧...2020-07-26- 这篇文章主要介绍了解决vue watch数据的方法被调用了两次的问题,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧...2020-11-07
- 这篇文章主要介绍了c# socket网络编程,server端接收,client端发送数据,大家参考使用吧...2020-06-25
- 这篇文章主要介绍了vue 数据(data)赋值问题的解决方案,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧...2021-03-29
- 这篇文章主要介绍了Python3 常用数据标准化方法详解,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧...2021-03-24
OPPO R9s如何开启Real原声技术?OPPO R9s开启Real原声技术教程
本篇文章介绍了OPPO R9s如何开启Real原声技术的方法,有需要的小伙伴可以进来看一看。 OPPO R9s如何开启Real原声技术?Real原声技术是R9s自带的音质提升技术,开启之后...2016-12-31- 这篇文章主要为大家详细介绍了node.js从数据库获取数据的具体代码,nodejs可以获取具体某张数据表信息,感兴趣的朋友可以参考一下...2016-05-09
- 这篇文章主要给大家介绍了关于swift中利用runtime交换方法的相关资料,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧。...2020-06-30
- 使用下以两种方法时必须把字段设为”主键(PRIMARY KEY”或”唯一约束(UNIQUE)”。1:使用REPLACE INTO (此种方法是利用替换的方法,有点似类于先删除再插入) 复制代码 代码如下:REPLACE INTO Syntax REPLACE [LOW_PRIO...2013-10-04
- 这篇文章主要介绍了PostgreSQL 恢复误删数据的操作,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧...2021-01-18
- 这篇文章主要介绍了C#实现窗体间传递数据实例,需要的朋友可以参考下...2020-06-25