想设计一个类似支付宝的在线支付系统，问如何着手？

Question

想设计一个类似支付宝的在线支付系统，用j2ee，jms，这里的难点在哪里？ 如何构架更有效，更易于扩展？如何和hoop结合？

Answer 1

难点在于

1. 申请支付牌照

2. 跟银行谈判

顺便问一下，你是开玩笑的吧，大概基础架构什么的心里都没数就做在线支付系统？

---

虽然我了解得也不多，不过可以大概提一下。这个跟语言无关。每个部分都可以选择不同的具体语言来实现；但是对于性能要求比较高的部分，可能还是免不了要引入C/C++来实现。

首先是最前端，与用户打交道的WEB端。考虑到用户量的问题，必然要做负载均衡。硬件或者软件都有很多解决方案，比如软件可以用开源的nginx、haproxy、lvs什么的。WEB端的基本功能是 用户服务平台、支付网关、商户服务平台（提供针对商户的订单管理功能）。

在WEB后面需要一系列的服务相互配合，这里细节略去。详情可以参考各支付平台给商户的各种文档，里头可以窥知一二。

服务的背后就是数据，所以必然得有数据库，得考虑用什么数据库。然后要考虑的两个主要问题是：1. 数据量、请求量都很大，怎么解决压力的问题。分库分表什么的，少不了；这还不够，你不能把所有请求都直接扔给数据库，所以得引入memcached/redis之类的来作为缓存；有了缓存，又得考虑数据的一致性问题…… 2. 数据的安全性，主从同步、数据恢复这些东西我都不是很熟，必然得有专业的DBA才行。

在整个核心支付流程之外，还得考虑支付的风险，这得在支付流程内外都安插一些环节。你所提到的https，这个是最最基本的。在网络传输中被拦截数据的风险远小于在客户端被拦截的风险，所以你得有安全控件。这还远远不够。即使密码泄漏了，你也得用一定的方式保证用户的资金不被任意使用，跟不用说常见的欺诈、钓鱼之类风险，在这里，安全控件也能帮上不少的忙，详情可以参见知乎这个问题，里面有Fenng和白鸦的回答。

除了支付，你还得考虑保障后勤工作的清算对账，核对支付的疏漏。比如说我在评论里提到的，重复支付的问题是不能完全避免的，就得靠清算对账来完成。通常支付平台还得给商户提供流水以供商户核对。

以上列出的是我的一些粗浅了解，而且还仅限于技术的主要方面，其他的诸如费率、风险运营策略、商户运营策略（嗯，你们还得给商户提供各种语言的SDK以便接入，于是又得提供商户接入技术支持什么的）我了解的就更少了。

最后我的建议是，你们还是得找专业的人来做。要知道，在这个跟钱直接打交道的地方，一个小疏漏的后果可能就是几十上百万的损失。这种事情并不是没发生过。

Answer 2

任何技术难题都能实现，但问题时，你有支付牌照么？

Answer 3

调用支付宝API 和PAYPAL API 你就可以全球通用了，何必那么麻烦

Answer 4

我说各位，也许LZ是为了学习呢？