EOS设计者也谈EOS

作者：焦烈焱
链接：https://www.zhihu.com/question/23522551/answer/46501449
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

1. EOS 的初衷是解决企业级JAVA开发的一些共性问题，虽然已经有SSH等很多框架，但是在应用过程中有很多非功能需求并没有涉及，尤其是分布式环境下，以hibernate为例，如何实现多服务器配置文件的同步，如何做集群状态下性能的监控，开源软件都没有解决。由于我们有很多大型客户的经验，例如华为 工行，于是就把很多类似的经验体现在产品中。EOS 并不解决业务逻辑快速开发的问题，而是解决企业环境下非功能需求的问题，提高软件的可管理能力，尤其是大规模的软件开发，这也和我们的经验相关。同意 xxx 所说，目前市面上的快速开发平台解决复杂 ERP 系统的快速开发都不可能，所以 EOS 在设计之初考虑解决的就是解决非功能需求的实现，而不是业务逻辑的快速开发。

2. 基于JAVA做应用架构的方式很多，这也是有很多开源软件的原因，仁者见仁智者见智，EOS既然试图解决JAVA的应用架构，就不可避免的要有自己的理念，这些理念未必大家都认同，这也是我过去比较头疼的问题，也是开发者争议比较多的问题。不像工作流，大家对他的认识和定位比较清晰，比拼的是功能和性能，普元的工作流性能非常强，功能上对外接口特别丰富（真的不是自卖自夸），所以得到很多认同。

3. EOS中争议最大的是拖拽式开发业务逻辑（也就是说的可视化开发），其实拖拽式开发大家并不反对，例如拖拽式进行数据建模，但拖拽开发业务逻辑就未必是好事了。我们设计时即可以用拖拽式开发，也可以用spring bean的方式写代码开发业务逻辑。图形化（拖拽式）开发业务逻辑，最大的用处是处理异步的逻辑，例如调用一个 WebServices，同步调用时如果被调用方很慢，当前的线程也会被挂死，异步就没有这个问题，至少还能够超时释放（这里比较复杂，就不细说了），但是异步的代码写起来很复杂，要写成回调方式，这样代码的可读性就非常差（试想用回调方式调用 3 个 WebServices的代码结构），这样用图形化就比较简单，执行时会变成异步的。

4. 使用 EOS 时，最好根据自己的情况制定规范，因为 EOS 在做产品的过程中要考虑很多情况，但在企业中面临的问题就固定一些，例如不喜欢拖拽式开发业务逻辑可以不用，不要因为普元的培训时讲了这个方式就一定使用，也可以和普元的工程师探讨一下。使用一个框架的时候，技术团队可以多从设计原理、架构、面临问题的角度考虑一下框架的设计初衷，提高对技术的掌握。我的很多合作伙伴（例如工行、建行）他们都深入的掌握了 EOS，并和他们自己的实际结合了起来，变成了他们自己的框架，这一过程中他们的技术也有了很大的提高。

5. 做为设计者，EOS是一个在设计过程中让我们很纠结的产品，主要原因是他试图解决的问题比较复杂，也很广泛，而对于这一问题的解决方案又有很多种，尤其是有很多开源软件，无法穷举。在普元后续产品的设计中，我们吸取了这一经验，把要解决的问题更加聚焦起来。

6. 普元未来还是解决我们在大中型企业信息化的技术架构问题，但设计思路上更加聚焦。在 EOS、流程 之后，又有了 ESB、数据集成、数据质量、IaaS 等产品，目前的数据集成产品，是基于最流行的开源软件 Kettle，但是我们的重点是解决 Kettle 没有解决的调度问题（例如每晚有成千上万个作业，作业之间可能有先后持续，作业失败了怎么办，如何监控等）；目前的 IaaS 产品基于OpenStack，但是我们解决了 OpenStack 在企业私有云下的管理体系问题（例如小网段、心跳检测、高可用组件自身的高可用、多维度管理）。数据治理产品重点解决数据集成后，数据的血统分析和影响度分析，形成数据地图。