虽然集成并不一定是一个新的问题，但是在云集成中却面临着独特的挑战，它需要采用一种新的方法。但是，仍然有很多企业还是用点对点（P2P）解决方案来解决他们云集成需求。

　　为了成功的解决云集成的问题，我们需要超越点对点集成，并且避免发生重复性的相同错误。为了给该成果提供帮助，在这里我一共列举了点对点集成中所面临的十大陷阱的清单（没有特别的顺序），这样可以避免在云集成中出现重复：

　　1. 组装与购买：如果在你的IT部门中，拥有集成经验的开发者，那么你可以让他们在机构内部组建一个自定义的点对点集成，而不需要购买打包的解决方案。但是，建立自己的集成，通常意味着你还要管理和维护一个代码库，这并不是你业务的核心，并且这个代码库也很难更改。

　　2. Quickfire集成：假如说你需要快速的集成两个系统，并且聘请了一个开发人员在未来的几天之内从事于这个项目。你会注意到在工作效率方面有所提高，并且可以寻求再集成其他系统的机会。你聘请了相同的开发人员，并且期望进行相同的quickfire集成，但项目的复杂性成倍的增加。这时应该怎么办？一个最好的方法是进行系统化的集成，并且预先设立一个计划，而不是采用特定的点对点方式来集成化你的系统。

　　3. 将集成嵌入到您的应用程序中：将点对点集成嵌入到你的web应用程序中，虽然这可能是一种极具吸引力的方法，但是你应该谨慎使用这种方法。这对于那些十分简单的集成来说可能是非常有效的，但是随着时间的推移，你的集成逻辑在不同的web应用程序中会变得非常分散。相反，你应该将集成视为你应用程序体系结构中的一个单独的层级，并对逻辑进行集中化处理。

　　4. 创建应用程序之间的相关性：当采用点对点的方式来集成应用程序时，你要建立程序之间的相关性。比如说：假设你集成的是A应用程序和B应用程序。当应用程序A出现了修正或者更新时，那么你就需要对与应用程序B相关联的集成做出相应的变更。你还需要对集成进行重新测试来确保其是否正常运行。如果在该混合中加入了应用程序C，那么你的工作量就会出现成倍的增加。

　　5. 假设所有的一切都能正常运转：在进行快速点对点集成中，一贯会重复出现的错误之一就是假设事物不会出现故障。而现实是集成并不总是会按照计划的情况正常运转。当你对系统进行集成时，需要对错误进行设计，并且建立一系列的措施，用于解决各种各样不同类型的错误。在集成软件作为一种服务（SaaS）的应用程序时，对错误进行处理是一件非常棘手的事情，因为你只有有限的可视化，并且对SaaS供应商在该软件中所做出的变更也只有有限的了解。

　　对每一次集成都要进行测试。

　　6. 该工作是在昨天完成的：正是因为点对点集成适用于一个项目，但是这并不意味着它也适用于其他的项目。关键是对你所构建的每一个集成都要进行测试。遗憾的是，点对点集成通常是迅速构建和部署的，并没有进行充足的规划或者合理的测试，这样就增加了错误出现的可能性。虽然对集成进行测试是一项十分困难的工作，并且也需要大量的努力，但是，毫无疑问，这绝对是至关重要的工作。

　　7. 使用单独的顾问：有很多公司，他们的员工中没有具有丰富集成经验的开发人员，因此他们需要聘请顾问来解决他们的集成问题。采用这种方法的问题就是你通常对于顾问所提交的问题只有有限的认知度。如果你需要做出某些变更，通常需要与同一个顾问共同工作，而这通常是不太可能的。

　　8. 创建单点故障：由于你的点对点集成结构在规模和复杂性方面都会增长，因此在你的整个网络中，成为单点故障的可能性也会增加。当提到集成时，将单点故障的可能性降到最小化是优先考虑的事情，但是在点对点方法中，缺少去耦，对于消除你系统中的瓶颈来说就变得十分困难。

　　9. 黑盒的解决方案：自定义的点对点解决方案通常都是黑匣子。换句话说，它们缺乏报告的能力，无法告诉你在系统之间发生了什么。这就造成了如果系统正常工作的话，就很难消除故障，测量性能或者找出问题。

　　10. 创建一个庞大的结构：当你有2个或3个系统进行连接时，快速点对点集成相对便于管理，但是当你开始添加其他系统时，你的架构会迅速成为一个复杂的烂摊子。而且，因为没有两个P2P集成是完全相同的，管理您的集成就成为一个主要的难点。但是如果你在事先的设计工作中投入一些精力，那么就可以避免你构建出一个混乱的点对点结构，并且也可以避免你在压力下，从分散的集成结构中重新寻找新的解决方案。如果你有了一个深思熟虑的设计方案，并且简单的结构，那么久可以减少与集成相关的管理负担和成本。