http://heipark.iteye.com/blog/1847421
http://heipark.iteye.com/blog/1847421
http://wenku.baidu.com/view/f761cc1f55270722192ef769.html
服务框架:
一、servlet
二、netty
协议:
一、http 1.0
二、http 1.1
db:
mysql就能够了
ORM框架:
mybatis
缓存:
redis
技术:
网络通讯: tcp,http等;
Web服务:servlet, cgi脚本,asp等;
系统调度:多线程,并发等;
框架:
对应不一样的web服务技术,采用的编程语言不一样;
对应不一样的网络通讯协议,采用的框架也不一样,netty->tcp,servlet等web服务框架->http等;
对应系统调度,有不一样的多线程,多进程通讯框架等;
对应提供不一样的服务接口,有web service和restful两大类,前者基于soap协议,后者基于http协议,对应的框架就不少,不一一叙述;
你能够找本讲android的书看看,我记得不少国内的书都会在最后讲几个实战项目,涉及到服务器开发,最后建议你Java服务器开发框架能够用jfinal,实际上手机服务器开发就是作网站,输出的内容通常采用json
常见的服务器端编程技术有.net Java php python 等等
既然题主提到Android App,你不如去学习Java服务器端编程。
先系统的学习一下Servlet,安装运行Servlet的容量Tomcat
还得学习一下数据库,推荐MySql,练习简单的增删查改语句
学习Java链接数据库的方法JDBC
服务器与App交互数据推荐使用JSON
应该没有所谓的主流吧 - - 我只知道instagram使用了nginx、django、Gunicorn。。。
像instagram这么多用户的应用后台绝对不是这么简单。What Powers Instagram: Hundreds of Instances, Dozens of Technologies这篇文章是他们公布的架构,可供参考,另外网上也有一些逼人翻译与分析的文章。
最后说下个人用法:
目前使用nginx+uWSGI+flask
flask是python的一个轻量级框架,上面有介绍。
nginx主要是处理静态的请求,动态的交给uWSGI。
uWSGI是一个服务器,使用它能够很方便的部署python应用,并且处理速度也比较快。
网上能够找到不少关于nginx+uWSGI+flask的配置介绍。
三、数据库
数据库有Mysql、Oracle、SQL server等这些都是关系型数据库,还有非关系型数据库:memcached、mongodb、redis等。建议了解各类数据库的特色,根据本身的业务模型,选择最优的搭配。
四、开发语言
开发语言有不少python、php、perl、c++、java...基本上大部分语言均可以开发后台。每种语言都有本身的特色与框架,像这些语言都有不少公司用。
据我所知,使用python做为后台开发的有知乎、豆瓣、quora,并且如今大部分的新型互联网公司都倾向于使用python做为后台的开发语言。
python做为后台开发主要是能够实现快速的开发,同时可供选择的开发框架也有不少,好比:flask、django、tornado、bottle等。建议了解这些框架的特色。
六、数据交换格式
protobuf、json、xml。。。
这里面最节约空间与速度最快的是protobuf,通常使用json就行了,json的在空间与速度上都优于xml。若是是特别追求节约空间与速度就使用protobuf。
...
http://uwsgi-docs.readthedocs.org/en/latest/
某手机公司应用商店App(客户端、服务器端
具体要求:
一、须要有Coin金币中心;有帐户系统,充值系统(voucher充值);
二、应用商城还须要包含(含壁纸,视频,主题);
三、网页版本(可选)。
4:服务端安装(新加坡亚马逊云),后台系统维护(中英文界面);
5:金币对CP提供计费SDK。
6:app含新闻,新闻为从当地主要网站抓取。新闻含网盟代码;
7:app带消息推送,自动更新功能;
8:支持平板电脑;
9:另增长手机第一次开机上报功能,后台数据导出功能。
十、消息推送(采用第三方平台)
十一、二维码扫描功能。
开发商要求:
一、 成熟的App开发经验,最好具备app market开发经验。
二、 具有公司资质。
移动APP服务端API设计应该考虑到的问题
2014年,移动APP的热度丝毫没有减退,并无像桌面软件被WEB网站那样所取代,
不但如此,愈来愈多的传统应用、网站也都开始制做本身的移动APP,也就是咱们常说的IOS客户端、android客户端。
这仿佛又回到了多年前的CS架构,那时候咱们用VB、VC、Delphi在Windows平台上快速开发各类应用程序。
不一样的是,现在的移动端APP基本上都是联网从服务器端获取各类数据,客户端只是一个简单的表现层的工具。
不只仅是移动APP,包括面向服务的SOA架构,都须要制定一套统1、规范的接口,
那么,作这样的后端接口须要注意哪些问题呢?
一、跨平台性
所谓跨平台是指咱们的接口要可以支持不一样的终端,好比android、ios、windowsphone以及桌面软件、网站等,
一套接口,支持多端,就像当年Java的口号同样“Write Once,Run Anywhere”。
固然从本质上讲,服务器端的接口跟终端是没有太大关系的,只是接口应该考虑到不一样端的接入成本,
采用通用的解决方案,好比通讯协议就采用最经常使用的HTTP协议,若是是即时通讯,能够采用开放的XMPP协议,
作游戏的能够采用可靠的TCP协议,除非TCP不够用了,再采用定制的UDP协议。
数据交换采用xml或者json格式等等。
总之,要达到的目标就是让不一样的端可以很方便的使用你的接口。
二、良好的响应速度
若是要用一个指标来衡量接口的性能的话,那么我想最重要的就是响应速度了。
接口应该以最快的速度将数据返回给请求者。
试想,当咱们打开一个页面,若是“努力加载中”之类的提示超过三五秒钟的话,
咱们确定会变得不耐烦,移动app原本大部分就是用户在碎片化时间来使用的,
在有限的时间内,用户巴不得得到的信息越多越好,即便你的app界面设计的再好,用户也不会买帐。
提升响应速度又是个老生常谈的问题,大致上应该按照如下步骤来作:
初期,以功能为主,要保证功能完整,知足业务需求,这阶段可使用动态的语言,好比java、php、asp.net等,
配合设计良好的数据库结构和索引,能知足必定的需求;
其次,随着用户的增多,能够考虑一些缓存方案,缓存是解决性能问题的万金油,一般能起到立竿见影的效果。
最经常使用的静态文件缓存,memcached内存缓存等。
而后,单台机器的吞吐率不行了,经过负载均衡多加几台机器就好了。七八台机器,支持天天千万级的接口调用是可行的。
或者,直接采用CDN的解决方案,将绝大多数的静态资源交给CDN去处理。
总之,要达到的目标就是快,一个页面,秒开最好,超过三秒就须要找找缘由了。
三、接口要为移动客户端考虑
接口不只仅是提供数据和功能就完事了,更应该充分考虑移动端的特性,为移动端提供更加方便、快捷的接口。
好比,在移动端里,下拉刷新和上拉加载更可能是很常见的功能,若是接口仍然按照传统的web思路,
只提供按页读取的话,就会形成移动端的额外的数据请求和计算。 这时,接口就应该针对这两种类型的操做提供额外的支持。
再好比,对于一个新闻阅读类的app来讲,最新的新闻列表里的文章,特别是前几条,用户很容易点击进去看,
然后面的老的文章列表,一来用户下滑加载好几页的状况较少,二来过期的新闻用户也不多点。
若是,接口在返回新闻列表时,对于最新的列表,能够直接把文章的正文(或者部分正文,好比一屏的内容)信息一块儿传给客户端,
这样,用户在打开新闻详情页的时候,就不用再从服务器端获取了,天然能够作到秒开。
好比访问第一页时,接口能够返回文章内容,以下所示 ,content=1表示加载文章内容
newslist?page=1&pagesize=20&content=1
其余页时,newslist?page=5&pagesize=20&content=0 ,不用加载文章内容。
固然,客户端要跟接口作好配合,搭配好,才能最大化的提升性能。
好比,移动端都有左右滑动来看上一篇、下一篇文章或者图片的功能,
若是,当用户请求某篇文章的时候,服务器端顺便也把下一篇文章的内容返回回来了,
那么当用户看下一篇的时候,是否是就很快了呢。
固然这种preload的方案也不能滥用,若是预加载数据的命中率较低的话,也不行,白白浪费了不少的流量。
四、考虑移动端的网络状况和耗电量
若是让咱们说出哪类app比较好,可能还不大好说,可是若是让咱们说出哪些app不好,
咱们确定会说出那些 体积很大、占用内存多、界面很卡、费电的app很差。
对于移动APP开发者来讲, 网络流量和电池电量是不得不考虑的问题。
不过,您也许会说,这些跟接口没啥关系吧,服务器端的接口还能管得了客户端的网络流量和电量?
对于网络状况,接口应该具有为不一样的网络提供不一样的内容的能力,
一般,移动端的上网方式无非是2G(GSM、GPRS、EDGE)、3G(CDMA、TDSCDMA、WCDMA)、WIFI,
设想一下,若是用户在流量须要花钱的状况下,你的app给用户展现了视频、音频、大量的图片而没有通知用户的状况下,
用户会怎么想,毕竟国内的流量费用仍是很贵的。
还以上面的新闻列表接口为例,若是咱们可以知道用户的网络状况,只有在wifi的状况下才给用户传输封面图、缩略图之类的,
是否是能够帮用户节省不少流量呢。
newslist?page=1&pagesize=20&content=1&network=wifi
对于电量,首先咱们要弄清楚,app的哪些方面会消耗电量?
好比app有大量的计算、有很炫的视觉画面都会消耗电量, 另外,不断的移动网络连接也会消耗大量的电量,
咱们都知道移动网络是经过无线电波来通信的,那么发射装置就须要消耗必定的电量来发射和接收无线信号。
特别的是,频繁的连接会不断的切换网络设备与移动基站之间链接状态,这都会消耗一部分电量。
因此,对于接口而言,尽可能用少的连接传输多的数据,
好比,对于关于咱们、版本更新以及一些系统配置信息,彻底能够经过一次连接所有返回给客户端。
五、通用的数据交换格式
目前,对于接口和客户端的数据交换格式,基本上就是两种,xml和json,而如今使用json的应该占大多数。
交换的数据包括两种,一种是客户端请求服务器端接口时传递的一些参数,一种是服务器端返回给客户端的数据。
对于客户端的请求参数,如今也愈来愈多的接口要求采用json的格式,而不是以往最多见的key_value对了。
好比,接口须要username和password两个参数
key_value pair的方式是:
username=hutuseng&password=hutusengpwd
而后经过GET或者POST方式传送。
而经过json方式交换数据的话,格式以下,直接POST到服务器端。
{
'username':'hutuseng',
'password':'hutusengpwd'
}
对于服务器端返回的json数据格式,须要注意两个问题:
一是汉字编码问题,由于json(javascript)内部支持Unicode编码,会将汉字等转换成unicode编码保存,
因此在返回结果中,对于中文,能够直接输出中文,也能够输出中文的unicode编码,
json解析器都会很好的解析。
好比下面两种方式都是能够的。
{"code":"208","data":"\u53c2\u6570\u4e0d\u5b8c\u6574"}
{
"code": "208",
"data": "参数不完整"
}
二是字段的数据类型,特别是数字类型的,json中尽可能转成数字格式,
好比
{
'userid':128
}
不要写成
{
'userid':'128'
}
六、接口统计功能
在作PC端网站的时候,咱们都会给咱们的网站加上个统计功能,要么本身写统计系统,要么使用第三方的好比GA、百度等。
移动端接口API则须要咱们本身实现统计功能,
这时就须要咱们尽量多的收集客户端的信息,除了传统的IP、User-Agent以外,还应该收集一些移动相关的信息,
好比
手机操做系统,是android仍是ios,都是什么版本,
用户使用的网络情况,是2G、3G、4G仍是WIFI
客户端APP是什么版本信息。
这样,有助于咱们更好的了解咱们用户的使用状况。
七、客户端与服务端的肥瘦平衡
在之前C/S、B/S架构时,咱们就已屡次讨论过这个问题,客户端是瘦点好仍是肥点好,固然也没有固定答案,须要本身根据实际状况去作权衡。
可是,在移动开发中,因为客户端的修改会很费时费力,特别是IOS应用还要通过Apple审核,
另外,当前IOS开发人员、Android开发人员的人工成本广泛较高,人才紧缺,
基于这两点,能在服务器端实现的功能就不要放在客户端,毕竟服务器端程序的修改要比客户端方便、灵活、快捷的多。
八、隐式用户与显式用户
显式用户和隐式用户,我不知道这两个词用的是否确切。
显式用户指的是,APP程序中有用户系统,一个username、password正确的合法用户,称之为显式的用户,
一般显式用户都须要注册,登陆之后能完成一些我的相关的操做。
隐式用户指的是,APP程序自己就没有用户系统,或者一个在没有登陆的状况下,使用咱们APP的用户。
在这种状况下,能够经过客户端生成的UDID来标识一个用户。
有了用户信息,咱们就可以了解不一样用户的使用习惯,而不只仅是全体用户的一个总体的统计信息,
有了这些个体的信息以后,就能够作一些用户分群、个性化推荐之类的事情。
九、安全问题
网络安全已经从桌面互联网转到了移动互联网,从客户端蔓延到了接口API中。
传统固若金汤的网站,极可能由于接口的一点疏忽而遭受入侵。如今,在不少白帽子或者黑客的入侵思路中,
先看看移动端接口是否存在漏洞,再看网站是否有漏洞。
客户端APP与接口的通讯很容易被获得,只要在中间路由上嗅探一下就行,
whireshark、tcpdump这类工具使得这项工做变得简单无比。
因此,接口的安全工做不能马虎,暴力破解啊、SQL Injection啊、伪造请求和数据啊、重复提交啊也要考虑到,
若是数据特别敏感,能够考虑采用SSL/TLS等加密传输,或者客户端、服务器端约定一个加密算法和密钥,对来往传输的数据进行加密、解密
若是不采用RESTful API,能够采用基于WSDL和SOAP的Web Service的安全措施。
十、良好的接口说明文档和测试程序
接口文档有时候是项目初期就定下来的,先后端开发人员按照接口规范开发,
有的是接口开发完成后写的。
接口文档要清晰、明了,包含多少个接口,每一个接口的地址、参数、请求方式、数据交换格式、返回值等都要写清楚。
接口测试程序,有条件的话,也能够提供,方便先后端的调试。
十一、版本的维护
随着业务的变化,客户端APP和服务器端API都会发生变化,增长新的功能,修改已有的功能,
增长功能还好说, 若是是接口须要修改,那么就面临着同一个接口要同时为不一样版本的客户端服务的问题。
所以,服务器端接口也要作好相应的版本维护。
App server 与 Web server之间的区别
2009-12-17 12:02 1315人阅读 评论(0) 收藏 举报
serverwebweb服务服务器html浏览器
原文: http://www.javaworld.com/javaqa/2002-08/01-qa-0823-appvswebserver.html
app服务器和web服务器的区别是什么呢?
简单来讲,web服务器提供页面给浏览器,而app服务器提供客户端能够调用的接口。具体而言,咱们能够说:
Web服务器处理HTTP请求,而app服务器基于多种不一样的协议,处理应用程序的逻辑问题。
如下将详细介绍它们之间的区别。
Web服务器
web服务器处理HTTP协议。当收到一个HTTP请求以后,web服务器会返回一个HTTP响应,好比一个HTML页面。为了处理请求,它可能响应一个静态的HTML页面、图片、重定向,或者代理(delegate)其余动态响应。这些动态响应能够由其余程序生成,包括CGI脚本,JSPs,servlets,ASPs,服务器端的Javascript,或者其余服务器端技术。而这些服务器端程序响应,大多数时候都表现为HTML页面,供浏览器访问。
理解一个web服务器的代理模型(delegate model)相对比较简单。当web服务器接收到一个请求,它只是简单的将请求交给处理该请求的最优程序。除了为服务器程序简单的提供一个运行环境(服务器程序能够在其中运行,而且返回生成的响应)以外,web服务器不提供任何功能。服务器程序通常本身处理交换(transaction)、数据库链接、消息分发等。
虽然web服务器不提供以上的服务,可是它通常会提供诸如容错机制,负载均衡、缓存、集群等的可扩展性。然后者,通常来讲不该该部署在web服务器上,而应该在app服务器上!
App服务器
根据咱们的定义,app服务器能够基于各类不一样的协议(可能包含HTTP协议),为客户端程序提供应用逻辑的处理。不一样于web服务器主要发送用来展现在浏览器上的HTML页面,app服务器为客户端程序处理应用逻辑方面问题。应用程序使用这些逻辑,就如同调用一个对象的方法(或者面向过程编程中的函数)同样简单。
这些应用程序可能包含PC机上运行的GUI进程,web服务器,甚至其余的app服务器。app服务器和客户端之间的通讯并不局限于简单的显示标记,而是能够由程序逻辑,好比数据表单、方法调用,而非静态的HTML,这样,客户端程序就能够按需去用了!
在大多数状况下,app服务器经过元件API,好比基于j2ee app服务器的EJB,来提供应用逻辑。而更多的状况下,app服务器本身管理本身的资源。这些责任(gate-keeping)包括安全、进程交互、资源池、消息分发等。同web服务器同样,app服务器也可能须要各类可扩展性和容错机制。
一个例子
以一个提供实时价格和相关信息的在线商店为例,它极有可能提供了一个表单,用户能够选择不一样的产品并查询。它会查找,并经过HTML网页展现结果。这个网站可能有多种方式来实现这个功能,下面咱们将举两个相反的例子,一个不使用app服务器,而另外一个使用。经过这两个例子,能够帮助你理解app服务器的功能。
场景1:web服务器,而非app服务器
在这个场景里,web服务器独自提供在线商店的功能。它接受用户的请求,交给服务器端程序处理。该服务器端程序经过数据库,或者纯文本,查找到价格信息,而后生成HTML响应,经过web服务器返回给用户的浏览器。
总结来讲,web服务器仅须要接受HTTP请求,并响应HTML网页。
场景2: web服务器 + app服务器
同场景1同样,web服务器仍然代理脚本生成的响应。可是你能够把业务逻辑部署在app服务器上。这样,脚本就不须要去关注怎样查询和生成响应,而仅须要调用app服务器提供查询服务,从而利用其生成它的HTML响应。
在这个例子中,app服务器提供了价格查询的业务逻辑。这个逻辑不该该包含怎样去展现,或者强迫客户端使用这些数据。相反的是,客户端和app服务器进行交互,只有当客户端调用了app服务器的价格查询服务的时候,该服务才查找到信息并返回。
同HTML代码生成分离开后,价格查询逻辑的复用性提升了。另一个客户端,好比收银机,一样能够调用这个接口。而场景1里,价格查询服务就很难被重用,由于它和HTML页面紧密联系。
总结来讲,第二个场景中,web服务器处理HTTP请求,并返回HTML页面,而app服务器处理业务逻辑。
注意事项
近来,XML web服务器模糊了app服务器和web服务器的界限。发送一个XML请求给web服务器,web服务器能够像过去的app服务器同样,处理数据并返回响应。
另外,不少app服务器包含web服务器,这就意味着你能够把web服务器看作app服务器的一个子集。虽然app服务器包含web服务器的功能,可是开发者仍是不多以此身份发布app服务器。若是须要的话,他们一般将web服务器和app服务器分离开。这样的目的是,性能(简单的web请求不会影响到app服务器的性能)、发布配置(专用的web服务器,集群等)、更好的厂商选择。
About the author
Tony Sintes is an independent consultant and founder of First Class Consulting, a consulting firm that specializes in bridging disparate enterprise systems and training. Outside of First Class Consulting, Tony is an active freelance writer, as well as author of Sams Teach Yourself Object-Oriented Programming in 21 Days (Sams, 2001; ISBN: 0672321092).
javascript