这是一个创建于 1880 天前的主题，其中的信息可能已经有所发展或是发生改变。
主要业务比较简单 面向全体的有活动报名、活动日历和活动跟进 面向组织的有活动登记、活动发布、活动认证和总结、导入导出名单 面向管理员的有查看修改各种实体、导入导出名单
感觉体量小，压力不高，上微服务成本不划算， 但是又考虑到后续可能会有拓展业务和接入其他系统的需求，直接一步到位微服务可以减轻将来也许会有的需求
现在不知道怎么抉择，大家怎么看
第 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:04 +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