从为什么要重构到微服务架构.docx

从为什么要重构到微服务架构
公司决定将支付业务从原来所在部门剥离出来，成为一个独立的团队，以应付迅速发展的业务需求。原团队负责支付系统开发的几位同学转到现团队，形成开发班底。此后开始招聘，三个月团队扩充到10多个人。与此同时，公司业务也在300QPS。公司业务增长迅猛，数据量半年翻一番，访问量预估10倍增长。还有一个严峻的挑战，产品同学扬言要搞秒杀，秒杀…每秒十万的量必须支持到。这就超过MYSQL能承受的压力范围，需要把读操作切到内存数据库上，但是在SSH架构下，读写分离实现就得伤筋动骨了。另外由于Hibernate封装了对数据库的操作，不用写SQL了，精细优化也搞不定了。每次系统变慢，就得求DBA,帮看看有那些SQL被卡住了。每隔一段时间，还得请DBA导出SQL语句，研究怎么建索引。
系统臃肿，学习周期长
100多个接口，分为三个大项目。最大项目有1300多个类，其次是600多个和300多个类。
SSH架构，SVN版本控制，resin作为容器，Nginx前置路由。路由这个让人欣慰，它是整个重构工作的有力支撑。纯后端的项目，为移动端app，PCWEB应用提供接口。这也使得重构工作难度大大降低。如果把前端也耦合进来，那就更酸爽了。
庞大的系统规模为团队成员接手带来困难。支付业务独立出来后，开发人员从原来的5人，在2个月内扩充到10人。与此同时，兴奋的产品同学也都跟打鸡血一样，各种想法纷纷变为产品，开发压力骤增。但是新增的同学，看着几百个类，往往一片茫然，无法下手。不知道哪些功能实现了，哪些功能是待改进的。一直到3个月后，新员工才逐步进入角色。尽管如此，还是有不少恐龙级代码，无人敢挑战。最大的一个类的规模是2000多行，核心方法超过500行，大量重复代码，每次调整都以失败告终。
合作成本高
随着项目组人员增加，每次新版本开发都需要多人一起合作，修改同一个项目代码。虽然使用版本控制工具来对分支进行管理，但是不可避免的，大量的时间花费在代码冲突处理上。新增功能，增强功能，bug修复，支持各种客户端，都在一个项目上进行，需要建立不同的分支，高峰期五六个分支同时进行都是常见的。这种情况下，代码冲突的频率非常高。一个周的小版本开发，1天时间在解决冲突都是很正常的。
测试难度大
测试工作也逐步的恶化了。
测试环境构建难度高。随着分支的增加，每个进入测试的分支，都需要准备独立的测试环境。环境构建成本高。
刚测试完的功能，由于分支合并冲突处理，又得重新跑一遍。严重影响项目进度。
上线风险高
随着系统复杂度的增加，上线风险也越来也大。一个小功能的修改，打印一个日志，修复一个bug，都需要整体上线。一旦有一个地方修改错了，这个系统就崩溃了。上线时间长，一次上线，半个小时是必须的。
引入新技术困难
互联网公司对新技术的追求和使用显得特别饥渴，SSH框架降低开发难度和成本同时，也屏蔽了其他技术的导入。缓存机制，数据库优化，读写分离等，SSH有自己的一套逻辑体系，要调整姿势，成本相对高，技术难度也大，需要对实现底层有深入了解。
CONWAY'SLAW
很长一段时间，这个系统是2-3位开发人员在维护，对外接口、运营系统，都混杂在一起实现，访问量也不算大。3个独立系统，对应3个版本库，每个人负责1-2个系统。当有新功能添加到系统中的时候，大家优先考虑