• R语言
  • shiny最大同时用户只有20?

yufree

原来如此。看来R本来就不是用来干后端的料,shiny这算是横练武功。单线程还得排队这个限制太大了。放弃shiny专心钻研golang吧。

如果真要解决高并发的问题的话可以尝试上 ShinyProxy + Kubernetes ,比较复杂但是也不是做不到。
可以参考:基于 Amazon EKS 快速构建企业级 Shiny 平台

http://covid-2019.live/ 的后端是我前辈帮忙处理的,引用他的话是按下述方法来处理并发的:

Shiny-server的免费版存在性能瓶颈。
无论你部署多少硬件资源,到一定程度之后程序就跑不动了。
covid-2019.live 为了解决免费版的性能瓶颈问题,建立了多个Worker组成的集群。
将事先制作的Shiny-server的Docker镜像,部署到多台虚拟机中,搭建Worker。
用户访问网站时,走出CDN之后首先会来到基于 Nginx(Kong) 的Gateway服务器上,
Gateway会根据预先设置好的负载均衡参数,将流量转发到Worker,由Worker负责处理计算,页面渲染等处理。
这样既规避了免费版的性能瓶颈,又能在突发大流量到来时,一定程度上实现横向扩展。

但是如果再给我一次机会的话,我可能不会再选择Shiny来做有高并发场景的应用了😅

    InfinityLoop 这相当于用并行主机构架来替代原来 shiny server pro 里R的多线程了,丐版shiny server 只允许一个R线程就并行虚拟机开多个shiny server然后用负载来处理流量,也是个用工程来解决工具缺陷的思路。不过也是因为后台是R,低访问量时很多前后端繁琐配置都被 shiny 接管了,适合探索分析,要是换其他方案,开发上可能不会像 shiny 这么方便直观。

    开源的解决方案一般是先容器化放到 ShinyProxy 运行,再用 Kubernetes 或者 Docker Swarm 做编排。这是一条十分可行的路径,目前比较成熟的方案也基本都是类似的。缺点是要把整个流程调通需要一定的 DevOps 经验,而这些东西可能并不是 statistician 应该或者想花时间关心的。

    我觉得 statistician 应该重点关注如何写出确实需要高并发支持的爆款 app,到时这些运维问题自然可以寻求资源解决。

      nan.xiao

      这些运维问题自然可以寻求资源解决

      那就回到重复造轮子的老路了:R或者python写个原型然后又用其他语言重写一遍…

        tctcab 实践过后我也比较赞成这条路子,用Shiny快速迭代原型然后交给专业人员换种语言和架构开发稳健型的产品。

        我不了解我们 Shiny 这边的产品,不过可能也没有楼上说的这么糟糕。如 yufree 所说,Shiny Server 要被 RStudio Connect 取代了,可能免费版是有些限制,毕竟这种支持大规模用户访问的需求通常在商业应用中更常见一些。新冠期间不少疫情展示的应用都是用 Shiny 做的,比如:https://blog.rstudio.com/2020/11/19/using-shiny-in-production-to-monitor-covid-19/ 我不清楚技术细节,但支持成千上万用户同时访问应该是可以做到的,并不是一个硬性的瓶颈。

        chuxinyuan shiny定位就是个快速原型,产品经理拿这个做演示用的。

        这样的话 R 用户应该不陌生了,诸如:

        1. R 不支持大数据;
        2. R 不适合用户生产环境;

        然后现在好像可以加上一句 Shiny 只能做原型和单人演示。能与不能,都是一句话能下定论的。去年 Shiny 的主要开发者 Joe Cheng 专门就这个主题做过一场报告:https://rstudio.com/resources/rstudioconf-2019/shiny-in-production-principles-practices-and-tools/

        重申我不了解 Shiny 相关的产品,所以更大概率你们是对的。

        虽然可能有点偏题了,R/Shiny 能用在生产环境中,不过根据我的一些浅薄的意见,就是不是很建议。Shiny 的开发者远远不够传统专门做开发的人员多,要打造一个能够用 Shiny 来搞生产的团队难度远远要比组件一支用 Java 或者基于 JavaScript 的开发团队要高很多,一旦主要开发人员离职又找不到人的话很容易造成整个项目拉胯。

        另外就是如果要搞到商业化的程度,License 或者其他的费用相比对中小型公司来说负担还是有点大。对他们来说可能选择GCP 或者 AWS + 常用框架更具有可操作性(人也好招)。

        再一个就是如果运维都上到用 Kubernetes 程度了,可能用别的原生就支持高并发的框架的话都不需要这么复杂的运维就能搞定了,就感觉有点发力点没用对。

        以上只是我个人学而不深的一些浅薄意见,Shiny 适合非专业开发人士来快速做出能用的产品,但是大规模应用的话还是有一定的顾虑所在的。所以我觉得这可能也是很少在需要高频度使用的 2C 产品上看到 Shiny 身影的原因吧。

          InfinityLoop 嗯,如果说从招人的角度来说的话,那的确是一个很实在的顾虑,这我完全同意和理解。没办法,小众语言只能是这样苟延残喘的命运,要活下来确实得多发几倍的力。

          Cloud2016 就等你当产品经理然后第一个吃螃蟹了。