主要业务比较简单 面向全体的有活动报名、活动日历和活动跟进 面向组织的有活动登记、活动发布、活动认证和总结、导入导出名单 面向管理员的有查看修改各种实体、导入导出名单
感觉体量小,压力不高,上微服务成本不划算, 但是又考虑到后续可能会有拓展业务和接入其他系统的需求,直接一步到位微服务可以减轻将来也许会有的需求
现在不知道怎么抉择,大家怎么看
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
快速开发,不需要; 慢慢来 吹技术,可以。
|