Tagged: 云计算

Discuz在新浪云空间实现URL伪静态

新浪云SAE云空间在分布式基础上,几乎实现了普通虚拟主机全兼容的环境,但还是有一点点区别,比如URL Rewrite,新浪云空间实现URL Rewrite是通过在根目录编写一个 .appconfig 来实现的,同时在规则上也有一些区别

官方提供了一个原生 .htaccess 到 .appconfig 的转换工具:
http://htaccess.applinzi.com
我试了下 Discuz 的 Rewrite,转换后,发现没什么软用

RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^/data1/www/htdocs/711//1/topic-(.+)\.html$ portal.php?mod=topic&topic=$1&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^/data1/www/htdocs/711//1/article-([0-9]+)-([0-9]+)\.html$ portal.php?mod=view&aid=$1&page=$2&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^/data1/www/htdocs/711//1/forum-(\w+)-([0-9]+)\.html$ forum.php?mod=forumdisplay&fid=$1&page=$2&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^/data1/www/htdocs/711//1/thread-([0-9]+)-([0-9]+)-([0-9]+)\.html$ forum.php?mod=viewthread&tid=$1&extra=page\%3D$3&page=$2&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^/data1/www/htdocs/711//1/group-([0-9]+)-([0-9]+)\.html$ forum.php?mod=group&fid=$1&page=$2&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^/data1/www/htdocs/711//1/space-(username|uid)-(.+)\.html$ home.php?mod=space&$1=$2&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^/data1/www/htdocs/711//1/blog-([0-9]+)-([0-9]+)\.html$ home.php?mod=space&uid=$1&do=blog&id=$2&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^/data1/www/htdocs/711//1/archiver/(fid|tid)-([0-9]+)\.html$ archiver/index.php?action=$1&value=$2&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^/data1/www/htdocs/711//1/([a-z]+[a-z0-9_]*)-([a-z0-9_\-]+)\.html$ plugin.php?id=$1:$2&%1[

下面是我改写的、亲测有效的 Rewrite 规则:

RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^(.*)/topic-(.+)\.html$ portal.php?mod=topic&topic=$2&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^(.*)/article-([0-9]+)-([0-9]+)\.html$ portal.php?mod=view&aid=$2&page=$3&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^(.*)/forum-(\w+)-([0-9]+)\.html$ forum.php?mod=forumdisplay&fid=$2&page=$3&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^(.*)/thread-([0-9]+)-([0-9]+)-([0-9]+)\.html$ forum.php?mod=viewthread&tid=$2&extra=page\%3D$4&page=$3&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^(.*)/group-([0-9]+)-([0-9]+)\.html$ forum.php?mod=group&fid=$2&page=$3&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^(.*)/space-(username|uid)-(.+)\.html$ home.php?mod=space&$2=$3&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^(.*)/blog-([0-9]+)-([0-9]+)\.html$ home.php?mod=space&uid=$2&do=blog&id=$3&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^(.*)/(fid|tid)-([0-9]+)\.html$ index.php?action=$2&value=$3&%1
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^(.*)/([a-z]+[a-z0-9_]*)-([a-z0-9_\-]+)\.html$ plugin.php?id=$2:$3&%1

在新浪云SAE架构一个大型Web应用到底有多简单

一般大型Web应用是指具有大流量、高并发、海量数据等特征的Web应用,
支撑此类应用,必需要一个安全、高可靠、可扩展、易维护的动态平台,才能保证应用的平稳运行。

下面我们先来聊聊,如何架构一个支撑大型Web应用的动态平台?

上图是较多大型应用采用的架构模式(实际应用中,会随着业务和需求的复杂程度,而出现更多更复杂的多层架构)

1、分布式Web服务器

如前言所述,大型应用,具有大流量、高并发的特征,一台服务器,显然无法满足需求。
以一个日均8亿PV的网站为例,根据PV我们计算出每秒的并发为1万,并发峰值是3.7万(每天80%的访问集中在20%的时间里,这20%时间叫做峰值时间),如果要保证100QPS,则至少需要400台服务器一起分担压力。
另外,大型应用业务普遍比较复杂,业务拆分是很常见的架构模式,如微博平台针对用户的行为、关系、设置等从技术架构中进行了业务拆分。

2、负载均衡系统

负载均衡和分布式Web服务器可以说是“连体婴儿”,负载均衡系统是所有请求的入口,请求到达时,根据分发策略将请求分发到健康的Web服务器节点,从而实现对请求的合理调度。
负载均衡分为硬件和软件两种。硬件负载均衡效率高,但是价格贵。软件负载均衡系统价格较低或者免费,但效率较硬件负载均衡系统低,常见的如LVS、Nginx,软硬负载均衡系统并用也是常见的均衡方式。

3、CDN、反向代理

大型应用普遍用户量都非常庞大,遍布全国各地,甚至全球,并且处于不同的网络环境。所以需要CDN,去解决跨地区、跨运营商的访问速度问题。反向代理,则是部署在应用所在机房,请求到达时,首先访问反向代理服务器,反向代理服务器将缓存的数据返回给用户,如果没有缓存数据才会继续走应用服务器获取,减少获取数据的成本。反向代理有Squid、Nginx等

4、分布式数据库系统

很多大型应用都会面临一个数据库性能瓶颈问题,海量数据如何存储?高并发情况下如果保证数据库负载问题?复杂业务逻辑如何保证数据的一致性、安全性?大流量面前如果保证查询效率?
一个大型应用,必然需要一个高可靠的、可以提供大规模并发处理的数据库体系,如此才能保证整个应用的高可靠性。
一般数据库系统都会同时使用关系型(如MySQL)数据库和非关系型(即NoSQL,如MongoDB、Redis)数据库,以满足不同的业务场景。
在分布式部署的基础上,还会采用主从架构、读写分离,主库抗写压力,通过从库来分担读压力。

5、分布式缓存系统

在海量数据、大流量、高并发面前,光有高可靠的分布式数据库系统,是远远不够的!
缓存技术是关键,在大型Web应用中使用最多且效率最高的是内存缓存,最常用的内存缓存工具是Memcached。
一个好的缓存机制,可以提高访问效率、提高服务器吞吐能力、减轻数据库系统和文件系统的访问压力。
分布式缓存系统,则可以避免单点故障,提高性能,提供高可靠性和可扩展性,巨大容量的缓存池,也可以将发生宕机时缓存的穿透率维持在一个很低的水平。

6、分布式文件系统

大规模存储,也是大型应用一大特征,如图片、视频、音乐、压缩包等等。
因此高性能的分布式存储系统对于大型应用来说是非常重要的一环。

7、代码发布系统

从 本地开发 到 生产环境(测试),再到 灰度发布,再到 全网发布,
为了满足分布式环境下程序代码的批量分发和更新,大型应用都需要一个代码发布系统和机制。

8、分布式服务器管理系统

文章开头,我们提出一个 “易维护” 概念,何谓 “易维护”?
就是能够集中式的、分组的、批量的、自动化的对所有服务器进行管理,能够批量化的执行计划任务。
常见的集中配置管理系统和软件有:puppet、Cfengine

OK!到此,我们大概地全面描述了一个支撑大型Web应用的动态平台架构。
那么问题来了,架构一个这样的动态平台,需要多少人力成本?周期?IT成本?稳定性?安全性?可靠性?

你也许看到过诸如 “如何理解云计算中的IaaS、PaaS和SaaS”、“PaaS和IaaS的区别”、“为什么选择PaaS” 等等之类的文章。
现在请先忘了那些乱七八糟的概念,这一次,我们站在实际用例的角度,看看国内领先的 PaaS 云平台SAE是如何优雅的帮你解决以上问题的!

一张图告诉你,在SAE架构一个大型Web应用到底有多简单!

如你所见,SAE用成熟稳定的技术,帮您解决了所有问题,开发者只需专注于业务本身(写自己的代码,让别人加班去吧!)

1、分布式Web服务器

分布式部署是PaaS的天然特性,自然也是SAE的一大特性,在SAE的所有应用均是分布式部署,相当于每台Web服务器上都有代码,避开单点故障问题,稳定性不言而喻。
SAE的Web服务器,相当于纯粹的代码运行环境,我们先且称之为SAE Runtime吧!
SAE通过沙箱机制,将代码、数据、连接数、内存、CPU进行了安全隔离,保证了应用的绝对安全性。
看完这篇文章,你会发现,其实SAE全平台的Web服务都是分布式的。

2、负载均衡系统

SAE的Web服务器采用分布式部署的架构,这就需要均衡每一台服务器的负载,从而保证每一个请求的访问速度。
SAE通过7层(至于为什么叫7层,可能是因为它工作在OSI 7层网络模型的第7层应用层吧)经分析后转发到负载相对较小的Web服务器上。

3、CDN、反向代理

SAE的负载均衡服务器部署在电信机房,为了保证跨运营商访问速度,SAE在各大运营商的机房都有代理,代理通过专线和电信机房连接。
SAE拥有覆盖全国各大城市的多路(电信、联通、移动、教育)骨干网络CDN节点,用户只需简单的开启操作,就能使用高质量的CDN服务。

4、分布式数据库系统

SAE提供了MySQL、NoSQL(KVDB)两种分布式数据库服务,
SAE每组MySQL都采用 一主多从加一备份 的设计,充分保证了数据库的性能,以及数据的可靠性。
KVDB是SAE开发的分布式key-value数据存储服务,用来支持公有云计算平台上的海量key-value存储。KVDB支持的存储容量很大,对每个用户支持100G的存储空间,可支持1,000,000,000条记录。
KVDB是高性能高可靠存储,读写可达10W QPS。KVDB采用一主多从的分布式架构, SAE提供热备和定期冷备,发生宕机时,会自动切换到健康的DB上。

5、分布式缓存系统

SAE Memcache,是SAE为开发者提供分布式缓存服务。SAE Memcache采用企业级规模的缓存池。巨大容量的缓存池,将发生宕机时缓存的穿透率维持在一个很低的水平。同时支持无缝扩容,domain等概念。较传统Memcache更加稳定、可靠、高效。

6、分布式文件系统

Storage是 SAE 利用自身在分布式以及网络技术方面的优势为开发者提供的安全、高效的分布式对象存储服务,支持文本、多媒体、二进制等任何类型的数据的存储。开发者可通过客户端简单的完成文件的管理操作,SAE还提供了完整的 Storage API,以满足开发者的所有应用场景。

7、代码发布系统

在SAE,通过svn或git完成代码发布。代码提交后,SAE CodeFS会自动同步到所有Web服务器。

8、分布式服务器管理系统

......
(为什么是点点点??在SAE,你可以忘记这玩意了,因为在SAE是完全免运维的,开发者不需要管理自己的服务器,一切运维都交给了SAE!)

看到这里,你会发现,在SAE,其实每一个应用都是以大型应用的标准和规格运行着!

除此以外,SAE还提供了丰富的符合开发者实际业务场景的分布式Web服务,如:
DDoS防火墙/应用防火墙、FetchURL(分布式网页抓取服务)、Cron(分布式计划任务服务)、TaskQueue(分布式任务队列服务)、Channel(实时消息推送服务)、Push(手机通知推送服务,同时支持iOS、Android)等等,因为服务较多,为不使文章篇幅太长,就不一一介绍了!

如上,便是SAE(SinaAppEngine,http://sae.sina.com.cn)的魅力所在!

大型网站系统架构的演化

一个成熟的大型网站(如淘宝、京东等)的系统架构并不是开始设计就具备完整的高性能、高可用、安全等特性,
它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式、技术架构、设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线。
所以成熟的系统架构是随业务扩展而完善出来的,并不是一蹴而就;不同业务特征的系统,会有各自的侧重点,
例如淘宝,要解决海量的商品信息的搜索、下单、支付,
例如腾讯,要解决数亿的用户实时消息传输,
例如百度,它要处理海量的搜索请求,他们都有各自的业务特性,系统架构也有所不同。
尽管如此我们也可以从这些不同的网站背景下,找出其中共用的技术,这些技术和手段可以广泛运行在大型网站系统的架构中,下面就通过介绍大型网站系统的演化过程,来认识这些技术和手段。

一、最开始的网站架构

最初的架构,应用程序、数据库、文件都部署在一台服务器上,如图:
云厉的博客

二、应用、数据、文件分离

随着业务的扩展,一台服务器已经不能满足性能需求,故将应用程序、数据库、文件各自部署在独立的服务器上,并且根据服务器的用途配置不同的硬件,达到最佳的性能效果。
云厉的博客

三、利用缓存改善网站性能

在硬件优化性能的同时,同时也通过软件进行性能优化,在大部分的网站系统中,都会利用缓存技术改善系统的性能,使用缓存主要源于热点数据的存在,大部分网站访问都遵循28原则(即80%的访问请求,最终落在20%的数据上),所以我们可以对热点数据进行缓存,减少这些数据的访问路径,提高用户体验。
云厉的博客

缓存实现常见的方式是本地缓存、分布式缓存。当然还有CDN、反向代理等,这个后面再讲。本地缓存,顾名思义是将数据缓存在应用服务器本地,可以存在内存中,也可以存在文件,OSCache就是常用的本地缓存组件。本地缓存的特点是速度快,但因为本地空间有限所以缓存数据量也有限。分布式缓存的特点是,可以缓存海量的数据,并且扩展非常容易,在门户类网站中常常被使用,速度按理没有本地缓存快,常用的分布式缓存是Memcached、Redis。

四、使用集群改善应用服务器性能

应用服务器作为网站的入口,会承担大量的请求,我们往往通过应用服务器集群来分担请求数。应用服务器前面部署负载均衡服务器调度用户请求,根据分发策略将请求分发到多个应用服务器节点。
云厉的博客

常用的负载均衡技术硬件的有F5,价格比较贵,软件的有LVS、Nginx、HAProxy。LVS是四层负载均衡,根据目标地址和端口选择内部服务器,Nginx是七层负载均衡和HAProxy支持四层、七层负载均衡,可以根据报文内容选择内部服务器,因此LVS分发路径优于Nginx和HAProxy,性能要高些,而Nginx和HAProxy则更具配置性,如可以用来做动静分离(根据请求报文特征,选择静态资源服务器还是应用服务器)。

五、数据库读写分离和分库分表

随着用户量的增加,数据库成为最大的瓶颈,改善数据库性能常用的手段是进行读写分离以及分表,读写分离顾名思义就是将数据库分为读库和写库,通过主备功能实现数据同步。分库分表则分为水平切分和垂直切分,水平切换则是对一个数据库特大的表进行拆分,例如用户表。垂直切分则是根据业务不同来切换,如用户业务、商品业务相关的表放在不同的数据库中。
云厉的博客

六、使用CDN和反向代理提高网站性能

假如我们的服务器都部署在成都的机房,对于四川的用户来说访问是较快的,而对于北京的用户访问是较慢的,这是由于四川和北京分别属于电信和联通的不同发达地区,北京用户访问需要通过互联路由器经过较长的路径才能访问到成都的服务器,返回路径也一样,所以数据传输时间比较长。对于这种情况,常常使用CDN解决,CDN将数据内容缓存到运营商的机房,用户访问时先从最近的运营商获取数据,这样大大减少了网络访问的路径。比较专业的CDN运营商有蓝汛、网宿。

而反向代理,则是部署在网站的机房,当用户请求达到时首先访问反向代理服务器,反向代理服务器将缓存的数据返回给用户,如果没有没有缓存数据才会继续走应用服务器获取,也减少了获取数据的成本。反向代理有Squid,Nginx。
云厉的博客

七、使用分布式文件系统

用户一天天增加,业务量越来越大,产生的文件越来越多,单台的文件服务器已经不能满足需求。需要分布式的文件系统支撑。常用的分布式文件系统有NFS。
云厉的博客

八、使用NoSql和搜索引擎

对于海量数据的查询,我们使用nosql数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NOSQL有mongodb和redis,搜索引擎有lucene。
云厉的博客

九、将应用服务器进行业务拆分

随着业务进一步扩展,应用程序变得非常臃肿,这时我们需要将应用程序进行业务拆分,如百度分为新闻、网页、图片等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者同享数据库来实现。
云厉的博客

十、搭建分布式服务

这时我们发现各个业务应用都会使用到一些基本的业务服务,例如用户服务、订单服务、支付服务、安全服务,这些服务是支撑各业务应用的基本要素。我们将这些服务抽取出来利用分部式服务框架搭建分布式服务。淘宝的Dubbo是一个不错的选择。
云厉的博客

文章来源:http://www.cnblogs.com/leefreeman/p/3993449.html

示例浅谈PHP开发手机APP接口,即API开发

API(Application Programming Interface,应用程序接口)架构,已经成为目前互联网产品开发中常见的软件架构模式,并且诞生很多专门API服务的公司,如:聚合数据百度APIStore

作为最流行的服务端语言PHP(PHP: Hypertext Preprocessor),在开发API方面,是很简单且极具优势的
这篇文章写给不太了解PHP开发API接口的开发者

一、先简单回答两个问题

1、PHP 可以开发客户端吗?
答:正确的回答是,不适合,因为PHP是服务端脚本语言,负责 B/S或C/S 架构的S部分,即:Server端的开发。(别去纠结 GTK、WinBinder了)

2、为什么选择 PHP 作为开发服务端的首选?
答:跨平台(可以运行在UNIX、LINUX、WINDOWS、Mac OS下)、低消耗(PHP消耗相当少的系统资源)、运行效率高(相对而言)、MySQL的完美搭档,本身是免费开源的,......

二、如何使用 PHP 开发 API 呢?

有兴趣细研究的,可以先看看百科介绍:
http://baike.baidu.com/item/api/10154

百科写的比较泛,嫌文字多?好吧,那就不看了,先了解下 API 是什么鬼
1、API 比开发 WEB 更简洁,但可能逻辑更复杂,API 只返回结果,也就是只完成数据输出,不呈现页面
2、WEB 开发,更多的是 GET 和 POST 请求,API 还有 PUT、DELETE 请求
3、和 WEB 开发一样,首先需要一些相关的参数,这些参数,都会由客户端传过来,也许是 GET 也许是 POST,这个需要开发团队相互之间约定好,或者制定统一规范
4、有了参数,根据应用需求,完成数据处理,例如:获取用户信息、发朋友圈、发消息、一局游戏结束数据提交等等
5、数据逻辑处理完之后,返回客户端所需要用到的相关数据,例如:用户信息数组、朋友圈列表、消息状态、游戏结果数据等等,那数据是怎么返给客户端呢?常见有XML、JSON,设置相应的header并把要返回的数据直接打印出来即可
6、客户端获取到你返回的数据后,在客户端本地和用户进行交互

所以我们大概知道,API 其实不存在Web领域的 MVC 架构模式,若要分层的,API 也只有 M 和 C 两层,当然,后端可能会有更加复杂的架构!

通过下面一个HTTP协议的API实例来理解PHP怎么开发API:

<?php
/**
 * 比较标准的接口输出函数
 * @param string  $info 消息
 * @param integer $code 接口错误码,很关键的参数
 * @param array   $data 附加数据
 * $param string  $location 重定向
 * @return array
 */
function var_json($info = '', $code = 10000, $data = array(), $location = '') {
    $out['code'] = $code ?: 0;
    $out['info'] = $info ?: ($out['code'] ? 'error' : 'success');
    $out['data'] = $data ?: array();
    $out['location'] = $location;
    header('Content-Type: application/json; charset=utf-8');
    echo json_encode($out, JSON_HEX_TAG);
    exit(0);
}

$a = empty($_GET['a']) ? '' : $_GET['a'];
$qq = empty($_GET['qq']) ? 0 : intval($_GET['qq']);

//假设这是数据源,如MySQL
$data = array();
$data[979136] = array('qq'=>979136, 'vip'=>5,'level'=>128, 'reg_time'=>1376523234, 'qb'=>300);
$data[979137] = array('qq'=>979137, 'vip'=>8,'level'=>101, 'reg_time'=>1377123144, 'qb'=>300);

preg_match('/^[a-zA-Z]+$/', $a) || var_json('非法调用');
isset($data[$qq]) || var_json('用户不存在', 100001);

switch ($a) {
    //获取用户基本信息
    case 'info': 
        //你的更多业务逻辑 ...
        var_json('success', 0, $data[$qq]);
        break;
    //获取动态消息
    case 'message':
        var_json('您正在调用动态消息接口', 0);
        break;
    //获取好友列表
    case 'friends':
        var_json('你正在调用好友列表接口', 0);
        break;
    default:
        var_json('非法调用');
}

把它部署到服务器之后,任何语言都可以通过HTTP协议调用诸如下面的URL接口:
http://demo.979137.com/api/test/user.php
http://demo.979137.com/api/test/user.php?a=info&qq=979137&ticket=test
http://demo.979137.com/api/test/user.php?a=info&qq=979138&ticket=test
http://demo.979137.com/api/test/user.php?a=friends&qq=979137&ticket=test
http://demo.979137.com/api/test/user.php?a=fuck&qq=979137&ticket=test

接口输出示例,返回的是一串json:

{
    "code": 0,
    "info": "success",
    "data": {
        "qq": 979137,
        "vip": 8,
        "level": 101,
        "reg_time": 1377123144,
        "qb": 300
    },
    "location": ""
}

json具有很强的跨平台性,几乎每种开发语言都可以直接解析,下面是一个PHP作为客户端调用的示例:

<?php
header('Content-type:text/html;charset=utf-8');
$url = "http://demo.979137.com/api/test/user.php
$arg = array(
    'a'  => 'info',
    'qq' => '979137',
);
$query_string = http_build_query($arg);
$ch = curl_init($url.'?'.$query_string);
curl_setopt($ch, CURLOPT_HTTP_VERSION , CURL_HTTP_VERSION_1_1);
curl_setopt($ch, CURLOPT_USERAGENT , 'QQ_Mobile_V5.5');
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT , 60 );
curl_setopt($ch, CURLOPT_TIMEOUT , 60);
curl_setopt($ch, CURLOPT_RETURNTRANSFER , true);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
$response = curl_exec($ch);
$httpcode = curl_getinfo($ch , CURLINFO_HTTP_CODE);
curl_close($ch);
if ($response === false) {
    var_dump(curl_error($ch));
} elseif ($httpcode != 200) {
    var_dump($httpcode, '接口请求失败');
} else {
    $ret = json_decode($response, true);
    var_dump($ret);
}

页面输出结果:

array(4) {
    [“code”]=>int(0)
    [“info”]=>string(7) “success”
    [“data”]=>
    array(5) {
        [“qq”]=>int(979137)
        [“vip”]=>int(8)
        [“level”]=>int(101)
        [“reg_time”]=>int(1377123144)
        [“qb”]=>int(300)
    }
    [“location”]=>string(0) “”
}

实际业务中,就是拿到了接口返回的数据之后,结合自身的业务为用户提供服务!

三、实际项目中,我们在开发 API 时应该注意的几个点(仅供参考)

1、单文件实现多接口的形式有很多种,例如:if..elseif.. 或 switch 或 很多框架里用到的统一入口通过调用类函数体
2、数据输出建议使用json,json具有很强的跨平台性,大多编程语言都支持json解析,json正在逐步取代xml,成为网络数据的通用格式
3、为了保证接口安全,一定要加入鉴权体系
4、对于线上的API,务必关闭所有错误显示同时把错误写到日志里,PHP中可以通过 error_reporting(0) 屏蔽所有错误
这样做的目的,一方面是保护接口安全,防止输出不该打印的错误信息
另一方面是保证输出的是正确的数据格式,如json,假如不是标准的json格式,客户端在解析时就会出错,由此影响客户端的正常运转
PS:我们平时在使用手机APP时,手机会闪退,多半是这个原因,即接口调用异常
5、开发 API 和 WEB 有一定的区别,如果是 WEB 的话,如果程序写的有问题,比如有个notice 或 warning 级别的错误,在 WEB 里可能不会有什么问题,也许就只是导致 WEB 的某个部分错位或乱码。但如果是 API,就会严重调用的客户端了,如果是手机APP,那闪推啥的,是必然的,如果同样也是Web调用,也可能会出现 Server Error 了
6、一定要重点考虑稳定性和响应速度,因为我们在使用手机APP时,都不希望APP经常闪推、而且希望应用很流畅

话说,牛逼的架构,一般都有自己的 API 框架!

这里给 ThinkPHP 打个广告:
目前 ThinkPHP 5ThinkPHP 家族的一个颠覆性重构版本,Slogan:为 API 而生

再扯一下腾讯、微博、淘宝等这些个开放平台吧,
它们所谓的开放,其实就是给开发者提供一系列的API,开发者根据他们提供的技术文档,按规定的调用方法,调它们提供的接口,你就可以获取到他们的相关信息,
例如:QQ用户基本信息、微博登录、淘宝店铺、商品消息等等。然后开发者再根据这些数据,在你的应用里完成交互。
另外,我们常用的 Ajax 其实也是 API 调用的一种体现形式

微信公众号:程序员到架构师

最新文章

Return Top