作为公司的CTO，我入职公司已经有2年半了，从公司A轮开始，一直到现在的B+轮；从一个工程，到现在40多个微服务；从最早的只有一个mysql实例，到现在我们有十几个数据库实例，还有hbase、hybrid for mysql、hadoop、maxcompute、poloDB等存储演变；从当时只有两台nginx单点，到现在的lsb（阿里云LVS）、网关（spring cloud zuul → spring cloud gateway）、微服务负载均衡（ribbon）等；我们走过很多路、踩过很多抗，至今为止回忆起来，都觉得是一笔宝贵的财富。从这篇文章开始，我想一边回忆，一边随笔，把我们走过的这些路都记录下来，希望这些经历能给予看到这篇文章的人一些帮助。
记得刚到公司的时候，公司的技术部门大概有12人左右，在一个大厂房里，当时是2个安卓、2个IOS、4个后端、2个测试、2个前端。我记得我第一次给大家开会说道，我们今年要全力的提升技术架构，为公司下一个阶段做好储备.......当时的话，我记得我给予了大伙很大的压力，我以为这样的压力会让大家更加有危机感，好可以更加拼命的去工作，但我完全想错了；在未来的2周内，离职了近半数人...
我通过和每一个离职员工交流，我发现了问题，这些员工并不是那些985、211出来的，上一家公司的背景也是很一般，他们享受惯了安逸，并没有很明确的目标。所以，他们认为后面一定会很辛苦，而为这样的公司，没有必要付出这么多。
当时我记得还剩下来7名员工吧，而后来，这七名员工中，有四人一直跟我们战斗下来，现在成为了我们的核心人员，我应该为他们鼓鼓掌，我发现这几名员工他们同样是没有明确的目标，不是985、211，但他们有一项非常牛逼的能力——抗压力能力。其实当时的后端的工程是整个放在一个工程里的，虽然也有做服务化，但这个服务化是上一任CTO为了应对未来工程独立化提前做的，我倒觉得这是一个相当不错的选择，既没有让工程变得复杂，又能为未来考虑；当然，如果都放在一个工程里，去服务化，也不失为一个good idea。我记得我来做的第一件事儿就是服务化的拆分，把dubbo工程独立出来，拆出来一个个的project。
当时的架构图就是这个样子，所有的工程都在一个打的工程里，里面有dubbo的，有springboot1.x的，大概我记得一共有13个工程吧。这带来了一个头疼的问题，版本号和打包时间长的问题，所有的pom都依赖于最外层的一个大的pom，所以，每次打包都要全量的打，时间非常久。其次，某一个工程报错，会导致整个打包失败，效率比较低。因此，第一件事就是，把dubbo、web工程（spring boot）都独立出来。
独立化推进的过程还是很艰辛，版本号的冲突，代码的强耦合都给我们带来的了很大的负担，我们采用一个个工程慢慢独立的策略，新工程当然全部都采用独立化的dubbo；做了这些之后，每个后端就可以有了owner业务的概念了，大家不再是为了实现一个工程到处去其他工程中零散的写很多代码；而出现了“支持”的概念，一次版本迭代不再是一个人可以完成的了，需要几个人同事迭代来进行开发；彼此的代码解耦，单元测试解耦，发布解耦等带来了很多好处，到此为止，架构1.1时代我们花费了小半年的时间终于赢来了全面的解耦。
其实很多公司目前还是这一套架构体系，无非是在这套体系会搭配很多中间件来解决未来会发生的问题，这个我会在架构演变的过程中，慢慢把每个中间件引进的时机和作用以及解决的问题来讲解的，我相信这样带有事件时间线的讲解，会让大伙更生动的理解，我们公司技术演变过程中的“进化”。
