从基于ESB的平台迁移到云原生平台的难点在什么地方？

从这个问题来说，主要是esb的平台迁移到云原生平台，关注微服务架构如何实现的问题。我们知道对于单体架构业务转变为微服务的架构面临着一些固有的特点，如微服务之间如何通信，微服务之间数据如何共享，迁移过程如何不影响现有业务等。如果原来的基于esb平台上的业务是linux系统，客户端调用应该问题不大。

如果业务需要重构，可以选择微服务架构作为新架构，切勿为了上云而上云。
架构的转变目前没有完全自动化的工具能够实现，还是需要开发人员，基于选定的微服务架构去进行改造，如果是老旧的单体应用改造成本的确很大。
目前，windows系统上跑容器，我们项目有些经验，但在业内目前还不是主流，主要还是linux系统。
客户端本身对管理端的调用都是通过网络协议实现的，因此管理端上容器不会对客户端有影响。

云原生的目的不是重构和技术升级，是为了更灵活和高效的解决业务问题。ESB的大单体应用整体搬迁技术上问题不大，但是没有业务上的收益，甚至效果更差。实际遇到很多客户的经验是小步快跑，老ESB会和微服务应用共存很长一段时间，我们用运用一些微服务容器化的敏捷集成技术将无法改造的老系统和新系统打通。业务挑战严峻，对灵活性和开发迭代周期短的业务领域应用，可以优先考虑转到这个方向上来。
原有的服务变成微服务更多的是业务问题，业务领域拆分的合理性才是重点。技术上有很多工具实现，包括.net服务容器化，红帽就提供.net core基础镜像和迁移支持。客户端一定是最大限度的保证稳定不变，这也是集成层解耦的主要目的。