在路上---基于SCA规范的应用服务框架成长记(一)(连载中...)

        每个人在人生的不同阶段都在成长，父母们为自己记录了过去的成长历程，自己也在成年以后记录着自己的成长历程。程序员或者架构师都有着自己的“孩子”，不论自己的孩子是好是坏，都为自己的孩子有一点成绩而激动不已。现在的我也正在培育着一个自己的“孩子”，虽然在它成长过程中我要付出很多，但是看着它的成长，让我觉得所有的付出都是值得的。因此通过这种方式，记录下它的成长，记录下遇到的种种困难和解决之道，为自己也为其他程序员架构师在培育“孩子”的过程中提供可能有帮助的一些信息。

 

一．初涉SCA

       阿里新子公司成立，我也从业务开发组调动到了平台架构组，平台架构组当时的职责就是完善XPlatform来支持多个业务产品线部门的业务开发，XPlatform是基于MDA理念的快速开发平台。但随着业务部门开发灵活性要求的日益增加，XPlatform在可定制化，模块化就日渐暴露出了不足。在4月份的技术战略调整以后，开始了翻天覆地的XPlatform重构计划，而我就被分配负责考虑底层架构重构以及服务框架的设计。

       当时首先考虑模块化重构底层的时候，感觉OSGI是一个很好的方向，因此在重构服务框架前期的Cache模块时候采用了OSGI策略，可以动态替换Cache，但是在使用的过程中发现，此模块化并非我们所需的模块化。OSGI的模块化比较彻底，就连每个Bundle的dependency都是自己维护和管理，这样对于动态载入和卸载提供了坚实的基础，但同时也为它提供了最难处理的一个问题：复杂的ClassLoader机制。而回顾当前的业务开发场景，是否真的有这样强模块隔离的需求，回答往往是否定的。而作为动态的载入和卸载，的确是很好的一种特性，但是作为商业化的产品，特别是现在的互联网应用，机群中部署的应用模块往往来说并不需要单独装载和部署。另一方面来看OSGI面向的主要是对于单机服务开发模块化的解决方案，并非SOA的解决方案，而当前互联网应用在很大程度上需要互联互通，模块化是基础，但是并非最终的解决手段。

       这时候开始关注与SCA，对于SOA具体实施的一种实践性的规范，规范本身的模块化可扩展性给我留下了很深的印象。SCA和OSGI在模块化思想上有很多类似的地方，在SCA中Composite就是Bundle虚拟体，而SCA的优点就在于它只是规范，只是一种设计思想，不约束实现语言，平台以及其它细节，这也是互联网应用的一种趋势。信息共享达到信息价值最大化，这是企业应用的目标，在实现这个目标的时候需要抛开实现过程中的细节。就好比程序员往往关注的是使用什么好的技术能够开发出最炫的应用，而老板关注的是如何在最短最快的情况下满足用户需求，两者之间如何能达成双赢，那么就是架构师的职责了。

       既然认定了SCA这条路，那么就开始走吧，第一步当然是看规范，OSOA上关于SCA的规范十分详尽。SCA规范虽然已经有些年头了，但是正式纳入OSOA并且成为一个较为广泛认可的规范其实时间并不长，国外Sun,Bea都用一些类似的产品，但也没有大规模推广，而在Apache的孵化项目中Tuscany是SCA最出名的实践开源项目，对于我来说当然是加入开源大家庭。我在接触Tuscany的时候，它还是0.9之前的milestone2，但到现在为止，短短的几个月，已经发布到了v1版本了，可见发展迅速。对于Tuscany的关注，我看见现在国内也越来越多，Tuscany最大的特点就是它的架构可扩展性很强，这也是SCA规范所需要的架构体系，要做到SCA的模块化和扩展性，必须有灵活的基础架构作为支撑。

       三下五除二，用Tuscany搭建了SCA规范中描述的几个通用场景，简单的java bean，spring的集成，异步回调，rmi远程调用等等，当然遇到了不少问题，由于Tuscany本身也是孵化过程中，最大的问题就是相应的文档少，作为一个初学者，只能通过Demo了解大致的使用方式，遇到问题也就通过跟踪它的代码来学习，不过这个过程，让我也对整个框架的体系架构有所了解，就如大牛所说，真正的体系架构是一个运行期的概念，而非设计期的，设计期其实就是SCA规范本身，而运行期的部分才是真正的体系架构。

       预研终究是在做实验性的工作，是否能够产品化，还需要实践来检验。XPlatform的重构正式启动了，平台架构师们组织了一次内部重构技术方案讨论会，我将前期的研究结果以及SCA的思想和实现都作了展示，同时结合我们重构的目标作了技术实施可行性介绍。与会的另外一个架构师提出了使用Spring实现SOA的ESB模式的解决方案，经过比较和讨论最后我的计划方案得到了肯定，但是我自己心里其实也没有底，毕竟如果真的在XPlatform的体系架构中实施SCA，那么将会波及各个产品线的底层架构，如果后续出现无法修复的问题，那么这个责任可不小。同时在过去的那些年头，EJB就是一个很好的反面例子，一个规范理念是重要的，但是实施环境是否合适也会决定成败，SCA是否适合未来的阿里软件技术方向，当时的我没有把握。最后我主动提出降低风险的设计方案，平台底层分成两部分：基础服务框架（BSF）和应用服务框架（ASF），前者主要应用于XPlatform内部核心组件的插拔交互，后者应用于上层应用的组装，发布，交互。

        Alisoft-xplatform-core-service-framework这个就是服务框架项目的子工程目录名，也是我的SCA之路的第一步。当走出这第一步以后，就再也不能回头了，常用老马的一句话来激励自己：我可能不是最聪明的人，也不是最努力的人，但是坚持可能就让我比别人成功。Tuscany为我开启了SCA的实践之路，但Tuscany并不是像看起来那么美，要走适合服务框架的SCA之路，难题才刚刚开始。