平台架构

1年多了，完全这个文集的事忘记的一干二净了，直到今天，偶然浏览一下自己的文章。

这一年多的时间我们的产品陆陆续续发生了很多事情。「微客多」产品「已死」，或者换一种方式叫「重生」。

因为跟腾讯的某种关系我们代理了腾讯高朋旗下的微商产品（我们就叫项目 W），这个产品完全是新项目，重新组队招人做。但是人很难找，不排除公司给的工资比市场低的可能。最后放低要求招到了4-5个人，然后开始干活。

项目借鉴「微客多」，但是优化了以前的表结构，架构。但是实际上很多功能都是「微客多」做完之后，「项目 B」重新 Copy 过来，做一些重复性的工作。

刚开始「项目 B」可能改的不错，但是后来估计也是项目时间进度紧张，有些地方就懒得改了。

随着每份需求可能要做两边，然后开始考虑做两个项目合并的事情，合并之后好出多多，这就是所谓的平台架构。

但是合并说起来容易，做起来真的很难，难是的是数据迁移问题。于是从开始合并之后，「微客多」只修改 bug，不做新需求。前两个月可能改一下 bug，后面基本上没动过微客多的代码了。

合并之后的项目，代码只有一份了，好维护，用户登录之后会根据不同的平台标识显示不同的 LOGO，不同的平台，价格是不一样的，打着高朋团购的牌子当然要贵的多。

一个 SAAS 平台不可避免的会出现定制单，因为一个产品不可能满足所有的需求。

定制单我们的怎么做的呢？还是把主项目代码 Copy 一份过来改，然后这样后面就会导致一个问题，我们的主项目一直再快速的更新迭代做新需求，越到后面，代码和定制单差距越大，然后有一天我们的定制客户突然想用我们的主项目新功能了怎么办？还能怎么办？重写呗。

其实我们还有一个好办法，我们把公司的业务模块拆开来做，每一个模块都做成一个独立的项目，支持其他平台，这里的平台包括定制单。比方说我们做一个交易中心专门负责微信支付有关系的接口实现（包括微信发红包，微信退款），我们的邮箱系统，我们的 CDN 系统还有硬件系统，都按照支持多平台来设计架构。

数据是怎么打通的呢？可以使用接口，内网访问保证速度，有些接口保证必要的鉴权。