这是一个创建于 2873 天前的主题，其中的信息可能已经有所发展或是发生改变。
前几天看到 oschina 发布的 2017 年前 50 的项目，其中有一个整合了各种技术的项目（原话是：中小型企业打造全方位 J2EE 企业级开发解决方案），github 地址： https://github.com/shuzheng/zheng，v 友们怎么看这个项目，是不是大公司都是这样设计的？
 | 1 feverzsj 2018-01-26 12:02:06 +08:00  2 中小型企业吃饱了上分布式，这种架构一看就是卡到爆的 |
 | 2 RorschachZZZ 2018-01-26 12:05:51 +08:00 @feverzsj 厉害了。 |
 | 3 whypool 2018-01-26 12:08:00 +08:00 这跑起来成本太高了 |
 | 4 liuzuo 2018-01-26 12:12:26 +08:00 不知道对 docker 支持如何。 |
 | 5 tamlok 2018-01-26 12:13:15 +08:00 via Android 挣钱的 zheng ？ |
 | 6 dan2001go 2018-01-26 12:23:34 +08:00 via Android 之前我的一家公司也是这么玩呢，微服务 RPC 一整套的架构方案。定位给中小企业，提供技术服务什么的。其实有多实用不太清楚，但是这个概念是新的，就是老的项目没搞头了，换个新的说法。有些没什么技术的老板或公司可能吃这一套，以为是很牛逼的东西，方便圈点钱。 |
 | 7 stanjia 2018-01-26 12:29:34 +08:00 架构方案 之后升级版本是不是还要重新买授权呀 |
 | 8 yulitian888 2018-01-26 12:31:42 +08:00 答复楼主，这种结构很正常（虽然我不是做 java 的） to #1 卡到爆，你确定？这种设计不是可以很轻松地增加服务器的数量，对不？举例：业务旺季（如，双 11 ）期间多加两倍的云主机进去好像很合理，对吧 to #3 和上面说的刚好相反，接上述示例，淡季减少服务器数量即可省钱。另外，抠门的话全都堆在一台服务器上似乎没什么不妥。 |
 | 9 p2pCoder 2018-01-26 12:32:29 +08:00 在一家前十 P2P 的大数据部门，项目架构和这种类似 |
| 10 yulitian888 2018-01-26 12:33:17 +08:00 接楼上 #8 楼我自己，勘误 这种设计 [是不是] 可以很轻松地增加服务器的 [数量？对吧！] |
 | 11 HuHui 2018-01-26 12:34:11 +08:00 大一点的见过的，一方面整合第三方框架，一方面自己结合 eclipse 自己做插件，形成自己的一套平台。大多数都带有代码生成器之类的。最早接触过的金蝶的还结合自己的业务制定了一套自己的规范、概念（比如元数据）。 以前还挺鄙视这种做法的，等到了小公司才发现大多数小公司做的也就是技术拼凑而已，很难形成一个平台 /体系。 |
 | 12 l00t 2018-01-26 12:36:23 +08:00 @yulitian888 要不要跑跑看，看一个最小实例能塞在一个机器上不？ |
 | 13 learnshare 2018-01-26 12:37:20 +08:00 我全部都要？ |
 | 14 wizardforcel 2018-01-26 12:37:36 +08:00 via Android 有些人就是想不通，优化来优化去，不如直接加服务器。 |
 | 15 yanw 2018-01-26 12:40:48 +08:00 粗略看，我们公司也是差不多这个架构 |
 | 16 woodface2233 2018-01-26 12:42:45 +08:00 via iPhone 看不到了啊 |
| 17 yulitian888 2018-01-26 12:46:36 +08:00 @l00t 最小环境搭建的话，那不就是一台开发环境吗？莫非 java 项目有什么与众不同的问题？我手里有个规格比这个大一倍以上的玩意（不过不是 java 做的）在一台服务器上跑的好好的，哦，实际上还不是一台物理服务器，只是 Dell 服务器里的一个虚拟机上跑，并没用到整机。和这个项目不同，大量中间件、组件、服务用的是商业平台，而不是开源的，数据库是 sql 2012，消息队列是微软 MSMQ，缓存是 memcached、RavenDB |
 | 18 bramblex 2018-01-26 12:50:40 +08:00 4 看到 “企业级” + “中小企业” 四个字，就要明确这公司的目标群体是传统行业的小老板。 所以说白了就是蒙外行人的，就跟去电脑城买电脑一样，用不用有没意义再说，反正是“顶配”。 |
 | 19 Mogugugugu 2018-01-26 15:10:21 +08:00 我们都是全都堆在一台服务器上的话，没这么复杂，但是服务也不少 0 0 另外，这种基本都是练技术 + 快速开发，特适合外包，拉过来 改一下就能用的 。。。 |
 | 20 buliugu 2018-01-26 15:20:59 +08:00 楼主你看看 spring cloud 是不是也差不多（逃 |
 | 21 wangfengqi2010 2018-01-26 15:51:16 +08:00 技术好多啊 |
 | 22 TuringGooner 2018-01-26 16:12:31 +08:00 2 我感觉这个项目就是拿来练手然后收不住了 |
 | 23 zpf124 2018-01-26 16:16:09 +08:00 |
 | 24 calming 2018-01-26 17:23:50 +08:00 起码这样解耦了啊，代码写起来给劲儿，现在公司这老项目 200 大几十张表，上百个 module，看的人要死 |
 | 25 c4fun 2018-01-26 17:41:59 +08:00 好多传统企业，在搞互联网转型的时候都是这么玩的，架构也是这个。 |
 | 26 xuminzhong 2018-01-26 17:43:49 +08:00 粗略看了下，这样的架构，根本跑不了大数据（大的数据量），很多环节会出现瓶颈。 应对数据量小但业务复杂也许可以，但也没必要堆砌这么多技术，一般新手难以上手，老手也不好掌握。 一楼 @feverzsj 说的是对的。 以后遇到「企业级」 3 个字，都可以简单理解为卡、慢。 |
 | 27 Amayadream 2018-01-26 17:48:02 +08:00 码云的首页基本全是这种, 恨不能把所有技术都塞到一个项目里, 反正没明白想解决什么问题, 只能理解为练手的 demo 合集了 |
 | 28 winglight2016 2018-01-26 17:49:57 +08:00 微服务架构仅仅适合业务复杂度达到一定程度和规模的公司，恰恰不是面向中小企业的 |
 | 29 CtrlSpace 2018-01-26 17:52:08 +08:00 我刚转型做 Java Web 的时候，看过很多类似的快速开发项目，如 zheng / iBase4J / hsweb / renren-fast / jeeSite 之类的，都是以 Spring 为核心整合起来的。 可以说学到不少套路吧。 但是，项目规模不一样，架构也很不一样，代码组织方式也很不一样。 感觉一两个人的话，水平一般的情况下，复杂的东西还是很难掌控的。 我也很好奇大公司大项目是怎么架构和组织的，楼下有大神分享吗？ |
 | 30 iRiven 2018-01-26 21:43:16 +08:00 我也感觉卡到爆 |
 | 31 swulling 2018-01-26 22:28:54 +08:00 这才几个模块。。就说什么卡到爆什么的 这么说吧，某厂的广告系统，全厂没有一个人能够把它给完整的了解的，哪怕是所谓的架构师、首席科学家等。 什么叫复杂，当你维护着一个年入百亿的系统，你敢随便动动试试？ |
 | 32 wdlth 2018-01-26 22:33:45 +08:00 看上去不同模块是不同的人搞的，然后拼凑到一起，有的用模板引擎有的又用 JSP …… |
 | 33 Doodlister 2018-01-26 22:40:04 +08:00 via Android @wdlth 模板引擎 一是为了 做代码生成器。 二是为了动静分离吧。 |
 | 34 FinalDream 2018-01-27 00:11:54 +08:00 说卡到爆的说说卡到爆的原因呗 |
 | 35 abcbuzhiming 2018-01-27 00:23:51 +08:00 @yulitian888 其实我一直没搞懂这种微服务架构的一个核心问题，比如楼主这个，用了 mysql，应用层是可以很方便的扩充服务器，但是 mysql 这个数据持久层怎么办，最后的压力还是会到数据库这来，某些强一致性事务靠缓存是不行的 |
| 36 abcbuzhiming 2018-01-27 00:30:00 +08:00 @FinalDream 它的拓扑图里有关系数据库，但是却没有回答在应用层玩分布式后，最后数据如何在 mysql 达到一致的问题，除非应用场景不需要强一致，并且 mysql 里的数据关系结构很松散类似 KV，否则瓶颈就在这 |
| 37 yulitian888 2018-01-27 08:23:21 +08:00 @abcbuzhiming 在有多层的架构下，每一层都是可以单独做缓存的，每一层也都可以单独做数据持久化。比如我们的一个项目，在消息队列持久化的地方用了 ravenDB，在 UI 层用了 mongoDB，当然在数据访问层必然也是有缓存的，所以 sql 的压力并不一定会大到不可接受的程度。另外，sql 服务器是要做群集、镜像的，读写分离妥妥的好吧（注：我们不是用 java 写的）。至于强一致性吧，sql server 是可以支持 [跨库事务] 的啊，没觉得有什么问题，mysql 不熟，应该有类似的功能吧？ |
 | 38 panpanpan 2018-01-27 08:32:33 +08:00 via iPhone 框架感觉太重了，不过做外包的时候拿一些模块来参考一下比较合适。 |
 | 39 karting 2018-01-27 09:42:44 +08:00 适合的就是最好的 |
 | 40 uleh 2018-01-27 10:48:10 +08:00 这种项目说白了就是“模板” 直接下载到本地就可以跑，稍微改改就能用 加功能也简单，找几个刚毕业的或者培训班出来的就能上手 |
 | 41 hantsy 2018-01-27 12:09:34 +08:00 1 业务上功能挺多。 但看了其中几个子模块的源代码，技术上都很常见，代码写法比较僵化（各模块中的组织结构就如同工具生成的一样）。完全是面向数据的设计，没任何地方体现 OOP 概念，没有体现软件设计概念的东西比如（ DDD，SOLID ），虽然是用 Java 写的。Spring API 调用仅用到一些常用的，基本上没用到 Spring 4 以后的一些新功能。 至于现在中小企业，大公司是不是吃这一套，我不大清楚。如果是我参与的项目，绝对不允许用这样的东西，代码完全是从业务角度堆出来。 单从技术上对于我而言，没研究价值。对于一些基础的 scaffold 项目，我基本不考虑它提供的业务功能，重要的是技术架构上考虑，基础技术的使用上是否合理，和工具支持，CI/CD 自动化上支持等。 但这种东西，就如 @uleh 所说， 对于一些公司，KPI 驱动的，连自己准备基础架构的能力有限的人可能有用，只要做出来的界面能忽悠老板就好了。 |
 | 42 guoyuchuan 2018-01-27 20:11:06 +08:00 不同境界的人看待的问题是不一样的，我这样的新手看的并不是他的架构，而是他项目里面的代码，看他用了什么技术，处理什么样的事情，怎么去处理；而我对 41 楼所说的什么“面向数据的设计，没任何地方体现 OOP 概念，没有体现软件设计概念的东西比如（ DDD，SOLID ），虽然是用 Java 写的。Spring API 调用仅用到一些常用的，基本上没用到 Spring 4 以后的一些新功能。”里面的好多东西都是只知道一点点，而且还停留于理论阶段，在项目中如何体现以及使用还知之甚少。看完所有的评论，还是学到了很多。 |
Select Language