怕的话就放编译过或者混淆过的版本进去呗。
具体问题应该查看云服务提供商给出的用户条款里。

@domty
还有就是可能需要考虑到对服务器端的性能是否有影响，有影响的话尽量放到客户端上去搞。
还有就是数据安全性。

服务器端既要为 web 端负责，又要为 app 端负责啊。
所以你改了 app 就又要改 web 端。
如果这个需求是同时针对两个客户端的话，改服务器端或者客户端都行。
如果只是针对单一客户端的话，该这个客户端的。

不过考虑到审核问题，我觉得你的选择还是挺合理的。

@poorguy
感觉前端的模块化和组件化也是早晚的事，未来的开发模式可能越来越像 node 的开发模式，用 node 开发小型的功能模块应该会很快。

jquery+ajax 不是 b/s 架构吗？
b/s 架构有 cookie 和 session 哪，认证的时候查 session 登录状态不就行了吗

你去支付宝的开发平台看它给的官方文档就知道了
支付宝支付完成要向你支付回调接口发送支付状态数据 你可以在这个接口里专门设置一个状态

充值页做一个定时 ajax 查询，当查询支付状态成功的情况下修改页面状态

当然现在好像有 web socket 这种东西模拟 b-s 的长连接， server 接收到支付成功的时候直接向浏览器推送支付成功消息就行。

mobiscroll 的做法貌似是把整个 input text 做成 disable 的了，调调背景颜色让它看上去像正常可用的 input 就行

样子看起来像 mobiscroll 啊
我以前好像做过类似的

一个国家一个吧 这样即使一个挂了也不影响其他的

@li24361
什么意思？
下订单和支付不是两个流程吗 支付和扣款在服务器端看来应该是一个过程里的吧

用户点击发出支付请求 服务器端获得请求后 先效验 之后扣除用户款项 修改订单支付状态 返回请求结果

假使你把扣款 修改支付状态等分拆成单独的服务接口 也应该存在 rollback 或者 commit 的执行步骤吧，否则一旦在支付过程中出现错误已修改的数据就无法恢复了。
假使以上这些数据库操作都是异步的，粗糙点想，当一个请求新进入消息队列后，先检测消息队列的长度，一旦队列过长（比如大于某个设定的阈值），直接返回创建请求失败。给每个请求的执行时间设定一个超时时间，一旦超过超时时间直接中止执行就地回滚。

我只做过小型的订单支付模块，以上只是我的理解。

@Sharuru
+1

把定语去了 就是同时 显示 最大整数和最小整数
最大整数和最小整数是什么？

支付，扣款，回复结果放一条事务里执行，失败回滚
扣款失败等于支付失败，查钱的时候等于没被扣过款

@tanteng
别想太多了， cookie 在谁手里谁就是主人，最多超时时间设短点让人家答题频繁点。
再想做下去，感觉你要付出的成本会高很多，而提升的效果未必理想。

这不就是一种另类的登录方案吗？
用 session 啊 或者类似 session 的有超时时间的服务器端缓存啊。
cookie 存 sessionid ， session 就是个以 sessionid 为 key 的键值对啊，值对象里存是否通过验证字段。
超时清楚该 session

def add(x:Int)(y:Int) = x + y

我就是发个感慨，另外你们有的回答有点跑题了
我就是干 java web 的，开始找工作了，在 V2EX 的酷工作板块翻了几页，看到的找服务器端的都是招 php/python/node 的，真正找 java web 的相对少些
而且现在讲究前后端分离，半调子 java+半调子 javascript 感觉不好找工作啊

楼上说的对,找个国内提供比较好的云服务提供商,负载均衡的问题交给他们去解决,比你自己解决的成本低很多

简单点的做法就是像你说的 把数据库层打包组织成 lib,然后维护这个 lib 给两个项目

或者可以试试吧数据库层和服务层的代码打包做成服务器内置服务,提供被调用的接口给两个项目用.
其余两个项目主要做 接收请求->解析请求->转发给内置服务->获取内置服务结果->回复请求
你看这个办法行不?

行业不景气....