1.1 艰难的决定 -- 系统重构
1.1.1 外贸B2C平台野蛮生长期
5年前，笔者刚入职现在的公司，进入后主导负责一个B2C外贸电商网站，时值外贸电商野蛮生长期，基本随便上一个小型B2C网站鼓捣推广几个月便可盈利，其中最大的一个站点后来达到单日最高13W美金，日PV 400W，当时整个项目团队每天沉浸于高额销售额的喜悦下，所谓一白遮百丑，由于销售额的高企，潜藏于背后的海量问题一直未能爆发
1.1.2 业务和技术矛盾爆发期
14年10月，平台冲向了最高销售额后，情况开始急转直下，首先是销售额由于友商竞争及一些其他问题开始腰斩，其次，由于平台技术架构的不合理网站开始频繁崩溃，业务和技术冲突开发爆发，笔者作为技术，对业务情况不大清楚，这里着重介绍下技术层存在的问题
最大的平台架构之初，是作为一个小型卖货网站来搭建的，其本身负载能力非常弱，平台架构的重大原罪如下[以下简称旧平台]：
静态化问题：系统架构初时，犯了很多小型电商网站会犯的毛病，前台详情页和列表页全部生成了静态页，这在后面造成了少量的问题，最大的问题就是数据不实时问题
单库问题：数据库只有一个单库，后面做了主从，但实际优化有限
弱缓存问题：前期基本没引入什么缓存，后面加入了redis缓存，这方面做得很弱
服务器提供商问题：我们当时用的一个传统物理服务器提供平台，该平台的服务器老化问题比较严重，经常出现硬件性故障，给我们制造了不少麻烦，时至今日，放在上面的一些小网站还时不时出事
系统百家争鸣问题：我们最多时同时运营了7个B2C平台，这些平台每个系统的架构都不一样，有的基于ecshop、有的基于magento、zencart...造成的问题是，团队技术最多时达到了快50人，但平均到每个平台的后端最多也才4、5人左右，由于互相不熟悉各自的系统，各个平台的人力无法共用，这造成了非常严重的人力浪费，后来平台业务下降期，好多人陆续离职...
平台人力不足问题：由于百家争鸣问题的存在，导致资源向最大的平台倾斜实在有限，技术层面的问题，很多人都知道，但由于资源限制，很是有心无力，平台除了功能开发和维护，很难调出太多精力对最大的平台进行大的架构调整
其它小问题...
1.1.3 碌碌无为的15年上
15年初，作为最大平台的主程，有感于混乱的现状，我向总裁办提出了外贸B2B2C系统重构计划，但当时旧平台虽然在业务下滑期，依然还有着不少的销量，所以一方面总裁办同意了重构计划，另一方面需要保证旧平台的正常运作和功能开发，理解公司苦衷的同时，不得不吐槽下，这实在是件鱼和熊掌不可兼得的事
1.1.4 匆匆上马的重构1期失败版
15年中我升级部门副经理，9月开始着手重构事宜，当时调过来着手重构的开发只有4人[团队精英]，由于我想快马加鞭赶紧上线新平台，所以很多东西没有经过仔细调研，在2个月后完成了第一期的开发便着手上线事宜，不过由于一些重大功能的缺失，被紧急喊停，这是我管理失败
整个2015年就几乎这样混完了，15年底16年初，我们团队组织架构调整，迎来了新的技术总监兼部门经理......
1.2 血战2016
新的技术总监经过长期调研后，认为商城平台整个架构有必要全部推翻重做，经过和总裁办协商达成一致，老平台只留一人进行维护，不进行新功能开发，其它人员[18人左右]全部调入新平台重构项目进行封闭开发
1.2.1 长达半年的封闭开发
2月底，公司给我们租了一个酒店，新平台的开发人员全部转入这个酒店封闭开发[作息时间比现在IT业流行的996还要恐怖得多]，开发期间，各种方案探讨、技术调整细节不表，到6月底，我们出关...
1.2.2 系统调整期
16年10月我们开始进行平台迁移，到17年3月新平台开始稳定，这期间主要进行一些bug调整和性能调优
1.2.3 系统重构总结
B2B2C：
通过这次重构，我们基本整合了所有平台，以后需要新增站点，直接添加平台即可，避免再踩入过度浪费人力的深坑
大量新技术的引入：
ELK日志系统
swoole服务化
mongo代替mysql
elas替换sphinx搜索引擎
数据交换中心
......
架构上云：
使用阿里云和亚马逊云代替传统物理服务器提供商
CDN合理利用：
CDN合理利用代替静态化技术
小结：
笔者有幸见证了这个平台业务层面的起萌到辉煌，再到没落，直至现在的重新起跑，技术层面的浴火重生，跟随这个项目一起大起大落，一起成长，感恩一起奋斗的兄弟，感恩平台，感觉公司。以下的章节，将围绕我们的新平台技术架构开始展开。
