技术框架
大公司都喜欢自研，小公司喜欢用开源
大公司基于自己的技术实力，有专门的中间件研发团队来维护开发一些中间件产品
比如阿里巴巴，现有的技术框架大多都是自己封装或者自研产品：分布式服务框架–HSF、Dubbo，数据库AliSQL，链路监控鹰眼，甚至JDK也基于openJDK定制一版AJDK
比如美团点评，分布式调用Pigeon、监控Cat
小公司则更喜欢基于开源的解决方案
比如dubbo是开源的，而且很多公司都在用，即使是很久没更新的，依然继续采用，或者用还在维护的当当的dubbox
比如链路监控大家就用开源的zipkin
比如建设微服务架构，现在就流行使用spring cloud整体方案了
为什么明明有成熟的开源方案了，大公司还要自己搞一套呢？
- 大公司最初也是小公司，他们最初也是尝试使用开源方案但是遇到了瓶颈，于是定制化魔改了一版
- 没有可行的开源方案，所以自研了，但是等开源有了，已经有上千个服务在使用自研系统，无法替换了
- 自研系统与公司内部其他产品增加了很多适配与集成特性，为了更加使用其他中间件产品而封装
越老的公司自研产品越多，而且大公司内部自研产品功能越来越像
比如你会发现大众点评的pigeon的设计与dubbo是如此的相像，但是大众还是用自己的pigeon
现在spring cloud中的各个组件，估计阿里都有自己类似的实现，但是当时阿里开发的时候，spring cloud还没有，所以只能在自研道路上越走越远
同时在阿里的研发只要记住阿里中间件的使用规则即可，不用关注细节
这有好处也有坏处，好处自然是方便更可靠，更易集成阿里体系，坏处就是你知道的开源与技术也许在自研产品上已经不适用了，使用内部中间件的套路与技巧出了阿里没有什么用处
挖财目前也有强大的中间件团队，为了解决开源中的坑，也逐渐走上了自研道路，很多开源框架都加入了自己维护的代码，没有好的方案就进行自研
现在技术革新比较快，往往后来就有的开源框架也能很好的解决类似的问题
所以作为架构一定要保持2套技术体系的学习，一套是公司内部封装的技术，一套是开源中流行的解决方案
学习中会发现很多是相似的，很多是可以提升的，或者给公司内部中间件做贡献，或者给开源做贡献，都是不错的实践~
