search

turms-im / turms

🕊️ The world's most advanced open source instant messaging engine for 100K~10M concurrent users https://turms-im.github.io/docs
Apache License 2.0
1.72k stars 266 forks source link

Support implementing config management and service discovery via k8s #760

Open JamesChenX opened 3 years ago

JamesChenX commented 3 years ago

btw: we don't recommend using k8s (cloud service) for turms servers, because turms servers are lightweight and can work with other cloud service portfolios (e.g. auto-scaling instances, monitoring/logging service) pretty well. k8s should only be used if our users (will) have already a complex system and they want to introduce turms servers into it.

itmagus commented 1 year ago

@JamesChenX 如果要把turms-im做为云原生微服务体系的一部分，感觉所述（只有当我们的用户（将）已经有一个复杂的系统并且他们想在其中引入 turms 服务器时，才应该使用 k8s），是有必要的。 我刚接触turms-im不久，理解还不太深刻，有一点使用感触，不一定正确哈。

  1. 像我们的开发环境，是基于k8s的gitops的方式，不是所有的服务都跑在本地，如果需要在turms-im做一些个性化怎么快速的提交代码，打镜像和发布？
  2. 关于镜像的打包，使用的是dockerfile,感觉打包的时间还是比较长，如果使用Buildpacks的话，是不是会好一些？springboot本身应该也是支持的。
  3. turms-im采用插件的方式，去进行扩展，感觉比较好，同时也需要与其它的服务去交互。 比如实现一个对话式AI应用场景，可能需要与RASA或应用的服务去交互 这个时候，如果是在同一微服务的体系下，交互起来应该更方便，然微服务的体系太多，云原生的服务治理，会是个比较好的选择吗？
  4. 看作者提到rosket又弃用了,是因为不适合IM的应用场景吗？ 看了turms-im文档的内容，定位是中大型的应用场景，把性能放到了首位，边界也规划的十分清楚，涉及的知识点也是非常的多，感谢作者的付出，深表敬佩。目前还只做了，打包和部署的工作，后续随着应用的深入，再请教
JamesChenX commented 1 year ago

Thanks for your advice.

  1. Forking turms project into your repository hosting service, and managing it like your own service should be good enough.

    • Just remember to pull the code frequently because turms add features, enhancements, fixes frequently as you may have noticed.

    • PR is welcome, so if you think the PR implementing a common feature/enhancement/fix or whatever, you can commit a PR so that I can maintain the related features to work fine with it in the later updates, and ensure there are no break changes for your changes.

  2. It's slow currently because it uses QEMU to build images for linux/arm64 as you can see in .github/workflows/publish-turms-service.yml. So if you don't need the images for linux/arm64, you can build images: turms-gateway: DOCKER_BUILDKIT=1 docker build --rm=false -t "ghcr.io/turms-im/turms-gateway:latest" -f turms-gateway/Dockerfile . turms-gateway: DOCKER_BUILDKIT=1 docker build --rm=false -t "ghcr.io/turms-im/turms-service:latest" -f turms-service/Dockerfile . You can try them, and they will be far faster than your current builds.

And turms is removing spring gradually, so we don't want to be stuck in the spring-related dependencies, and there are no good reasons to use Buildpacks currently.

  1. It's a good enhancement for turms to work for K8S, and I want to adapt turms for K8S, but I don't have the effort for it and there is no plan for the adaption in the v1.0.0 release.

  2. Removing RSocket because it's useless for turms. It makes workflow abstract and complex and brings useless overhead (turms never need these Reactive Streams semantics) as described in https://rsocket.io/about/protocol. So there is no reason to use RSocket.

itmagus commented 1 year ago

感谢解答