手上某个网站的架构问题和考虑的对应策略

有时间就写下来留此存照， 要不然过段时间就忘记了。

架构这种的东西，系统不崩溃，客户是不会关心的，能跑就好。

所以这些问题， 多半会不了了之， 成为我自己一个人的意淫。

所以更要写下来， 留给自己一段美好的回忆。

现存的架构图

现存架构概要 1. 名为www.xxxpay.com的支付系统，承担SSO单点登录和支付的双重作用 2.支付系统前端的portal是单例部署， 考虑到支付流程的可靠性，需要session保持，没有横扩展 3.Logic-API采取Restful架构，no share，无状态。 与portal之间的报文用密钥加密，可以轻松横扩展 4.数据库采用mySQL主从备份 4.与网银的接口包括由logic-api发出的加密报文，专用的batch服务器跑的job等 5.名为www.xxxshoping.com的B2C网站，通过画面跳转，加参数，跳转到支付系统的login画面 支付系统的login画面做完login，生成loginToken，持久化到数据库中 并且将loginToken和帐户名保存到Memcached中 loginToken和帐户名被作为http response发回客户端，保存入Cookie 下次再打开该B2C网站，首先redirect到支付系统，确认login。 由此实现跨域SSO 现存架构的主要问题和考虑对应 1. Portal是单点部署， 生产环境应该严禁单点部署。 对应： 应该考虑用Web服务器集群。 考虑用Session Memcached 2. login功能和支付功能耦合在一起，不利于系统横扩展。 对应： 将login功能和支付功能拆分成两个子系统，子域名。 Login功能考虑用Oauth来平台化 随之伴随着将数据库拆分，按业务纵切分。 3. 支付系统中，长事务结构太明显，从前端画面到后端网银API的调用，支付链条太长，事务纵深太大。 对应： 在连接网银API前面加一个JMS容器， 将支付过程由同步变成部分异步。 这个系统用于灾备， 在原有系统的压力达到一定的阀值的时候，作为应急切换。

#by Tony@nanjing#

#2013-3-18#