我们用于标识/帐户管理、资源调配等的底层共享服务是独立的，所有交互都通过基于AMQP的消息总线进行。代理商与他们接触的服务位于同一地点。如果需要，这种方法可以为我们提供跨有损网络的规模和弹性，并使我们能够正确地保护交互。它还为我们提供了在"任何云"上托管服务的灵活性。不过，当我们谈到cloudbeespaas是基于服务的时，它更深入了一层，与更以应用程序为中心的方法（如Heroku）相比，这是一个关键的区别。在以应用程序为中心的方法中，一切都从创建应用程序开始。所有资源和管理命令都附加到应用程序本身。这样做的优点是简单，一个应用程序影响另一个应用程序的可能性很小。在一个以应用程序为中心的世界中，可以立即为应用程序配置数据库并将其绑定到一个著名的位置。但是，如果您想在应用程序之间共享数据库或其他资源，这可能会变得困难。您可能需要投资于一个应用程序架构，以便在每个应用程序中共享（通过REST接口等），并且应用程序很难处理多个类型的相同资源。此外，服务合作伙伴本身并不是以应用程序为中心的。必须为每个希望使用服务的应用程序提供合作伙伴帐户，因为每个应用程序都有自己拥有和管理的资源命名空间。在像CloudBees这样以服务为中心的架构中，没有一个服务是"主"服务。相反，每个服务都附加到一个CloudBees帐户，并且能够公开帐户级别的功能（比如它的管理UI），并且可以提供属于帐户的资源，这些资源可以被CloudBees PaaS中的其他服务或资源引用。由于每个服务管理自己的资源集，CloudBees公开了绑定工具，允许一个服务上的资源绑定到另一个服务的资源。所以，就这样云蜂：如果你订阅独立使用我们的Jenkins、Forge、Application或Database服务，您可以将它们组合在一起，以拼凑出对您的团队有意义的工作流。当您的应用程序与许多内部和外部的移动部件相交时，并且您正朝着更灵活的持续交付方法前进，那么您需要这样做灵活性。如果如果要创建使用数据库的应用程序，请分别创建应用程序和数据库，然后将它们绑定在一起，使数据库作为应用程序中的资源可用。如果以后想为测试创建另一个数据库，并希望切换应用程序以使用测试数据库，只需重新绑定。在一个以应用程序为中心的体系结构中，应用程序只能连接到为其创建的数据库，因此您必须将数据库数据拆下并全部备份，而不是只交换应用程序所在的数据库使用。这些这只是两个例子，其中CloudBees基于服务的PaaS架构使困难变得简单。它们也是企业中典型的现实世界中的重要案例。这也是为什么您可以期望CloudBees在加速企业采用PaaS的过程中扮演重要角色年。为了更多关于AnyCloud的信息，请下载我们的AnyCloud white报纸，史蒂文Harris，产品部高级副总裁cloudbees.com网站