手下某个网站的架构有关问题和考虑的对应策略
手上某个网站的架构问题和考虑的对应策略有时间就写下来留此存照， 要不然过段时间就忘记了。架构这种的东西
手上某个网站的架构问题和考虑的对应策略
有时间就写下来留此存照， 要不然过段时间就忘记了。
架构这种的东西，系统不崩溃，客户是不会关心的，能跑就好。
所以这些问题， 多半会不了了之， 成为我自己一个人的意淫。
所以更要写下来， 留给自己一段美好的回忆。
现存的架构图
现存架构概要 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#
