V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  heqingpan  ›  全部回复第 1 页 / 共 5 页
回复总数  84
1  2  3  4  5  
9 天前
回复了 iamtuzi3333 创建的主题 Vue.js 哭了,前端真的太难受了。
如果想掌握,个人建议静下心来,单独练习 html+css 。
万变不离其宗,练习时只用写 html 和 css 文件,不需要用现代工程避免被其干扰精力。

找个 css 系列教程或一本书,基本只要练习几个常见的布局(用 flex ),最后模仿一两个网站的页面(尽量 1 比 1 复刻)就差不多可以掌握。后面写页面时,就算有遗漏你也知道该用什么方式,搜索一下就能解决。

我基本都写后端,很多前集中学一小段时间,配合熟悉 js ,之后用什么前端框架基本都很好上手(写功能没问题,就是规范化可能不太好)。
@EliStone
我目前也有 99 元的服务跑 r-nacos ,没有压力。

它虽然在 java 用的比较多,不过也支持多语言,有用到配置中心的话也可以试试。
@fzdwx
@Cloud9527

感谢反馈😁

目前的用户中较多是用于开发、测试环境,用于生产环境相对少一些。

这个情况也可以理解

1. 刚开始,使用肯定是在测试环境使用
2. 使用一段时间后,就算觉得应该比较可靠,不过线上跑的好好的也不太敢轻易动,或者自己开发环境可以自主决定,线上环境不归自己管,所以线上照旧。
3. 剩下的是使用一段时间确认其稳定可靠,然后可以决定或影响线上版本,才能进行切换。

第 3 种线上使用的数量会少一些,正因为如此,更希望有在线上使用的反馈(也相信它会越来越多)。


当然开发、测试环境使用也是非常欢迎的,毕竟它是用户可能会使用的第一步,同时它一样能发现产品的问题,推进产品的发展。
@cksspk
@visper

感谢来自第一批用户的反馈😁
@putyy 感谢
@longzhx 好建议,我后面抽空补一份对比表。
@southsala 感谢支持😃
star+1
@gitxuzan 感谢支持,过程有什么问题或建议可以找我或者到 github 提 issue 。
哈哈,原因就这么被找到了😎
推荐 r-nacos (原名 rnacos),用 rust 重新实现的 nacos 配置注册服务。

特点:
* 自带 web 控制台管理,有登陆校验,支持暴露到外网使用。
* 运行占用内存小,接近 5 千个配置,450 个服务实例,服务使用的内存在 15M 左右。
* 应用文件小,应用 20M ,docker 30M 。
* 支持 http 协议(nacos open api)访问,同时 nacos 生态不同语言的 sdk 都支持。
* 高性能,配置写入 1.7 万 tps ,配置查询 8 万+qps 。
* 部署简单,不依赖外部数据库,启动应用即可使用。
我个主要当做网盘用于备份照片和文件。

其它的都是一时兴起的折腾,用电脑玩玩就好。
189 天前
回复了 panlatent 创建的主题 分享创造 来推荐推荐自己的开源项目和经验吧
[r-nacos]( https://github.com/nacos-group/r-nacos) 一个基于 rust 重新实现的 nacos 配置注册服务。(star: 692, docker 下载量: 25k+)

相较于 java nacos server 来说,是一个提供相同功能,启动更快、占用系统资源更小(接入接近 5 千个配置,450 个服务实例,服务使用的内存在 15M 左右)、性能更高、运行更稳定的服务。

其设计上完全兼容最新版本 nacos 面向 client sdk 的协议支持使用 nacos 服务的应用不用修改代码直接平迁到 r-nacos 。

经验:
1. 用 rust 重写原 java 写的常用中间件,一般占用系统资源更小、性能更高;完成度比较高的话还是有很多人愿意使用。
2. 作者最好也是开源项目的用户,最开始当做满足自己的需求。当你能比较好的满足自己的需求,也会同时满足同类场景的用户。
3. 项目的第一版核心功能基本需要自己独立开发,要做好心理准备。
csdn 页面乱七八糟,个人是坚决不用。
210 天前
回复了 kerb15 创建的主题 程序员 公网部署 Nacos 被入侵了...
@kerb15 如果只是通过公网下发配置,那换 r-nacos 应该能满足你的场景。

部署 r-nacos 后只暴露独立的控制台网络端口到外网,用于下发配置。
sdk 网络端口只给内网应用使用,不要对外网暴露保证安全。
211 天前
回复了 kerb15 创建的主题 程序员 公网部署 Nacos 被入侵了...
OP 暴露 nacos 到外网的目的是什么?

如果只是想用控制台做运维,可以试试用 r-nacos (用 rust 重新实现的兼容服务)。

r-nacos 的控制台支持对外网暴露。
控制台使用独立端口号,然后对这个端口号所有请求加上登录与鉴权验证。
控制台登陆接口内置错误频次限制与验证码,避免对账户的暴力遍历破解。
@Felldeadbird
除非没人用,不然都忙。

成品前忙开发,成品后忙写文档、推广给潜在用户。
亲身实践过,如果不依赖三方库从 0 开始写,一般 AP 会比 CP 简单些。

不过 CP raft 一般都有库(与业务无关的基础部分),而 AP 没有( AP 一般和业务相关较大,没有通用库)。

CP 基于库做二次开发与 AP 从 0 开发相比,工作量会差不多。(和具体业务有关)

我之前在写 r-nacos (用 rust 重新实现 nacos )时,有分别用 CP(基于 raft 库)实现配置中心,用 AP (从 0 开发)实现注册中心。
它们两块整体工作量上感觉差不多。

附上去年在本站发的相关帖子: https://v2ex.com/t/974680
@pckillers
我上面说的动态感知配置变更,是通过配置中心 client 监听配置中心内容实现的,是不是监听本地配置文件。

k8s 就算能更新 pod 的配置文件,如果想不重启更新配置,还应要应用主动监听配置文件内容是否有变化。(相当于自己实现动态配置功能)

通过动态配置做切流、回滚等流程控制很好用。

没有动态变更配置的能力,可能不会想去写这类控制代码;但系统支持这个能力,在写新的高风险链路逻辑时一般都会加上,在遇到问题能快速回切止损。

当你用上一次避免问题扩大代之后,你应该就不愿意放弃它。
1  2  3  4  5  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2712 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 30ms · UTC 08:20 · PVG 16:20 · LAX 00:20 · JFK 03:20
Developed with CodeLauncher
♥ Do have faith in what you're doing.