我伴随公司走了4年了，我觉得有必要把我这四年来经历的技术架构的演进沉淀下来分享给大伙，里面有些内容不一定100%准确，因为有些已经记不太清楚了，如有偏差，请反馈给我哈，谢谢。
这个是我们早期的样子，17年2月份，我进入公司，那时候只有一个大的工程，里面大概有12个子工程；当时的工程是有服务化思维的，因此，采用了dubbo做服务化的隔离（用户、商户、报名单、岗位、青团宝）。dubbo的上层是web层，采用springMVC的框架进行入参处理。
这套有一个比较头痛的问题就是打包问题，当时的团队还没有将dubbo拆分到不同的工程中，这就出现了两个问题：
- 代码库没有隔离，导致大伙还是要在一个工程里开发，分支无数。
- 打包的容错率极低，只要任何一个项目有问题，打包都会失败；这是因为这12个工程都依赖一个大的parent配置。
于是，我们做的第一件事儿，就是将服务化拆分；通过把工程分开，把组织架构明确，每个人只维护自己的工程，迭代的效率当然也提高了不少。虽然应用架构被很好的剥离了，但我们又面临另一个问题，数据库是都放在一起的；这会直接导致
- 早期的RDS的监控功能不多，我们也没有开启日志，不能查看全量的sql（因为穷，得省着点花）。
- 早期的sql写的很差，甚至索引建的都是错误的；因此，全屏飘着慢sql，你都不知道CPU彪起来是哪个业务干的。
为了解决这个问题，我们继续拆分了DB，将DB隔离开，解决了业务之间因为慢sql影响的问题，但没有解决慢sql本身（后面有详解）。但分开之后，我们面临一个问题，就是级联查询没法用了面对运营跑sql的需求，我们得要写很多脚本，这极大程度增加了我们的工作难度。我们想了集中解决方案：
- 用ES来承接数据，做信息聚合操作，但问题一个是ES的成本在阿里云上太高了，我们用不起；另一个是ES的DSL学习成本也很高，有一些查询写不出来。
- 将所有实例的数据，通过binlog导入到一个实例中，这个带来的问题是，需要搭建一套canal，并要开发一套消费逻辑。
- 用数据工具将数据直接导入，例如：datax这种开源中间件。
我们基于阿里云，选择了方案3，通过云上的dts（数据传输工具），来将多实例汇总到一个实例中，我们基于这个实例开发整个的后台和数据中心功能。我们这套数据库体系跑了一年，还是比较稳定的，大概是在第二年才慢慢出现了一些瓶颈（后续阐述）。
随着我们迭代越来越快，我们爆发了另一个问题，就是当一个dubbo的接口做了更新的时候，没有意识去通知对方，直接导致系统报错。理论上，dubbo的接口一般是开闭原则，并不支持你在上面更新。但实际上业务在早期的时候的变化是非常快的，表的DDL变更相当频繁，如果每次都新追加接口，系统维护的成本会非常大，而spring cloud的http的接口，在接口的字段的增加和删除方面，有天然的支持。
另一方面，团队要快速扩招，那时候的我们没有钱，我们无法给出很有竞争力的薪资来招募那些能力很强的人。而dubbo这时候就显得很笨重，不仅要学会springMVC这一套，还要学习dubbo的服务化生态，学习成本十分高；因此，我们做了一个决定：把dubbo全面过度到springcloud体系上去。当然这件事儿，我们是一步步做的：
- 建立springcloud注册中心eurika，新的应用统一用cloud来写。
- 老的项目，如果调用新的，通过cloud客户端去调用。
- 将老系统由下往上梳理，下层提供全套cloud接口，上层一个个切换，这个阶段过程中是很痛苦的，因为整个系统体系中，cloud和dubbo是并存的，这里面我们踩了很多坑，比如dubbo重启的时候，eurika还没有摘掉，导致访问报错等。
这里顺便提一句，因为在cloud体系内，对内部和外部提供的接口，我们用的都是一套；那如何区分内部和外部的接口呢，我们是通过/cloudService/***加这么一个前缀，然后通过nginx来判断前缀，阻断外网IP访问的。这里有一些细节，为什么要阻断呢？因为内部接口和外部的接口的差异很大，外部接口要承载DDOS→WAF→网关的三层保护，还要有用户的token校验等；而内部接口天然保持信任，并没有很多校验。如果你把内部接口暴露到外网上，那等于你把家门给拆了，谁都能进来。
