Golang Go语言中开发学校内部使用的平台 该上微服务吗
Golang Go语言中开发学校内部使用的平台 该上微服务吗
主要业务比较简单 面向全体的有活动报名、活动日历和活动跟进 面向组织的有活动登记、活动发布、活动认证和总结、导入导出名单 面向管理员的有查看修改各种实体、导入导出名单
感觉体量小，压力不高，上微服务成本不划算， 但是又考虑到后续可能会有拓展业务和接入其他系统的需求，直接一步到位微服务可以减轻将来也许会有的需求
现在不知道怎么抉择，大家怎么看
那不上 java，你这个噶奥不好得有工作流
更多关于Golang Go语言中开发学校内部使用的平台 该上微服务吗的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
目测压力不会大，可以使用单应用的微服务项目：
https://github.com/Wizzercn/NutzWk/tree/v5.x-mini
或者想搞分布式复杂点，可以用分布式版本（主分支）：
https://github.com/Wizzercn/NutzWk
我觉得这个问题其实很简单，考虑到后期需求扩展，肯定是能上微服务就上的。如果项目微服务化了，主要对服务器资源的消耗在哪里，比如 java 项目，内存肯定是主要原因，那么就做一个简单的压测，目前服务器资源能承载多大的业务量，如果可以接受就做，如果不行那就再考虑。
微服务只是部署层面的拆分，代码层面一样可以做到逻辑的解耦和规划，可以了解一下 DDD
微服务原本是为了组织结构为研发带来的壁垒，推荐可以了解一下康威定律，就会更深刻的理解微服务解决的本质问题是团队分工
[和业务体量、业务复杂度的关系其实没有大多数人想的那么大，只是微服务顺手解决了这些问题而已]
楼上大多数人对微服务几乎只有 [术] 上的了解，对其 [道] 毫无所知
微服务的研发成本、部署成本、维护成本都是显著上升的，正如我们知道的”世界上没有完美的架构“，所以微服务是带来了一些问题，从而解决了一些问题
所以！
总结一下！
你的希望是自己的服务可扩展性和可维护性，你还记得大学课本里面说啥了没？
高内聚，低耦合
微服务只是在部署维度尝试做了这些事
那么微服务高内聚的是什么？是业务
微服务低耦合的又是什么？组织结构和团队
而你的关注点在哪儿？在代码本身，那么这个维度怎么解决呢？就是代码的纵向和横向的设计与拆分，可以好好参考一下 DDD，可以直接用其作为你的战术也可以简单参考一下，anyway，做一下你的领域设计，设计出一个可以运行好多年的架构出来吧。
加油。
决定单体了
发现自己确实存在不少误解，其实一开始把微服务当成选项之一就是为了解耦。了解了一下 DDD，确实是一个很好的参考，多谢多谢
哈哈其实一是为了积累经验二是减少以后系统增加业务的复杂度，三是赶时髦吧（捂脸
因为最近很火的亚子，devops 其实只入了个门玩过 jenkins，微服务还没碰过，还是蛮想尝试一下的
结合实际，很有道理，我选型的思路过于理想化了
单体就够，解耦还是看架构业务领域设计，遇到瓶颈再解决。自己首先对项目有个期望，现在的架构设计是否跟的上未来的业务发展速度，若两年内都不会有很大的发展就没必要上微服务。我的理解技术永远是服务于业务的，只有业务上的发展才能带动技术上的突破。
针对“Golang Go语言中开发学校内部使用的平台，该上微服务吗”这一问题，作为IT领域Go语言方面的专家，我认为可以从以下几点进行考量：
- 服务拆分与独立性：学校内部平台若功能复杂，可以拆分为多个独立服务，如用户管理、课程管理、成绩管理等。Go语言适合构建微服务，其轻量级协程和并发支持能高效处理这些服务。
- 可扩展性与可维护性：微服务架构提供更高的可扩展性和可维护性。每个服务可以独立部署、扩展和维护，降低系统整体的复杂度和风险。
- 技术栈与工具支持：Go语言有丰富的框架和工具支持微服务，如Go-kit、gRPC等。同时，容器化技术如Docker和Kubernetes也支持Go语言，便于部署和管理微服务。
- 实际需求与资源：需考虑学校内部平台的实际需求、团队的技术能力和资源情况。若团队熟悉微服务架构并具备相应的技术能力，上微服务是合理的选择。
综上所述，若学校内部平台功能复杂且团队具备相应技术能力，使用Go语言开发并采用微服务架构是可行的，能带来诸多优势。但具体决策还需结合实际情况进行权衡。
