有人用過普元eos的嗎？

從EOS平臺使用者的角度，不客氣的說，EOS在Eclipse方面的應用在國內是領先的，有朋友曾經通過研究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，同步調用時如果被調用方很慢，當前的線程也會被掛死，異步就沒有這個問題，至少還能夠超時釋放（這里比較復雜，就不細說了），但是異步的代碼寫起來很復雜，要寫成回調方式，這樣代碼的可讀性就非常差（試想用回調方式調用 3 個 WebServices的代碼結構），這樣用圖形化就比較簡單，執行時會變成異步的。4. 使用 EOS 時，最好根據自己的情況制定規范，因為 EOS 在做產品的過程中要考慮很多情況，但在企業中面臨的問題就固定一些，例如不喜歡拖拽式開發業務邏輯可以不用，不要因為普元的培訓時講了這個方式就一定使用，也可以和普元的工程師探討一下。使用一個框架的時候，技術團隊可以多從設計原理、架構、面臨問題的角度考慮一下框架的設計初衷，提高對技術的掌握。我的很多合作伙伴（例如工行、建行）他們都深入的掌握了 EOS，并和他們自己的實際結合了起來，變成了他們自己的框架，這一過程中他們的技術也有了很大的提高。5. 做為設計者，EOS是一個在設計過程中讓我們很糾結的產品，主要原因是他試圖解決的問題比較復雜，也很廣泛，而對于這一問題的解決方案又有很多種，尤其是有很多開源軟件，無法窮舉。在普元后續產品的設計中，我們吸取了這一經驗，把要解決的問題更加聚焦起來。6. 普元未來還是解決我們在大中型企業信息化的技術架構問題，但設計思路上更加聚焦。在 EOS、流程 之后，又有了 ESB、數據集成、數據質量、IaaS 等產品，目前的數據集成產品，是基于最流行的開源軟件 Kettle，但是我們的重點是解決 Kettle 沒有解決的調度問題（例如每晚有成千上萬個作業，作業之間可能有先后持續，作業失敗了怎么辦，如何監控等）；目前的 IaaS 產品基于OpenStack，但是我們解決了 OpenStack 在企業私有云下的管理體系問題（例如小網段、心跳檢測、高可用組件自身的高可用、多維度管理）。數據治理產品重點解決數據集成后，數據的血統分析和影響度分析，形成數據地圖。