在本文中，我整理了从许多集成项目中以集成顾问的方式学到的教训。无论是建筑师还是开发人员，在计划新的集成项目或升级当前集成项目时，可能会发现此信息很有用。

企业集成项目管理的经验和教训（系统集成项目管理经验）

规划阶段

观看供应商演示后不要立即做出决定

在评估阶段，将坐在许多供应商的演示文稿和演示中。但是不要基于此判断任何集成产品。集成产品在演示中可能看起来不错，但有责任通过根据实际生产工作负载对其进行评估来做出最终决定。

在做出决定之前，请对每个供应商的产品进行PoC，以查看在预期的2-3年的流量下其性能如何。另外，如果要替换现有系统，请考虑迁移路径及其提供的支持。

正确安排团队成员

在计划新的集成项目时，从第一天开始雇用具有适当技能的人员总是更好的选择。如今，许多集成项目都需要超出集成中间件范围的专业知识。DevOps，基础架构，可观察性，数据库，安全性和编程是新员工应具备的一些顶级技能。

例如，当的团队正在开发集成时，通常需要联系其他团队来完成任务。可能需要咨询DBA来验证数据库架构，从Ops工程师那里获得帮助以计划部署，并从QA团队那里获得指导来设计性能测试方案。协作对项目有利。但是，如果过多地依赖他人，那将会拖累开发进度。

如果的团队拥有上述专业知识怎么办?这样，的团队就可以自足解决自己的问题并快速行动。因此，在规划，构建和管理集成项目时，拥有一支由各种人才组成的团队至关重要。

开源还是商业供应商?

最终，这个决定归结为两个因素：时间与金钱。认为的组织主要选择哪个选项?

预算充裕的组织会在商业集成工具，支持服务和高素质人才上投入大量资金。他们的主要目的是尽快完成整合项目并投放市场。时间对他们来说至关重要-不管他们花多少钱来建立和支持项目。

另一方面，有些组织的预算和资源有限。但是，他们有足够的时间尝试使用开源工具。他们经常自己支持产品，并为开源社区做出贡献。

选择集成供应商时，必须仔细考虑这两个方面。

实施阶段
正确进行集成DevOps流程

传统上，开发人员执行所有集成，然后他们将最终的工件投入运营中，以将其部署到生产中。由于缺乏集成工具特定的知识，因此运营团队在尝试进行部署和故障排除时遇到了噩梦。

部署新工件后，大多数集成中间件服务器都需要重新启动。必须从负载平衡器池中取出服务器，部署工件文件，然后将服务器添加回池中。大多数时候，运营团队必须在多台服务器上重复该过程，以使其保持同步和一致。总而言之，新的工件部署是一个耗时，容易出错的手动过程。

想象一下，如果不得不一天之内进行多个部署，那么这将给开发人员和运营团队带来压力。这使整个开发，测试和部署周期变慢-甚至需要花费数周的时间来部署集成的一个小的修复程序。

如果集成开发人员具有强大而快速的流程来本地验证其更改并以可靠的方式将其推向生产，则可以消除这种情况。完善的CI/CD管道将自动构建开发人员更改，对其进行测试，并最终以最少的人工干预跨多个环境部署构建工件。它具有可扩展性，高效性和可靠性-使的开发人员和运营团队感到满意。

因此，请考虑从第一天开始建立适当的DevOps流程，以管理的集成开发流程。

用于集成项目的CI/CD管道示例。资源。

遵循正确的弹性模式

通过集成中间件集成两个系统时，不仅应该关注幸福的道路。如果没有的控制，将无法保证源系统和目标系统的来来往往。但是，完全可以控制中间件在下雨天的行为。

如果源系统期望以同步方式进行响应，请尝试利用中间件随附的可靠性功能，例如重试和断路器。对于需要可靠传递的消息，请使用异步消息传递而不是请求-答复操作。

最重要的是，如果在中间失败，请不要保持沉默。尽可能执行必要的日志记录，并实施补偿事务，以确保故障后的一致性。

正确保护移动中的数据

对流经集成中间件的数据负责。在企业数据泄露之后，主动保护数据移动总是比执行损坏控制总要好。

从外部系统接收数据或向外部系统发送数据时，请使用中间件支持的传输层或应用程序级安全方案。如今，大多数工具都支持双向TLS，OAuth2.0等标准。

运维阶段

正确设置可观察性堆栈

负责将到达集成中间件的任何消息传递到其最终目的地。这可能会在许多方面出问题。中间件可能无法处理请求，或者目标系统没有响应。或者，中间件没有从源系统收到任何信息。如何自信地说出实际情况?

此时，可观察性工具将为提供帮助。使用分布式跟踪工具来跟踪跨系统的消息的端到端遍历。这样，可以发现丢失消息的地方。Jaeger是分布式跟踪工具的一个很好的例子。

使用Logstash，Fluentd和GreyLog等日志聚合工具将中间件日志发送到中央位置，以便可以从中央位置进行日志分析。诸如ElasticSearch，Kibana和Splunk之类的工具提供了丰富的日志分析支持。

通过在服务器机群上启用实时遥测，可以收到有关停机，服务器负载过重以及机队整体运行状况的通知。这有助于运营团队主动解决问题，而不是等待灾难。

调试工具是团队的朋友

系统发生事件后，的团队成员不应该玩分布式游戏。应该有一套适当的调试工具来隔离系统中的故障。

拥有模拟源系统和目标系统的工具对于孤立地对集成中间件进行故障排除至关重要。ApacheJMeter，SoapUI和Postman是此类工具的少数示例。

为了快速识别集成瓶颈，的团队成员还应该熟悉Java堆转储分析和SQL查询跟踪等技能。

按比例扩展到源系统和目标系统

当上游系统扩大规模并发送更多流量时，集成层也应按比例扩大。否则，中间将存在性能瓶颈。

将流量发送到速度较慢的下游系统时，应遵循最佳做法，以免耗尽它们。例如，可以在中间件和下游系统之间放置一个消息队列，以便中间件可以在其中放置消息，而不是将消息直接发送到下游系统。这样，队列就像缓冲区一样，吸收了传入流量中的突然尖峰。另外，可以考虑在集成层限制消息的数量作为预防措施。

结论

无论使用Kubernetes和服务网格之类的云原生技术，还是使用VM和ESB都没有关系。重要的是从小处着手，加快迭代速度，并从错误中吸取教训。

当想通过ESB将消息从系统A发送到B时，至少在第一次迭代时，不必在Kubernetes上部署所有内容。从长期可以承受和建立并维护的技术堆栈开始。随着的集成项目在组织中获得坚实的立足点，可以接受新的趋势。

好了，今天的文章分享到这就结束了，要是喜欢的朋友，请点个关注哦！–我是简搭(jabdp)，我为自己“带盐”，感谢大家关注。