技术框架的演变

最开始是没有框架的，大家都各玩各的，同样的问题，反复多次在不同的团队解决。

后来大家发现都是同样的问题，反反复复出现，还在不停的被解决。所以提出建立一个公司级别的框架。

但是框架建立后又带来了 新的问题，框架本身要更新迭代。而框架又跑在业务应用里面，框架团队已经尚失了对框架的控制权。因为框架版本的升级要完全由业务团队决定，业务团队同意升级，才能升级。业务团队决定怎么用，就怎么用，可以完全不经过框架团队决定。

第3代框架 应该采用 thin sdk + sideCar模式。 这个thin sdk 跟框架具体功能没有关系，而且比较简单，只是简单的做代理到sideCar上。这样，thin sdk 基本上不用升级。而且跟特定技术没有直接关系，对业务应用入侵的也只有 thin sdk，屏蔽了技术细节，也让业务团队聚焦到业务实现上。

框架上大部分的实现逻辑都在sideCar上。由于sideCar 不是和业务应用直接部署在一起的。也和业务代码不耦合，这样框架的控制权任然可以回到框架团队。回到框架团队后，框架团队就比较好控制版本，也就控制了框架的分裂。

本质还是康威定理，组织和IT系统的对齐

另外框架还要加上 微内核

thin sdk+ sidecar 、微内核、生态、分布式