app服务器

http://heipark.iteye.com/blog/1847421
http://heipark.iteye.com/blog/1847421
http://wenku.baidu.com/view/f761cc1f55270722192ef769.html


服务框架:
1、servlet
2、netty
协议：
1、http 1.0
2、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的配置介绍。



3、数据库
数据库有Mysql、Oracle、SQL server等这些都是关系型数据库，还有非关系型数据库：memcached、mongodb、redis等。建议了解各种数据库的特点，根据自己的业务模型，选择最优的搭配。

4、开发语言
开发语言有很多python、php、perl、c++、java...基本上大部分语言都可以开发后台。每种语言都有自己的特点与框架，像这些语言都有很多公司用。
据我所知，使用python作为后台开发的有知乎、豆瓣、quora，而且现在大部分的新型互联网公司都倾向于使用python作为后台的开发语言。
python作为后台开发主要是可以实现快速的开发，同时可供选择的开发框架也有很多，比如：flask、django、tornado、bottle等。建议了解这些框架的特点。

6、数据交换格式
protobuf、json、xml。。。
这里面最节约空间与速度最快的是protobuf，一般使用json就好了，json的在空间与速度上都优于xml。如果是特别追求节约空间与速度就使用protobuf。
...


http://uwsgi-docs.readthedocs.org/en/latest/



某手机公司应用商店App（客户端、服务器端
具体要求：
1、需要有Coin金币中心；有账户系统，充值系统（voucher充值）；
2、应用商城还需要包含（含壁纸，视频，主题）；
3、网页版本（可选）。
4：服务端安装（新加坡亚马逊云），后台系统维护（中英文界面）；
5：金币对CP提供计费SDK。
6：app含新闻，新闻为从当地主要网站抓取。新闻含网盟代码；
7：app带消息推送，自动更新功能；
8：支持平板电脑；
9：另增加手机第一次开机上报功能，后台数据导出功能。
10、消息推送（采用第三方平台）
11、二维码扫描功能。
开发商要求：
1、        成熟的App开发经验，最好具有app market开发经验。
2、        具备公司资质。


移动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格式等等。
总之，要达到的目标就是让不同的端能够很方便的使用你的接口。

2、良好的响应速度
如果要用一个指标来衡量接口的性能的话，那么我想最重要的就是响应速度了。
接口应该以最快的速度将数据返回给请求者。
试想，当我们打开一个页面，如果“努力加载中”之类的提示超过三五秒钟的话，
我们肯定会变得不耐烦，移动app本来大部分就是用户在碎片化时间来使用的，
在有限的时间内，用户恨不得获得的信息越多越好，即使你的app界面设计的再好，用户也不会买账。

提高响应速度又是个老生常谈的问题，大体上应该按照以下步骤来做：
初期，以功能为主，要保证功能完整，满足业务需求，这阶段可以使用动态的语言，比如java、php、asp.net等，
配合设计良好的数据库结构和索引，能满足一定的需求；
其次，随着用户的增多，可以考虑一些缓存方案，缓存是解决性能问题的万金油，通常能起到立竿见影的效果。
最常用的静态文件缓存，memcached内存缓存等。
然后，单台机器的吞吐率不行了，通过负载均衡多加几台机器就行了。七八台机器，支持每天千万级的接口调用是可行的。
或者，直接采用CDN的解决方案，将绝大多数的静态资源交给CDN去处理。

总之，要达到的目标就是快，一个页面，秒开最好，超过三秒就需要找找原因了。

3、接口要为移动客户端考虑

接口不仅仅是提供数据和功能就完事了，更应该充分考虑移动端的特性，为移动端提供更加方便、快捷的接口。
比如，在移动端里，下拉刷新和上拉加载更多是很常见的功能，如果接口仍然按照传统的web思路，
只提供按页读取的话，就会造成移动端的额外的数据请求和计算。 这时，接口就应该针对这两种类型的操作提供额外的支持。

再比如，对于一个新闻阅读类的app来说，最新的新闻列表里的文章，特别是前几条，用户很容易点击进去看，
而后面的老的文章列表，一来用户下滑加载好几页的情况较少，二来过时的新闻用户也很少点。
如果，接口在返回新闻列表时，对于最新的列表，可以直接把文章的正文（或者部分正文，比如一屏的内容）信息一起传给客户端，
这样，用户在打开新闻详情页的时候，就不用再从服务器端获取了，自然可以做到秒开。

比如访问第一页时，接口可以返回文章内容，如下所示 ，content=1表示加载文章内容
newslist?page=1&pagesize=20&content=1
其他页时，newslist?page=5&pagesize=20&content=0 ,不用加载文章内容。

当然，客户端要跟接口做好配合，搭配好，才能最大化的提高性能。
比如，移动端都有左右滑动来看上一篇、下一篇文章或者图片的功能，
如果，当用户请求某篇文章的时候，服务器端顺便也把下一篇文章的内容返回回来了，

那么当用户看下一篇的时候，是不是就很快了呢。

当然这种preload的方案也不能滥用，如果预加载数据的命中率较低的话，也不行，白白浪费了很多的流量。

4、考虑移动端的网络情况和耗电量

如果让我们说出哪类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有大量的计算、有很炫的视觉画面都会消耗电量， 另外，不断的移动网络链接也会消耗大量的电量，
我们都知道移动网络是通过无线电波来通讯的，那么发射装置就需要消耗一定的电量来发射和接收无线信号。
特别的是，频繁的链接会不断的切换网络设备与移动基站之间连接状态，这都会消耗一部分电量。

所以，对于接口而言，尽量用少的链接传输多的数据，
比如，对于关于我们、版本更新以及一些系统配置信息，完全可以通过一次链接全部返回给客户端。

5、通用的数据交换格式

目前，对于接口和客户端的数据交换格式，基本上就是两种，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'
}

6、接口统计功能

在做PC端网站的时候，我们都会给我们的网站加上个统计功能，要么自己写统计系统，要么使用第三方的比如GA、百度等。
移动端接口API则需要我们自己实现统计功能，
这时就需要我们尽可能多的收集客户端的信息，除了传统的IP、User-Agent之外，还应该收集一些移动相关的信息，
比如
手机操作系统，是android还是ios，都是什么版本，
用户使用的网络状况，是2G、3G、4G还是WIFI
客户端APP是什么版本信息。

这样，有助于我们更好的了解我们用户的使用情况。

7、客户端与服务端的肥瘦平衡

在以前C/S、B/S架构时，我们就已多次讨论过这个问题，客户端是瘦点好还是肥点好，当然也没有固定答案，需要自己根据实际情况去做权衡。
但是，在移动开发中，由于客户端的修改会很费时费力，特别是IOS应用还要经过Apple审核，
另外，当前IOS开发人员、Android开发人员的人工成本普遍较高，人才紧缺，
基于这两点，能在服务器端实现的功能就不要放在客户端，毕竟服务器端程序的修改要比客户端方便、灵活、快捷的多。

8、隐式用户与显式用户

显式用户和隐式用户，我不知道这两个词用的是否确切。
显式用户指的是，APP程序中有用户系统，一个username、password正确的合法用户，称之为显式的用户，
通常显式用户都需要注册，登录以后能完成一些个人相关的操作。

隐式用户指的是，APP程序本身就没有用户系统，或者一个在没有登录的情况下，使用我们APP的用户。
在这种情况下，可以通过客户端生成的UDID来标识一个用户。

有了用户信息，我们就能够了解不同用户的使用习惯，而不仅仅是全体用户的一个整体的统计信息，
有了这些个体的信息之后，就可以做一些用户分群、个性化推荐之类的事情。

9、安全问题

网络安全已经从桌面互联网转到了移动互联网，从客户端蔓延到了接口API中。

传统固若金汤的网站，很可能因为接口的一点疏忽而遭受入侵。现在，在很多白帽子或者黑客的入侵思路中，

先看看移动端接口是否存在漏洞，再看网站是否有漏洞。
客户端APP与接口的通信很容易被得到，只要在中间路由上嗅探一下就行，
whireshark、tcpdump这类工具使得这项工作变得简单无比。

所以，接口的安全工作不能马虎，暴力破解啊、SQL Injection啊、伪造请求和数据啊、重复提交啊也要考虑到,
如果数据特别敏感，可以考虑采用SSL/TLS等加密传输，或者客户端、服务器端约定一个加密算法和密钥，对来往传输的数据进行加密、解密
如果不采用RESTful API，可以采用基于WSDL和SOAP的Web Service的安全措施。


10、良好的接口说明文档和测试程序

接口文档有时候是项目初期就定下来的，前后端开发人员按照接口规范开发，
有的是接口开发完成后写的。
接口文档要清晰、明了，包含多少个接口，每个接口的地址、参数、请求方式、数据交换格式、返回值等都要写清楚。

接口测试程序，有条件的话，也可以提供，方便前后端的调试。



11、版本的维护

随着业务的变化，客户端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).