大公司的项目都是这样玩的？我见识少，求指导！

[yanzishang]

前几天看到 oschina 发布的 2017 年前 50 的项目，其中有一个整合了各种技术的项目（原话是：中小型企业打造全方位 J2EE 企业级开发解决方案），github 地址： https://github.com/shuzheng/zheng，v 友们怎么看这个项目，是不是大公司都是这样设计的？

[feverzsj]

中小型企业吃饱了上分布式，这种架构一看就是卡到爆的

[RorschachZZZ]

@feverzsj 厉害了。

[whypool]

这跑起来成本太高了

[liuzuo]

不知道对 docker 支持如何。

[tamlok]

挣钱的 zheng ？😂

[dan2001go]

之前我的一家公司也是这么玩呢，微服务 RPC 一整套的架构方案。定位给中小企业，提供技术服务什么的。其实有多实用不太清楚，但是这个概念是新的，就是老的项目没搞头了，换个新的说法。有些没什么技术的老板或公司可能吃这一套，以为是很牛逼的东西，方便圈点钱。

[stanjia]

架构方案 之后升级版本是不是还要重新买授权呀

[yulitian888]

答复楼主，这种结构很正常（虽然我不是做 java 的）
to #1 卡到爆，你确定？这种设计不是可以很轻松地增加服务器的数量，对不？举例：业务旺季（如，双 11 ）期间多加两倍的云主机进去好像很合理，对吧
to #3 和上面说的刚好相反，接上述示例，淡季减少服务器数量即可省钱。另外，抠门的话全都堆在一台服务器上似乎没什么不妥。

[p2pCoder]

在一家前十 P2P 的大数据部门，项目架构和这种类似

[yulitian888]

接楼上 #8 楼我自己，勘误
这种设计 [是不是] 可以很轻松地增加服务器的 [数量？对吧！]

[HuHui]

大一点的见过的，一方面整合第三方框架，一方面自己结合 eclipse 自己做插件，形成自己的一套平台。大多数都带有代码生成器之类的。最早接触过的金蝶的还结合自己的业务制定了一套自己的规范、概念（比如元数据）。
以前还挺鄙视这种做法的，等到了小公司才发现大多数小公司做的也就是技术拼凑而已，很难形成一个平台 /体系。

[l00t]

@yulitian888 要不要跑跑看，看一个最小实例能塞在一个机器上不？

[learnshare]

我全部都要？

[wizardforcel]

有些人就是想不通，优化来优化去，不如直接加服务器。

[yanw]

粗略看，我们公司也是差不多这个架构

[woodface2233]

看不到了啊

[yulitian888]

@l00t 最小环境搭建的话，那不就是一台开发环境吗？莫非 java 项目有什么与众不同的问题？我手里有个规格比这个大一倍以上的玩意（不过不是 java 做的）在一台服务器上跑的好好的，哦，实际上还不是一台物理服务器，只是 Dell 服务器里的一个虚拟机上跑，并没用到整机。和这个项目不同，大量中间件、组件、服务用的是商业平台，而不是开源的，数据库是 sql 2012，消息队列是微软 MSMQ，缓存是 memcached、RavenDB

[bramblex]

看到 “企业级” + “中小企业” 四个字，就要明确这公司的目标群体是传统行业的小老板。

所以说白了就是蒙外行人的，就跟去电脑城买电脑一样，用不用有没意义再说，反正是“顶配”。

[Mogugugugu]

我们都是全都堆在一台服务器上的话，没这么复杂，但是服务也不少 0 0
另外，这种基本都是练技术 + 快速开发，特适合外包，拉过来 改一下就能用的 。。。

[buliugu]

楼主你看看 spring cloud 是不是也差不多（逃

[wangfengqi2010]

技术好多啊

[TuringGunner]

我感觉这个项目就是拿来练手然后收不住了

[zpf124]

@buliugu 感觉整个 spring 系列都越来越大了，spring 都出 5 了， 又新加了一堆各式各样的模块。

话说 spring 的依赖注入有别替代框架吗？

[calming]

起码这样解耦了啊，代码写起来给劲儿，现在公司这老项目 200 大几十张表，上百个 module，看的人要死

[c4fun]

好多传统企业，在搞互联网转型的时候都是这么玩的，架构也是这个。

[xuminzhong]

粗略看了下，这样的架构，根本跑不了大数据（大的数据量），很多环节会出现瓶颈。

应对数据量小但业务复杂也许可以，但也没必要堆砌这么多技术，一般新手难以上手，老手也不好掌握。

一楼 @feverzsj 说的是对的。

以后遇到「企业级」 3 个字，都可以简单理解为卡、慢。

[Amayadream]

码云的首页基本全是这种, 恨不能把所有技术都塞到一个项目里, 反正没明白想解决什么问题, 只能理解为练手的 demo 合集了

[winglight2016]

微服务架构仅仅适合业务复杂度达到一定程度和规模的公司，恰恰不是面向中小企业的

[CtrlSpace]

我刚转型做 Java Web 的时候，看过很多类似的快速开发项目，如
zheng / iBase4J / hsweb / renren-fast / jeeSite 之类的，都是以 Spring 为核心整合起来的。
可以说学到不少套路吧。

但是，项目规模不一样，架构也很不一样，代码组织方式也很不一样。
感觉一两个人的话，水平一般的情况下，复杂的东西还是很难掌控的。
我也很好奇大公司大项目是怎么架构和组织的，楼下有大神分享吗？

[iRiven]

我也感觉卡到爆

[swulling]

这才几个模块。。就说什么卡到爆什么的

这么说吧，某厂的广告系统，全厂没有一个人能够把它给完整的了解的，哪怕是所谓的架构师、首席科学家等。

什么叫复杂，当你维护着一个年入百亿的系统，你敢随便动动试试？

[wdlth]

看上去不同模块是不同的人搞的，然后拼凑到一起，有的用模板引擎有的又用 JSP ……

[Doodlister]

@wdlth 模板引擎 一是为了 做代码生成器。 二是为了动静分离吧。

[FinalDream]

说卡到爆的说说卡到爆的原因呗

[abcbuzhiming]

@yulitian888 其实我一直没搞懂这种微服务架构的一个核心问题，比如楼主这个，用了 mysql，应用层是可以很方便的扩充服务器，但是 mysql 这个数据持久层怎么办，最后的压力还是会到数据库这来，某些强一致性事务靠缓存是不行的

[abcbuzhiming]

@FinalDream 它的拓扑图里有关系数据库，但是却没有回答在应用层玩分布式后，最后数据如何在 mysql 达到一致的问题，除非应用场景不需要强一致，并且 mysql 里的数据关系结构很松散类似 KV，否则瓶颈就在这

[yulitian888]

@abcbuzhiming 在有多层的架构下，每一层都是可以单独做缓存的，每一层也都可以单独做数据持久化。比如我们的一个项目，在消息队列持久化的地方用了 ravenDB，在 UI 层用了 mongoDB，当然在数据访问层必然也是有缓存的，所以 sql 的压力并不一定会大到不可接受的程度。另外，sql 服务器是要做群集、镜像的，读写分离妥妥的好吧（注：我们不是用 java 写的）。至于强一致性吧，sql server 是可以支持 [跨库事务] 的啊，没觉得有什么问题，mysql 不熟，应该有类似的功能吧？

[panpanpan]

框架感觉太重了，不过做外包的时候拿一些模块来参考一下比较合适。

[karting]

适合的就是最好的

[uleh]

这种项目说白了就是“模板”
直接下载到本地就可以跑，稍微改改就能用
加功能也简单，找几个刚毕业的或者培训班出来的就能上手

[hantsy]

业务上功能挺多。

但看了其中几个子模块的源代码，技术上都很常见，代码写法比较僵化（各模块中的组织结构就如同工具生成的一样）。完全是面向数据的设计，没任何地方体现 OOP 概念，没有体现软件设计概念的东西比如（ DDD，SOLID ），虽然是用 Java 写的。Spring API 调用仅用到一些常用的，基本上没用到 Spring 4 以后的一些新功能。

至于现在中小企业，大公司是不是吃这一套，我不大清楚。如果是我参与的项目，绝对不允许用这样的东西，代码完全是从业务角度堆出来。

单从技术上对于我而言，没研究价值。对于一些基础的 scaffold 项目，我基本不考虑它提供的业务功能，重要的是技术架构上考虑，基础技术的使用上是否合理，和工具支持，CI/CD 自动化上支持等。

但这种东西，就如 @uleh 所说， 对于一些公司，KPI 驱动的，连自己准备基础架构的能力有限的人可能有用，只要做出来的界面能忽悠老板就好了。

[guoyuchuan]

不同境界的人看待的问题是不一样的，我这样的新手看的并不是他的架构，而是他项目里面的代码，看他用了什么技术，处理什么样的事情，怎么去处理；而我对 41 楼所说的什么“面向数据的设计，没任何地方体现 OOP 概念，没有体现软件设计概念的东西比如（ DDD，SOLID ），虽然是用 Java 写的。Spring API 调用仅用到一些常用的，基本上没用到 Spring 4 以后的一些新功能。”里面的好多东西都是只知道一点点，而且还停留于理论阶段，在项目中如何体现以及使用还知之甚少。看完所有的评论，还是学到了很多。

[buliugu]

@zpf124 play，虽然有点小众，但是无状态的设计十分赞