有人用过普元eos吗？
站在EOS平台用户的角度，不客气的说，Eclipse中EOS的应用在国内是领先的，也有朋友通过学习EOS的设计和原理，在工作中获得了很大的帮助。
所以在我看来，使用任何工具和平台能否获得个人的技术成长，取决于你能否从平台的使用中得到提升和总结，不是把平台当工具，而是把平台当教材。想想如何设计一个平台，如何构建一个层级体系等等。
在技术路线上，企业平台是最接近最新技术的，普元就是其中之一。普元正在升级EOS微服务框架和容器云，并将其在BPS方面的优势应用于DevOps的设计和实现。
而且，普元正在开发新一代数字化企业云平台，目标是发布一个可以部署在私有和公共环境的Paas平台。有兴趣或者想学习相关技术，可以在百度搜索EAII。
附上EOS设计师智虎的一段回答。供参考。
作者:焦烈艳
链接:公司将引入普元公司的EOS框架，对公司未来的技术发展有什么影响？——焦烈焰的回答
来源:知乎。
版权归作者所有，授权请联系作者。
今天刚看到这个问题。作为EOS的设计师，我不敢客观的说，主要说说设计时的思考。
1的初衷。EOS是为了解决企业JAVA开发中的一些* * *问题。虽然有很多框架比如SSH，但是有很多非功能性的需求在应用过程中没有涉及到，尤其是在分布式环境下，以hibernate为例，如何实现多服务器配置文件的同步，如何在集群状态下监控性能，这些都不是开源软件能够解决的。因为我们有很多大客户的经验，比如华为工行，所以我们在产品中体现了很多类似的经验。EOS并没有解决业务逻辑快速开发的问题，而是解决了企业环境中非功能性需求的问题，提高了软件的可管理性，尤其是大型软件开发，这也和我们的经验有关。我同意何的观点，目前市场上的快速开发平台是不可能解决复杂ERP系统的快速开发的。所以在设计之初，EOS考虑的是解决非功能性需求的实现，而不是业务逻辑的快速开发。
2.基于JAVA做应用架构有很多方法，这也是为什么有很多开源软件的原因。不同的人有不同的看法。既然EOS试图解决JAVA的应用架构，那么必然有自己的想法。这些想法可能不会得到所有人的认同。这也是我过去比较头疼的问题，也是开发者比较有争议的问题。不像工作流，大家对它都有清晰的认识和定位，比拼的是功能和性能。普元的工作流性能很强，对外接口功能特别丰富(真的不是吹牛)，所以获得了很多认可。
3.EOS最有争议的是业务逻辑的拖拽开发(也就是可视化开发)。其实大家都不反对拖拽式开发，比如数据建模，但是拖拽业务逻辑未必是好事。我们在设计的时候，要么用拖拽开发，要么用spring bean的方式写代码开发业务逻辑。图形化(拖放)开发业务逻辑，最大的用途是处理异步逻辑，比如调用WebServices。如果同步调用时被调用者很慢，当前线程会被挂起，那么异步就不会有这个问题，至少可以随时间释放(这里比较复杂，我就不赘述了)，但是异步代码写起来很复杂，如果回调的话很难读取(想象一下回调调用三个网页)
4.在使用EOS的时候，最好根据自己的情况制定规范，因为EOS在做产品的过程中要考虑很多情况，但是企业面临的问题是固定的。比如你不喜欢拖拽业务逻辑，你可以不用，因为你在普元的培训里讲过这个方法，你也可以和普元的工程师讨论。技术团队在使用一个框架时，可以从设计原理、架构、面临的问题等角度考虑框架的设计初衷，从而提高对技术的掌握。我的很多合作伙伴(比如工行、建行)对EOS的掌握很深，并结合自己的实际成为自己的框架，他们的技术也在这个过程中得到了很大的提升。
作为设计师，EOS是一个在设计过程中困扰我们的产品。主要原因是他试图解决的问题复杂而广泛，解决这个问题的方法有很多，尤其是开源软件很多，不可能面面俱到。在濮院后续产品的设计中，我们吸取了这一经验，重点解决了需要解决的问题。
6.未来，普元将解决大中型企业信息化的技术架构问题，但设计思路会更加专注。在EOS和process之后，还有ESB、数据集成、数据质量、IaaS等产品。目前的数据集成产品都是基于最流行的开源软件Kettle，但是我们的重点是解决Kettle没有解决的调度问题(比如每天晚上有几千个作业，可能会连续持续，作业失败怎么办，如何监控等等。);目前IaaS产品都是基于OpenStack的，但是我们已经解决了OpenStack在企业私有云的管理系统问题(比如小网段、心跳检测、高可用以及高可用组件本身的多维度管理)。数据治理产品侧重于数据整合后的数据谱系分析和影响力分析，形成数据图谱。