0.写在最前面的

18年初，正式结束8年的金融IT行业生涯，入职废都一家小型互联网公司。

金融行业自身的行业特性，以及机构的IT组织架构，决定了其技术体系的随动性很弱。整体架构数十年来一直以SOA方向发展实现，由ESB/ESC作为中枢串联各单体应用。近几年虽然某些行业巨头公司，开始在某些业务系统实践分布式架构，但整体架构的变革并无变化；同时所谓的分布式架构，也大都仅限于业务功能模块的拆分。

---

在一个行业深耕多年，能够更多的感知到IT的发展历程，以及对一个行业的影响。遥想小二十年的字符前端系统，现在仍在某些银行使用，尚未实现到图形前端的转变。而对于直接Web起步的互联网应用，这都是难以想象的事情。

无论数年前的SSH还是目前很火的Spring Boot，都为作为开发利器为技术人员提供便利，但同时也导致非常多的技术人员，不知所以然亦可完成功能开发。在废都这个技术氛围不足的城市里，会突然发现，工作近十年的开发人员连TCP Socket都没有概念；在很多技术人员的意识中，百度能解决的问题才是问题；而做Java开发的小伙们，居然PC上连一份JDK API都木有。

遥想刚毕业的年代，作为金融IT行业的公司，互联网是隔离的，而那时移动网络还尚在起步，只是在某个遥远的角落有那么几台PC老爷机能够上网。互联网给技术人员提供了极大的便利，同时也造就了很多“互联网开发人员”。

---

在目前公司中作为架构师，带领着小二十号人，团队技术人员由移动端开发(Android/IOS)和Java开发构成。这些跳槽过来的技术人员在过往项目中，移动端开发人员一两人完成App的开发，而Java开发则团队作战开发单体应用。最直接的表现就是，移动端开发能够说清楚App做什么有什么模块，而Java开发只能和你聊这个模块怎么样。

每次软件架构的变革，人员分工、组织架构也伴随发生变化，对于人员的要求也同时也悄无声息的发生改变。

在单体应用的时代，安排一两个高手，开发通讯协议等公共组件搭建系统，剩余人员只关注业务的实现开发，不用清楚通讯协议是TCP还是HTTP，报文格式是Json还是XML。若有问题两拨人扯扯皮，最终领导施压高手解决，开发人员有指望坐等即可，很多人以为这就是开发，“我们”可以一直这样下去。

当微服务架构的变革来临，以前单体应用中的一个业务模块可以作为独立的应用，类似Spring Boot这样的开发利器，对于小企业来说不需要再有高手去搭建系统，业务开发人员可以基于Spring Boot上来实现。不会再有两拨人扯皮，也不再会有指望，唯有百度来解忧。最终不知所以然的业务开发人员，只能跟随在百度的后面变的迟缓、落后，函数式编程、响应式编程的持续发展，忽然有一天，你会发现自己已经落伍了，再想去学习会发现已经落后太多，而也没有企业会愿意提供这么大的成本去让你补习。

关于35+技术人员存在意义的讨论，一直不绝于耳，也有人问过我怎么考虑的。只是退休年龄都会变，35又算什么，失去饭碗的技术人员，只是不知道自己的饭碗是什么，不知不觉的被时代淘汰，就这么丢了。

---

公司业务尚在发展期，前期一个小团队基于Spring Cloud搭建了微服务架构，而最终的产物只是想当然的产物；再加上与上游系统整体架构上的偏差，导致整个服务调用链路不伦不类。最终经过分析、对比最终选择重构整个微服务架构，与其说重构不如说重做。这也是我写博客的缘由，记录整个微服务架构重构从分析、选型到实践的整个过程。