ESB zone

闲话通用技术之四 ：原材料到深加工

Spring从提供一堆开源组件到提供开源产品，这里面透露出来的信息是：有些企业不但需要原材料，还需要深加工的产品，对于企业来说，能够提供产品级别的解决方案，比提供一些原材料更有价值。这给我们解决大规模使用开源技术的公司也是一个很好的佐证，产品化虽然不是银弹，却能够有效解决前面3节所描述的问题（苦中作乐，首次）。

一、首先谈谈必要性：

• License的管理：我想国内大部分公司并不关心这件事情，但对于一家大型企业，还是非常有必要的，搞不定，那天你就会中弹。
• 版本的管理：我们遇到过不同产品使用同一个开源产品的不同版本的情况，给开源产品的升级、自身业务的合并带来很大麻烦，一般人还不敢动，只能由大牛搞之，然后全面递归测试。
• 技术的控制：不同的项目使用不同的技术，五花八门，很是热闹，看的人眼花缭乱，有些人还自以为用的开源技术越多越牛，实则是苦了自己、苦了同事。且每个技术都是半吊子，留下一堆遗憾，常用语是“下一次”，实际很少有人下一次把遗憾补上；有时甚至因为已经使用的技术由于某个点不能满足，就换一个同类的能够满足的需求的技术；有甚者，自己搞一个本项目特色化的技术，别的产品还不能使用。
• 学习的需要：把自己使用到的开源技术的文档合并起来，起码有百兆大小，再辅以业务资料，新人不死也要退层皮。这也间接导致，新人上手率低，工作效率低，阅读已有代码难度高；不理解足够的开源技术，就无法开始编码，这是多么痛苦的一件事情。
• 业务与技术隔离的需要：技术的升级，联动着业务升级；业务升级又联动着技术升级。各自都不能独立发展，耦合度太高了。
• 架构思想执行的需要：从实践来看，规则和文档无法确保我们架构思想的执行，对于企业内部来说，强约束比弱类型更有利，产品化是把架构思想固化的一种强力工具，是强约束的有利保证，就像EJB产品把EJB规范固化一样，不按照这种思想搞，你就是不能RUN。
• 架构管理需要：当业务逐渐扩大到时候，我们就需要不断调整我们的架构，把相关研究和技术纳入技术体系，通过产品把这些点串起来，逐步引入到生产环境，可以大大降低架构变迁带来的风险。此外，通过统一的产品才能更好的满足架构的规划与设计
• 专业化的需要：不是每个程序员都需要变成架构师，术业有专攻。【对于新人可能有些残酷，但可以通过其它手段来达到架构师水平。】

二、在什么时候开始通用技术的产品化：

• 如果有现成的产品，那么就直接使用。
• 资源足够充足、又准备建高楼的时候。【通常不靠谱，谁知道你这楼能否建起来】
• 至少有上百台服务器，5个以上的系统，管理问题层出现，抱怨比较多，效率低下的时候。
• 开发成本上升的拐点。

三、几个原则：

• 降低业务与技术的耦合。
• 尽可能多的封装开源技术，利用配置、标准、协议来暴露。
• 实现架构思想固化。
• 支持架构的规划与设计。
• 支持管理。