这是一个创建于 2226 天前的主题，其中的信息可能已经有所发展或是发生改变。
主要业务比较简单 面向全体的有活动报名、活动日历和活动跟进 面向组织的有活动登记、活动发布、活动认证和总结、导入导出名单 面向管理员的有查看修改各种实体、导入导出名单
感觉体量小，压力不高，上微服务成本不划算， 但是又考虑到后续可能会有拓展业务和接入其他系统的需求，直接一步到位微服务可以减轻将来也许会有的需求
现在不知道怎么抉择，大家怎么看
第 1 条附言 2019-10-07 19:05:45 +08:00
学校内部是指给学生和学生组织用的:D
 | 1 murmur 2019-10-07 17:54:30 +08:00 那不上 java，你这个噶奥不好得有工作流 |
 | 2 wizzer 2019-10-07 17:57:15 +08:00  2 目测压力不会大，可以使用单应用的微服务项目： https://github.com/Wizzercn/NutzWk/tree/v5.x-mini 或者想搞分布式复杂点，可以用分布式版本（主分支）： https://github.com/Wizzercn/NutzWk |
 | 3 coolair 2019-10-07 18:00:26 +08:00 via Android 没必要 |
 | 4 luob 2019-10-07 18:02:02 +08:00 25 面向工资开发：不需要 面向简历开发：能上就上 |
 | 5 imzcg 2019-10-07 18:45:36 +08:00 via Android 我认为学校的服务器资源不会太好，还是单体比较好 |
 | 6 Reficul 2019-10-07 18:51:4 +08:00 via Android activiti ？ |
 | 7 Leigg 2019-10-07 18:51:19 +08:00 via Android 4 楼道破真相 |
 | 8 shangyes OP @murmur 工作流倒不需要，java 有个问题就是开发周期相对当下流行的其他 web 语言长，学生兼顾学业和开发，拖长了项目会写的和**一样 |
| 10 shangyes OP @imzcg 哈哈哈哈哈哈哈哈恰恰相反，我们学校除了服务器和域名审批比较恶心，资源还是不错的，先前写了一个很简单的类慕课项目，申请了 4c8g 的服务器 |
 | 13 cabing 2019-10-07 19:14:13 +08:00 过于简单的系统做微服务有些过度设计。微服务维护起来会相对复杂。 看你描述的需求，单体完全满足，分好模块即可。。 |
 | 14 janxin 2019-10-07 19:17:05 +08:00 没必要... |
 | 15 inhzus 2019-10-07 19:36:55 +08:00 via Android 先上简单的微服务，慢慢扩展功能。一切都是面向简历开发 |
 | 16 animal 2019-10-07 19:50:45 +08:00 via iPhone 我觉得这个问题其实很简单，考虑到后期需求扩展，肯定是能上微服务就上的。如果项目微服务化了，主要对服务器资源的消耗在哪里，比如 java 项目，内存肯定是主要原因，那么就做一个简单的压测，目前服务器资源能承载多大的业务量，如果可以接受就做，如果不行那就再考虑。 |
| 17 imzcg 2019-10-07 19:52:34 +08:00 via Android 那么就 go 微服务来搞吧！满足你的一切需求 |
 | 18 lihongjie0209 2019-10-07 20:24:21 +08:00 没有微服务之前的所有应用都不能用吗？ 当你需要微服务的时候才需要微服务。 当你提出这个问题的时候就说明不需要 |
 | 19 shuangyeying 2019-10-07 20:52:37 +08:00 把选修课选课搞好一些大家就知足了。 |
 | 20 jackleelss123 2019-10-07 20:54:01 +08:00 @shangyes 看 4 楼，如果就是个外包项目的话，拿完钱赶紧撤，后期要改的话，加钱啊！如果不是，后期还要负责的话，不要给自己刨坑，多加点钱，上吧！ |
 | 21 helsonxiao 2019-10-07 21:27:13 +08:00 via Android 1 技术（微服务）的出现是为了解决某个（些）问题，我觉得可以联系整个应用的场景，分析下引入微服务是解决了问题，还是说只赶了时髦，单纯增加了程序开发和维护的复杂性？ |
 | 22 TheBestSivir 2019-10-07 21:31:26 +08:00 微服务只是部署层面的拆分，代码层面一样可以做到逻辑的解耦和规划，可以了解一下 DDD 微服务原本是为了组织结构为研发带来的壁垒，推荐可以了解一下康威定律，就会更深刻的理解微服务解决的本质问题是团队分工 [和业务体量、业务复杂度的关系其实没有大多数人想的那么大，只是微服务顺手解决了这些问题而已] 楼上大多数人对微服务几乎只有 [术] 上的了解，对其 [道] 毫无所知 微服务的研发成本、部署成本、维护成本都是显著上升的，正如我们知道的”世界上没有完美的架构“，所以微服务是带来了一些问题，从而解决了一些问题 所以！ 总结一下！ 你的希望是自己的服务可扩展性和可维护性，你还记得大学课本里面说啥了没？ 高内聚，低耦合 微服务只是在部署维度尝试做了这些事 那么微服务高内聚的是什么？是业务 微服务低耦合的又是什么？组织结构和团队 而你的关注点在哪儿？在代码本身，那么这个维度怎么解决呢？就是代码的纵向和横向的设计与拆分，可以好好参考一下 DDD，可以直接用其作为你的战术也可以简单参考一下，anyway，做一下你的领域设计，设计出一个可以运行好多年的架构出来吧。 加油。 |
 | 23 jugelizi 2019-10-07 21:32:51 +08:00 当然要上 尽管可能不是很有必要 却是一个方向 系统项目更加清晰 |
 | 24 wangyzj 2019-10-07 21:34:33 +08:00 工作上完全没必要，因为你要多投入一个人的成本 自己玩可以 同情被 devops 和微服务深深毒害的你 |
 | 25 zjsxwc 2019-10-07 21:39:10 +08:00 via Android 大学学生项目，额， 预算低还是算了吧， 难道是一台物理主机来开 N 个虚拟机来跑微服务集群？ 如果预算一个机房的话我觉得可以不然没必要。 |
| 26 TheBestSivir 2019-10-07 21:40:26 +08:00 @wizzer 单体的微服务项目，你是对微服务有什么误解么？一个 web 开发脚手架（框架？）怎么就和微服务框架扯上关系了，omg。 |
 | 27 charlie21 2019-10-07 22:00:29 +08:00 via iPhone 点破不说破，否则 ... 抹黑微服务？三分钟抬杠大军就在路上，就说你不懂微服务，扣帽子能扣死你 DDD 这种 玩意你既然提了那么最好解释一下 |
| 28 shangyes OP @cabing 决定单体了 @TheBestSivir 发现自己确实存在不少误解，其实一开始把微服务当成选项之一就是为了解耦。了解了一下 DDD，确实是一个很好的参考，多谢多谢 @helsonxiao 哈哈其实一是为了积累经验二是减少以后系统增加业务的复杂度，三是赶时髦吧（捂脸 @wangyzj 因为最近很火的亚子，devops 其实只入了个门玩过 jenkins，微服务还没碰过，还是蛮想尝试一下的 @zjsxwc 结合实际，很有道理，我选型的思路过于理想化了 |
| 29 shangyes OP 谢谢大家的建议 XDDD，决定老老实实单体 |
| 30 wizzer 2019-10-08 09:19:27 +08:00 @TheBestSivir 送你两个字，呵呵 |
 | 31 qwab16 2019-10-08 10:58:51 +08:00 单体就够，解耦还是看架构业务领域设计，遇到瓶颈再解决。自己首先对项目有个期望，现在的架构设计是否跟的上未来的业务发展速度，若两年内都不会有很大的发展就没必要上微服务。我的理解技术永远是服务于业务的，只有业务上的发展才能带动技术上的突破。 |
| 32 TheBestSivir 2019-10-08 11:06:48 +08:00 |
 | 33 hyperbin 2019-10-08 12:41:18 +08:00 via Android 过早的优化是万恶之源 |
 | 34 luozic 2019-10-08 13:13:09 +08:00 via iPhone 快速开发，不需要； 慢慢来 吹技术，可以。 |
Select Language