那么，要在中国这个规模上运行需要具备什么条件？

要构建满足中国规模需求的的企业级应用程序，其固有的挑战是无与伦比的。阿里巴巴集团就是一家大量使用 Spring 来解决独特挑战的典范。 阿里巴巴 本身是一个在线拍卖网站，类似于西方的 eBay。阿里巴巴集团又拥有几家其他的在线服务公司，如 支付宝（一个安全的交易处理商，类似于西方的 PayPal）、淘宝（一个比价购物引擎，类似于西方的 Shopzilla）以及 天猫（一个电子零售商，展示商家的目录，类似于西方的亚马逊）。

来自InfoQ的文章，“2012年11月11日（光棍节促销日），天猫和淘宝共接待用户访问1.47亿人次，3000万人完成购买，支付订单近1亿笔。零点时，超过1000万用户同时在线。” “光棍节促销日”是为了纪念单身人士而设立的节日。人们会进行相亲、参加速配活动，并且——有点像美国的网络星期一购物节——商家会提供各种优惠。 淘宝在短短24小时内报告了30亿美元的销售额。这几乎是美国两个最大电子商务网站2011年黑色星期五总销售额的三倍！这规模真是太惊人了！

阿里巴巴集团从未回避谈论他们正在做什么以及如何做的。他们很乐意参加2012年12月的SpringOne北京大会，会上他们详细介绍了如何利用Spring来应对独特的挑战。

那么，要应对“中国规模”的挑战，需要什么呢？毫不奇怪，需要很多！每家公司都有其特定的需求和用例，并开发了大量的定制基础设施和中间件来满足这些需求。在很多方面，这些架构都与Twitter、Facebook和Google的架构师多年来描述的架构相呼应。不同之处在于，通过建立在Spring框架之上，他们不必孤军奋战，并且可以更快地投入生产。Spring框架支撑了所有这些组织，提供了一个通用的、以POJO为中心的框架和惯例，同时使软件测试的难度大大降低。许多情况下，有才华的架构师在Spring的组件模型和运行时之上构建了自己定制的、特定用例的框架和中间件。

这些组织之间有很多共同之处。每个组织都处理海量数据，需要可扩展的服务和跨服务通信。通常，这些引擎支持注册表的概念，该注册表了解网络拓扑中哪些服务正在运行、哪些可用，以及支持的RPC合约（按类型）。这样的注册表知道如何配置每个实例，并考虑整个网络拓扑。每个组织都使用消息传递来可靠、快速地连接系统。每个组织都通过分解服务并独立扩展每个服务来实现最佳规模。这种分解意味着服务不共址，现在必须承担网络通信的成本。为了尽量减少网络通信，使用了具有已知合约的高效二进制数据表示。最后，为了向用户公开这些服务，他们构建了高度优化、几乎无状态的Web应用程序。

阿里巴巴集团在许多不同的地方使用了各种Pivotal技术。除了核心Spring之外，他们还根据不同的配置和用途使用了Spring MVC、Spring Security和Groovy。

他们还利用了Spring提供的深度灵活性，并在Spring之上构建了自己的框架。值得注意的是，其中许多代码作为开源代码在线提供。

阿里巴巴集团实际上有几种不同的服务方法，原因各不相同。其中一种方法称为Dubbo。Dubbo是一个高性能服务框架。它易于通过各种RPC模式导出和消费服务。它还易于将这些服务集群化。整个系统是开源的。你可以在GitHub上获取代码。

Dubbo建立在许多现有的开源组件之上，包括Apache Zookeeper、Redis，当然还有Spring。很容易看出为什么Dubbo已成为堆栈的关键部分，每天服务超过2000个服务，调用量超过30亿次。Dubbo已成为阿里巴巴基于服务的解决方案的关键组成部分，并已部署到整个阿里巴巴.com家族。

你可以使用Spring命名空间轻松设置和导出Dubbo服务，它工作如下：

  <!-- Application name -->
  <dubbo:application name="hello-world-app"  />

  <!-- registry address, used for service to register itself -->
  <dubbo:registry address="multicast://224.5.6.7:1234" />

  <!-- expose this service through dubbo protocol, through port 20880 -->
  <dubbo:protocol name="dubbo" port="20880" />

  <!-- which service interface do we expose? -->
  <dubbo:service interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" />

  <!-- designate implementation -->
  <bean id="demoService" class="com.alibaba.dubbo.demo.provider.DemoServiceImpl" />

消费服务同样容易。在客户端，你可以在Dubbo命名空间中使用dubbo:reference元素来绑定接口代理。然后，你可以将该代理的引用注入到任何需要的服务中，如下所示：

	
    <!-- consumer application name -->
    <dubbo:application name="consumer-of-helloworld-app"  />

    <!-- registry address, used for consumer to discover services -->
    <dubbo:registry address="multicast://224.5.6.7:1234" />

    <!-- which service to consume? -->
    <dubbo:reference id="demoService" interface="com.alibaba.dubbo.demo.DemoService" />

在支付宝中使用的另一种服务方法是一个他们称之为SOFA的项目，该项目还支持在分布式（并且重要的是，共址）环境中轻松导出和消费服务。SOFA提供了许多不同的RPC风格，并有多种绑定可用。使用SOFA导出服务同样容易，如下所示：

<sofa:service ref="beanId" interface="MyInterface">
 <sofa:binding.ws/>
</sofa:service>

<sofa:reference id="refId" interface="MyInterface">
 <sofa:binding.ws/>
<sofa:reference/>

除了<sofa:service.ws />之外，你还可以配置许多不同类型的绑定，例如：<sofa:binding.tr>、<sofa:binding.msg>和<sofa:binding.http> SOFA组件。

虽然SOFA本身非常有趣，但我真正喜欢的是他们构建了一个SOFA架构感知的Spring MVC版本，称为SOFA MVC。SOFA MVC提供了Spring MVC的扩展，包括对Velocity模板渲染的某些优化、数据模拟支持、A/B测试支持，以及基于Spring Security的特定安全漏洞（XSS、CSRF、上传过滤和Cookie）防护。此外，他们还构建了自己的部署和运行时，提供Spring应用程序上下文隔离和Servlet 3风格的Java配置等功能。

这种集成的运行时方法已被证明非常强大，而对于他们非常独特的需求，下一步将是从JBoss等较重的运行时迁移到自研、量身定制、更轻量级和定制化的容器，如Eclipse Virgo。他们认为OSGi是一个强大而有效的微内核，并提供了可扩展的架构。他们喜欢它为同一台机器上的多个部署提供的隔离（在这种规模下，他们会尝试尽可能多地共址和重用应用程序服务器！），并且他们喜欢OSGi所要求的服务规范。

我建议任何有机会的人去看看阿里巴巴集团的开源项目。我参观他们的组织非常有价值。我学到了很多关于他们如何改变世界。他们也给我提供了一些反馈，这些反馈都已反馈到SpringSource的工程部门，以便你们社区能够受益于阿里巴巴在每一次交易中所取得的进步。我个人要感谢淘宝的王晶宇、王新生、李丁和张乐伟；天猫的庄卓然、刘长定、梁飞、王福强；支付宝的杨兵、王磊；以及——特别感谢——（同样来自支付宝的）丁雪峰，他帮助组织了这次对阿里巴巴集团使用Spring方式的全面、深入的考察。