java架构师指南：集成微服务精简的集成方法

一个典型的企业有后端系统和集中式服务总线层，通常通过企业服务总线（ESB）来实现，该服务总线可以管理所有的集成逻辑，并由集中的团队管理。因为它能够以标准方式发布任何集成逻辑和单个位置来更新对后端系统的更改，企业可以最大程度地降低复杂性并优化性能。这对于面向服务的架构非常有效，但是传统的ESB具有相对较大的占用空间，并且需要太长时间才能启动以支持微服务器的精简分布式。

认识到ESB不适合微服务，一些开发人员正在建立集成到微服务器或依靠API来集成它们。然而，这些方法无法提供ESB提供的一些重要的可重用结构，例如预先建立的连接器，集成模板和模式，调解和转换逻辑。要明确的是，API是微服务体系结构的核心，但它们不是集成要求的解决方法。

集成微服务精简你的集成方法

更好的选择是集成微服务方法，其中常规的微服务和集成微服务器相互交互。这使开发人员能够利用集成微服务来进行中介，转换和其他服务集成功能，或将多个服务组合成单一服务。

基本上，集成微服务有助于利用微服务的要素，并将其添加到集成层。这些集成微服务可以被视为用于组合服务链接或链接多个细粒度后端系统以及转换和/或连接到云系统的小型服务层。

集成微服务的参考模型

此外，集成微服务方法为开发团队提供了更高的灵活性和代码的端到端责任。这意味着相同的（小）团队可以负责创建核心服务和组合服务，数据库处理，集成逻辑，云连接，协议转换，用户体验（UX）开发等。

这里描述的架构最好地支持编程语言，使开发人员可以在编写新服务的同时仍然使用现有的集成概念（如连接器，服务链接和路由）来构建精简的微服务器集成。

作为一种编程语言与高度专业化的配置语言，它为开发人员提供直观的附加优势，同时自然与开发工具兼容。

理想情况下，为了满足今天对用户和特设集成商的需求，它还应提供一个视觉上直观的界面，可能用更可视化的工具替代传统的数据流驱动方法，从而确保视觉模型与编程模型之间的平衡。一个更容易理解的方法，如序列图，将适用于此。

例如，公开客户信息的微服务器可能需要连接到Salesforce，这意味着开发人员必须构建连接器或调用一组API。在另一种情况下，传入的消息XML格式与后端系统期望的格式可能存在差异。对于这种集成场景，可以在每个服务中构建可重用的集成逻辑。然而，只有通过单独的集成微服务层，开发人员才能确保可扩展性 - 不仅是在时间，精力和成本方面，而且在重新工作和维护库的依赖性方面。

随着精简，敏捷，基于DevOps，分布式和微型服务式开发成为首选的技术模式，开发人员一直在努力寻找合适的集成方法。集成的微服务方法有助于提供与其以高度可扩展的方式解决集成挑战的能力的缺失环节，同时提供灵活性以满足不断变化的需求。

推荐阅读：java架构师指南之架构师的工作流程